× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We created a completely different program, not even named QSTRUP. You can
change the system value to be anything you want.

As you suggested, our startup program is a series of calls to other programs
which actually do the work. However, the first thing it does is look for a
program named ONETIME. If ONETIME exists it is renamed to @ONETIME and then
called. We would use that if we needed to do something special right after
the IPL.

Albert York     

        -----Original Message-----
        From:   thomas@inorbit.com [SMTP:thomas@inorbit.com]
        Sent:   Thursday, June 07, 2001 8:06 PM
        To:     MIDRANGE-L@midrange.com
        Subject:        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
        +---
+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.