Admin Alert: More Information on Semi-Restricted State, Vendor Profiles, and Storage Pools

December 7, 2011 Joe Hertvik

As we approach year end, I usually clear out my Admin Alert mailbox to see if there’s any good additional information about recent articles that I can pass along to you. Good thing, too, as some readers sent over workable ideas about getting into semi-restricted state and how to handle vendor profiles for auditors. Here’s what they said. I hope this information helps you.

On Semi-Restricted State TCP/IP, Suggestion #1

About my article on putting an IBM i system into semi-restricted state (where the system is down but TCP/IP is up), reader Richard Shearwood filled in some gaps about starting TCP/IP without having to IPL the system.

This [semi-restricted state] is an incredibly useful state but you said:

“Although there may be a way to restart TCP/IP from restricted state without IPLing, I’ve found it easier to just IPL into restricted state with TCP/IP started.”

In my case, I’ve found that once the system is restricted, you can simply use the Start Subsystem (STRSBS) command to start the QSERVER subsystem. You may also need to start the QSYSWRK and QUSRWRK subsystems.

STRSBS SBS(QSERVER)
STRSBS SBS(QSYSWRK)
STRSBS SBS(QUSRWRK)

This will enable TCP/IP for your usage. You’ll get an error advising you that the controlling subsystem isn’t started, but it all starts up and the servers you need are there.

TCP isn’t “started” in the sense that it normally is, so NETSTAT can be unavailable. But generally that’s not a major problem and it does save the IPL time. Obviously, if there are prestart job tasks in those subsystems, they will always be started when the subsystem is started. So you might need to edit your subsystems to get a really “clean” TCP/IP startup. My advice is to have a couple of CL programs to do the edits for you in that case. You should also have a printout of the subsystems descriptions in hardcopy or downloaded to your PC.

Richard’s technique looks good, but one of the unfortunate things about working with restricted state procedures is that you can’t always test them. Like everyone else, I run my systems pretty much non-stop so I wasn’t able to validate his technique. As a result, you may see some slight variations if you try this on your system.

I suspect that Richard’s technique may work differently depending on which versions of the OS/400 or i operating system you are running. When I tested semi-restricted state TCP/IP in my original article on an i 6.1 system, it seemed as if it only started the QSYSWRK subsystem. QSERVER and QUSRWRK were not started. However, Richard designated that QUSRWRK definitely needed to be started in his technique.

By default, some of the host server jobs run in either the QUSRWRK or QSERVER subsystems. And QSYSWRK contains a number of TCP/IP server jobs and the QSQSRVR jobs that are used to execute commands from client-side SQL jobs. So my gut feeling is that if you’re going to use this technique, you will probably want to manually start all three subsystems to ensure you can use any necessary TCP/IP functionality.

Richard also had a good comment about checking and adjusting prestart job entries in QSERVER, QSYSWRK, and QUSRWRK before bringing them up in semi-restricted state. I don’t usually put prestart jobs in these subsystems, but different shops do different things. And if you’re checking for prestart jobs, be sure to also check for autostart jobs that can start running jobs during subsystem activation. And don’t forget to put back any prestart or autostart entries that you removed for semi-restricted TCP/IP, before you bring your system back up live.

On Semi-Restricted State TCP/IP, Suggestion #2

As opposed to Richard’s suggestion, which displayed another way to start TCP/IP while in restricted mode, Luis Rodriquez came up with a different slant on starting TCP/IP and other system functions without restarting the entire system. Luis wrote:

One thing I did years ago was to use a data area object (*DTAARA) for controlling the execution of my startup CL. I created a data area called IPLCONTROL and filled it with parameters that defined what I wanted to do.

I then added a Retrieve Data Area (RTVDTAARA) statement to my QSTRUP program. RTVDTAARA pulls in the parameters the program uses to determine whether to run various commands. So if I had written ’10’ in the data area, the first ‘1’ would activate the QSTRUP program section where all the STRSBS commands are executed and the ‘0’ would have avoided the start of, say, QSPL. That way, I have good control about what goes on inside my startup program without changing system values or having to recompile programs.

Luis’ technique doesn’t invoke semi-restricted state, but it gets the job done. The only issue is that working with binary data can be tricky if you have multiple parameters. Setting a pair of ‘0’s and ‘1’s like Luis suggests isn’t bad, but if you get up to a 10-digit binary number that controls all your QSTRUP commands, it might be easier to make a mistake when setting parameters.

Does Semi-Restricted State Work on i 6.1 and i 7.1?

A reader named Dan wrote in to ask whether my technique of IPLing into restricted state with my system TCP/IP startup attributes equal to *YES would work with the i 6.1 and i 7.1 operating systems. It definitely works for i 6.1, because I just restarted a partition like this on a 6.1 system a few weeks ago. While it works for i 6.1, I can’t speak for i 7.1 because like most IBM i shops, I haven’t moved up to 7.1 yet. So if anyone has tried invoking semi-restricted state on an i 7.1 system, please let me know.

More Audit Protection for Vendor Profiles

Regarding my article on how to handle vendor user profiles during an audit, Rich Loeber of Kisco Systems checked in with a vendor viewpoint by suggesting the following idea.

Regarding securing required vendor profiles for auditors, we always tell our customers to use the two techniques that you have in your article: disabling the user profile; and setting the profile password to *NONE. One additional thing we tell them is to set their vendor profile up with the Initial Menu (INLMNU) parameter set to *SIGNOFF. This is just one more way to make sure that the profile cannot be abused. Our profiles often require All Object (*ALLOBJ) and Security Officer (*SECOFR) special authorities so having this third disabling parameter set up is comforting to the customers.

Setting INLMNU to *SIGNOFF tells the operating system that if the user manages to sign on with that user profile and password, the system will automatically sign them off. With the other two profile changes in the article, using all three parameters completes a trifecta of profile parameter changes that can make it nearly impossible for someone to sign on with a particular profile.