|
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/
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
