>What happens if someone, mistakenly, loads a module with 4 byte ADCONs into >above the bar storage? Yes, this is an error. I don't see anything in the >documentation about this.
We don't often document what the behavior is when you make a mistake. When you make a mistake and something bad happens (such as an abend) you look up the "something bad" and one hopes that With LOAD with ADDR64, the error is yours to deal with. That LOAD approach does not care what the RMODE of the module is, it expects you to get it right. This is also the case with LOAD with ADDR and an RMODE 24 module that is to be loaded above 16M. I believe that the binder will complain about a 4-byte adcon in an RMODE 64 module. I don't know if it complains about a 3-byte adcon in an RMODE 31 module. >The programmer ought to be allowed to choose the >most useful value. You know that I disagree. What you really want is a way to indicate that the AMODE is irrelevant and thus you would need a way to identify that the thing being loaded is data, not code. The system would not attempt to guess. The system does not currently keep the un-AMODEd entry point address. >(Do 64-bit V-CONs exist?) I don't think so, but 64-bit AD-cons with EXTRN do. >I'd suggest using LOADPT= to get an address not contaminated with >addressing mode bits, LOADPT does not necessarily equal entry point. So your use of that depends on what you need. Peter Relson z/OS Core Technology Design
