Re: BPXWDYN - Bug or no bug ?

2018-02-19 Thread Paul Gilmartin
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 ?

2018-02-19 Thread Sri h Kolusu
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 ?

2018-02-19 Thread Paul Gilmartin
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 ?

2018-02-19 Thread Jesse 1 Robinson
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 ?

2018-02-19 Thread Paul Gilmartin
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 ?

2018-02-19 Thread John McKown
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 ?

2018-02-19 Thread Paul Gilmartin
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 ?

2018-02-19 Thread Binyamin Dissen
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 ?

2018-02-19 Thread scott Ford
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 ?

2018-02-19 Thread Steve Smith
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