Well, you may be stuck using something like RTVJRNE or API QjoRetrieveJournalEntries for T-CD and checking the ESD for command DSPJRN. This presumes command DSPJRN is journaled.
The advantage of the API over the command (at least up to V5R4) is with the API you can retrieve entries in *TYPE5 format.
You can store them how you like but only need to add the last one.
Determining the time the DSPJRN ended for any use will be tricky. For your jobs run from the job scheduler you can retrieve the T-JS entries for the job. You need to be auditing for *JOBDTA though. For executions outside your control you will have fun sifting through job information trying to determine what was run after DSPJRN.
Actually it isn't as bad as it sounds. You would need to have everyone audited though. From the DSPJRN journal entry you could display the entries for the job starting with the DSPJRN entry's time stamp and receiver name. Read through the extracted list and find the next one after DSPJRN. Its timestamp, minus a nanosecond, gives you DSPJRN's ending timestamp.
You could try using the QIBM_QCA_RTV_COMMAND exit point to collect when the DSPJRN command is run but it wouldn't tell you when it completes.
Gary
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Wednesday, September 05, 2012 9:20 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: saving date/time windows
Various jobs use DSPJRN command. This particular journal extract will be scheduled (via job scheduler) at various times throughout the day and may change frequencies over time.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Monnier, Gary
Sent: Wednesday, September 05, 2012 11:10 AM
To: Midrange Systems Technical Discussion
Subject: RE: saving date/time windows
Are these DSPJRNs run by anyone or, just those run by your process?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Wednesday, September 05, 2012 8:55 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: saving date/time windows
Nothing to do with journal receiver detach/attach.
I need to collect all CUSTOMER file changes from when the last journal DSPJRN ran until the present.
And do it again later today.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, September 05, 2012 10:46 AM
To: Midrange Systems Technical Discussion
Subject: RE: saving date/time windows
Say again?
First, my email was two parts:
Part one was how to see when a receiver changed. Basically an alternative to DSPJRN to an outfile.
Part two was a method to trap exactly when that receiver changed.
You gave a sample of
**** from **** ***** to *****
date time date time
20120905 094621 20120905 094658
20120904 050000 20120905 094621
20120903 010000 20120904 050000
What is this about your job running every 5 minutes? What job does it run every 5 minutes? The DSPJRN to the outfile? Why do you need to record the intervals you run DSPJRN to an outfile? I thought you were interested in the attach date/time and the detach date/time. Not how often you tracked this.
Why have a never ending job that checks every 5 minutes for a journal receiver change when you can use an exit point to record when a journal receiver is detached? Why waste the cycles on your machine? Why have concerns about the never ending program cancelling out or failing when you could just use the exit point?
Now, what are you going to do with this log of attach and detach times?
In theory it would be quite easy for your backup processes to do a:
CHGJRNRCV
Use
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/QJORRCVI.htm
to list all journal receivers that are detached but have not been saved yet.
SAVOBJ the detached, unsaved receivers.
DLTJRNRCV the now detached, saved receivers.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>,
Date: 09/05/2012 11:26 AM
Subject: RE: saving date/time windows
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Thanks but I am NOT looking for when a receiver changes. That could occur every 3 days.
My job could run every 5 minutes.
I want to save the intervals that MY job ran with!
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, September 05, 2012 10:21 AM
To: Midrange Systems Technical Discussion
Subject: Re: saving date/time windows
Ok, we've already established that rolling off after an interval is acceptable.
Knowing that, let me ask, how long do you keep your journal receivers?
Because you could use an API like:
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/QJORRCVI.htm
to get these attributes if you still have the receivers.
Failing that, you could log when a receiver changes by using this exit
point:
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/xchgrcv.htm
pros of the first one: No data area, table, etc maintenance required.
Rob Berendt
midrange.com
