I had an SQL stored procedure go nuts (more on that in another thread). It connected from one system to various other servers to do this action:
CREATE PROCEDURE ROB.PROPAGATE_QLNKOMT()
LANGUAGE SQL MODIFIES SQL DATA
SET OPTION DATFMT = *ISO
P1 : BEGIN
DECLARE OMIT_LIST CHARACTER VARYING ( 32000 ) ;
SELECT FSXCMD INTO OMIT_LIST
FROM QUSRBRM . QA1AFS
WHERE FSNAME = 'QLNKOMT'
;
UPDATE RACK1HST . QUSRBRM . QA1AFS
SET FSXCMD = OMIT_LIST
WHERE FSNAME = 'QLNKOMT' ;
UPDATE GDWEB . QUSRBRM . QA1AFS
SET FSXCMD = OMIT_LIST
WHERE FSNAME = 'QLNKOMT' ;
UPDATE GDISYS . QUSRBRM . QA1AFS
SET FSXCMD = OMIT_LIST
WHERE FSNAME = 'QLNKOMT' ;
... repeat for more lpars...
The update worked fine for RACK1HST and GDWEB. Went absolutely nuts on GDISYS. Generated so many QRWTSRVR jobs the system came darn close to going casters up.
All lpars are running 7.4 and are at the same PTF levels.
I'll concentrate on the error on another thread. This thread is more on mitigating the damage.
The prevention to having so many QRWTSRVR jobs spawn is twofold. One is to change the number of prestart jobs which may run
CHGPJE SBSD(QUSRWRK) PGM(QRWTSRVR) MAXJOBS(50)
they also had me use Navigator, Network, Servers, TCP/IP Servers, DDM, Properties, Subsystems, Alternate action and change that to Reject.
Now I no longer get infinite number of jobs.
You may want a larger number of prestart jobs. This is a development lpar and gets minimal use. Since the goal was to prevent the thousands of jobs initiated I could have made it much higher.
Failure to set the option to "Reject" will just have it stop using prestart jobs and generate BCI jobs instead until your system fills up. This I know...
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
midrange.com
