on Fri, 25 May 2007 15:19:35 -0400, J R <[EMAIL PROTECTED]> wrote:
>
>Right, but maybe the intervening de-allocate was done without a DEQ.
>
That's what I believe.
>Besides, the message "IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED" may
>not come to pass the way you think. It says that the *ddname* is no longer
>allocated. A better test might be via the command "free da('FOO.BAR')".
>
Good point. I'll try it ...
>In any event, I believe the alloc and free commands are probably driven off
>the DSABQ; the first free removes the DSAB, the second one does not find it.
> Whether the dataset remains allocated or, more to the point, enqueued, is
>another matter.
>
OK. And I added Greg S's SLEEP. During the sleep, when I attempt
to allocate from my TSO session, I get:
MIM1088 CONTENTION WITH FREEDSN OWNS EXCL ON LSTC3MVS
MIM1089 YOU NEED SHR SYSDSN FOO.BAR
IKJ56225I DATA SET FOO.BAR ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
... DEQ is not happening. It works as it should. And SYSTSPRT
output for both steps says:
free dataset('FOO.BAR')
READY
free dataset('FOO.BAR')
IKJ56247I DATA SET FOO.BAR NOT FREED, IS NOT ALLOCATED
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
