On Sun, 13 Mar 2016 08:13:11 -0500, Peter Relson wrote: >>What happens if the program that employs such a product was fetched from a >>program object with the (newfangled?) deferred/incremental load protocol? > >This is only one of the reasons that reallocating STEPLIB (and perhaps any >other system-allocated DD) is not supported. >The operating system cannot prevent an authorized program from doing >whatever it wants, but you won't get any sympathy if something bad >happens. > >And of course in this case the system actually did prevent this specific >reallocation. The message seems pretty clear, as does the documentation >for the dynamic allocation code associated with the IKJ56236 message. > Thanks. Does the OS likewise prevent freeing and reallocating an active TASKLIB? The considerations seem similar.
I suspect Lindy's requirement was overspecified. The real need may be not to reallocate STEPLIB but to execute a program from an arbitrary library, not necessarily in STEPLIB. But that facility is provided by ATTACH TASKLIB and TSO CALL (which I suspect uses a TASKLIB). But I wonder, what is the character of MVS programming that impels recurrent requests to reallocate STEPLIB rather than using those existing facilities, and entices various vendors to provide circumventions, however risky or restricted? (Well, the Rexx ATTCH* facilities, for example, have no TASKLIB option.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
