Re: RCVJRNE usage

[CRPence <CRPbottle@xxxxxxxxx>]

  Why not just code the request in a loop against the *CURRENT 
receiver?  That of course assumes two receiver changes will not occur in 
such a short period that the loop skips a receiver, but if the change is 
that fast, then how many Create Object entries would be missed?  TFRCTL 
to itself may even be an option, coded after the receive request.  Both 
of those options seem better than submitting a new version of the 
processing, if they are valid alternatives.?

  The receiver change seems to be a hard stop condition; i.e. RCVJRNE 
will end with '3' being passed as the first byte of the second parameter 
to the exit program.  See the "Note:" at:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/cl/rcvjrne.htm

Regards, Chuck

Hudson, Ron wrote:
> User requirement: When EDI data is written to the IFS using a 3rd
> party package (that I do not have the source code to), I need to
> forward this data to a PC based system.
>
> Solution: I submitted the RCVJRNE command using the QAUDJRN to call
> an exitpgm that I wrote to FTP the data to the PC based system. 
> RCVJRNE JRN(QAUDJRN) EXITPGM(CAGPL/CAPTURE) JRNCDE((T)) ENTTYP(CO) 
> ENTFMT(*TYPE4) DELAY(*NEXTENT 60) Works great, but....
>
> Issue: When the journal receiver changes, my job ends normally.  
> This is a major problem.
>
> Questions:
>
>  1. Is there a better solution?
>  2. I've done a lot of trial and errors with the parameters
>     of RCVJRNE, is there any combination that will make it 
>     continue running when the receiver changes? 
>  3. Should I code the exit pgm to resubmit the RCVJRNE command
>     if the first byte of the second parameter is a '3' or the
>     second byte is a 'N'.