It is my recollection that RMODEX=64TRUE was introduced to inform the binder to override its default processing which determines the RMODE of a class (e.g., of a load module) based on the lowest common denominator of the RMODEs it finds defined (such as associated with each CSECT). Before RMODE 64 was supported, the assembler allowed RMODE 64 and, according to previous posts, metal C used it (this usage was pretty dumb, IMO). The binder explicitly treated that RMODE 64 attribute as RMODE ANY (there's even a message).Thus the effective lowest common denominator when all CSECTs had RMODE 64 was RMODE ANY. It would have been dangerously incompatible, when RMODE 64 was supported, to honor, all of a sudden, the attribute that had been previously treated in a different fashion. That could easily have broken many programs. RMODEX=64TRUE says "trust me, I know what I'm doing with the RMODE 64 attribute, so if you see RMODE 64 then treat it as RMODE 64". As a result, when all CSECTs have RMODE 64, and RMODEX=64TRUE is in effect, the result is RMODE 64. The RMODE=64 parameter option is a different matter entirely. That can be viewed as saying "I don't care what the CSECTs say, trust me, make this module RMODE 64" so you're already taking responsibility for any error you might have introduced within the CSECTs. Peter Relson
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
