Hardware Mapping

from Al Macintyre

I have an idea for an improved AS/400 report, more friendly to a spectrum of 
users, on the connected hardware that will make it easier for everyone to 
manage our configuration, and also make life easier for end users who 
occasionally need to know a bit of information about some work station 
address, but I do not know exactly the best way to implement it & hope that 
by sharing my exploratory ideas here, other folks will suggest ways to 
further improve this & make it practical.

There may be TAATOOLS or Hawkeye or other 3rd part resources that do this, 
but my employer does not have this stuff & there is no expectation this might 
change in the forseeable future.  It is beneficial for me to continually 
improve my 400 understanding anyway & I have a mountain of shareware to 
trainscribe via twinax from various e-mail & URLs.  Getting access to someone 
PC in the evenings to get this stuff in another way is another challenge for 
me some time.

Right now the local 400 map is MIS-familiarity in which we have to look in 
2-3 places to get all the information desired, and I am thinking to have a 
report / inquiry that puts it all in one picture so other people do not have 
to know the 400 commands to get at the stuff in all places, just get it off a 
menu.  

But the remote 400 map is either non-existant or incredibly MIS-hostile of 
value to almost no one.  We need something on the 400 as friendly as we had 
with S/36 CNFIGSSP.  In the absense of this, perhaps a series of *OUTFILEs 
can get the 400 data to feed into a program we write to get the equivalent 
picture.

Think a clone of PRTDEVADR, 
which adds a line or two to each connected address on the map,
or GO DEVICESTS/10 does all PRTDEVADR without any blanks to fill in what we 
called the various controllers but all too often I forget DEVICESTS & hard 
time finding it from clues like CFG

We have been maintaining the description from WRKCFGSTS *DEV enter & F14
such that anyone looking there sees 
"Jane Doe session 3" or
"Department-X location-Y" 
such as "Just outside Production Office" or
"Far North East Corner of Factory"
which facility's "Shipping Office"

I would want that description line to be added to my PRTDEVADR clone to make 
it incredibly easy for anyone looking at the local map to correlate which 
work station is which user or shared location.  RTVOBJD OBJ(work station 
address) OBJTYPE(*DEV) TEXT(&TEXT) or alternatively figure out how to get at 
the data shown on WRKCFGSTS that is most essential to mapping ... port-switch 
or virtual ... with help of DSPOBJ *DEVD to *OUTFILE

Periodically we have some disconnect reconnect problem or upgrade hassle in 
some office & the description reverts to some autoconfig language, so I want 
to periodically list all that have that language so we can rekey the 
meaningful stuff before we hurting for "Where the heck is DSP57?"

WRKCFGSTS *DEV F4 *PRINT reference - major clue is who signed on right now
DSPLOG - several more clues who was last person to sign onto that address

In addition to this, I would like to show if a connection is via simple 
twinax, 5250 emulation, client access, etc.  Say which it is on the map.  It 
may be that the 400 does not know, or that data is in some device field(s) 
whose significance has escaped me.

I was contemplating an intermediate work file with names of device addresses 
and some fields to which we add such essentials.  One field would be user 
name who normally operates that work station, because 
RTVUSRPRF User-Name TEXT(&TEXT) STATUS(&DISABLED) PWDEXP(&EXPIRED) 
PRVSIGN(&LASTON) LMTCPB(&CMDLINE) SEV(&JOBLOG) USRCLS(&IBMCLASS) 
OUTQ(&PRINTEM) PRTDEV(&PRINTER)
can get at the text description & other neat & useful stuff to help with a 
variety of trouble-shooting to figure out why some user is having this or 
that problem

We have populated our user text description after user name & title or 
department affiliation with location ending in telephone extension number

We had populated our WRKCFGSTS *DEV enter F14 with spelled out User Name, but 
we could substitute same name as RTVUSERPRF so that DSPOBJ *DEVD to *OUTFILE 
would have User-Name in TEXT so I could then link that to a similar dump of 
public information on users.

However, I want some information more public than others.

As new staff work on our 400 configuration this tool then could help everyone 
with

address ABC1234 has some error messages
key in address ABC1234 to inquiry screen & be told 
the current work station settings for which printer JOBQ etc.
whose office that device is in
what type of connection (twinax, CA etc.)
and public info about the person who normally works in that office
(from user profile text line & perhaps a few other details like whether or 
not they have command line authority & what their BPCS access chart looks 
like)
in other words - all the little bits & pieces of clues we now gather from 
many different places & have to remember "What was the command to get that 
again?"

but for the new MIS person, or the new system helper - there are all these 
nuances that are important in diagnosing problems, but instead of struggling 
to teach them how to get the data, with reference lists of 400 commands & 
menus, this tool would mean that the focus can be on interpreting the data

Another variant is when some end user gets an error message
you cannot update whatever because of JOB _____ & it identifies the work 
station address that their update conflicts with
so go to another session & run the job which tells you info about the work 
station of your choice (less detail than MIS trouble shooter needs)
whose work station is that
who is signed onto that work station right now
if it is signed off, who was the last person to use it
phone extension where that work station is located

Software can extract that stuff from 400 system information
think about what stuff people probably need to gather or access
create simple to use inquiry program to give this kind of data to the users
extracting only the data we need to solve the typical challenges, 
without being buried in the other extraneous details that are there.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---