I'm probably not really understanding what you want to do. So I'll give a try at an alternate explanation for what I _think_ you want. You have a "test" version of a program, call it TESTPGM, in your production PDSE. This is a test version of PRODPGM in the same PDSE. You have another program, MAINPGM, which invokes PRODPGM. You want MAINPGM to invoke TESTPGM instead, without any changes to MAINPGM. You are running MAINPGM inside some sort of debugger. You debugger can "dynamically rename" TESTPGM to PRODPGM by using the IEWBLODI. I am wondering why you can't simply do a LOAD on TESTPGM, then use and IDENTIFY to create a CDE for the name PRODPGM using the EPA for TESTPGM which you can get from the LOAD. Something akin to:
LOAD EPLOC=NEWNAME ST 0,NEWEPA SAME ENTRY POINT LR 1,0 LOAD EPA TO GPR1 IDENTIFY EPLOC=OLDNAME,ENTRY=(1) Note, that I'm going mainly off of memory, so please excuse any errors in the above. On Wed, Aug 9, 2017 at 2:46 AM, Giliad Wilf < 000000d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: > apologies All. Sorry for the "dense" post. Here is a re-send: > Hi All, I'm trying to do an in-core re-bind of a program object > currently residing in a PDSE, rename it, and present its new name to > Contents Supervisor, by dynamically calling IEWBLODI to do > the job. IEWBLODI fails, issuing MSGIEW2678S, stating "MODULE CONTAINS > DATA CLASSES NOT SUPPORTED BY THE LOAD FUNCTION", and further > explaining "Module contains one or more deferred classes". > This program object has been generated by Enterprise COBOL V5.1 > for z/OS. The problem does not occur when the same source gets > compiled by Enterprise COBOL V4.2 for z/OS. > Close inspection and comparison of the outputs of two compilers, > V4.2 vs. V5.1, reveals that COBOL V4.2 generates program objects > V2, while COBOL V5.1 generates program objects V3, that obviously contain > some deferred data classe(s). > I've tried to enforce 'COMPAT=PM2' on the binder at step LKED of the > procedure IGYWCL that called COBOL V5.1 to produce the > initial program object, to no avail. The binder rejects this > override and terminates with RC12. > Deferred classes are described as some performance measure > intended for postponing costly instantiation, until they are really > required. > This in-core re-bind for renaming, is part of a home-written debug > monitor, intended to allow shop users to do maintenance on production > COBOL subroutines, place them under some temporary name > in production PDSEs, and renaming them in-core into their > "production" names before invoking main programs that call them, > so that these main programs will be able to call the subroutines by their > "production" names (without having to change anything in > the calling main programs). > OS is z/OS V2R2. > Any advice will be greatly appreciated. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
