It's not the JCL per-se. The combination of XOBJ object modules and the Prelinker was a tactical solution to advancements in programs, originally created for C programs. XOBJ object modules addressed several deficiencies in OBJ object modules, such the ability to have long case-sensitive external symbol names.
While it does the intended job, the Prelinker has several drawbacks, such as the inability to incrementally rebind a module so created (read "csect replacement"). The prelinker does not handle GOFF object modules such as produced by C/C++ with XPLINK and COBOL V5. GOFF object modules can define characteristics of a program which cannot be represented in a load module. Note that the binder has been producing program objects for over 25 years. It is difficult to make significant enhancements to OBJ object module and load module formats. Some important things have been added such as AMODE 64 and quad-word alignment. [email protected] On Tue, 26 Jan 2016 13:52:28 -0600, Bill Woodger wrote: > Sorry not to be clear that I was paraphrasing the PL/I Programming Guide: > > > "Cataloged procedures IBMZCB and IBMZCBG use features of the program > management binder introduced in DFSMS/MVS ® 1.4 in place of the prelinker > supplied with Language Environment. These procedures produce a program object > in a PDSE. > > Cataloged procedures IBMZCPL, IBMZCPLG and IBMZCPG use the prelinker > supplied with Language Environment and produce a load module in PDS. Use > these procedures if you do not want to use a PDSE. > > ... > > The IBMZCB cataloged procedure, shown in Figure 11 on page 142, includes two > procedure steps: PLI, which is identical to cataloged procedure IBMZC, and > BIND, > which invokes the Program Management binder (symbolic name IEWBLINK) to > bind the object module produced in the first procedure step. > ... > > The IBMZCPL cataloged procedure, shown in Figure 13, includes three procedure > steps: PLI, which is identical to cataloged procedure IBMZC; PLKED, which > invokes the Language Environment prelinker; and LKED, which invokes the > linkage editor (symbolic name IEWL) to link-edit the object module produced in > the first procedure step." > > At the end of the day, it is the JCL which determines where the executable > program resides. > > PL/I can create programs which do not require to be a Program Object. COBOL > V5 cannot. > > Aside 1: Without an "unless we feel like it" clause, I'm not buying a "we > won't do that" unless the Board are behind it. > > Aside 2: Who thought it was a good idea to name a place where one or more > Object Programs can turn up a Program Object. That's clear, right? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
