NIGHTLY BACKUP - making sure users are not on the system

[Guest.Visitor]

I have a question regarding nightly backup. Currently my shop does a user lib backup at 10:00 PM nightly. People get to the AS/400 off hours via the internet. I am concerned about the timing of things.... i.e.. if the backup is happening, and people are logged on,, I am sure files that are being used will not be backed up... in the event a restore would be needed--things might be out of sync. I am looking for a failsafe way to automatically kick users off the system (if any are logged on), do a backup, then let people back in.... ANy set of commands that could be placed in the backup CL to maybe shutdown QINTER after kicking people out etc... ??? not sure what I need to pull this off thanks gang... Rob O.

[Guest.Visitor]

NIGHTLY BACKUP - making sure users are not on the system

If all the users sign on through QINTER, then the simplest method is to do an ENDSBS QINTER with *IMMED. Make sure that you send out a warning at say, 5 minutes and 1 minute before you end the subsystem. After the backup, do an STRSBS QINTER to restart the subsystem. Russell

[Guest.Visitor]

NIGHTLY BACKUP - making sure users are not on the system

Rob, This is how I would handle your situation: 1. SNDBRKMSG to warn all users to sign-off due to Backup in 10 minutes 2. ENDSBS QINTER, QBATCH, QSERVER with OPTION(*CNTRLD) DELAY(*NOLIMIT) 3. After 10 minutes, ENDHOSTSVR SERVER(*ALL) 4. ENDTCP 5. ENDSBS QCMN, QINTER, QBATCH, QSERVER with OPTION(*IMMED) 6. After 5 minutes, start the backup. 7. Restart QCMN, QINTER, QSERVER, & TCP/IP 8. After the backup, restart QBATCH This assumes that: 1. The procedure is either run from the console, or from a custom batch subsystem and job queue (external from QBATCH subsystem/jobq). 2. All memory resident programs check for the end-job status flag. 3. There are no other active batch or interactive subsystems. Steps 3, 4, & 5 will definitely kick out everyone but the console operator. Step 7 will allow people to connect/signon and initiate some jobs that may interfere with the backup. To remove this possibility, you could interchange steps 7 and 8. However, it is my experience that you should allow people to connect so that in case anything goes wrong, the technical staff can still get in to fix it remotely. You could opt to insert an initial sign-on program into your non-technical users' user profiles to check if the backup is in progress, and if so, bar them with an informative message. Hope you find this useful.

[Guest.Visitor]

NIGHTLY BACKUP - making sure users are not on the system

We simply ENDSBS *ALL in our save program - which is more or less an automated version of the option 21 save with tape library management. We also reboot the system in this program. On a different thread, people mentioned that was to high a frequency for ipling. I felt no need to change is as everything is running smoothly. I'm curious what thoughts are on this. John

[Guest.Visitor]

NIGHTLY BACKUP - making sure users are not on the system

John, ENDSBS *ALL is brutally simple and effective. I like it, and use it whenever it is safe to do so. However, I would not advise it for an automated procedure in a busy production machine running on a 24x7 work schedule. This is most specially true when you have internet users connecting from anywhere (and any time-zone) in the world.