Re: RE: Secondary console in QCTL

On Mon, 24 September 2001, Adam_Driver@kaz.com.au wrote:

> I might try it on a test machine, this is production. This is probably what
> happened, I just thought it was strange that QHST didn't show QCTL grabbing
> it in the first place. However, it is working now thanks to a workstation
> entry in QINTER with *ENTER rather than *SIGNON.

It might be that even IBM work management developers could give barely an 
educated guess as to how the timing would work on your machine. If you are 
running a fairly standard startup program that does STRSBS QINTER with no 
preceding delays (e.g., a loop that tests the status of other subsystems before 
allowing the next one to attempt to start or similar delays), then, as I 
understand things, predictability can suffer.

Lots of things happen while QCTL is starting. While workstation allocation is 
going on within it, it can also be autostarting jobs such as your startup 
program. If locks or whatever are encountered while running through devices for 
QCTL, QINTER can be starting elsewhere and it'll begin its own workstation 
allocation. You might have a *CONS workstation entry in QCTL that you don't 
have in QINTER; this might change the timing enough that QINTER device 
allocation speeds past QCTL (pure speculation on my part for illustration). The 
point is that the external subsystem descriptions may be very different, not to 
mention the obvious fact that the named controlling subsystem almost certainly 
does a couple additional things that affect timing. Further, depending on what 
happened before the previous shutdown to different device description objects 
or any other objects accessed during startup, every startup will have somewhat 
different timings.

I suspect that the only way to maintain any predictability is by coding the 
startup program for it. For example, the very first thing a startup program 
might do is check object locks on QCONSOLE *DEVD to see if it's been allocated 
to QCTL yet or maybe call the Retrieve Subsystem Info (QWDRSBSD) API to see if 
it returns status *ACTIVE yet for QCTL, and do a DLYJOB loop until true. (I'm 
not sure either of those would really work, just using them as examples.) Once 
a stable state of QCTL is reached, then STRSBS for the next subsystem and do a 
DLYJOB loop on it; likewise do similarly for STRTCP or STRMSF or any supporting 
function, each time waiting for stability before starting a new startup command.

I doubt anybody but IBM or possibly benchmarkers would be interested in such a 
startup program though. So, I figure predictability for which subsystem gets 
what and when does it get it -- assuming both configurations allocate the same 
devices or whatever -- will remain unpredictable.

Tom Liotta



--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788
Fax  253-872-7904
http://www.400Security.com


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