IASPs: What They Are and Why You Need Them on IBM i

Jake:    00:00:00    Hello everyone and welcome to today's web seminar, IASP, IFS, and disk analysis. Oh my. This web seminar is being produced by iPro Developer and is sponsored by Robot. If you have any technical difficulties during today's web seminar, please click on the help widget on your player console to receive assistance. And if at any time you're having audio difficulties or problems with advancing of the slides, simply hit your F5 key to refresh your webcast console. Also, please note today's web seminar will be available to view for 12 months. You will receive an email when that is ready to review.

Jake:    00:00:33    Now I would like to introduce today's presenters. Chuck Stupca worked for IBM in Rochester, Minnesota 43 and a half before retiring at the end of 2011. In his time at IBM, Chuck worked with high-availability solutions including independent disk pools. In his assignment he developed courseware that help customers implement independent disk pool solutions.
 

Jake:    00:00:56    Chuck Losinski is director of automation technology for the Robot product line. He has more than 25 years of experience with IBM i systems. Chuck's background includes system implementation, programming, operations, and support. He is certified as an IBM system administrator and has helped customers automate business applications. With that, Chuck Losinski, the floor is yours.
 

Chuck Losinski:    00:01:21    Hey, thanks, Jake. Really appreciate it. Good morning everyone, it's really a pleasure to share the stage again with my friend Chuck Stupca. It's going to be an interesting secession today. I want to set the stage a little bit before today's presentation. First what's going to happen is Chuck Stupca is going to be discussing the capabilities of independent auxiliary storage pools, or IASP. This technology isn't new technology. It's been around for probably a decade now, but it's really finding new life with the whole PowerHA world.
 

Chuck Losinski:    00:01:52    Then after Chuck introduces this technology to you, we're going to go live onto one of my systems and we're going to actually show you commands related to independent ASPs as far as configuring, enabling, and adding them into your jobs. Then we're going to finish up with some robot technology from help systems that analyzes what you have stored there in independent ASPs. Chuck, I'm going to turn it over to you.
 

Chuck Stupca:    00:02:22    Thanks, Chuck. Welcome from me as well to all of you. Let's take a look as Chuck, he introduced what we're going to talk about. First we're going to talk about what independent ASPs, how they fit in with this single level storage concept. Again, that's been one of the foundations of the technology that IBM i is built on. So we're going to talk about what they are, how we're using them, how we fit this into PowerHA for I. As Chuck said, he's going to show you some demos and robot tools for looking at independent ASPs.
 

Chuck Stupca:    00:03:02    Let's take a look at single level storage. One of the big bonuses of our architecture is the fact that people never had to worry about where they were putting things in disks. When we introduced the System/38, at that point it time all of the architectures basically had you tell them where you wanted to put files and how big a space to reserve for those files. In the System/38 we did away with all of that and we created what was called single level storage. We basically scattered things all over the disks for you so that you didn't have to worry about what was where.
 

Chuck Stupca:    00:03:46    In addition, disk storage was basically just an extension of main storage. You just gave us a name of something you wanted to work with and we went and found it. We converted it into an address, and that could either have been in main storage or it could be out in disk storage. You didn't know, you didn't care. It was up to us to find it. You didn't have to worry about, oh, do I have to load this file? Do I have to go and get this information into main storage? That went away with a single level storage concept.
 

Chuck Stupca:    00:04:21    Now of course since you had no idea what was where, when a disk unit went bad, and in the the original releases of the system there was no raid protection, you basically lost data. What did you lose? Well, since you didn't know what was where you lost the whole thing and you had to restore the whole system. It wasn't a real good recovery tool. So disk storage ASPs or basic ASPs were developed to help with that. You could now direct libraries to the basic storage pools. So now when you lost the disk unit you knew what you lost. It wasn't everything. It was only what was in the storage pool that contained the lost disk unit.
 

Chuck Stupca:    00:05:18    In basic ASPs, everything that was put out there was still addressable within this single level storage address space. So every job, every user could get access to any of the information on any of the disk units. We went one step further with that when we created this concept called an independent storage pool. In this case we again isolated disk units into this disk pool. The difference here is that the addresses that were stored in the disk pool were not readily available to all the users.
 

Chuck Stupca:    00:05:59    What I'm trying to show here is an extension of the address space to include in the independent ASP. In order to do that, the user had to attach themselves to this independent disk pool in order to get at the information that was out there. It wasn't readily available to them. There are some different characteristics between a basic ASP and an independent ASP. Basically the basic ASPs link to the system ASP. You don't independently vary it on or off when you IPL the system. The ASP comes online.
 

Chuck Stupca:    00:06:42    You can put library names that are in your basic ASP can go into your system values of QSYS label and QUSER label. No problem there. With an independent ASP you can vary, they are independently varied on or off. What that means is that we can switch these between multiple systems. We can vary it off on one system, switch it to a second system, and vary it on. They have a device description and this pool number. You'll see that in the demo that Chuck is going to show you. Basically the independent ASPs are of three types. The UDFS which is IFS types of objects only, primary disk pool, and a secondary disk pool. I'll talk a little bit more about those.
 

Chuck Stupca:    00:07:41    Basically as we've shown, there are a collection of disk units that are basically isolated if you will from the disk units that are in the system ASP or in any basic ASP. Again, bring them on and offline. The information out there is only accessible by a job that's been attached to the independent ASP. Again, when we get to the demo, Chuck will show how that's done. There's multiple ways to do that. The independent ASP is a separate database.
 

Chuck Stupca:    00:08:28    When you vary on the independent ASPs, one of the key things that's done in the vary on process is to take the cross reference information in your ASP 1 through 32 and merge it into the cross reference information in the independent ASP. What that means is the more data you put in the independent ASP, the faster this goes. If you leave all of your data in ASP 1 through 32, the merge is from the ASP 1 through 32 into the independent ASP. So the more you're trying to merge in, the longer it's going to take.
 

Chuck Stupca:    00:09:16    Okay, you can have duplicate library names. You can have multiple independent ASPs on a system. Each of those independent ASPs can have a library of the same name. That's important if you're consolidating smaller systems into a larger system and you're using an independent ASP concept for that consolidation.
 

Chuck Stupca:    00:09:44    Okay, I talked a little bit about primaries and secondaries. Really what this means is that, think about one of the primary reasons we had developed AST's was to store general receivers. What that allowed us to do was to basically separate the data from the journals so that it made recovery faster if you were doing journaling and commitment control, because one or the other one would be protected.
 

Chuck Stupca:    00:10:19    Then the concept came, okay, how do I try to do something like that if I put my data into an independent ASP? Can I still separate my journal receivers? Yes you could by putting those journal receivers into a secondary ASP. They would vary on together, vary off together, and switch together. They would stay together as a unit when they were in operation.
 

Chuck Stupca:    00:10:52    Okay. This brings about what we called a library name space. If I have multiple independent ASPs on the system and each independent ASP has the same library name in it, won't I get confused? The answer is no because you can really be attached to only one of these at a time. You would see only one instance of the library. I like to say that when you're operating in this environment, think about what would have happened if instead of having independent ASPs, you had separate distributed systems? Each one of the systems would have the same library name. A user signed onto system A wouldn't be confused about the library of the same name on system B.
 

Chuck Stupca:    00:11:44    Same thing here. If I'm signed on and attached to ASP group one, I will only see the library there. I have no knowledge of what's in the other independent ASPs on the system. That was part of the big development innovation that made it so that it took us a while to finally get this implemented. Okay, so basically the primary reason for doing independent ASPs, at least the motivation for it was to do high availability and to be able to move this information, programs and data from one system to another in the event of a failure. We also found many users who would use this for consolidation.
 

Chuck Stupca:    00:12:39    If I'm going to switch from one system to another, what's that got to do with this single address space that we were talking about when we said that this is single level storage and all addresses are just dynamically assigned by a system? What happened is that we took those range of addresses we had and we divided them into two parts. We said these were for addresses that are not in ... there's some foreign addresses that wouldn't go into an independent ASP. That set of range of addresses was available to every system that could potentially own an independent ASP.
 

Chuck Stupca:    00:13:28    That set of addresses was basically reused over and over again on different systems because that information wasn't switching. The information that went into your basic ASPs and ASP one was not going to move from one system to another, so we could assign the same address in any of these systems. If we were putting things into an independent ASP, we had to take addresses from a different segment of the address availabilities.
 

Chuck Stupca:    00:14:03    If we had two systems that were capable of taking ownership of an independent ASP, then this address space down below for objects in an independent ASP would be split in half. One system would get half of the addresses available. When it owned the independent ASP it would use those. The other system would get the other half of the addresses available. When they've created or expended objects in the independent ASP it would use those. These addresses then would move back and forth from system to system. You wouldn't lose any data. You wouldn't have any conflicting addresses when you moved the independent ASPs. That again was a big part of innovation that had to take place in order to implement this.
 

Chuck Stupca:    00:14:53    Okay, data resiliency, HADR, offline backup. Oftentimes we use this in conjunction with SAN storage utilizing the capabilities that are in the SAN storage to assist us with some of these procedures. We can isolate and consolidate. One of the things that you could do if you were an application developer is you could say, "Well, let's see. I need a copy of the previous release." You can have all of that information in one ASP. "I need the current release." That's in another ASP. "I need the next release that we're working on and I need the release after that that we're starting work on."
 

Chuck Stupca:    00:15:42    You can have each one of those in a different independent ASP and the users who wanted to work on a problem that occurred in the previous release would attach to that independent ASP and run their tests. It's much simpler to do that than it is to have multiple partitions or multiple individuals systems.
 

Chuck Stupca:    00:16:12    Okay. Again, this is where I talked about in the single environment you can have ... one of our customers that I worked with many years ago was trying to consolidate 104 different small 170s. Each one had one or two disks. Trying to do that as a partition environment was cost prohibitive. So they went to independent ASP environments and reduced the number of independent ASPs they needed by further consolidation within their company to, they didn't need 104 of those. They only really needed about 30. That's the concept that you can use when you're looking at these independent ASPs on separate systems.
 

Chuck Stupca:    00:17:08    Of course, the key again for us was to try to provide some high-availability capabilities utilizing these independent ASPs. That started with on the far left the switch independent ASPs. That was enhanced into geographic mirroring with synchronous replication between two systems. Then we went to geographic mirroring which was asynchronous replication between systems. Now, the geographic mirroring concept is software-based. The systems that were involved in mirroring this information in the independent ASP, you actually had to have both of your operating systems up and running to be able to keep these separate sets of disks in sync with each other.
 

Chuck Stupca:    00:18:10    In the case of Metro Mirror, Global Mirror, FlashCopy, one level switching, all of these four solutions are SAN storage based. Currently all of these, I know the Metro Mirror, the FlashCopy are also supported in the V7000, which is directly attachable to an IBM i partition. And the software supports the V7000 implementations as well.
 

Chuck Stupca:    00:18:48    Okay. Some people said, "Well, why should I even need an independent ASP? Couldn't I just fully replicate utilizing the full system?" You can if you have a SAN storage unit. The geographic mirroring support does not work for full system replication, so you'd have to be talking about a SAN storage implementation. The other thing is that means you tie up bandwidth sending over what are temporary objects. Temporary objects get over to the second system.
 

Chuck Stupca:    00:19:35    In order to utilize the independent ASP, in order to use that second system you have to IPL it. When you IPL the second system, all those temporary objects get thrown away, so you tie up bandwidth for useless things. The other issue is that if your primary system crashes and you go to the second system to IPL the backup, because we replicated everything, we replicate the fact that the system crashed and your IPL will be abnormal on the backup. There are some definite drawbacks to a full system replication that you don't have if you do an independent ASP.
 

Chuck Stupca:    00:20:22    Now, the biggest concern people have is that this is going to be a difficult thing to do. In fact we have hundreds of customers who have done independent ASPs. We've had people come in to Rochester to take what we call an independent ASP workshop where they would work with their data and try to set up their environments and get them to an independent ASP and test them or at least test some of the major function. Then we even would do some switch overs, and we would be done with that exercise in four or five days. Now, were we all done and could the customer just go back and set it up? Well, if they were big time gamblers they might. But you would still want to do some more extensive testing. The whole point of our workshop was to prove the feasibility and the simplicity at which you could set that up.
 

Chuck Stupca:    00:21:28    All right. That's because we can put all these different objects into an independent ASP. If you look at that, you're looking at practically all of the objects that any application would be using as part of its normal operations. Some things don't go into an independent ASP. They're more of the system related functions like authority lists and device descriptions and so forth. I've put these four objects in different colors because these objects, even though you can't put them in independent ASP, the IBM i HA products will automatic replicate any changes made to these objects if you've registered them.
 

Chuck Stupca:    00:22:29    So let's say you have a user profile, and you want that user profile to stay in sync between systems that are going to own your independent ASP. You can register that user profile and say you want to keep the different components of that profile in sync with each other, and the two systems will do that for you. You don't have to put it into an independent ASP in order to keep it current on both systems, nor do you need a replication product for it. You can use the IBM i support for that.
 

Chuck Stupca:    00:23:06    Okay. Again, these are all the different kinds of thing that PowerHA system for I will replicate for you between systems that have the capability of owning an independent ASP, again so you can try to keep all of these things in sync with each other. Okay. What do you put where? I try to say put as many of these different kinds of things that your application uses into the independent ASP. Because that means when you switch, the application has everything it needs in order to run on that backup system.
 

Chuck Stupca:    00:23:46    My idea is put as many of those things in there as you possibly can. The only thing that we had to do in order to get these in almost all instances was to change some of the work management related considerations like attaching, how did you attach the user to that independent ASP? That was what we had to do. The other thing we had to do was put in symbolic links so that a user could be redirected from their IFS path. Instead of going into ASP one, they would automatically be directed into an independent ASP simply by the symbolic links.
 

Chuck Stupca:    00:24:33    Those were the kinds of changes we made. We rarely if ever made the application changes themselves. This is just kind of more of a list of kinds of things as to what should go where. I'm using a term here called SYSBAS. SYSBAS is basically your independent ASPs 1 through 32. All of those ASPs are referred to as SYSBAS. These are the objects that we try to put there, and put the rest of our objects into the independent ASP.
 

Chuck Stupca:    00:25:20    The last object that we felt was the most important to get into the independent ASP was the JOBQ. Although we put JOBQs into the independent ASP, one of the things about them is that they're not persistent. If you vary off switch and vary on, you lose the contents of that JOBQ. You'll have to repopulate that. Otherwise everything is persistent across the systems.
 

Chuck Stupca:    00:25:50    Okay, talked about IFS. Again, try to move as much of that as you possibly can. Use symbolic links. If you have a path that has /QSYS.lib, that cannot be symbolically linked. You have to be cautious of those kinds of things when you move them in. Basically the proof of concept is done. When you've done the proof of concept you've pretty much, outside of the more intense testing you've pretty much got a good notion of what you need to do in order to get access any of the objects that you've moved into your independent ASP.
 

Chuck Stupca:    00:26:39    The key thing is that independent ASP migration was originally thought to this big imposing project when in fact it's usually not all that difficult to get things into the independent ASP, get your work management changes done. Again, the biggest issue that you would have in implementing this would be to what degree you want to exercise testing before you go live.
 

Chuck Stupca:    00:27:17    Okay. One of the things that was added was this ability to force changes in main storage. If we were to just, you could vary off your independent ASP, switch it, and vary it on on the other side. That kind of defeats the purpose, or vary it back on again, that kind of defeats the purpose of the availability aspects of the independent ASP. The reason you were doing the vary off was to force things that were in main storage to the disk units so that when you did this DS FlashCopy, your FlashCopy contained absolutely everything you needed to know about the database that had been produced on the production system.
 

Chuck Stupca:    00:28:08    So instead of having to vary off, we had this function, we implemented a function called quiesce which goes through main storage and forces the pages out to the independent ASP without taking it offline, so it's only a matter of a few seconds. FlashCopy takes a few seconds if even that. Now you're ready to attach this FlashCopy to a system and take the backup. This quiesce function really was designed to improve availability of a single independent ASP.
 

Chuck Stupca:    00:28:45    Again, we've had lots and lots of customers come in and implement independent ASPs, wide varieties of industries, wide varieties of applications. We've worked with some of the application providers to produce, and here's a list of some of them that basically have modified their application set such that they will work quite seamlessly in an independent ASP.
 

Chuck Stupca:    00:29:23    I urge you to go out and look at the red books. There's also if you look at the lab services, you'll find availability for classes as well as consulting services from lab services. Formal education, the last I checked on this they're really not offering classes. You have to ask for one and they will try to work it in. The enablement workshop was what I referred to as you would bring your information to Rochester, sit down, or if you could set up an independent ASP a consultant could come and work at your location. But again, that's usually for four to five days. We've pretty much worked through most of the major things that you'd be worried about in terms of trying to implement and look at utilizing an independent ASP in your environment.
 

Chuck Stupca:    00:30:32    Now, what I've done is gone very rapidly over the concept of an independent ASP and how to put things out there, how to get at them, and how to get your users connected to an independent ASP. Now Chuck has set up an environment using an independent ASP on one of his systems. We can show you utilizing the demo capabilities how this all ties together and when you actually see it in practice as opposed to on a series of charts that represent theory. It will hopefully make this all a lot clearer. Let's turn this over to Chuck Losinski and have him go through his demo that he's set up for us.
 

Chuck Losinski:    00:31:32    Yeah. Chuck and I got together on this a few weeks ago and talked about the possibility of doing a live demo. So we configured independent ASPs on several systems. Had a lot of fun with this, and of course the robot products work in an independent ASP environment, so of course it's always good to be able to show our customers exactly how that works. Chuck's going to help describe some of what we've got going on here. We're going to start from the beginning with the configured device ASP command. I'm going to bring that up.
 

Chuck Losinski:    00:32:11    Okay, so we do have a disk pool or an independent ASP already configured on this particular system. But let's say you were going to define an independent ASP. You do with something like this. We have the ability to selected the available disk units for this independent ASP. Now, on this particular system you'll see as I execute this command that that there are no available disk units to actually assign to this disk pool. But be advised that we do have a disk pool, and it's called pool_01. We're going to take a look at that now. So configure device ASP, that would be the command you'd use to actually get the independent ASP configured. Any comments on that, Chuck?
 

Chuck Stupca:    00:33:06    Yeah. That is a recently added command. Prior to that command you had to use the GUIs to do the creation of an independent ASP. You still can do that. I worked on this architecture for a long time and I'm not necessarily a GUI guy. I'm a command line guy, so I was happy to see the commands.
 

Chuck Losinski:    00:33:36    Yeah. With all the other commands that are part of this environment, it sure makes it easy. The thing about independent ASP is, in order for them, as Chuck mentioned, in order for them to be available to your partition is that they do need to be varied on. I've executed a work configuration status command, work config status for my pool_01. As you can see, it is available. Here's a question you, Chuck. When would be the best time to turn this disk pool on or add this dk pool to this partition? During IPL and add the vary config command to the IPL program?
 

Chuck Stupca:    00:34:18    You can write that. You can in your, I can't remember the name of the IPL program. The startup program.
 

Chuck Losinski:    00:34:31    Yeah. The startup program, yeah.
 

Chuck Stupca:    00:34:32    There we go. All right. So you could add into this startup program this vary on of pool_01. Be aware that if there's any types of errors, you'd have to handle those in that startup program. The other thing is that if you are in a switch disk environment, be aware that that pool is only going to exist on one of the two systems. That's why if you're going to build that into the startup program, you have to be able to handle the fact that that disk pool might not be there.
 

Chuck Losinski:    00:35:11    Right. Okay. Well, there's also a display ASP status command. This is indicating that the ASP is currently available, the independent ASP called pool_01. It looks like it took six minutes and nine seconds for this system to be attached. It seems like a long time.
 

Chuck Stupca:    00:35:37    Right. If you look at the third line in your display, you see that that took three minutes and four seconds. So that's basically more than half of your, about half of your vary on time. That's that database cross reference file merge going from ASP one into the independent ASP, which probably means you had a lot of data in ASP one.
 

Chuck Losinski:    00:36:10    Yeah. That's exactly what we had. We had most of our data out there in just a few libraries in the independent ASP.
 

Chuck Stupca:    00:36:16    Right. That's why that time was more extended than what you'd see if you had populated your independent ASP with the information.
 

Chuck Losinski:    00:36:29    Here's a list of relational database entries. As you can see, pool_01 is added as a addressable database here on the system. Something interesting, go ahead.
 

Chuck Stupca:    00:36:50    I just wanted to to add that if you looked at that, you saw basically the ASP one database which is C0091 Baker 26. That's your local database. It is combined with pool_01 so that when you were referencing data, you see data in both the independent, in both databases. Again, you see that seamlessly. Places where you have to worry about that if you're trying to do journals or you're trying to do commitment control and you're crossing that database boundary. That's the only time you have to worry about the fact that there's actually two databases there.
 

Chuck Losinski:    00:37:39    All right. Let's talk about the integrated file system, the IFS a little bit. To address the root directory in the integrated file system you would address it like this using the work with object links command. In order to address the IFS structure in the independent ASP, you have to prefix the directory with the pool name. There we go. There's our independent, the root directory of our independent auxiliary storage pool. And if I drill into that, now I'm seeing the root level directories as they exist in the independent ASP. Chuck, you said if you're converting an application that uses directories that you want to place into the auxiliary storage pool, you recommended adding symbolic links ...
 

Chuck Stupca:    00:38:46    Correct.
 

Chuck Losinski:    00:38:48    ... like this. And crate a symbolic link so that your application can still address into that IFS directory. Then you don't have to worry about that prefix.
 

Chuck Stupca:    00:39:03    Correct.
 

Chuck Losinski:    00:39:04    All right. Okay. That's the end of the IFS structure. What about the library structure? Let's use the work lib the command. A lot of people don't realize that if you use the F10 key on the work with libraries, command there's an option to work with a particular ASP device. Let's take a look at that. Okay. I've now requested that the screen or the command lists all the directory or all the libraries that exist in this particular ASP device. A lot of people forget that this column exists on the work with libraries command. I can address so or can look at those libraries from the independent ASP directly.
 

Chuck Losinski:    00:39:58    Likewise if you're going to create a library, for instance if I'm going to create a Chuck Stupca library, I can specify that the ASP or that the library be created in the independent ASP like that. Okay. Let's go ahead and add that. Okay. It says that that library was created. If I go back and display the libraries that are in that auxiliary storage pool, you will see that Chuck S is there. Now if I tried to create that library in the independent ASP and it already existed in the base pool, the operating system would slap me on the hands and say no, I can't do that. Would that be a correct statement, Chuck?
 

Chuck Stupca:    00:41:06    That is correct.
 

Chuck Losinski:    00:41:08    Likewise we've got another question I see from our listeners ... oh, go ahead.
 

Chuck Stupca:    00:41:12    Another thing, let's say that you're on your production system and you added this library. But somebody on your backup system put this library in the basic ASP. When you went to go vary on the independent ASP, it would stop you when it hit this library conflict. You would have to either, the best idea is to rename the library in ASP one so that you can finish that vary on.
 

Chuck Losinski:    00:41:52    All right.
 

Chuck Stupca:    00:41:53    So that's something you have to watch out for in a switching environment is to make sure that you have control over the names are going into ASP one.
 

Chuck Losinski:    00:42:04    Okay, I'm going to use the work lib command and I'm going to look at all libraries. Actually, I'm going to look at Chuck S. I'm going to do something like that. Let's just see. Okay. It says it cannot find that object. Okay, it can't find that. I'm going to do a work object and I'm going to work for a file, RBC message history, and let's see where that file exists.
 

Chuck Losinski:    00:42:38    It says it exists in a couple places, a couple of Robot libraries. But I know for a fact that this file also exists in my independent auxiliary storage pool. But currently the job that I'm in, the interactive job that I'm in does not have the independent auxiliary storage pool as part of its addressable namespace. I can't see it. It's not directly addressable by my job.
 

Chuck Losinski:    00:43:01    What I can do is use the set ASP group command. That basically will add that independent ASP as addressable space for my job, so let's do that. Pool_01. I'm going to use the set ASP group pool_01 for my interactive job. Now I'm going to re-execute my work object command for RBC MH. Notice that now we have another library there, Chuck independent ASP. That library does exist in the independent ASP and I can now address it in my job.
 

Chuck Losinski:    00:43:41    That's one of the things you need to do in your jobs is add that independent ASP in order to address that data. There's a couple ways you can do that. If you can you're using Robot Schedule for instance, we have a way in Robot Schedule for you to specify what independent ASP you want to include in your Robot job. That shows up on the properties of your Robot job. Let's take a look at that.
 

Chuck Losinski:    00:44:16    Okay. You can see here on my Robot job, it's just a batch job that is running on the I. I have an additional ASP listed here, pool_one. It's going to use the base libraries and directory structure. It's also going to be able to address the data that's in the independent ASP. Chuck, this is where you were talking about consolidating multiple independent systems into one system using independent ASP technology. So theoretically you could create the same job and have it run over multiple independent ASPs. Or you could create in one job and duplicate it.
 

Chuck Stupca:    00:45:00    Correct, correct.
 

Chuck Losinski:    00:45:01    Okay. That's a real good application of independent ASP technology. Also you can do it through a job description. We have a job description that we created for Chuck Stupca on this particular system. Let's take a look at that job description. I'm going to scroll down if you're familiar with work management technique on job descriptions. You may or may not have noticed that there is a initial ASP group associated with job descriptions.
 

Chuck Losinski:    00:45:39    What we've done is we've added this job description now to a user profile called Chuck S. All right, let's take a look at that user profile and let's take a look at the job description that is associated with this job. You can see that the Chuck two job description has been added Chuck Stupca's user profile. What does that mean? Well, what that means is now when Chuck goes to sign on, and I'll pretend to be Chuck Stupca. He shared his password with me. Shame on you, Chuck. Okay, let's go ahead and sign on now with his user profile on my Wisdom system.
 

Chuck Losinski:    00:46:30    Now on my original system where I signed on, there's a command that Chuck told me about called work ASP job. Now, keep in mind for my session that I have active right here, I added pool_01 to that. Now Chuck Stupca on the second session also has pool_01 as part of his job. So the work ASP job shows that we have two jobs that has that independent ASP associated with them. I assume, Chuck, if you had multiple independent ASPs on this system you'd see all those listed if they had jobs active.
 

Chuck Stupca:    00:47:13    You'd see them whether they had an active job or not. You'd see pool_02. If there was nobody there, that's fine. Pool_03, it might show you another job. It is designed to show you users across all of the independent ASPs you have on the system that are varied on.
 

Chuck Losinski:    00:47:34    Yeah. Okay. We've got independent ASP technology going on here. We've got databases in the pool_01. We've got some files out there. I've shown you how Robot Schedule can address independent ASPs on Robot jobs simply by choosing the independent ASP that you want to run your job against. But we also have a tool called Robot Space. Robot Space has the ability to do very specific monitoring over your independent ASPs as well. Let's look at Robot Space and its independent ASP capabilities.
 

Chuck Losinski:    00:48:13    First of all, when you install Robot Space on your system, it takes a look at what you have configured on your system. In this case, Robot Space sees that it has the base pool, and also there was an independent ASP associated with this system. It incorporated that, it added that to the list of monitored ASPs. With Robot Space what you can do is you can set up thresholds for monitoring. So what Robot Space will do is it'll automatically go out to your independent ASPs as well as your base pool, and it will check on an iterative basis the amount of storage that has been used up on that disk pool.
 

Chuck Losinski:    00:48:55    The last check of that disk pool says that we're using 10% of the available space. The growth in the last hour was zero. But we set up three thresholds, a 50%, a 75%, and a 90%. We've also set up an hourly growth threshold of 5%. Then inside the monitoring tool you set up how you want to be notified or if you the notified if the threshold is exceeded. I've set up the 50%. I'm going to be notified via our Robot Alert tool. So Robot Alert is going to send me an email when we hit 50%.
 

Chuck Losinski:    00:49:33    When we hit the second threshold, the 75%, well, now we're hitting a higher threshold. I'm going to send that off to my operation staff. I'm also going to post into our network consolidation tool a warning status. Then when we hit our third threshold of 90%, then we're going to send in the heavy guns. We're going to bring in the Robot SWAT team and we're going to take a look at what's going on. The same with the growth threshold, if I exceed 5% growth in an independent ASP in the last hour, I want to know about that. Also I'm going to post a warning inside of our network consolidation monitoring tool.
 

Chuck Losinski:    00:50:17    That's the first place where you can use Robot Space to monitor your independent ASPs. We also have something called a storage audit. A storage audit is basically a set of cleanup tasks and analysis that you can run against your disk pools to help you with cleanup. I've got several created here that run either against the independent ASP or everything. I did create one that runs specifically against pool_01. I've got a specific requirement there to do some cleanup on pool_01.
 

Chuck Losinski:    00:50:58    Basically what we do is we tell the storage audit to look at certain libraries, certain objects, certain out queues, and certain IFS directories. In this case I've told it to look at everything in my library structure as well as my IFS structure, and also look at all my out queues. Then for each of these audits I then have a list of available tasks that I can run against the audit.
 

Chuck Losinski:    00:51:24    In this case what I've asked it to do is take a look at what's stored on that independent ASP and to do some actions. For instance it can automatically clean up old unused save files. It can list damaged library or IFS objects. It could be that in the last 24 hours let's say you lost a bunch of disk space in your independent ASP and you want to know, was it a new or a restored object that somebody placed into that independent ASP? So we're going to create an audit report over that and run that maybe on a daily basis.
 

Chuck Losinski:    00:52:02    And to prevent that file member full message that you see on occasion, we also have the ability to list those file members that are almost full. This audit is scheduled, in this case we have it running through Robot Schedule. The results of the audit look like this. Let's take a look at the audit that ran on the 10th. Let's take a look at the reports that were generated. Here's your spool files. I'm just going to to take a look at first of all the list of objects that were created or restored in the last 24 hours.
 

Chuck Losinski:    00:52:40    Okay, so here's the list of objects that were created or restored in the last 24 hours. It shows you a total. Likewise, let's take a look at this one. This is list of physical files, physical file members that are 90% of their maximum record capacity. Good news is I don't have any that have exceeded that. So we're good there. And with these audits you can change the thresholds, so for instance if you wanted to change that 90 to be 95% or 80% you could certainly do that. Those are called storage audits. They help you keep your disk space nice and tidy.
 

Chuck Losinski:    00:53:18    We've gotten monitoring storage audits, and then we've got something called collection groups. What collection groups do in Robot Space is they go out on an iterative basis and they basically take a shot of what's stored on your disk space. From that snapshot you can look at historical reports and analysis of what's stored out there. So for instance, I'm going to look at the storage collection that took place here just today. If I click on libraries, it shows me all my libraries that I have stored out there. If I click on object, and it shows me the one that takes the most space on top.
 

Chuck Losinski:    00:54:04    Okay. Now from here I can right-click and I can say, "Show me the size history for that particular library." Oh, look at that. Okay, looks like we're growing a little bit. So over time that object is growing. That's because we run this storage collection on an iterative basis. We're actually running it on this system every day. You might want to run it every week or every other day. It all depends on how you want to do it.
 

Chuck Losinski:    00:54:32    What we're doing is because we're collecting this data over time, not only do you have the ability to analyze the latest and greatest information, but you also have ability to compare this information over time. As you can see on this system, the largest file on the system is this RBC MH file. Once again if I look at size history, let's see what that looks like. Yeah, okay. It looks like that's the file that is causing most of our growth.
 

Chuck Losinski:    00:55:04    All right. Let's say I want to compare the most recent collection with my collection from a couple days ago. What we're going to do is we're going to compare those two collections and we're going to say, "Okay, what has changed the most?" I'm going to compare objects between those two collections, and let's see. It's going to tell us what object has changed the most over that two day period. Voila, well, it happened to be that RBC MH file. You could do that. I could compare day to day. I could compare day to week or maybe a collection from even a month ago.
 

Chuck Losinski:    00:55:47    At the member level I can also see record counts. I can filter my data to look at physical files or logical files. I also have the ability to see how many deleted records my files have. That's going to help you identify those files that need to be reorganized. Finally you can look at this information graphically. This shows how much of my used disk space, and my independent ASP is owned by the operating system versus me. Now if I display all the data as D that's associated with that independent ASP, it says, "Well, you got all this pink is available disk, and here's what's used by your application. Here's what's used by the operating system."
 

Chuck Losinski:    00:56:41    This is just touching on the capability of the Robot Space product. I hope you like what you see. We've developed a product over the last 12 years or so, and we have a new version coming out that's going to have even more capability, and that should be coming out hopefully first quarter of 2015. Fortra is more than just scheduling and disk space monitoring. We've got solutions to cover all the various aspects of your IBM i from an operational standpoint, and also from a security and business intelligence standpoint. Fortra has been working on the IBM i for a long time actually before there was an IBM i. We started out on the 38 in 1882. And we are doing more and more multi-platforms. So if you do have needs in that direction, we can definitely help you out. With that, I believe we've got a few minutes for questions, Chuck.
 

Chuck Stupca:    00:57:42    Sure.
 

Chuck Losinski:    00:57:43    All right, and Jake, can you moderate our Q&A?
 

Jake:    00:57:48    Absolutely. Thanks a lot, Chuck. Before we do begin the Q&A session, I would like to ask the audience to please take our survey by clicking on the red survey widget on your audience console. We do have a few questions and a few minutes to go for Q&A, so we're going to jump right in. Here's our first question. How can FlashCopy took advantage of IASP?
 

Chuck Stupca:    00:58:05    The way takes advantage of the independent ASP is that you have your data in the independent ASP, you do the quiesce function. You take the FlashCopy. The set of disk units that are in the FlashCopy are then attached to a second partition that you can then utilize to take a backup for off-site storage. So your production system doesn't have to deal with a save while active or with downtime to your independent ASP in order to get it saved and shipped out.
 

Jake:    00:58:50    Fantastic. Here's our next question. When replicating an IASP, what are the advantages versus disadvantages of replicating the data via V7000 versus PowerHA?
 

Chuck Stupca:    00:59:01    All right. The advantages in the V7000, okay, let's look at the two. If you're using V7000 replication, the overhead to do the replication is in the V7000 units. It's not in your production system. So you've offloaded that. Users would see only minor delays because of the time it would take to write to the disks. Secondly, if I'm replicating between V7000s, let's just say for some reason my backup system failed or I had to take my backup system online. I was going to put a PTF on, whatever. When I took that second system off-line, replication still continues between the V7000s because they're still online. Those two things are definite positives over PowerHA. So in general, my biased opinion was the SAN storage provided better replication technology.
 

Jake:    01:00:22    Fantastic. Thank you. Here's our next question. How is the data about the system kept up to date? Cross-reference jobs, or do these have to be run daily?
 

Chuck Stupca:    01:00:34    Is that an IASP question or a Robot question?
 

Chuck Losinski:    01:00:38    I think that's more of an IASP question.
 

Chuck Stupca:    01:00:44    Okay, so basically what happens is that any jobs that would, if you're referring to the database cross-reference jobs, those are always active. They are keeping the information in the independent ASP cross-referenced. Anything that changes in ASP one is also kept up to date I those cross-referenced jobs. So when you vary on the independent ASP, you typically will see that information being kept up to date. I think that's what's being asked, but I'm not sure.
 

Jake:    01:01:27    Chuck Losinski, actually that attendee wrote in and asked about the Robot portion of that.

Chuck Losinski:    01:01:33    I see. I'll tell you what, we're getting close to the top of the hour, Paul. I think we'll take that offline and follow up you after the presentation. Thank you.
 

Jake:    01:01:43    Fantastic. I'm afraid we have run out of time for this web seminar. I'd like to thank Robot for making today's event possible, and I'd also like to thank both Chucks for great presentations. Just a reminder, this seminar will be available on demand starting tomorrow. So feel free to come back and review. Have a great day everyone, and thank you so much for attending.
 

Chuck Stupca:    01:02:03    Yeah, thanks everyone.