Carsten, thank you for your reply! I find the docs on EXITPGM, TOTIME, & DELAY do not adequately explain the conditions by which '0' is passed to the exit program. Although the docs indicate that TOENT & DELAY are mutually exclusive, it doesn't indicate the same for TOTIME & DELAY. EXITPGM: Information in the first byte of the second parameter - Char(1): Passed to the Exit Program from the System '0' No journal entry is passed on this call of the exit program. TOTIME: <No discussion on the impact of the '0' in the 2nd parameter.> DELAY: Specifies the number of seconds that the command processing program (CPP) waits for a new journal entry to arrive if the last entry has already been received. After the last entry in the journal is received and passed to the exit program, the CPP tries to receive the next entry. If no new journal entry exists, the exit program is passed a value of 0 in the first byte of the second parameter. Note: This parameter is valid only when TOENT(*NONE) is specified, and the last receiver specified on the RCVRNG parameter identifies the journal receiver that is currently attached when journal entries are starting to be received. <The following may be key to my misunderstanding. Please advise:> When the last entry on the journal has been passed to the exit program and no journal entries are currently available to be passed to the exit program, one of the following occurs: <done with doc copy> Where I may be getting hung up is "the last entry on the journal has been passed". In my case, the last journal entry in the *time range* has been passed, but not the last one in the journal. Still, the DELAY parm help specifies that it "is valid only when TOENT(*NONE) is specified", which is true by default. Perhaps the docs should add that TOTIME must not be specified? That would seem to make sense, since TOENT & TOTIME both potentially cause RCVJRNE to quit before reaching the end of the journal. ANYWAY, the problem of the output file remaining open in the exit program and the buffer hiding records waiting to be flushed still remains. The job has steps following the RCVJRNE that require the records still sitting in the buffer. I'm going to try using OPNDBF before the RCVJRNE, and then CLOF afterwards, to see if this will force the file to close. Also, I wonder if it would have been more appropriate to use DSPJRN to an outfile in this application. (There may have been concerns about the size of the outfile on a space-starved system.) Comments and advice welcomed. GA --- Carsten Flensburg <flensburg@xxxxxxxxxx> wrote: > Hello GA, > > - Could it be because RCVJRNE hits the TOTIME value before it hits the > DELAY (which is the trigger of the '0' being passed)? > > Best regards, > Carsten Flensburg > > ----- Original Message ----- > From: "G Armour" <garmour400m@xxxxxxxxx> > Sent: Monday, March 15, 2004 7:25 PM > > > A really frustrating "bump" has got two of us scratching our heads. > We > > are using RCVJRNE and an exit program written in RPGLE: > > > > RCVJRNE JRN(EEHLIB/TESTJRN) EXITPGM(EEHJ115R) FILE((APH115)) + > > RCVRNG(*CURCHAIN) FROMTIME(031204 090000) + > > TOTIME(031204 180000) ENTTYP(PT PX UB UP DL) DELAY(1) > > > > In the RPG program: > > > > c *Entry Plist > > c Parm JrnRcv > > c Parm $Flag > > > > $Flag is a 1-character field. For each journal entry processed, $Flag > is > > set to '1'. After the last journal entry is processed, we are > expecting > > RCVJRNE to call the exit program again, passing '0' in $Flag. > Instead, > > the exit program is NOT called, and the RCVJRNE command ends, passing > > control back to the calling CL program. __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.