Thank you Barry! That is exactly what I was looking for. :-)
Dave Cole
At 8/20/2019 03:50 PM, Barry Lichtenstein wrote:
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 lists...@listserv.ua.edu with 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
