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



Chuck,

RCVJRNE fires an exit point program whenever a journal entry of
the specified type is written, there is nothing to put in a loop. I
submit the job using *CURRENT, which for example is receiver AUDRCV0132.
When this receiver rolls to 0133, my job ends. Submitting the RCVJRNE
command again with *CURRENT keeps it working using receiver AUDRCV0132.
I've been reading that IBM link backwards and forwards for the past 2
days. I feel like I'm very close to having this resolved, but just not
quite there.

Martin's solution seems to be my only alternative at the moment.
Using the RTVJRNE command instead, will allow me to use it in a program
loop, reading the audit journal using *CURCHAIN and keeping track of my
position based on the last time the loop executed.

Thanks for the thoughts,
Ron



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, August 13, 2008 3:08 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: RCVJRNE usage

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.h
tm

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'.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

**********************
** LEGAL DISCLAIMER **
**********************

This E-mail message and any attachments may contain
legally privileged, confidential or proprietary
information. If you are not the intended recipient(s),
or the employee or agent responsible for delivery of
this message to the intended recipient(s), you are
hereby notified that any dissemination, distribution
or copying of this E-mail message is strictly
prohibited. If you have received this message in
error, please immediately notify the sender and
delete this E-mail message from your computer.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.