Re: This way or that?

> From: JGiusto@patuxent.com (Joe Giusto)
>  
>  How about a process that would run periodically to remove members for
>  deleted users or members that have not been accessed in x number of days?

& Empty Members

Yes, we need to write the CL & stick it in IBM Job Scheduler or Help Robot or 
whatever we have, so we can set it up then forget it.

> From: DBale@lear.com (Bale, Dan)
>  
>  Here's the problem as I see it with using device IDs 
>  as names for members or
>  as a key field for any purpose that extends past the end of the job.  In
>  most Rumba and CA shops I've been in, you can never count on getting the
>  same device ID from day to day.  (I don't know whether device IDs can be
>  "hardcoded".)  Maybe you're not a Rumba or CA shop now, but what if you
>  become one in the future?  Also, what do you do if a user's workstation 
goes
>  down and they have to use another workstation?
>  
>  Too much M.I.S. personnel intervention for my taste.  If your data entry
>  users are only allowed one signon session, why not use their user ID 
instead
>  of the device ID?  You avoid both aforementioned problems.  I will admit to
>  not having done data entry apps since several years ago, so I may be
>  forgetting some of _valid_ reasons for using device IDs.  I just remember
>  all too well the problems we had using them.
>  
>  - Dan Bale

Shops that have the common hassle with setting unique sign on display IDs, 
for which there are supposedly non-obvious work-arounds & solutions, might 
want to use member based on user name if they are in a reality of users with 
only one session or users who can keep track of which session they started a 
batch on.  In my reality there is a spectrum of users between those who will 
always need some hand holding to power users who some day will have my job.  

We give people multiple sessions because it is productive for them to be 
doing a variety of inquiry concurrent with entering some transactions, and 
the nature of the job is everyone is exposed to interruptions interrrupted by 
interruptions, and teaching them how to inquire out of sessions is not for 
the low end expertise users who will invariably turn off their workstations 
at day end, losing track of how many interrupted sessions inquired into other 
sessions.

In other words, users start a batch, get interrupted, need to do a really 
quick transaction, open a new batch, get the quick deal resolved, then return 
to the not so urgent batch, but which session was that on.

Decades ago on a S/34 I wrote a batch control system in which batches had 
names like GL00057 (General Ledger Transactions) MC0100 (Mail Order Cash & 
Check Payments) DI073 (Dealer Wholesale Invoices) in which the number was 
assigned sequentially to the batch type & instructions to users were to write 
the batch number on the media control paperwork associated with entry, so 
they could always update an old unfinished batch IF THEY KNEW ITS NUMBER ... 
the act of creating unique # also updated a batch control file that had 
record for each one with what its status was & who was last person to mess 
with it when ... from which a report could be run to identify misplaced 
batches to help at EOM closing.  

This multi-member approach based on sign-on session is much easier to manage 
... it forces users to finish one batch before they start another, unless 
they have multiple sessions, and if there is some problem with data in a 
batch blocking completion it lights a fire under everyone to get it resolved.

When my web meister added external NT to our system, I cautioned him that 
none of the PC users would be able to access BPCS until he got unique ids for 
each device, because the default QPDAV00001 would become QPDAV000 then 
letters associated with application which means they all would be crashing 
their BPCS jobs into each other.

Now the folks who dial in or otherwise connect to our LAN have their initials 
then a number for concurrent session ID from same session ... such as JSM002 
... I do not know how he did it ... that's outside my speciality, but someone 
at IBM told him how ... thus I figure that if you can solve it on an M$ OS, 
you can solve it on just about any market leader.  I've seen posts various 
places spelling out how to do it on CA ... I just do not know if the solution 
is an OS4 work around that needs re-inventing with each release.

When a user's work station goes down, I normally tell them they need to do 
their work all over again, but that there is a work around that I can do that 
will take a while IF THEIR BOSS ASKS ME TO ... "no, I need your BOSS to tell 
me that this is required"

because people are not supposed to be keying in humongous batches that are 
never taken to a conclusion ... we want some reasonable facimile of on-line 
real time data ... and I want that person's manager to know the rate at which 
that person's work station is going down & perhaps in need of justifying an 
upgrade.

Al Macintyre  ©¿©
http://www.cen-elec.com MIS Manager Programmer & Computer Janitor

Accept that some days you are the pigeon and some days the statue.
Murphy's Mom brought wrong baby home from hospital so it should be Kelly's 
Law.

+---
| 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
+---