On 2018-10-18 08:22, Peter Relson wrote:
FWIW, within IBM code, a BLDL could not get a 306-04. A module fetch after
a BLDL? Sure. But the directory entry is not relevant to that particular
"decision".
LLA does not care at all about the APF nature of a data set.
Abend 306-04 results specifically from checking DEBAPFIN and finding it
off.
If PDSMAN is issuing 306-04 out of BLDL, then it is 100% wrong. If PDSMAN
is in some way intercepting a "load with GLOBAL=YES" and issuing the
abend, then you'd have to find out in what circumstances (I know nothing
about PDSMAN). Does PDSMAN truly take on the task of doing a module fetch?
That strikes me as "unwise" (to be charitable).
I would be very surprised if anything was in any way sensitive to a change
in the APF state of a data set in a concatenation after OPEN of that
concatenation. For everything other than the LNKLST when LNKAUTH=APFTAB is
in effect, this is checked by OPEN, captured in DEBAPFIN, and never
checked again while the DCB is OPEN. Doing just about anything else would
likely have abominable performance characteristics. There is certainly no
notification made about a change in the APF state of a data set.
Thanks Peter. This confirms a lot of what seems "not right" about this
situation.
The dump shows DEBAPFIN is on. The BLDL is issued by a FOCUS module, not
by LOAD. On return from BLDL, R15=4, R0=0, R1=00000306, and there is no
sign in system trace of IBM BLDL code being executed. After FOCUS
receives the BLDL results, it (not IBM code) issues the ABEND306-4.
FWIW, IBM BLDL does not document providing any particular value in R1 on
return with return code 4.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
