I can't speak for BPXWDYN, but I remember when REUSE became available in TSO. 
Before that, a CLIST writer (this was before REXX was ported to TSO) had to 
code like this:

FREE DD(like-I-care-if-it's-allocated)
ALLOC DD(now-I-want-it) ...

This was necessary because if the DD was not already allocated, a gratuitous 
FREE would give the user a snarky message to that effect. With REUSE, the 
allocation would take place with no distraction to the user either way.

The result was the *same* DD allocated to the data set(s) desired. This goes 
back to around 1980 +/-.  

J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, February 19, 2018 11:44 AM
Subject: (External):Re: BPXWDYN - Bug or no bug ?

On Mon, 19 Feb 2018 11:29:04 -0600, John McKown wrote:

>On Mon, Feb 19, 2018 at 7:04 AM, Gary Freestone wrote:
>> 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).​
There's a flag in a TU, S99NOCNV, to control it.
>> 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.
Feels wrong.  I thought Gary wanted to keep the original allocation so there 
would be two of them, not free the first.

-- gil

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