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



On 28-Jun-2016 07:41 -0500, Hayes, Daniel wrote:
I have an issue happening that cannot happen.

The CL program listed below, on occasion, not frequently, does what
the partial joblog below is showing.

It is called from an RPG program when LR is on.

In this particular instance the CL program Ends then 0.147576
Seconds later it begins on line 34.02 again.

This CL is ONLY called from this RPG program, nowhere else on the
system.

P04572 - RPG (Relevant segments)
MOD05I 'J04572CCX ' C @@CCX
...
MOD05C* Write Check Information record for Carecentrix
MOD05C *INLR IFEQ *ON
MOD05C CAREC IFEQ 'YES'
MOD05C CALL @@CCX
MOD05C ENDIF
MOD05C ENDIF

J04572CCX - CLP (Entire Program)
PGM
/* Backup check files */
CPYF FROMFILE(*LIBL/F04572) +
TOFILE(*LIBL/F04572BK) MBROPT(*REPLACE) +
CRTFILE(*YES)
CPYF FROMFILE(*LIBL/F04573) +
TOFILE(*LIBL/F04573BK) MBROPT(*REPLACE) +
CRTFILE(*YES)
/* Write records to F55061 from F04573 */
CALL PGM(P04572CCX)
/* Create an extract file for CareCentrix */
CALL PGM(J55061) PARM('N')
ENDCLPGM: ENDPGM

JOBLOG from run in question;
06/27/16 08:19:47.497464 QCLRTNE QSYS 0058
J55061 CCXJDEOBJ *STMT
Statement . . . . . . : 17400
Message . : - RETURN /* RETURN due to end of CL program */
06/27/16 08:19:47.497568 QCLRTNE QSYS 0058
J04572CCX CCXJDEOBJ 0025
Message . : - RETURN /* RETURN due to end of CL program */
06/27/16 08:19:47.645144 QCADRV QSYS 03C4
J04572CCX CCXJDEOBJ 000D
Message . : 3402 - CPYF FROMFILE(*LIBL/F04572)


Without having the entire source for the program, a reviewer can not be assured that what was chosen as the "relevant segments" are the *only* relevant snippets of the code; i.e. even if that is the only CALL, both of those IFEQ have the potential to evaluate as true more than once, if the program has any way to reach that same code a second time. Of course, as a change to that code, an additional indicator could be defined and tested, testing if the CALL was not already done and then immediately setting-on that indicator just before the CALL; i.e. explicitly prevent a second call if doing so is undesirable, because merely testing *INLR for that non-LR purpose is inappropriate.

The entire joblog also may be valuable for review [by more eyes], rather that just that chosen snippet; e.g. there may be an indication that the RPG program itself was invoked twice, such that a natural consequence is that the CLP being invoked twice is likely expected, and therefore the question becomes instead about the RPG pgm vs the CLP as having been an apparent unexpected second-invocation.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.