RE: PSDS System Date / InternalJobID

Dave Keck wrote:

>Buck, A record in this file is relevant 
>only for the duraction of the interactive 
>session.  The records in the file would 
>persist only if recommended periodic 
>purges were not executed.  In the event 
>purges are not executed duplicate keys 
>can result if using (the fully qualified job 
>as key)  Rather than deal 
>with a duplicate key message at some 
>point, I would prefer the file just grow 
>until someone decides that the 
>recommended purging is good.

As usual, I wasn't clear enough.  Sorry.  I was under the impression that
this file was intended to save status information for checkpoint/restart
functionality.  That implies that the status is only valuable as long as the
utility is processing a particular dataset.  My example of this was SEU
editing a source file/lib/mbr.  If SEU falls over, it has a work area that
it uses to recover the member from.  The "key" to that recovery process is
not the job name, but the user ID/source file/lib/mbr.  Once we've replaced
that member in the source file (normal termination) the status data are no
longer useful to anybody, so SEU "deletes" it.

Applying the SEU analogy to your utility, the status records keyed on fully
qualified job name would seem to be inadequate as a checkpoint facility: if
I accidentally kick the plug out from my terminal, I will need to sign on as
a new job, and I cannot recover the status from a previous job.  Likewise,
user ID alone isn't enough - the programmer can be working on project A in
job 1, and project B in job 2.  This seems to point toward using user and
project ID as the "natural" key.

This presumes that there is inherent cleanup occurring under the covers;
that we aren't accumulating stale records from extinct jobs.  What you're
saying is that you don't want to perform the cleanup automatically; that
there's a purge program that'll run once in a while.  This is where the
duplicate key becomes a problem.  Sort of.

Assuming that you really aren't doing a checkpoint/restart type of thing,
and are just storing some stuff for the convenience of the programmer, the
fully qualified job name should be fine.  If you really want to keep the
stale records (for eventual purging) and are afraid of duplicates, then you
have several avenues open to you for the discriminator: QDATE, job start
date from QUSRJOBI, UDATE from when the job started or a simple sequence
number.  In any of these cases, you don't use the discriminator as part of
your KLIST - just use the qualified job.  Use the discriminator as *DESCEND
in the actual key (DDS).  This way you avoid duplicate key errors and can
read the most recent record without having to reconstruct the complete
unique key (which QDATE and UDATE would possibly miss.)

As an aside, I hesitate keeping stale records in the status file.  If you
really want and need some sort of history, move (copy/delete) the records
from the active file to an archive file.  This way you avoid many of the
complications inherent to managing the "archive" records when they're mixed
in with "active" records.

Buck Calabro
Aptis; Albany, NY
"We are what we repeatedly do.
 Excellence, then, is not an act, but a habit." --Aristotle


Billing Concepts Corp., a NASDAQ Listed Company, Symbol: BILL
+---
| 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
+---