QStrUp and v4r4m0

[Guest.Visitor]

I recently upgraded my OS to v4r4 from v4r2. My original QSTRUP worked as listed here without a hitch... QSYS/STRSBS SBSD(QSPL) MONMSG MSGID(CPF0000) QSYS/STRSBS SBSD(QSERVER) MONMSG MSGID(CPF0000) QSYS/STRCLNUP MONMSG MSGID(CPF0000) QSYS/RTVSYSVAL SYSVAL(QCTLSBSD) RTNVAR(&CTLSBSD) IF COND((&CTLSBSD *NE 'QCTL QSYS ') *AND (&CTLSBSD *NE- 'QCTL QGPL ')) THEN(GOTO CMDLBL(DONE)) STRTCP /* START TCPIP */ QSYS/STRSBS SBSD(QINTER) MONMSG MSGID(CPF0000) QSYS/STRSBS SBSD(QBATCH) MONMSG MSGID(CPF0000) QSYS/STRSBS SBSD(QCMN) MONMSG MSGID(CPF0000) QSYS/STRSBS SBSD(QSNADS) MONMSG MSGID(CPF0000) DONE: QSYS/RTVSYSVAL SYSVAL(QSTRPRTWTR) RTNVAR(&STRWTRS) IF COND(&STRWTRS = '0') THEN(GOTO CMDLBL(NOWTRS)) CALL PGM(QSYS/QWCSWTRS) MONMSG MSGID(CPF0000) STRHOSTSVR SERVER(*ALL) /* STARTING HOST SERVERS */ NOWTRS: RETURN CHGVAR VAR(&CPYR) VALUE(&CPYR) ENDPGM The new QSTRUP with v4r4 was included as follows... . . . QSYS/STRSBS SBSD(QSPL) /* START QSPL SUBSYSTEM */ MONMSG CPF0000 QSYS/STRSBS SBSD(QSERVER) /* START QSERVER SUBSYSTEM */ MONMSG CPF0000 QSYS/STRSBS SBSD(QUSRWRK) /* START QUSRWRK SUBSYSTEM */ MONMSG CPF0000 QSYS/STRCLNUP MONMSG CPF0000 QSYS/RTVSYSVAL SYSVAL(QCTLSBSD) RTNVAR(&CTLSBSD) IF ( ( &CTLSBSD *NE 'QCTL QSYS ' ) + *AND ( &CTLSBSD *NE 'QCTL QGPL ' ) ) THEN(+ GOTO CMDLBL( DONE ) ) STRTCP /* START TCPIP */ QSYS/STRSBS SBSD(QINTER) /* START QINTER SUBSYSTEM */ MONMSG CPF0000 QSYS/STRSBS SBSD(INVCTL) /* START INVCTL SUBSYSTEM */ MONMSG CPF0000 QSYS/STRSBS SBSD(QBATCH) /* START QBATCH SUBSYSTEM */ MONMSG CPF0000 QSYS/STRSBS SBSD(QCMN) /* START QCMN SUBSYSTEM */ MONMSG CPF0000 QSYS/STRSBS SBSD(QSNADS) /* START QSNADS SUBSYSTEM */ MONMSG CPF0000 DONE: QSYS/RTVSYSVAL SYSVAL(QSTRPRTWTR) RTNVAR(&STRWTRS) IF ( &STRWTRS = '0' ) THEN(+ GOTO CMDLBL( NOWTRS ) ) CALL PGM(QSYS/QWCSWTRS) MONMSG CPF0000 STRHOSTSVR SERVER(*ALL) /* STARTING HOST SERVERS */ NOWTRS: RETURN CHGVAR &CPYR &CPYR ENDPGM The main difference I can tell is the QUSRWRK subsystem starting up before the STRCLNUP. Then the call to STRTCP. Then following up with QINTER, QBATCH etc... just as before. The problem is that I get error messages during the job QSTRUPJD, stating "Routing entry sequence number xxxx already exists." With the routing sequence number changing forcing several errors during startup. Is the Prestart Jobs when QSYSWRK is started duplicating some of the work done by STRTCP, thus giving me a MSGW with 'Job complete but with errors"?? If so, do I need to change the routing entries for the Prestart jobs in QSYSWRK? Do I manually STRTCP after the IPL is complete? Is there another way I can achieve the same startup that I had originally without using QSYSWRK and starting STRTCP? If I ignore the error message, the job completes normally, thus finishing the job and starting my QINTER, QBATCH and other subsystems so that my users can start work, or I can dial in through the network. Any suggestions or knowledge from previous experience with this is greatly appreciated. Rick

[GlenKerner]

Rick, I don't use QUSRWRK subsystem. The order that I have in my start up is: STRSBS SBSD(QSVCDRCTR/QSVCDRCTR) STRSBS SBSD(BBIGPL/QCMN) STRSBS SBSD(QSYS/QSYSWRK) STRTCP /* START TCP/IP */ STRSBS SBSD(QSERVER) STRPJ SBS(QSERVER) PGM(QIWS/QZDAINIT) STRHOSTSVR SERVER(*ALL) /* START TCP/IP HOST SERVERS */ STRTCPSVR SERVER(*ALL) /* START TCP/IP NETWORK SERVICES */ STRSBS SBSD(QCTL) STRSBS SBSD(QSNADS) STRSBS SBSD(BBIGPL/QBATCH) STRSBS SBSD(QSPL) Then other subsystems, PM/400, and device vary ons. After each start command it does monitor for CPF0000 & CPF9999. I haven't seen the message you described but I also haven't looked. The monitors may be capturing it since it is really just a warning message. (*note: The program already existed when my boss upgraded to V4R4 (before my time) and when I got here there were some problems with all services being started. I had to rearrange the order to this to get them all up) Glen

[Guest.Visitor]

Rick, Our startup pgm starts QSYSWRK and QUSRWRK after all the other subsystems (QBATCH QINTER, etc), and before the STRTCP runs. After TCP starts we start the TCP Servers (redundantly) and the HOSTSVRS. The program has been this way from V3R7 thru V4R5. The only changes have been the addition of whatever is new for the release, and always put in position after all the normal stuff is started. No problems so far. HTH some. Happy holidays. Jack

[Guest.Visitor]

OK, let me ask a strange question... Just what does QUSRWRK and QSYSWRK do? What subsystems and processes do they start that are relevant to 'daily' processing? Thanks! Rick

[Guest.Visitor]

Rick, QSYSWRK runs all the TCP/IP daemons for all the services configured. Third party software vendors also add their daemons to this subsystem. QUSRWRK was introduced with V4R4. It runs some additional network services related to/started thru Operation Navigator facilities (I think). I'm sure someone else can add more definition. Regards. Jack

[Guest.Visitor]

OK, I made the switch and ran a test last night. After adding the MONMSG CPF0000 after the STRTCP entry and moving the QSYSWRK to the end of the Subsystem start list, I was able to IPL and get started without any MSGWs on the WRKACTJOB screen. (A first since the upgrade) The problem now is, that the VRYCFG is not being run on my display device descriptions. I have a specific naming convention, so using the QPADEVxxxx doesn't work for me. What would have changed so that the VRYCFG isn't running now? Is there a particular order it has to run in before it tries to allocate the Display Devices? Rick