Re: start-up program QSTRUP

Dan:

On Thu, 07 June 2001, D.BALE@handleman.com wrote:

> 1.  Can I safely use CHGJOB LOG(4 00 *SECLVL) LOGCLPGM(*YES) in this program?

It's safer and easier to change the job description itself. Use the auto-start 
job entry to point you to the job description to change. Default is 
QSYS/QSTRUPJD. External definitions mean no source code changes, etc.

> 2.  When I insert new commands to run, I believe I need to at least duplicate
> IBM's effort to monitor for escape messages.  IBM uses MONMSG MSGID(CPF0000) .
>  Is that enough?  I thought I have seen in the past where the absolute
> catch-all MONMSG monitored for CPF0000, CPF9999, & MCH0000.  Yea or nay?  What
> happens if a command fails and a message is issued waiting for a reply?  Will
> the console ever show a signon screen?

It's probably enough. Prompt the commands you add to see if any msg IDs other 
than CPFxxxx can be monitored for. A monitor for CPF0000 should catch CPF9999; 
any MCHxxxx messages that might show up are likely to mean something is very 
wrong and if you don't actually handle it, it's unpredictable how the rest of 
your program will run anyway. In any case, your console should be available 
even if other subsystems haven't been started.

My personal opinion is that IBM's default QSTRUP is a poor model to start from. 
I believe we all should determine a good model and say good-bye to old QSTRUP. 
For example, the first important statements should be a couple of CHKOBJs that 
verify that the real startup programs exist. Then the rest of the 
QSTRUP/startup program should simply call routines such as 'call StrMySbss' 
which does the appropriate initial STRSBSs, 'call StrMySvcs' which does the 
appropriate STRTCP and perhaps STRTCPSVRs and/or STRHOSTSVRs, etc. Once 
written, a decent new QSTRUP should never have to be changed itself, only the 
specific sub-programs would need additional or changed statements.

In some systems, I've inserted calls at appropriate points to a routine that 
executes commands from different source members. That way I can dynamically 
customize a QSTRUP for a single day or for a period of time without compiling 
at all. Simply add a statement to a source member that day.

If there's a need for a good open-source project, I think QSTRUP is an 
excellent place to start.

> 3.  Doesn't it seem odd that IBM qualifies all the commands except the MONMSG,
> IF, CALL, and others?  Don't these also have the same exposure to being
> "hijacked" by another library higher than QSYS in the library list?  Is it
> possible to have a library higher than QSYS during the normal execution of
> this command at IPL?  (Possibly the QSYSLIBL system library list?)

Although such commands might be "highjacked", what would they do? Someday just 
for fun, try to create a working replacement for CALL or IF (or MONMSG or DO 
or...) that has a command-processing program other than QSYS/QCLCALL or 
QSYS/QCLIF or duplicates of those programs. Sure, it can be done; but if it's 
done on your system, it's done by a clever programmer who already has access -- 
your security is already gone. Your startup program is the least of your 
worries. Or if your concern is simply that your startup won't run as expected, 
well, neither will anything else that day. You're probably best served by 
finding it in your startup. Do you qualify commands in your job scheduler 
entries? all SBMJOBs? every CLP you write? every call to QCMDEXC?

Overall, I'd call it an almost insignificant risk. But possible.

Tom Liotta

-- 

___________________________________________________
The ALL NEW CS2000 from CompuServe
 Better!  Faster! More Powerful!
 250 FREE hours! Sign-on Now!
 http://www.compuserve.com/trycsrv/cs2000/webmail/




+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---