I guess I never really noticed this and maybe it is documented, but even if it
is it's
worth some discussion because it's not the behavior I would have expected.
Here is the "feature" (z/OS 2.1, RSU1603):
1) There is a DDDEF called AAAA. It points to a DSN defined with DISP=SHR (no
volser / unit).
2) The SYSLIB concatenation includes DDNAME AAAA (last in the concatenation, I
didn't
test a different order).
3) At execution time DD AAAA is overridden in the JCL to point to a different
VOLSER than
the cataloged version.
4) The data set used in the SYSLIB concatenation is the cataloged version, not
the override.
Allocation messages confirm AAAA override is allocated to the VOLSER specified.
SMP/E APPLY File Allocation report shows the dynamically allocated
DD SMPnnnnnn allocated to cataloged version. Allocation messages confirm
SMPnnnnnn DD was allocated to the cataloged version as well, so it isn't
just an error in the report.
The library in this case is not a target lib of the product being maintained,
but an
IBM maclib needed for assembly. I've always just overridden the entire SYSLIB
in the past. One would think just overriding "AAAA" would be easier since
there are a bunch of DDs in the SYSLIB concatenation.
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:[email protected]
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
