Admin Alert: Prototype Instructions for Running TCP/IP in i5/OS Restricted State
December 1, 2010 Joe Hertvik
|
A reader recently wrote asking how to configure i5/OS to use TCP/IP communications while in restricted state. Here are my prototype instructions for accomplishing this task. Due to constant uptime demands on my machines, however, I haven’t yet been able to fully test this process. But I invite any interested readers to test these instructions and write in with suggested changes. I’ll publish the best comments in a future article. Getting Started with Restricted State TCP/IP If you’re running recent versions of i5/OS or the i operating system, you should be able to run a subset of TCP/IP functions in restricted state. IBM added this capability in order to support a limited set of capabilities that restricted save and restore operations might need, especially operations that allow the operating system to talk to a backup device via TCP/IP. The key to this process is that you should be able to piggyback on this support for other reasons, if you just follow the rules. Here’s how I would try to set up an iSeries, System i, or Power i box to talk to a remote server via TCP/IP while the system is in restricted state. First, you must understand that TCP/IP can be started and run under restricted state, but there’s a catch. You can’t start up any TCP/IP servers, point-to-point profiles, or the IPv6 portion of the TCP/IP protocol stack. These features cannot be started because your i5/OS or i system is in restricted state and the subsystems that control these features will not be running. The only TCP/IP feature that can be started and used while the system is in restricted state are the IPv4 interfaces, because they do not require individual jobs running in a separate subsystem in order to start up. This means that if you have one or more IPv4 interfaces configured on your system, you can use those interfaces to communicate with the outside world while your system is in restricted state. To accomplish this, here’s an untested drill I put together according to IBM’s Tips and Techniques for Using TCP/IP on i5/OS Redbook. The Drill 1. First make sure that there isn’t any active processing activity occurring on your system and that it’s OK to put the system into restricted state. Then put the system into restricted state by using the following End Subsystems (ENDSBS) command. ENDSBS SBS(*ALL) DELAY(60) This command will give any running jobs 60 seconds to complete before shutting down all processing and putting the system into restricted state. You can monitor for when the system gets into restricted state by looking for the following CPF0968 message in the QSYSOPR message queue. CPF0968 - System ended to restricted condition 2. Start TCP/IP in restricted state. This can be done by running the following Start TCP (STRTCP) command. STRTCP STRSVR(*NO) STRIFC(*NO) STRPTPPRF(*NO) STRIP6(*NO) As mentioned above, this starts TCP/IP without starting up any TCP/IP servers, interfaces, point-to-point protocols, or any of the IPv6 interfaces. This is important because if you try to start TCP/IP in restricted state with any other parameters, TCP/IP will not start. Check the QSYSOPR message queue to insure that TCP/IP was started correctly by using the following Display Message (DSPMSG) command. DSPMSG MSGQ(QSYSOPR) 3. Once TCP/IP is started, you can then start your IPv4 interface with the following Start TCP/IP Interface Command (STRTCPIFC) command. STRTCPIFC INTNETADR(XXX.XXX.XXX.XXX) 4. At this point, you should be able to reach your i5/OS box through the IPv4 interface you just started. You can check whether the interface is active by running a simple PING command from another computer on the same network. PING XXX.XXX.XXX.XXX 5. This procedure assumes that you’ll want to run a pre-written program to monitor and send out a TCP/IP alert if a certain situation occurs. If you’re running an option 21 backup, you may want to send an email or text message alert to your system operators if you need to initialize a tape or if there’s an error message. If you want to run your program interactively, you can simply call it from the command line of your system console session and it will run. However, interactive processing may not be advisable in restricted state. If your program goes into a loop, you may have trouble cancelling it because the system console will be the only active job in your system. You’ll probably want to run your TCP/IP communications program as a batch job running in the QCTL subsystem (the default controlling subsystem). 6. The problem with running batch jobs in QCTL is that if you submit them as batch jobs, they will automatically run as a priority 10 job in QCTL. Recall that priority 10 is also the same priority that the system console job runs at. And like running an interactive job from the system console job, you may have trouble if your priority 10 batch job starts looping and consuming excessive system resources. You may not be able to end an out of control batch job because the system may not give the system console enough cycles to do anything. The only cure for this is to enable QCTL batch jobs to run at a higher priority than the system console. To run QCTL batch jobs at priority 50, you’ll need to set up a routing entry to run batch jobs at priority 50. You can do this by running the following Add Routing Entry (ADDRTGE) command to the QCTL subsystem. ADDRTGE SBSD(QCTL) SEQNBR(650) CMPVAL(QBATCH) PGM(QSYS/QCMD) CLS(QSYS/QBATCH) i5/OS and i operating systems use routing entries to determine how to process incoming jobs. Each routing entry includes which system class objects should be used to designate the runtime priority an incoming job should be run at. This command adds a new routing entry to the QCTL subsystem that designates that when a job enters the QCTL subsystem with its routing data parameter equal to ‘QBATCH’, the job will execute using the QSYS/QBATCH class object. The QBATCH class object specifies that any jobs using that class will run under priority 50. Note: If QCTL isn’t the name of your controlling subsystem, add the routing entry to whatever controlling subsystem that you are using. 7. To submit a batch job to QCTL and have it run at priority 50 inside the controlling subsystem, submit the job with the following Submit Job (SBMJOB) command. SBMJOB CMD(command) JOB(job_name) JOBQ(QSYS/QCTL) RTGDTA(QBATCH) Jobs submitted to the QSYS/QCTL job queue run in the QCTL subsystem, and an unlimited number of jobs can enter and run in QCTL at the same time. Because you have the word ‘QBATCH’ designated in the SBMJOB Routing Data (RTGDTA) parameter, the job will run with the values specified in the QBATCH class object. By default, the QBATCH class assigns a run priority of 50 to any jobs that are using it and the job will run as a batch job in the controlling subsystem. At this point, you should be able to run your designated TCP/IP program in QCTL batch while the system is restricted. If written correctly, the job should be able to use the active IPv4 interface to communicate with the outside world, as needed. 8. When you’re finished with your restricted state processing, the final trick is to end i5/OS IPv4 interfaces and TCP/IP before you exit restricted state. If you don’t do this, you may experience unexpected results when you restart your system and come out of restricted state. To end these items, issue the following End TCP/IP Interface (ENDTCPIFC) command and End TCP/IP command. ENDTCPIFC INTNETADR(XXX.XXX.XXX.XXX) ENDTCP OPTION(*IMMED) This should end TCP/IP cleanly, allowing you to start up again without any issues. So this is my prototype program for running TCP/IP communication jobs in restricted state. As I mentioned, I’m not able to completely test it on my system because I’m limited as to when I can put my systems in restricted state. Please feel free to try this routine on your system and email me the results via the IT Jungle team’s contact Web page. I’ll publish the best entries in a future issue.
|
