In listserv%201008071456113396.0...@bama.ua.edu, on 08/07/2010
at 02:56 PM, Paul Gilmartin paulgboul...@aim.com said:
IIRC, the OP stated somewhere that running his entire program under
the TMP was an unattractive option,
That's a separate issue.
as is authorizing his entire program.
How
On Wed, 4 Aug 2010 21:11:40 -0400, Shmuel Metz (Seymour J.) wrote:
In listserv%201007271150351024.0...@bama.ua.edu, on 07/27/2010
at 11:50 AM, Paul Gilmartin said:
Thinking of it, ISPF is probably bad advice. You'd need to be
running under ISPF, which means you'd need to be running under
In listserv%201007271150351024.0...@bama.ua.edu, on 07/27/2010
at 11:50 AM, Paul Gilmartin paulgboul...@aim.com said:
Thinking of it, ISPF is probably bad advice. You'd need to be
running under ISPF, which means you'd need to be running under TSO,
which means you'd need to be running APF
In listserv%201007261223100235.0...@bama.ua.edu, on 07/26/2010
at 12:23 PM, Paul Gilmartin paulgboul...@aim.com gibbered:
I know; Shmuel will say
that wouldn't be safe.
Well, if you're going to tell everybody what I'm going to say, I hope
that you don't mind if I start telling everybody what
In listserv%201008020804527174.0...@bama.ua.edu, on 08/02/2010
at 08:04 AM, Paul Gilmartin paulgboul...@aim.com said:
READY
allocate path('/u/me/nonesuch')
IKJ56228I PATH /u/me/nonesuch NOT IN CATALOG OR CATALOG CAN NOT BE
ACCESSED
That probably comes from DAIRFAIL rather than DYNALLOC. Was
On Tue, 3 Aug 2010 01:16:44 -0400, Gerhard Postpischil wrote:
Next they'll expect DISP=MOD to work for a member g
Well, DISP=MOD has its own semantic, whic is:
o Not very well known (I need to repeatedly explain it to colleagues).
o Quite useful.
o Not very intuitive (except by strained
The reason *I* hate OMVS is that those using it via some
C/C++/JAVA/whatever-clickable-stuff have no clue how things are
implemented in z/OS. So in case of an error they take any return
code/reason
code they get at face value. Unfortunately, that is the completely *wrong*
way to go about his. In
On Mon, 2 Aug 2010 08:12:50 -0400, Shmuel Metz (Seymour J.) wrote:
In listserv%201008020415450799.0...@bama.ua.edu, on 08/02/2010
at 04:15 AM, Barbara Nitz said:
You've provided me with an excellent example for my statement above.
Because that message is issued by TSO (IKJ prefix) or rather,
In listserv%201008020415450799.0...@bama.ua.edu, on 08/02/2010
at 04:15 AM, Barbara Nitz nitz-...@gmx.net said:
You've provided me with an excellent example for my statement above.
Because that message is issued by TSO (IKJ prefix) or rather, by
dynalloc which uses some DAIR interfaces into
Paul Gilmartin offered the following:
Well documented; inexcusably counterintuitive. I suspect the
historical rationale is that 40+ years ago allocation couldn't
muster the resources to perform a STOW to delete a member when
the allocation had the form above.
Nope. There WAS
On Mon, 2 Aug 2010 14:38:08 -0500, William H. Blair wrote:
For there to have been a rationale (for a decision or choice)
there would have to have been a decision or choice (not to call
STOW to delete the member). There never was such a decision made
so there was (and is) no need to justify
I have to side with William on this one, the DISP in JCL refers to the dataset,
not a member, and if DISP did work the way you describe, I would find it to be
counter-intuitive. When I have had users make this mistake, I have always
looked at them rather incredulously - I have a hard time
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Monday, August 02, 2010 3:13 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: remove() of PDSE member leaves PDS locked
On Mon, 2 Aug 2010 14:38:08 -0500, William H. Blair wrote
The resource deficiency,
then, appears to have been in the designers' perspective.
Considering options and selecting one based on a cost/
benefit analysis is more laudable than approaching the
problem with tunnel vision and failing to consider other
options than one.
No!
The lack of perspective
Scott Rowe wrote:
I have to side with William on this one, the DISP in JCL
refers to the dataset, not a member, and if DISP did work
the way you describe, I would find it to be counter-intuitive.
When I have had users make this mistake, I have always looked
at them rather incredulously - I
I never said that it can't make sense to someone else, why would you want to
imply that?
Steve Comstock st...@trainersfriend.com 8/2/2010 4:59 PM
So if it doesn't make sense to you then it can't make sense to anyone
else? Communication is difficult; put yourself in the other person's
frame of
Paul Gilmartin retorts:
I see never been any consideration as a failure of the
designers to step back and ask themselves, What will be
the customers' perception of this behavior?
The resource deficiency, then, appears to have been in the
designers' perspective.
That might be a
Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Scott Rowe
Sent: Monday, August 02, 2010 3:39 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: remove() of PDSE member leaves PDS locked
I have to side with William on this one, the DISP in JCL refers to the dataset,
not a member, and if DISP did work
On 8/2/2010 6:14 PM, Bill Fairchild wrote:
The scope of DISP is applied to a data set. Some, but not
all, behavior of a PDS member are like that of a sequential
data set. I suspect that this is the source of the
confusion.
Next they'll expect DISP=MOD to work for a member g
Gerhard
At 10:07 AM -0500 on 7/30/10, Paul Gilmartin wrote about Re: remove()
of PDSE member leaves PDS locked:
As for the attempt to remove a member in a PDS:
dsn=datasetname(member),disp=(old,delete)
is NOT the way to do it. While it is certainly possible to address
a member of a
PDS
Nowadays the only rationale, spurious, is that it's always
been that way.
This is not spurious, in this case.
For 40+ years, people have expected it to work this way.
Why should IBM, just because of a malcontent, suddenly change well-documented,
consistant, and expected behavior?
And ever
On 8/1/2010 5:25 PM, Robert A. Rosenberg wrote:
I agree that this failure to do what was requested is
counterintuitive. DSN=datasetname(member) turns the member into
a sequential dataset. Thus a disp=(old, delete) should act the
same way as if the DSN pointed at an actual sequential dataset -
On Fri, 30 Jul 2010 10:20:51 -0400 Gerhard Postpischil gerh...@valley.net
wrote:
:On 7/29/2010 7:08 AM, Binyamin Dissen wrote:
: There is very little difference (from the programmers view) between BSAM and
: BPAM. QSAM and BSAM, on the other hand, are quite different.
:I guess it depends on your
On 7/29/2010 7:08 AM, Binyamin Dissen wrote:
There is very little difference (from the programmers view) between BSAM and
BPAM. QSAM and BSAM, on the other hand, are quite different.
I guess it depends on your definition of very little. E.g.,
STOW is considered a BPAM macro. but works just
On Thu, 29 Jul 2010 00:23:57 -0500, Barbara Nitz wrote:
Gil,
you said that you hate MVS and that you consider it archaic. I have seen your
struggles with it (more willingness to understand than from a lot of others
thatjj
I have observed), so please do not take the following as an attack on you:
Barbara Nitz wrote:
Do you happen to know if SAS/C had access to the PDSE macro interfaces
()? That may be how SAS/C does it. As far as I know, these interfaces
allow you to replace or delete a member, as they provide the equivalent
services to the (PDS) macros like STOW.
Yep,
Yep, they have a low-level I/O library for BSAM etc
http://support.sas.com/documentation/onlinedoc/sasc/doc/lr2/lrv2ch3.htm.
Pretty simple stuff. Most vendors that use IBM C/C++ have written their
own similar low level I/O library.
PDS's low-level access method is called BPAM, and that is not
Barbara Nitz wrote:
Yep, they have a low-level I/O library for BSAM etc
http://support.sas.com/documentation/onlinedoc/sasc/doc/lr2/lrv2ch3.htm.
Pretty simple stuff. Most vendors that use IBM C/C++ have written their
own similar low level I/O library.
PDS's low-level access method is
In the above link you will notice functions called osbldl (which does a
BLDL) and osfind (which does a FIND)
and osstow (which does a STOW). So they handle PDS(E) just fine.
I stand corrected. But I really hate when BPAM is named BSAM (or QSAM). (I
didn't read further than the first two
On Thu, 29 Jul 2010 05:44:13 -0500 Barbara Nitz nitz-...@gmx.net wrote:
:But I really hate when BPAM is named BSAM (or QSAM).
There is very little difference (from the programmers view) between BSAM and
BPAM. QSAM and BSAM, on the other hand, are quite different.
--
Binyamin Dissen
It seems the symptoms have led me to draw wrong conclusions. The fact that
ISPF reports the PDSE *in use* the moment I stepped over remove() in the
debugger led me to believe that remove() was causing the PDSE to be locked
and the following fopen() to fail. But some experimentation shows that
On Wed, 28 Jul 2010 00:33:10 -0500, Barbara Nitz nitz-...@gmx.net
wrote:
Can you show the ENQ that you're talking about? Reason I am asking is that I
don't believe that you're faced with an ENQ. Rather, you are probably faced
with a latch, as that is the way PDSE (and HFS) members and
Etienne Thijsse wrote:
On Wed, 28 Jul 2010 00:33:10 -0500, Barbara Nitz nitz-...@gmx.net
wrote:
Can you show the ENQ that you're talking about? Reason I am asking is that I
don't believe that you're faced with an ENQ. Rather, you are probably faced
with a latch, as that is the way PDSE
TSO RMFMON
SENQ D
M goes back to menu. Z exits the utility.
Thanks :-)
Etienne
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search
At 1:15 PM -0700 on 7/27/10, Edward Jaffe wrote about Re: remove() of
PDSE member leaves PDS locked:
Robert A. Rosenberg wrote:
What is so hard (or dangerous) about just altering the status of
the EXC to SHR and then running the same code as the DEQ (after
first checking if the second entry
On Wed, 28 Jul 2010 17:06:24 -0400, Robert A. Rosenberg wrote:
respect the DISP=SHR request. The fact that the SYSDSN ENQ is not
compatible with a shared DASD environment (a design flaw that ISPF
fixes with its ENQ requests by adding the VOLSER to the DSN in its
RNAME Parm) due to the no longer
Etienne,
How do I show ENQ's ? I am afraid I don't have any experience with stuff like
this. I also have no idea what a latch is...?
The easiest way is to do a D GRS command. Unfortunately, in order to use
that, you need to know at least the major name. The ENQ that has been
talked about would
Barbara Nitz wrote:
The easiest way is to do a D GRS command. Unfortunately, in order to use
that, you need to know at least the major name. The ENQ that has been
talked about would have a major name of SYSDSN, with minor name of your
dataset. *That* ENQ is exclusive whenever there was a
On Mon, 26 Jul 2010 12:23:10 -0500, Paul Gilmartin paulgboul...@aim.com
wrote:
On Mon, 26 Jul 2010 11:02:24 -0500, Etienne Thijsse wrote:
If I use the C function remove() to remove a member from a PDSE, then from
that moment on, the PDSE is locked, ISPF says in use, I can't create a new
member
Etienne Thijsse wrote:
On Mon, 26 Jul 2010 12:23:10 -0500, Paul Gilmartin paulgboul...@aim.com
wrote:
On Mon, 26 Jul 2010 11:02:24 -0500, Etienne Thijsse wrote:
If I use the C function remove() to remove a member from a PDSE, then from
that moment on, the PDSE is locked, ISPF says in
On Tue, 27 Jul 2010 19:02:19 +0800, David Crayford dcrayf...@gmail.com
wrote:
Etienne Thijsse wrote:
On Mon, 26 Jul 2010 12:23:10 -0500, Paul Gilmartin
paulgboul...@aim.com
wrote:
On Mon, 26 Jul 2010 11:02:24 -0500, Etienne Thijsse wrote:
If I use the C function remove() to remove a
On Tue, 27 Jul 2010 19:02:19 +0800, David Crayford wrote:
Etienne Thijsse wrote:
Thanks for responding, Gil. There is no other stream. When I run under the
debugger, the PDSE remains accessible with ISPF right up to the remove()
statement; when I step over it, it is locked.
It's yet possible
On Tue, 27 Jul 2010 08:47:30 -0500, Paul Gilmartin paulgboul...@aim.com
wrote:
On Tue, 27 Jul 2010 19:02:19 +0800, David Crayford wrote:
Etienne Thijsse wrote:
Thanks for responding, Gil. There is no other stream. When I run under the
debugger, the PDSE remains accessible with ISPF right up
On Tue, 27 Jul 2010 09:01:46 -0500, Etienne Thijsse wrote:
That may well be true. At this moment however, I know nothing about ISPF
services or how to call them from C. I'll keep this in mind as a lost resort,
if all
else fails.
The best I can say is that it's in the book.
At the moment I am
On Tue, 27 Jul 2010 09:47:15 -0500, Paul Gilmartin paulgboul...@aim.com
wrote:
On Tue, 27 Jul 2010 09:01:46 -0500, Etienne Thijsse wrote:
That may well be true. At this moment however, I know nothing about ISPF
services or how to call them from C. I'll keep this in mind as a lost resort,
if
On Tue, 27 Jul 2010 10:15:11 -0500, Etienne Thijsse wrote:
Any idea how to get rid of this ENQ SHR ?
Have you verified that there's an outstanding ENQ?
Use the TSO command FREE DSN(whatever.dsn) or equivalent call to
DYNALLOC or BPXWDYN.
Use TSO LISTALC STATUS SYSNAMES and find the DDNAME and
On Tue, 27 Jul 2010 10:47:07 -0500, Paul Gilmartin paulgboul...@aim.com
wrote:
On Tue, 27 Jul 2010 10:15:11 -0500, Etienne Thijsse wrote:
Any idea how to get rid of this ENQ SHR ?
Have you verified that there's an outstanding ENQ?
Use the TSO command FREE DSN(whatever.dsn) or equivalent call
On Tue, 27 Jul 2010 11:35:24 -0500, Etienne Thijsse wrote:
There is a SYS00035 DDNAME associated with the PDSE, but freeing it with
dynfree gave me error 4 reason 1056, which means the dataset hasn't been
closed. :-(
So that didn't work...
Was it SHR? Why does C RTL have it OPEN? (It's
On Tue, 27 Jul 2010 11:50:35 -0500, Paul Gilmartin paulgboul...@aim.com
wrote:
On Tue, 27 Jul 2010 11:35:24 -0500, Etienne Thijsse wrote:
There is a SYS00035 DDNAME associated with the PDSE, but freeing it with
dynfree gave me error 4 reason 1056, which means the dataset hasn't been
closed. :-(
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Etienne Thijsse
Sent: Tuesday, July 27, 2010 12:09 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: remove() of PDSE member leaves PDS locked
On Tue, 27 Jul 2010 11:50:35 -0500, Paul Gilmartin
() of PDSE member leaves PDS locked
On Tue, 27 Jul 2010 11:50:35 -0500, Paul Gilmartin
paulgboul...@aim.com
wrote:
SNIPPAGE
Thinking of it, ISPF is probably bad advice. You'd need to be
running under ISPF, which means you'd need to be running under
TSO, which means you'd need to be running APF
At 8:47 AM -0500 on 7/27/10, Paul Gilmartin wrote about Re: remove()
of PDSE member leaves PDS locked:
remove() upgrades this to EXC (bad design of C RTL; as you say, SAS
(RIP) does better). Then there's no way to downgrade it to SHR (bad
design of GRS).
I agree with you about the bad
Robert A. Rosenberg wrote:
What is so hard (or dangerous) about just altering the status of the
EXC to SHR and then running the same code as the DEQ (after first
checking if the second entry is a SHR request [if it is an EXC do not
run the code])?
Agreed. This is a long-standing complaint.
Can you show the ENQ that you're talking about? Reason I am asking is that I
don't believe that you're faced with an ENQ. Rather, you are probably faced
with a latch, as that is the way PDSE (and HFS) members and directories are
serialized. And the reopen just hits the latch, not the ENQ.
(And
On Mon, 26 Jul 2010 11:02:24 -0500, Etienne Thijsse wrote:
If I use the C function remove() to remove a member from a PDSE, then from
that moment on, the PDSE is locked, ISPF says in use, I can't create a new
member in it using fopen() in the same program. The PDSE only gets unlocked
after the
Hi,
If I use the C function remove() to remove a member from a PDSE, then from
that moment on, the PDSE is locked, ISPF says in use, I can't create a new
member in it using fopen() in the same program. The PDSE only gets unlocked
after the program has ended.
In the joblog I saw that the PDSE
56 matches
Mail list logo
