We recommend against using LOAD with GLOBAL=(YES The system will free the storage when the LOADing address space terminates, so that is often a system integrity exposure when the LOADing address space is not non-memtermable.
CSVDYLPA should be used instead of LOAD GLOBAL=YES Jim Mulder -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Richard Zierdt Sent: Tuesday, November 5, 2024 11:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extended linkage index - documentation? PC routine definition problem Problem solved by LOAD . . . GLOBAL=(YES,F) macro / parameter. Another sidebar consideration: When LOADing a module into common storage, the module cannot be linked with PAGE or an ABEND 306-10 is issued. z/OS is probably trying to conserve space. Thanks to all Richard Zierdt ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Peter Relson <rel...@us.ibm.com> Sent: Tuesday, November 5, 2024 8:01 AM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Extended linkage index - documentation? PC routine definition problem Linkage Indexes are reserved via LXRES, using either the LXLIST or ELXLIST keyword. ELXLIST is properly documented as relating to "extended linkage index". I don't know why the OP had difficulty locating that information. Searching the z/OS Linkage Indexes are reserved via LXRES, using either the LXLIST or ELXLIST keyword. ELXLIST is properly documented as relating to "extended linkage index". I don't know why the OP had difficulty locating that information. Searching the z/OS documentation for extended linkage index had the expected hits. Adam J's response describes just what the OP did wrong. Peter Relson z/OS Core Technology Design h the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
