RE: Disabling Qinter... (Follow up question) -- MIDRANGE-L

The basic issue here is that if you want a device allocated to a subsystem
other than QINTER with absolute certainty you must  either exclude that
device from qinter or tell QINTER not to allocate it on the start of the
subsystem.

We allow devices starting with "X" to run in QPGMR when QINTER is down.

The subsystem descriptions look like this:

--------------------------------------------------------

Subsystem description:   QPGMR          Status:   ACTIVE
                                                        
Work station name . . . . . . . . :   X*                
Job description . . . . . . . . . :   *USRPRF           
  Library . . . . . . . . . . . . :                     
Maximum active jobs . . . . . . . :   *NOMAX            
Control job at  . . . . . . . . . :   *SIGNON           

--------------------------------------------------------

Subsystem description:   QINTER         Status:   ACTIVE 
                                                         
Work station name . . . . . . . . :   X*                 
Job description . . . . . . . . . :   *USRPRF            
  Library . . . . . . . . . . . . :                      
Maximum active jobs . . . . . . . :   *NOMAX             
Control job at  . . . . . . . . . :   *ENTER             

--------------------------------------------------------

This way QPGMR get the devices that start with "X" unless they specifically
transfer to QINTER.  

<commentary>
I do not like controlling users by device description, it is too easy to get
around.  I prefer to control users by their initial programs, i.e. using a
data area to set system availability.  In my opinion this is easier to
manage when you have groups with different availability needs.
</commentary>

Regards,

Scott Ingvaldson
AS/400 System Administrator
GuideOne Insurance Group

-----Original Message-----
date: Fri, 5 Mar 2004 20:42:46 -0500
from: "jt" <jt@xxxxxx>
subject: RE: Disabling Qinter... (Follow up question)

I would say this describes the way the devices Actually are allocated much
better than I did, Tom.  It would be an asynchronous task, I'm sure, and
depending on how the internal tables are stored, and such you've said, it
Would HAFta be slightly unpredictable.  (Except the first SBS to allocate a
DEV should always get the lock, afaik...  Dunno how multiple cores handle
task dispatching, of course.)

Afaik.. Thaz a'least one Mystery down t'day done been Solved, Tom!...;-D


| -----Original Message-----
| From: midrange-l-bounces@xxxxxxxxxxxx
| [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Tom Liotta
| Sent: Friday, March 05, 2004 8:23 PM
| To: midrange-l@xxxxxxxxxxxx
| Subject: RE: Disabling Qinter... (Follow up question)
|
|
| midrange-l-request@xxxxxxxxxxxx wrote:
|
| >   9. RE: Disabling Qinter... (Follow up question) (jt)
| >
| >So, the order the subsystems are started is the key, afaik.
| Again, that may
| >NOT be how it used to work but that's my recollection, and it
| Certainly may
| >not even apply any more as the OS sure Has Changed over the decades.
|
| I've had a slightly different impression over the years that
| somewhat explains the unpredictability of which subsystem gets
| the device. It isn't exactly which subsystem starts first,
| although that certainly can affect the outcome. I've thought it's
| more accurate that it's which subsystem attempts to allocate the
| device first, regardless of which starts first.
|
| Think of two subsystems started in a CL program one after the other:
|
|  ===> strsbs SBS1
|  ===> strsbs SBS2
|
| The first STRSBS command will complete almost immediately, and
| the second command is executed. We then have two subsystems
| starting up at the (more or less) same time. If you watch them
| perhaps via WRKACTJOB, you'll see them both running through
| devices trying to allocate them.
|
| Now, imagine SBS1 has all workstations listed for allocation
| while SBS2 is only defined to allocate device ZZZZZZZZ, which was
| created only recently after a whole bunch of other devices
| already existed.
|
| Since SBS2 has only the single device in its table, it almost
| certainly will be able to get it allocated before SBS1 has the
| time to get around to it. So even though SBS2 "started" last, it wins.
|
| I also have thought that device names, or identifiers, aren't
| necessarily stored with the subsystem description in alphabetical
| order, but instead in perhaps a FIFO order tied to the date/time
| it was first defined to the subsystem description. So, if
| ZZZZZZZZ had been the very first device created and assigned,
| SBS1 might be much more likely to get it before SBS2 can.
|
| Beyond the possible orderings of device identifiers, the handling
| of errors on various devices during allocation can slow the
| process significantly for one or the other subsystem. This would
| also decrease predictability.
|
| If somebody really knows how it works, it might be instructive to
| the rest of us.
|
| Tom Liotta
|
| --
| Tom Liotta
| The PowerTech Group, Inc.
| 19426 68th Avenue South
| Kent, WA 98032
| Phone  253-872-7788 x313
| Fax    253-872-7904
| http://www.powertech.com

   
This message and accompanying documents are covered by the Electronic
Communications Privacy Act, 18 U.S.C. §§ 2510-2521, and contains information
intended for the specified individual(s) only. This information is
confidential. If you are not the intended recipient or an agent responsible
for delivering it to the intended recipient, you are hereby notified that
you have received this document in error and that any review, dissemination,
copying, or the taking of any action based on the contents of this
information is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail, and delete the original
message.