On 4/1/11 4:40 AM, Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx wrote:
<<SNIP>> I have (after much digging and posting on forums) found out
that it's possible that the message queues by those names may have
existed on the system but the workstation devd did not and that the
devd might not have been "associated" with that message queue and it
could not be created.
I would certainly expect some message somewhere would, even if only
as a diagnostic message, log that as an unexpected or undesirable
condition. In whatever job the autoconfig changes take place would seem
most likely. It would seem easy enough to force that condition and test
using named devices.
<<SNIP>> We do not revoke authority to the devices so the RVKOBJAUT
should not have been a factor.
Of course we probably do not _know_ if the auto-configuration feature
which modifies or creates virtual display devices similarly does not use
that feature as processing to "reset" an existing [or just-created]
workstation message queue to the desired default authority settings.
Although if the loop or many T-AF entries were a side effect as noted in
the APAR, there probably would have been some complaints about display
sessions that failed to start, some undesirable CPU consumption in a
subsystem or system job, or the many unexpected authority failures.
This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact