In reply to David and others, a couple of points that might be of interest:
* I confirm that the MIGRATABLE attribute is just as people have suggested, to indicate whether a program can be copied between PDS and PDSE, or saved as a load module in a PDS when it was able to be saved as a program object in a PDSE or UNIX. All such operations always requires the binder. * Though there is a bit in the PDS Directory Entry (IHAPDS PDSNMIG), a load module cannot have this attribute. That bit is remapped for a program object, in a load module it is part of PDS2RLDS. Thus you can (for instance) read the directory of a PDSE and still determine if the member is "migratable". A bit is also defined in the PMAR (IEWPMARL PMARL_NMIG). * There is a relationship with the binder COMPAT option, to the extent that the binder has automatically determined the COMPAT level. If the user decides to set COMPAT to some not-required higher level (perhaps to exploit some non-executable feature like binder COMPRESSion), the MIGRATABLE option can still be on. * Besides the two macros, AMBLIST also reports on the MIGRATABLE bit. This is documented in Diagnosis: Tools and Service Aids, that it will print either NON-MIGR or MIGRATE (the explanation of those is no more detailed than the macros). * One of the reasons for setting non-migratable is that the module "text" exceeds 16MB. Binder has elected to not enumerate all the possible reasons. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
