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
