Wilt, Charles wrote:
-----Original Message-----
<snip>
I once ran across a customer who didn't use the QSTRUPPGM system
value. THAT threw a nasty little twist into an installation routine!
(But I learned a LOT along the way about what that system value
really did.)
Tom, I'm curious about this...care to expand?
I assume this means the had QSTRUPPGM as *NONE.
So how did they handle startup?
Charles:
Until I actually _looked_ at what happened during system startup, it
didn't make a lot of difference to me how it worked. It didn't occur
to me that someone would want to do it any differently. But when you
start installing stuff in a lot of other companies' systems, you get
a quick education into how many different ways there are to view the
same things.
In short (this is a general description, not full details), when
your system starts, the subsystem named in QCTLSBSD is started.
This, of course, is generally QCTL or QBASE. (Not guaranteed.)
If you look at QCTL, you'll _probably_ see an auto-start entry --
QSTRUPJD. It generally points to job description QSYS/QSTRUPJD, but
doesn't have to.
If you look at that *JOBD, you'll probably see that it runs under
user profile QPGMR and that it causes program QSYS/QWDAJPGM to be
called. (Can be changed if desired to a different *JOBD, a different
profile, a different program...)
Program QSYS/QWDAJPGM generally simply checks to see if system value
QSTRUPPGM names a program, and, if it does, then it calls that program.
For most discussions, that about all there is to it.
But as with just about every part of most systems, you can customize
at any point. You can add your own auto-start entry or change the
one that IBM supplies. You can create your own *JOBDs. You can run
under your own profiles. You can call whatever programs you choose.
Note that all of this is why [STRSBS QCTL] generally works so well
to come up from restricted state. QCTL starts, the auto-start entry
goes active, the *JOBD indicates how to reach the startup program,
the startup program does the various details...
You can even do like Evan did and structure your own startup.
As long as you get the controlling subsystem started and cause the
system components that you need to run in their proper order, it
doesn't matter too much what techniques are used. (Well, except for
the likely confusion that might be caused to those who come after you!)
The majority of us have probably not seen any system startup
sequence that wasn't what IBM sent out with the system when they
shipped it. If you see something often enough for enough years, you
can become blinded by it.
It can be a surprise when you're first forced to see what's really
there, even if it makes perfect sense.
Tom Liotta
midrange.com
