On Thu, 14 Dec 2023 11:54:28 -0500, Phil Smith III <li...@akphs.com> wrote:
>++VER(Z038) FMID(VABC840) . >++ZAP(ABCDITSK) . >NAME ABCDITSK ABCPROC#C C_CODE >----------NAME ABCDITSK ABCPROC#C C_CODE. >GIM23101E ** THERE IS A SYNTAX ERROR IN A ZAP CONTROL STATEMENT FOR MODULE > ABCDITSK IN SYSMOD ABC8401. Like ++JCLIN, ++ZAP contains pseudo statements instead of actual superzap statements. SMP/E processes these pseudo statements which are sometimes incompatible with the real functionality. This is an SMP/e error message (not superzap). SMP/e may or may not support certain features. You will need to determine how SMP/e handles the various NAME statement options. Consider a simple ++ZAP where in superzap where you specify NAME MYLMOD MYCSECT. Your first problem is that you don't zap an SMP/e LMOD. Instead, you would ++ZAP (MYCSECT) and use NAME MYCSECT. I think you can specify the LMOD if you only want to affect a single load module instead of all load modules with that csect name. Verify that ABCDITSK is an SMP/e LMOD. ABCPROC#C is too long for an SMP/e MOD name so I'm guessing that you omitted an optional superzap NAME that SMP/e is relying upon. Look at the superzap NAME statement. LE programs complicate the situation a little. I've never packaged them so I can only suggest how I would approach this. I'm guessing that SMP/e either requires a superzap NAME option specifying module name or requires ABCPROC#C be renamed to a valid ++MOD name which can be specified in the ++ZAP name. I'm guessing by this time, superzap with PDS/e now supports "NAME load-module module csect". Remember that SMP/e may not have implemented all of the superzap NAME options. I suspect the C_CODE option is supported but it's possible that it's automatically determined in SMP/e and should not be specified as a NAME option. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
