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