Program objects and PDSEs are in no way new features. Why all the pother? On Wed, Mar 25, 2015 at 8:08 AM, John McKown <[email protected]> wrote:
> On Tue, Mar 24, 2015 at 10:53 PM, Robert A. Rosenberg <[email protected]> > wrote: > > At 13:23 -0500 on 03/23/2015, John McKown wrote about Re: (Regular > > Expressions followup): > > > >> There is a big > >> problem with the desire to advance versus the desire to continue to > >> use what already works. As an example, look at some of the posts in > >> IBM-MAIN about COBOL 5 requiring that the executable be in a PDSE and > >> impossible to run from a PDS. > > > > > > What is generated by the COBOL 5 compiler that that requires the use of a > > PDS/E > > to store the Program Object as opposed to placing it as a Load Module in > a > > PDS? If the requirement is about the compiler itself, what is its > structure > > that requires a PDS/E? > > ref: > http://www-01.ibm.com/support/docview.wss?uid=swg27041176 > > <quote> > The need for PDSE datasets and Program Objects are built into the very > core of COBOL V5. Just a few examples of features that COBOL V5 uses > and will use that require Program Objects(PO) and thus PDSE datasets > for executables are: > > Improved init/term scheme relies on user-defined classes in object, > requiring PO > QY-con requires PO > (A performance improvement for RXY (long displacement) instructions. > Condition-sequential RLD support requires PO > A performance improvement for bootstrap invocation > PO can get page mapped 4K at a time for better performance > NOLOAD class DWARF debugging data requires PO > Common reentrancy model with C/C++ requires PO > XPLINK requires PO and will be used for AMODE 64 > > </quote> > > -- > If you sent twitter messages while exploring, are you on a textpedition? > > He's about as useful as a wax frying pan. > > 10 to the 12th power microphones = 1 Megaphone > > Maranatha! <>< > John McKown > -- John Gilmore, Ashland, MA 01721 - USA
