MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » September 2012

RE: saving date/time windows



fixed

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





Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact