Re: Virtual device names and impact on data areas -- BPCS-L

Rick said:

>  BPCS V6.0.02   AS400 Mixmode
>  
>  We had a problem with user output queues changing randomly within our BPCS 
>  environment.  

We had the identical scenario on BPCS 405 CD, but it hurt us more with
printers, and we are no longer having the problem on anything like the same
scale, but our fix won't work for you, so perhaps I can make some suggestions
based on what we figured out along the way.

Our fix was to tell people who use virtual addresses 

1. Do not be signed onto BPCS/400 via pass-through, or dial-in, at the same
time as someone else who needs a virtual address because you will crash each
other.  

But if you absolutely positively must be on at the same time, do not be into
the same collection of modules --- e.g. if one virtual addressed person is in
some version of customer order maintenance, shipping, billing etc. then the
work areas start with letter B then first 8-9 characters of virtual address,
so no other virtual addressees, signed onto the same environment, had better
be concurrently in anything related to customer orders.

2. Agree among yourselves on which job environment settings you are going to
use, such as default spool that does not have a printer attached, so that you
can move out your stuff as needed.  Just in case someone else reset values
contrary to the general agreement, EVERY TIME you sign-on, first go to the
settings & compare them with the agreed on picture & if you need something
else temporarily, put them back again before you sign-off.

3. We made equipment & pass-thru configuration alterations to dramatically
reduce the need for virtual involvement, then our PC crew purchased emulations
that added to the virtual mess, instead of following my reccommendation to buy
PC connections that do not use the troublesome virtual method.

We still have users who violate these principles, particularly in the customer
order maintenance area & I suspect that is one of the reasons our customer
orders are so often in a mess that the users are unable to explain, although I
suspect the amount of damage being caused, in order of big scale to smaller is
1. Users who have abnormal job termination & keep it a secret.
2. A particular DFU jockey who really needs one of those BPCS for Dummies
manuals from SSA's partners - I just found out Slicker's are for BPCS V6 not
V4.
3. My own struggles to fix customer orders that have gone to Hades.
4. Multi-session users who cannot remember why pass-thru is non-smart into the
same set of applications, so they do it without thinking about the
consequences.

>  On virtual device names, the AS/400 may assign up to a 10 position number. 
>   ( qpadev000Y)   Within BPCS, when you do a F13 to display or change 
>  Workstation data, notice the data area name in the top center of the
screen. 

It is a whole lot worse than you realize.  Check the DOC on overall system
logic -- BPCS 405 CD is SSALOG00 in BPCSDOC in the software objects library.
I imagine yours is in a similar area.  Basically there are tons of work areas
created in applications throughout BPCS in which the first couple letters have
to do with the nature of the application & the last 8 letters come from the
virtual device name.  The document supposedly lists all the programs & file
names where this is going on.

>   In my example, my workstation device name is QPADEV000Y 
>  and BPCS assigns a data area for the workstation of QQPADEV000.   
>  Notice, due to the length of the name and the extra Q Bpcs puts in front 
>  of the data area name, the Y is dropped from my data area.  
>  What this is causing is for anyone else entering BPCS with a similiar 
> device name, once BPCS adds the Q to the front of the data area, 
>  then my data area and someone else's will actually be the same. 
>   IF someone else changes their output queue inside this, mine will also 
>  adapt their change since both are using the same data area, thus my output 
>  queues are changing randomly.

As I stated earlier, this is only the tip of the iceberg.  You really need to
check your BPCS DOC, for which you either need SYS authority, or a small
cluster of DOC #s - enough for you to get into & see / print them & actually
if you have command line authority & can WRKMBRPDM you can bypass BPCS
security on viewing SSA's documents.

>  My question is, can you make the system only use so many characters when it
>  assigns virtual device names and if not, how do I stop this conflict from 
>  happening.
>  
>  Thanks for any suggestions.

This month we upgraded OS/400 from V3R7 to V4R3 - I don't remember which V$R#
did it but one of them changed the IBM rules on this a bit - something else to
check out - I used SNDPTFORD to get summary stories & have not made the time
to study beyond that.  

There are several places in IBM OS innards where we can adjust ceilings on how
many of these virtual names can exist.  Perhaps less for you, since we are
using M36.  What happened with us is that IBM would assign, at time of user
sign-on the next one that is available, from a bunch that have been previously
created & my thinking is that where ever IBM stores these QPADEV code names,
perhaps we could change them to some other legal name, according to the IBM
rules, using totally unique names when the last 2 characters are lost to BPCS.

In other words, this is a question for someone who understands whether or not
IBM OS is really doing what it looked like it was doing to us - not assigning
next numerical combination, but next available assignment from those not in
use & can we alter those names, so that when IBM assigns one, it uses our
altered names & not the orginals?  I have not actually tried this, but we
alter a lot of other stuff that IBM assigns, and have had no trouble with that
principle so far, once we figured out how, usually with help from a lot of
experts.

If that is doable, then it also solves the BPCS problems - both the minor
nuisance you discovered and the more serious ones we had to cope with, and may
still be having occasionally.

Another area of exploration might be how the user profile gets to BPCSMENU in
the first place.  It just might be possible to get to something else first
based on User-Name.  We have our profiles setup so that most users go straight
to BPCSMENU program, then their second program is *SIGNOFF.  But perhaps we
could go someplace else first then to BPCSMENU.  Supposedly there is some way
to have other OS4 stuff occur before the first program at time of sign-on,
similar to how your Message Queue lights up, irrespective of your profile
preferences.

Once again the SSALOG00 document tries to explain environment definitional
issues.  I would not like the idea of mucking around here to have different
users sign onto a subtly altered library list, in which a substitution for the
Q-data area is in their own unique library list addition, but someone more
ambitious than I might make it happen then share solution with BPCS_L (hint
hint).

However, if I was taking the chance, I might modify BPCSMENU so that upfront
it creates a library name based on user sign-on name - perhaps the identical
10 character ceiling, no Q or B or anything in front.  If the library does not
exist, then create it & copy into it the data area that BPCS usually uses for
job queue & printer & other rules, with the same name, and place this library
at the beginning of the user's library list.  I am just speculating here in an
area where I am far from being an expert, but my thinking is that with it
being at front of library list, access to the data area would come out of
library unique to user-name, and your known problem would go away, but what
would that do to the other problem I allude to here?

Hoping that I have given you some nutricious food for thought that you can
use.

Al Macintyre
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---