Here’s a link to a nice IBM post about how to run a full system save in batch mode while the system is restricted.
Batch saves in restricted state are made possible by a Batch Time Limit parameter (BCHTIMLMT) added to the End Subsystems command (ENDSBS) you submit to put the system into restricted mode. This enables you to submit a batch full system backup job into the QCTL subsystem and to specify a maximum amount of time to run before the batch full save ends and the system exits out of restricted state.
The exact procedure can be found on IBM’s Running a Full System Save or SAVSYS in Restricted State Batch Web page. This looks interesting and something I’ve been looking for a long time, but there’s a few caveats on this Web page, including:
- The system console goes away while the batch full save is running. This is a major drawback to the procedure.
- You can’t answer messages while the save is running, because the system console is blank while the save is running
- If you want to cancel the save according to the site, you need to force the system console into Dedicated Service Tools (DST) to kill the save.
I haven’t tested this yet but if this site includes current information (and it specifies this technique is good for i5/OS 5.3 through i 7.1), I’m not sure what the advantage of running a batch full save is if I can’t access my system console, answer messages, or cancel the job while it’s running. Granted there may be more to this technique than meets the eye, but keep an eye on these items if you decide to implement. If you try this technique, let me know how it goes by dropping me an email at joe@joehertvik.com .
We are able to get around a lot of the caveats described by running the full save from the console in an unattended way. In spite of the our attempts at adding monitor messages and reducing errors, we occassionally get hardware error message that interrupts the job. It’s a reality of life.
A while ago we moved away from the operators using the console to do their work. That left the console free. We initiate program that sits in a data queue wait status. Then the job scheduler submits at job at the appropriate time that sends a message to the data queue. That causes the program on the console to start executing the shutdown, backup, and restart.
We find that it works well without the mentioned cautions.
Thanks, Jared. My shop does almost the exact same thing. When I took over six years ago, they used to rely on IBM i operators to run the Sunday and nightly backups. This was expensive and a lot of times, these guys sat around doing nothing but watching the system.
Using this technique, we eliminated the after-hours operator shifts and converted the IBM i operators to Help Desk technicians where we really needed the help.
What it comes down is that there are better ways to automate an IBM i backup.
Now if I could just figure out how to allow my system console to email me pages during restricted state whenever there’s a message waiting on my backups, I’d be doing really well.
We have taken three approaches to that issue.
1) First approach is if we get an error that we can monitor for (tape not available or tape not initialized), then we set a flag and drop down to the part where it starts the system back up. After the system is brought back up, there is code to say if the flag is set, email the on-call and let them know the backup wasn’t done and why.
2) Second approach is a completion message at the end of the backups. I usually get up around 5am. If I don’t have a completion message, I know I need to check the system and see why.
3) Third approach was put in by our network services folks. They have some kind of process running on PC that checks (I’m assuming pings) the IBM i and all the other servers periodically during the day. If a system doesn’t respond, then network services folks get an alert text. (I happen to be included, since I handle the backup scripts for the IBM i.) They have predetermined time when they don’t check knowing that the system is down (in this case for backups).
Between the three approaches we get things covered, but it certainly is extra work at multiple levels. If somehow (in dream land) we could send an alert while in restricted state, that would be nice. I thought I heard that Ops Nav had some kind of external monitoring function, but haven’t looked into it. Also HelpSystems I think advertises some product that does external monitoring of messages and sends alerts. I haven’t looked into that either. Guessing that they have no way of handling a machine in restricted state.
BRMS allows unattended backups using both methods (Batch or dedicated console monitor). The console monitor application just sits and waits for a backup job to be sent to it and processes it. However, it does have a function key that will interrupt it so you can use the console temporarily to do things like change tapes from your tape library.
Thanks for the info Doug. We don’t use BRMS in our current location but we’re moving some systems to a sister location that uses it for everything. Nice to know this is available. The IBM post and my past experience all point to people who roll their own without paying for BRMS>
I use the BCHTIMLMT option to run an unattended full save. The program holds the QCTL jobq and then submits the save with the BCHTIMLMT option to the qctl jobq. Then the scheduler releases the qctl jobq at the appropriate time and hey presto we have a full system save. Obviously we have to emulate the save 21 in the program but the result is the same.
Interestingly enough I used to run a similar save 25 years ago on the as/400 by having a special user profile that would call the restricted save when you logged on the user at the console. Normally DSP01 in those days. In both cases I run a IPL after the save to restart the box..
This is interesting. Do you have anything set up to automatically fire up TCP/IP and send out an alert if there’s a problem (say you need to load another tape)?
I have done that at other sites but have not got around to setting it up at the current client. Good reminder!