On Mon, Feb 19, 2018 at 7:04 AM, Gary Freestone <maz...@iinet.net.au> wrote:

> These days we are opting for BPXWDYN in our REXXs instead of TSO ALLOC.
> One
> of the main reason for the switch is BPXWDYN's ability to return the DDNAME
> it allocated via the RTDDN parameter.
>
>
>
> Chasing down a bug in my code lead me to discover an idiosyncrasy with
> BPXWDYN that I think is a bug, but maybe not. So I'm seeking your opinions.
>

​I think this is normal for SVC 99 (DYNALLOC).​



>
> If I have the following
>
>
> Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
>
> Say 'DDname allocated is 'dd
>
> Call bpxwdyn "Free fi("dd")"
>

​Hum, what I would try is to add the "CLOSE" parameter in the BPXWDYN
​parameter list. The "CLOSE" parameter is not accepted on z/OS 1.12, but is
on z/OS 2.3. And, on z/OS 2.3, this results in the second BPXWDYN getting a
different DD name.

REXX program:

/* REXX */
TRACE I
CALL BPXWDYN "ALLOC FI(MACLIB) DSN('SYS1.MACLIB') SHR REUSE"
SAY "RC1="RC
CALL BPXWDYN "ALLOC RTDDN(DD1) DSN('SYS1.MACLIB') SHR REUSE CLOSE"
SAY "RC2="RC
SAY "DD1="DD1​
CALL BPXWDYN "ALLOC RTDDN(DD2) DSN('SYS1.MACLIB') SHR REUSE CLOSE"
SAY "RC3="RC
SAY "DD2="DD2

​In the above, the DD1 & DD2 had _different_ SYSnnnnn values.



>
>
>
> Running this exec gives something like "DDname allocated is SYS00746"
>
>
>
> However, if any.dataset.name is already allocated to an alternate DDNAME
> that is not in concatenation then, instead of allocating a new DDname it
> just returns the DDNAME of the existing allocation.
>
> You can see this with this code
>
>
>
> Address tso "alloc fi(abug) da('any.dataset.name') shr resue"
>
> Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
>
> Say 'DDname allocated is 'dd
>
> Call bpxwdyn "Free fi("dd")"
>
> And you will get "DDname allocated is ABUG"
>
>
>
> Problem is because I'm not getting a new allocation my FREE is freeing up a
> DDNAME allocated by a totally different process.  In my case causing an
> abend sometime later because a DDname that should be allocated is not.
>
>
>
> This doesn't seem right to me.  An "ALLOC" should do a new allocation every
> time.   Comments
>
>
>
> Gary Freestone
>
>
>
>
>
>
>


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to