Re: BPXWDYN - Bug or no bug ?
On Mon, 19 Feb 2018 08:46:50 -0500, Steve Smith wrote: >You need to set flag "S99NOCNV Do not use an existing allocation to satisfy >this request." But I don't know if BPXWDYN allows this. > z/OSIBM Using REXX and z/OS UNIX System Services Version 2 Release 3 SA23-2283-30 Chapter 6. BPXWDYN: a text interface to dynamic allocation and dynamic output Requesting dynamic allocation TU(hex-tu-value) Builds an allocation text unit (TU) from the specified string. For example, alloc tu(000100010002c1c2) is equivalent to alloc fi(ab). TU can be used multiple times in an allocation request. Ugh. >Depends on what you call a bug... DYNALLOC itself has driven me crazy with >all the various flags and options trying to figure out "convertible", etc. > It's worse than a bug; it's bad design defaulting to obfuscation with the goal of performance. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
Gary,
Use this trick to let BPXWDYN allocate to a new DD instead of using the
existing one. (Credit to Paul Gilmartin who's made this discovery in one of
his earlier discussion on IBM-Main which is available at
https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/QKKcj6LYBik/tF68-svA50sJ
)
so you just need to supply the RECFM parm to get a new allocation. I chose
RECFM (F,B) . if you're going to actually use the dd, then it is a catch
22 as you need to know ahead of time what the recfm is, However if you do
know the RECFM then here is a work around
Address tso "alloc fi(abug) da('any.dataset.name') shr resue"
Call bpxwdyn,
"Alloc rtddn(dd) da('any.dataset.name') recfm(f,b) shr reuse"
Say 'DDname allocated is 'dd
Call bpxwdyn "Free fi("dd")"
Thanks,
Kolusu
IBM Mainframe Discussion List wrote on
02/19/2018 06:18:13 AM:
> From: Gary Freestone
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 02/19/2018 06:29 AM
> Subject: BPXWDYN - Bug or no bug ?
> Sent by: IBM Mainframe Discussion List
>
> 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.
>
>
>
> 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")"
>
> 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
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
On Mon, 19 Feb 2018 20:14:29 +, Jesse 1 Robinson wrote: >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: > >CONTROL NOMSG >FREE DD(like-I-care-if-it's-allocated) >CONTROL MSG >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. > I recall an era when FREE of an unallocated DDNAME was fatal to the CLIST (of course, the programmer should know better!) but ALLOCATE of a DDNAME in use merely gave a snarky message. So, I resorted to: ALLOCATE (like-I-care) FREE ALLOCATE (now-I-want-it). RTDDN was a boon. I still shudder when I see programmers using RANDOM() to generate DDNAMEs and hoping for the best. >With REUSE, the allocation would take place with no distraction to the user >either way. > For many years, REUSE did not work for UNIX files (it's better now). I think there was some semantic confusion about the overloading of "REUSE" and UNIX allocations could never be reused (like-I-care). For some of the interim, BPXWDYN development generously added an internal FREE when the programmer coded REUSE. >The result was the *same* DD allocated to the data set(s) desired. This goes >back to around 1980 +/-. > But I believe that the OP wanted the *same* data set allocated to two different DDNAMES, or at least not to disrupt the existing allocation, and allocation conversion or the REUSE option thwarts that. I don't know the meaning or the intent of allocation conversion, except that it's a PITA. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
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:
CONTROL NOMSG
FREE DD(like-I-care-if-it's-allocated)
CONTROL MSG
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
robin...@sce.com
-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
To: IBM-MAIN@LISTSERV.UA.EDU
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
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
Re: BPXWDYN - Bug or no bug ?
On Mon, Feb 19, 2018 at 7:04 AM, Gary Freestone 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_ SYSn 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
Re: BPXWDYN - Bug or no bug ?
On Mon, 19 Feb 2018 08:46:50 -0500, Steve Smith wrote: >You need to set flag "S99NOCNV Do not use an existing allocation to satisfy >this request." But I don't know if BPXWDYN allows this. > I thought such an option was added to BPXWDYN several years ago, but I can't find it in the Ref. I thought that BPXWDN lately supports a recherché facility for supplying an arbitrary TU, but I can't find it in the Ref. It's not my day. Ask about BPXWDYN S99NOCNV in MVS-OE. Someone there knows. >Depends on what you call a bug... DYNALLOC itself has driven me crazy with >all the various flags and options trying to figure out "convertible", etc. > I suspect some of these were desperate attempts to improve performance in the Bad Old Days. Same as lazy "VARY OFFLINE". Why is special authorization needed to mount a virtual tape? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
I don't believe there is a way you can force BPXWDYN to do this.
What you can try is check the DDNAME for SYSn, though if you are running
split screen
Another option is to force a DDNAME (perhaps Zhhmmsst?)
On Tue, 20 Feb 2018 00:18:13 +1100 Gary Freestone 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.
:>
:>
:>
:>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")"
:>
:>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
:>
:>
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Binyamin Dissen
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
Gary, What are you trying to do in the Rexx program/clist ? Scott On Mon, Feb 19, 2018 at 8:46 AM, Steve Smith wrote: > You need to set flag "S99NOCNV Do not use an existing allocation to satisfy > this request." But I don't know if BPXWDYN allows this. > > Depends on what you call a bug... DYNALLOC itself has driven me crazy with > all the various flags and options trying to figure out "convertible", etc. > > sas > > On Mon, Feb 19, 2018 at 8:18 AM, Gary Freestone > wrote: > > > ... > > > Comments > > > > This doesn't seem right to me. An "ALLOC" should do a new allocation > every > > time. > > > > > -- > sas > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
You need to set flag "S99NOCNV Do not use an existing allocation to satisfy this request." But I don't know if BPXWDYN allows this. Depends on what you call a bug... DYNALLOC itself has driven me crazy with all the various flags and options trying to figure out "convertible", etc. sas On Mon, Feb 19, 2018 at 8:18 AM, Gary Freestone wrote: > ... > Comments > > This doesn't seem right to me. An "ALLOC" should do a new allocation every > time. > > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
