× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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'.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.