The Four Hundred

Most shops frequently need to put their iSeries or AS/400 boxes into a restricted state to perform full system backups, to add hardware to their system, or to execute some other task that can't run while normal business processing is occurring. (The necessity of restricted states is not unique to OS/400 servers; it's a fact of life for all kinds of servers.) While the mechanics of entering a restricted state on an OS/400 are simple, there are some pitfalls to avoid.

The most common technique for entering restricted state from your system console is to end all your subsystems, including the controlling subsystem, designated by the Controlling Subsystem system value (QCTLSBSD). An iSeries machine in restricted state is unable to accept any connections or run any jobs, except for jobs running on the system console (the only active environment on a restricted machine). While the most common technique for entering restricted state is to issue an End Subsystems (ENDSBS) command with the *ALL parameter, there are several other tasks you may also want to perform before you end your subsystems. These commands will help you cleanly end important jobs and avoid corrupting data as you restrict processing. Here's a quick checklist of items to check or execute before putting your AS/400 into restricted mode.

Be sure to give your Domino servers sufficient time to close all their tasks before you go into restricted state. Five minutes after issuing the ENDDOMSVR command should be enough. If you don't close your servers cleanly before you end the subsystem each server is running in, you run the risk of corrupting your Domino data.

Check for disconnected jobs on your system console. Many shops set up their iSeries boxes to disconnect jobs that have been inactive on the system for a set period of time. An AS/400 cannot enter restricted state unless there is only one active job running on the system console in the controlling subsystem. So if there's a second disconnected job on your system console, you need to end that job before restricted state processing can complete. So it's important to find and end disconnected jobs before you issue your ENDSBS command. To view disconnected jobs, run the Work with Active Jobs (WRKACTJOB) command and press F14 to include disconnected, suspended, and inactive prestart jobs. If a job has a status of "DSC," it's a disconnected job, and it can be ended by entering 4=delete in front of the job and pressing Enter.

Optionally, you may want to end your Client Access host servers through the End Host Servers (ENDHOSTSVR) command. You may also want to end your TCP/IP servers through the End TCP/IP Server (ENDTCPSVR) command, as well as ending TCP/IP itself, through the End TCP/IP (ENDTCP) command. Performing these commands will cut off interactive and TCP/IP access before restriction. You can end these functions by issuing the following commands:

This is an optional step, and you can enter restricted state without ending these functions. But it helps to run these commands if you want to completely batten down your system before it goes into restricted state.

At this point, your system is ready to go into restricted mode, by using the ENDSBS command to end all subsystem processing:

If you've taken the trouble to cleanly end production jobs, Web sites, Domino servers, and disconnected system console jobs, as outlined above, then using *IMMED in the OPTION parameter--which immediately ends all jobs running in each subsystem, along with the subsystem itself--shouldn't be a problem. If you haven't cleanly ended all running processes, you may want to instead consider using the *CNTRLD value in the OPTION parameter, combined with a delay time for ending each subsystem. Using these options ends your subsystems in a controlled manner, which gives each subsystem some time to cleanly terminate its running jobs before it is forced to end. Here's how you would enter the ENDSBS command with the *CNTRLD option:

In this case, OS/400 will give each subsystem 5 minutes (or 300 seconds, as specified in the DELAY parameter) to end cleanly before it forces a subsystem end.

After running ENDSBS, the trick is knowing whether your iSeries has entered restricted state. There are a few ways to do this, but I recommend waiting a few minutes after issuing the ENDSBS command (at least the amount of time in the DELAY parameter for controlled endings) and checking the QSYSOPR message queue for message ID CPF0968, "System ended to restricted condition." If your processing is dependent on restricted state (such as a full system backup), don't continue until you verify you're in restricted state. There are also some programmatic ways to check for restricted state entry, but those techniques are beyond the scope of this article.

Once your iSeries or AS/400 is in restricted state, you can perform system backups or any other tasks that require a dedicated system. If your work requires you to IPL the system and leave it in restricted state after the IPL, there is also a technique for specifying that your iSeries V5R1 box can IPL into restricted state (see "You Can Re-IPL an AS/400 into Restricted State" for more details).

When you're finished with restricted state processing, you can reset your OS/400 box to its startup state by restarting the controlling subsystem, through the Start Subsystem (STRSBS) command. Most of the time, the controlling subsystem name is QCTL, but if you're unsure about which subsystem is your controlling subsystem, you can find its name by using the Display System Value (DSPSYSVAL) command to list the value of your QCTLSBSD system value:

Once you've identified the controlling subsystem, you can reset your system to its startup state by running the STRSBS command:

When the controlling subsystem starts, it also runs your system startup program (as defined in the system startup program system value, QSTRUPPGM), and your system will return to its IPL startup status.