RE: This way or that?

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

> -----Original Message-----
> From: James W. Kilgore [SMTP:eMail@James-W-Kilgore.com]
> Sent: Friday, June 09, 2000 7:45 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: This way or that?
> 
> Ken,
> 
> I don't have that much of a problem with the method, it's the data file
> growth that, IMHO, should be addressed.
> 
> For example, we have several people doing data entry to accounts
> payable.  The input work file has a member by device name.  When the
> user is finished with entry and requests a post, the post does an add to
> the open payables then deletes the entry from the work file.  Add to the
> payables, delete from the work file, loop.
> 
> Once the records are processed are they deleted? Not cleared, but
> deleted?  If so, can the files be changed to reuse deleted records?  Is
> the application using an internal record count that may not agree with
> record number?
> 
> If they are deleted and the process does use an internal record number,
> can a RGZPFM be submitted as part of the signoff or over night process
> to keep the file size down?
> 
> The overhead to create new members is small, but personally I wouldn't
> arbitrarily remove members unless I knew that the user was finished with
> whatever resided in the work file.  Nothing like coming into work and
> finding out that what you were in the middle of just got toasted!
> 
> "Graap, Ken" wrote:
> > 
> > Question -
> > 
> > We have a process that adds a member (member name=device name) to a file
> > which is then used as a work file for the current job. Once a member has
> > been added it is never cleared or removed.
> > 
> <<snip>>
> > 
> > If you were designing this application to optimize the use of system
> > resources (disk utilization, program performance, backup recovery etc)
> would
> > you remove these work files daily and add new members when needed or
> would
> > you leave the work files in place as we are doing?
> > 
> > I'm looking forward to all your thoughts....
+---
| 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
+---