This is what Frank said I think
Storage and its addressability Version 4.2.0 No other versions When you run COBOL programs, the programs and the data that they use reside in virtual storage. Storage that you use with COBOL can be either below the 16-MB line or above the 16-MB line but below the 2-GB bar. Two modes of addressing are available to address this storage: 24-bit and 31-bit. You can address storage below (but not above) the 16-MB line with 24-bit addressing. You can address storage either above or below the 16-MB line with 31-bit addressing. Unrestricted storage is addressable by 31-bit addressing and therefore encompasses all the storage available to your program, both above and below the 16-MB line. Enterprise COBOL does not directly exploit the 64-bit virtual addressing capability of z/OS; however, COBOL applications running in 31-bit or 24-bit addressing mode are fully supported on 64-bit z/OS systems. Addressing mode (AMODE) is the attribute that tells which hardware addressing mode is supported by your program: 24-bit addressing, 31-bit addressing, or either 24-bit or 31-bit addressing. This attribute is AMODE 24, AMODE 31, or AMODE ANY, respectively. The object program, the load module, and the executing program each has an AMODE attribute. All Enterprise COBOL object programs are AMODE ANY. Residency mode (RMODE) is the attribute of a program load module that identifies where in virtual storage the program will reside: below the 16-MB line, or either below or above. This attribute is RMODE 24 or RMODE ANY. Enterprise COBOL uses Language Environment services to control the storage used at run time. Thus COBOL compiler options and Language Environment runtime options influence the AMODE and RMODE attributes of your program and data, alone and in combination: *DATA*Compiler option that influences the location of storage for WORKING-STORAGE data, I-O buffers, and parameter lists for programs compiled with RENT.*RMODE*Compiler option that influences the residency mode and also influences the location of storage for WORKING-STORAGE data, I-O buffers, and parameter lists for programs compiled with NORENT.*RENT*Compiler option to generate a reentrant program.*HEAP*Runtime option that controls storage for the runtime heap. For example, COBOL WORKING-STORAGE is allocated from heap storage.*STACK*Runtime option that controls storage for the runtime stack. For example, COBOL LOCAL-STORAGE is allocated from stack storage.*ALL31*Runtime option that specifies whether an application can run entirely in AMODE 31. I know understand .... Scott On Wed, Jan 4, 2017 at 4:12 PM scott Ford <[email protected]> wrote: > Huh, > > > We are calling statically. > > Scott > > On Wed, Jan 4, 2017 at 4:07 PM Bill Woodger <[email protected]> > wrote: > > ALL31(ON) is only relevant for dynamic CALLs, and it is as Frank has > described - no switching, and if you CALL an AMODE(24), dynamically, you'll > likely break. > > > > Your resultant loadmodule is less than 16MB, and, when loaded, fits within > the available memory below the line. How close you are to exhausting that > memory with a minor increase in storage is unknown from what you have said. > > > > You are "getting away with it". > > > > The map of the loadmodule, produced by the program binder, will confirm > this. > > > > I think if you go over 16MB the binder will complain, but it has no way of > knowing what memory is available of the 16MB for when your program is > loaded, so you can have a loadmodule which binders successfully, but won't > fit in the memory available - if you have a change which adds sufficient > memory. > > > > You should be able to test this fairly easily. Find the size of the > loadmodule, add storage so that it is close to, but not, 16MB, and try to > load it. > > > > If no other handy methods, a quick "binary chop" will get a reasonable > "maximum" size you can load, and you can compare your actual loadmodule > size to that, to know how much leeway you have. > > > > If that is not enough leeway, you will have to make the assembler happy > with 31-bit addressing which will allow you to fully binder greater than > 16MB with everything static, or go with dynamic CALLs to the assembler and > have LE do its work, using ALL31(OFF) so you get the switching. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > -- > Scott Ford > IDMWORKS > z/OS Development > -- Scott Ford IDMWORKS z/OS Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
