Re: RCVJRNE exit program never getting '0' (no more entries) in 2nd parameter

[G Armour <garmour400m@xxxxxxxxx>]

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