At first blush I would consider a subfile. In this scenario, I happen to
personally prefer a subfile where the current row is always at the
bottom of the subfile display and earlier records scroll up the screen
as new entries are added to the subfile.
With this approach the data is in the subfile and when it is time to
process, just read the subfile.
On 9/5/2012 10:06 AM, Stone, Joel wrote:
I have a project where I need to save date/time windows for journal changes.
Below is an example.
The top window is the most recent time window. When the job is run next, the windows are all pushed down one row and the new window will be at the top.
What is a good method to handle this that others have used and liked?
Caveat: I don't want to update the perm data until AFTER the entire job successfully runs.
1) use data area: Copy DTAARA to qtemp, update it in qtemp, save it to perm dtaara at normal EOJ.
2) Use file: copy to qtemp, update, write back to perm file at normal EOJ.
3) Do one of above, but update perm file and rollback if job abends.
4) Any better methods???
Pros with dtaara: no file lock issues (each system gets own dtaara), no reorg or periodic maint issues; old dates will roll off
Cons with dtaara: must use offsets to find fields of interest: ugly and error-prone and hard to understand: chgvar %sst(&dtTmWindow 151 850)
Cons with file: cant CRTDUPOBJ with file, will have file lock contentions (Many systems would share file). Need to delete & reorg old records, more pgms, more maint.
**** from **** ***** to *****
date time date time
20120905 094621 20120905 094658
20120904 050000 20120905 094621
20120903 010000 20120904 050000
This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit http://www.symanteccloud.com