Re: Strange CL problem with SUBR

Adam
I've found that unless you have a GOTO (the ENDPGM label) or a RETURN
directly before where the subroutines are, there is nothing in the logic
flow to say bypass the subroutines.


Alan Shore

NBTY, Inc
(631) 244-2000 ext. 5019
AShore@xxxxxxxx
"If you're going through Hell, keep going" - Winston Churchill

midrange-l-bounces@xxxxxxxxxxxx wrote on 01/29/2008 11:38:06 AM:

I've run in to a problem where my SUBR code gets run instead of skipped
at the end of the program. My CL program's structure is as follows:

PGM
<declarations>

<do preprocessing for terminal 1>
CALLSUBR SUBR(sndReport)
DLTSPLF FILE(&rptPrtF) JOB(&JOB#/*N/&JOBNM) SPLNBR(&attSplNum)
/*If spool file not active error message occurs, ignore and continue. */
MONMSG MSGID(CPF3309)


<do preprocessing for terminal 2>
CALLSUBR SUBR(sndReport)
DLTSPLF FILE(&rptPrtF) JOB(&JOB#/*N/&JOBNM) SPLNBR(&attSplNum)
/*If spool file not active error message occurs, ignore and continue. */
MONMSG MSGID(CPF3309)

SUBR SUBR(sndReport)
<get user's email address>
<send mail with attachment>
ENDSUBR

ENDPGM


In this example, the code in the SUBR gets run _three_ times instead of
the expected two. Instead of going to ENDPGM directly after the second
MONMSG, the code inside the SUBR is executed. Oddly, if I add in a
meaningless CHGVAR between MONMSG and SUBR, then the SUBR is skipped as
expected.

The CL reference tells me that MONMSG can't be used directly after SUBR
or CALLSUBR, but I don't see any mention of problems when MONMSG
directly precedes SUBR. I've also Googled 'MONMSG SUBR PTF' and 'MONMSG
SUBR APAR' but didn't find anything.

FWIW, I also tried adding an empty EXEC(DO)-ENDDO block to the MONMSG to
no avail.

Can anyone recreate this problem?
--
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.