RE: PSDS System Date / InternalJobID

[dkeck@xxxxxxx]

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 just a simple 3 part key as described 
below.  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.
Regarding the internal job ID not surviving IPL's .. i saw that in the manual 
and that is OK.  I would not be using it to resolve to a job using the API's 
that use internal job ID as an input.  Rather I would be using it as my 4th key 
element ... a tie breaker.  It could be good for this because I can get the 
internal job ID any time a job is active and successfully chain to the record 
related to the job.  Future jobs would, (I think/hope/assume) likely have a 
different internal job ID even if they have the same JobUser/JobName/JobNumber 
as an old record in the file.   -DaveK

Buck wrote:
> David Keck wrote:
> 
> >To put things in perspective ... the 
> >application is a utility that a 
> >programmer may fire up and close 
> >down several times during the day.  
> >I want to preserve session-level 
> >(duration is life of interactive job) 
> >settings established in the morning 
> >so that they do not need to be 
> >re-established repeatedly during the day
> 
> Then the job number alone is a sufficient "discriminator."  Your original
> post said:
> > >     I am defining a file to contain info related to interactive jobs
> with
> > >one uniquely keyed record per relevant interactive job.  The info may
> > >persist for a long time.  The natural key of JobUser/JobName/JobNumber
> might
> > >in a rare circumstance yield a duplicate as the system recycles job
> numbers.
> 
> This is quite a different prospect from:
> >(duration is life of interactive job) 
> 
> Were I the programmer, I'd be looking for functionality similar to (gasp!)
> SEU's checkpoint/restart.  The nature of your utility will determine the
> ultimate "natural" key; in SEU's case it is user/source file/lib/member.
> When my job inadvertently falls over (darned power plug!) the checkpoint
> will know that my user was working on project z and will prompt me to
> recover it.
> 
> As an aside, the internal job identifier from QUSRJOBI gets invalidated by
> an IPL:
> http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3AM703/1.28.15#HDRJ
> OBRDE
> 
> Buck Calabro


---------------------------------------------
This message was sent through IDT.
http://www.idt.net/


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