RE: PSDS System Date / InternalJobID

For what's it worth, I think you may be working too hard at making the input
data perfect at the time of collection.  You have all these constraints that
make it hard to get it right.  Consider using post-processing to clean up
problems that you may find difficult to fix at collection time.

Consider using a data area or a user space or a database file.  They are
permanent objects in permanent libraries and you have 100 percent control of
their content.  When you start the job, look at the data area and decide if
you like its current content or if you want to change it.  After that, use
the data area content to attribute your database files.


Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of dkeck@idt.net
Sent: Monday, August 21, 2000 9:49 AM
To: MIDRANGE-L@midrange.com
Subject: RE: PSDS System Date / InternalJobID


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.  The utility should not impact the LDA as that could interfere with the
programmers other actvities.  The activation group in which the utility runs
may even be shut down, only to have the programmer fire up the utility
again.
I don't want the session defaults lost during this sequence.  Now it is true
that "anything that _can_ be changed _can_ be changed", and I am mindful of
this.  That's why the LDA, UDATE, and QDATE don't work.  The system date in
the
PSDS and the Internal Job ID from QRTVJOBI are good only if my original
concerns about them are resolved.
> >
> > UDATE is in adequate because it can change during the interactive
session,
> > albeit not automatically at midnight.  -Dave
> >
>
> If this can happen deliberately then is you're best bet is to put the date
> into a *LDA when you first get it, and use that subsequently?
>
> After all, anything that _can_ be changed _can_ be changed?
>
>
> +---
> | 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
> +---
>


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

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