Re: remove() of PDSE member leaves PDS locked
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 do you authorize part of a program? I don't believe there's any way for an unauthorized program not running under the TMP can invoke ISPF services. C /an unauthorized/a/ Well, I suppose that an authorized program could call the TMP in order top call ISPF, but I wouldn't consider that to be invoking ISPF services. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 TSO, which means you'd need to be running APF authorized. Really? Why do you believe that your program has to be authorized to run under the TMP? IIRC, the OP stated somewhere that running his entire program under the TMP was an unattractive option, as is authorizing his entire program. The relation is inverted -- I don't believe there's any way for an unauthorized program not running under the TMP can invoke ISPF services. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 authorized. Really? Why do you believe that your program has to be authorized to run under the TMP? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 you're going to say. How about you tell everybody what *your* going to say and let me decide what *I'm* going to say. You don't have the qualifications to be my spokesman. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: (Legacy) MVS vs. OMVS was: Re: remove() of PDSE member leaves PDS locked
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 the PMR
against TSO/E?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see http://patriot.net/~shmuel/resume/brief.html
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 reasoning). Had I been the designer, I would have invented a new keyword rather than overloading MOD. Appending to a member? Certainly not for PDS. I don't see why it couldn't be done for PDSE. Do ISPF LM services provide a corresponding facility? I suppose one might ALLOCATE DISP(MOD) and LMINIT the ddname. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
(Legacy) MVS vs. OMVS was: Re: remove() of PDSE member leaves PDS locked
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 my experience, the reason code given is completely
valid but at the same time completely obfuscates the real problem because
the first hint of trouble (aka the problem) is NOT shown anywhere.
And I know enough about both worlds that I cringe when I see:
128rexx say BPXWDYN( 'alloc path(''/tmp/nonesuch'') msg(wtp)')
08.26.36 STC07821 IKJ56228I PATH /tmp/nonesuch NOT IN CATALOG OR
CATALOG CAN NOT BE ACCESSED
I'm confident that no CATALOG search was attempted and failed This is
either an attempt to convert a UNIX completion status to terms familiar
to legacy MVS programmers or an indolent inclination to recycle an existing
message rather than invent a proper one.
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 TSO. I have always wondered about the
IKJ prefix, mainly because it is not in the book where the IEF messages (from
alloaction) are. Probably there is a reason behind this dating from very early
MVS times - please no historical discussion of that!
In a way, there was a 'catalog search' done, in the course of attempting to
allocate the dataset. BLDL ends up doing SVC12 which is called 'Catalog' SVC,
so you're right, the Catalog Search Interface (which came way later) was NOT
called, but there was some 'searching in the catalogues' going on. Hence the
IKJ message, which to someone from MVS says 'Dataset/File/Whatever not
found'.
I believe I even submitted a PMR
on the inaccuracy of the message. It went nowhere.
I am not surprised. :-) Every component answered strictly from their own point
of view, and they could not care less about the 'big picture'. From their own
narrow view, every component was right but as a whole, the stuff is useless.
And nobody wants to tackle this, as clarification requires mighty dollars that
IBM says 'whatever for? there are more important things to do.'
(I feel with you, I've been down that path numerous times. And have by now
given up to make them see the 'big picture'.)
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.
In this case, I disagree. I agree with Gerhard Postpischil. This is something
architected, and just because this construct does not exist in another
architecture, does not mean MVS should change theirs, just because a
programmer wants to (come hell or high water) use his own way or the *nix
way of doing it. Also, I do NOT consider it counterintuitive, but then I grew
up
on MVS.
Nowadays the only rationale, spurious, is that it's always
been that way. And ever shall be, as long as descendants of OS/360
endure. But such anomalies give me neither high expectations nor good
wishes for the destiny of z/OS.
Same argument as before: Changing this would require development dollars,
that IBM doesn't want to spend on this. But fear not, z/OS is going to be
clickable one of those days, and then you might get your wish! :-)
Lately, I received in a reply to an RCF:
... The [...] book documents what is supported, not what is
not being supported. if something is not mentioned, it should
be assumed that it is not officially supported even though it
may work. ...
Here, I largely sympathize with IBM. what is not being supported
is an unbounded set, impossible to enumerate in a manual. My issue
is that IBM did not document what is being supported, but merely
supplied a handful of examples leaving the reader to extrapolate
often with wishful thinking and a probable inference of internal
implementation.
Always a dangerous thing. But it goes hand in glove with my first point above -
The OMVS world comes from a different perspective and architecture than the
MVS world. I remember the very first service transfer education for what is
now WAS (we called it 'component broken' then). There was some guy
standing there talking about 'the shasta' and a lot of other vocabulary that no
one in the audience had ever heard before. And if you think they would first
establish a definition for something before using it you can think again.
NOT establishing a firm definition of terms before using them is the big
problem
I see with the OMVS stuff. And I had my share of fundamentals discussions
when I wanted that clear definition from OMVS before using something. It does
Not help when A is 'defined' by using B (which has not been defined).
This also goes both ways - and is a reason why I hate OMVS. My MVS training
tends
Re: (Legacy) MVS vs. OMVS was: Re: remove() of PDSE member leaves PDS locked
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, by
dynalloc which uses some DAIR interfaces into TSO.
DAIR uses DYNALLOC; DYNALLOC does not use DAIR. I suspect that the
message comes from code in BPXWDYN.
I have always wondered about the IKJ prefix,
Batch JCL gives:
IEF212I x STEP y - DATA SET NOT FOUND
The use of DATA SET is questionable. Support has attempted to refute
some of my PMRs with the claim that Unix files are not data sets.
But there's language in Using Data Sets that implies that anything
that can be allocated with a DD statement (DASD, tape, terminal, cards)
is properly called a data set.
And from the TSO READY prompt:
READY
allocate path('/u/me/nonesuch')
IKJ56228I PATH /u/me/nonesuch NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED
READY
Barbara, a catalog search was performed to to find and mount the data set
behind /u/me. But that catalog search succeeded. Catalog should not
be mentioned an an error message.
(Drifting topic) I hate OR messages. DYNALLOC should provide at least
a reason code to differentiate between NOT IN CATALOG and CATALOG CAN
NOT BE ACCESSED (in this case, neither applies).
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: (Legacy) MVS vs. OMVS was: Re: remove() of PDSE member leaves PDS locked
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 TSO. DAIR uses DYNALLOC; DYNALLOC does not use DAIR. I suspect that the message comes from code in BPXWDYN. I have always wondered about the IKJ prefix, Originally DYNALLOC did not have the ability to pass back an error message. There was a TSO service routine to analyze the DAIR status and compose an appropriate message. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 no rationale. None was needed. I guarantee you that it was never even considered as a possibility. DISP worked on the data set, period. That was all it was INTENDED to operate on, ever, and there was never any such thing as a decision made on the basis of insufficient resources (or anything else) not to support the deletion of a member instead of the entire data set when the JCL specified a member name and DISP=(whatever,DELETE). 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 something that never, in fact, happened. Nowadays the only rationale, spurious, is that it's always been that way. And ever shall be, as long as descendants of OS/360 endure. Nope. There is [still] no rationale because there has never been any consideration of the issue -- serious or otherwise. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 something that never, in fact, happened. Nowadays the only rationale, spurious, is that it's always been that way. And ever shall be, as long as descendants of OS/360 endure. Nope. There is [still] no rationale because there has never been any consideration of the issue -- serious or otherwise. Mentally reviewing this thread, I recall considerable sentiment (not necessarily majority) that when the user cites a member when allocating with a DELETE disposition, the reasonable expectation is that the entity to be deleted is the member mentioned. 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. 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. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
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 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 understanding why one would think that the scope of DISP would change based on whether a member name is coded - that just does not make sense to me. I guess it goes without saying, that I have never made this particular mistake. I have, of course, made numerous other mistakes, just not this one. Paul Gilmartin paulgboul...@aim.com 8/2/2010 4:13 PM 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 something that never, in fact, happened. Nowadays the only rationale, spurious, is that it's always been that way. And ever shall be, as long as descendants of OS/360 endure. Nope. There is [still] no rationale because there has never been any consideration of the issue -- serious or otherwise. Mentally reviewing this thread, I recall considerable sentiment (not necessarily majority) that when the user cites a member when allocating with a DELETE disposition, the reasonable expectation is that the entity to be deleted is the member mentioned. 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. 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. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
-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: 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 something that never, in fact, happened. Nowadays the only rationale, spurious, is that it's always been that way. And ever shall be, as long as descendants of OS/360 endure. Nope. There is [still] no rationale because there has never been any consideration of the issue -- serious or otherwise. Mentally reviewing this thread, ... 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? snippage The customers in those days actually read the doc and could, in many cases, program the thing from the display station as well as wire the plug boards for the external units. So, the customers came to see that DISP= was a DATA SET LEVEL disposition. At least this customer had that understanding. And when I wrote this for a Univac system, their equivalent of disposition was for the file not the data within the file. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 is yours! If I try to delete a PDS(E) member, as somebody else pointed out, do I delete it, its aliases, what's if it's an alias? At least we know its behavior. But, why should we change it just because Paul wants us to. We have documented and consistent behaviour that many understand. But, Paul doesn't like it, so we'd better change! - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 have a hard time understanding why one would think that the scope of DISP would change based on whether a member name is coded - that just does not make sense to me. 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 reference and try to find what would help them see things your way - or maybe discover that their way is actually better (reflects reality better, works better, etc.). Our courses are full of places where we have re-written explanations and labs after we gain insight into other perceptions and ways of seeing. I guess it goes without saying, that I have never made this particular mistake. I have, of course, made numerous other mistakes, just not this one. Paul Gilmartin paulgboul...@aim.com 8/2/2010 4:13 PM 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 something that never, in fact, happened. Nowadays the only rationale, spurious, is that it's always been that way. And ever shall be, as long as descendants of OS/360 endure. Nope. There is [still] no rationale because there has never been any consideration of the issue -- serious or otherwise. Mentally reviewing this thread, I recall considerable sentiment (not necessarily majority) that when the user cites a member when allocating with a DELETE disposition, the reasonable expectation is that the entity to be deleted is the member mentioned. 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. 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. -- gil -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 reference and try to find what would help them see things your way - or maybe discover that their way is actually better (reflects reality better, works better, etc.). Our courses are full of places where we have re-written explanations and labs after we gain insight into other perceptions and ways of seeing. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 reasonable expectation for 2010. However, JCL was designed in 1963 by Bernie Witt, George Mealy, and William Clark. There was little precedent -- perhaps only IBSYS control cards. I guarantee that there was no deficiency in those three gentlemen's perspective. Time has proven their inventiveness to be superlative. JCL (and, indeed, even code in object decks) that ran on OS/360 in 1966 is capable of being run under z/OS, with absolutely no [substantive] changes in most cases. DISP= in the DD statement applied to the DSNAME specified in that DD statement. Data sets with names (DSNAMEs) were a new invention in OS/360. DISP was also a new concept. They got to decide, as inventors, what these meant and what they would do. The intended/prospective customers would read the JCL manual and therein be TOLD what DISP= and DSNAME= meant and would do. Customer perception as a concept probably never entered into anyone's mind as System/360 or OS/360 were being designed. And I would bet that even if it had been raised as an issue in the form of this idea [how DISP=(whatever,DELETE) should work with a member name in DSNAME=] it would have been dismissed out of hand as silly. The inconsistency that you (and others) see is not something that anyone would see for decades. This thread is the very first time I have ever read of anyone suggesting this concept as an idea, either as a good or bad one. Despite how anyone could academically argue that it _should_ work, DISP IS an attribute of the DSNAME _allocation_ (that is, the DD [statement] when effected); if that is not clear, a simple explanation or statement of that fact should make it clear. It cannot reasonably be construed in that context to apply _sometimes_ to the member in the DSNAME= parameter and sometimes _not_ [which is what it would have to do if it were to apply in the case of DISP=(whatever,DELETE)]. To me, that is even more unreasonable than your insistence that (,DELETE) should mean delete the indicated member of the coded DSNAME. In other words, to have DISP=(whatever,DELETE) apply ONLY to a member of the PDS indicated by DSNAME= you have to redefine DISP to sometimes apply to the DSNAME and sometimes to apply to the member thereof. Isn't that inconsistent? I see it so. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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. That which is intuitively obvious to some is not necessarily intuitively obvious to all others. Sometimes we have to suspend our intuition and remember the rule which we have previously memorized, perhaps because the school of hard knocks forced us to. This is one of the many reasons for well-debugged documentation. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe 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 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 understanding why one would think that the scope of DISP would change based on whether a member name is coded - that just does not make sense to me. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 in the dsname, the DISPOSITION is always for the full dataset, NOT any 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. Nowadays the only rationale, spurious, is that it's always been that way. And ever shall be, as long as descendants of OS/360 endure. But such anomalies give me neither high expectations nor good wishes for the destiny of z/OS. 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 - IOW: Delete the member (which at this point IS the sequential dataset). Since this capability needs to be added to correct the it's always been that way behavior either add a REMOVE JCL value that can be used in lieu of DELETE to say to remove (ie: Delete the member) as a valid 2nd DISP Parm value, or add a PARMLIB setting to trigger the deletion of a member when requested via dsn=datasetname(member). In addition, there should be a PARMLIB setting to fix this DESIGN FLAW/BUG to return an error message and NOT delete the PDS when this type of request has been made. There are cases where IBM has changed the way that a function works and via a PARMLIB Setting you can turn off the new way the operation is performed so that it works the old way. Add the correct member delete code and require that it be activated via PARMLIB to work (IOW: Unless you add the needed setting, it will still do the old erroneous PDS Delete and not give an error message). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 shall be, as long as descendants of OS/360 endure. Every OS has its foibles. But, the people working with them know what they are (or should). But such anomalies give me neither high expectations nor good wishes for the destiny of z/OS. Ranting on IBM-Main does not change the behaviour. Documenting reasons for changes, along with sound business justification does. I should tell you the same thing, you told me, about the discussion regarding whether JCL was a programming language, a couple a weeks ago. I should, as tempting as it is, but I won't. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 - IOW: Delete the member (which at this point IS the sequential dataset). Exactly what do you wish to delete? If the member has alias entries, should these be deleted also? If no, will they stay widowed or should one be promoted to a non-alias? On the other hand, if the name points to an alias, should the alias be deleted alone, or with all associated entries? It looks to me as though you're trading one counterintuitive problem for another. At least the current behavior is documented, and most programmers won't do it more than once. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 definition of very little. E.g., :STOW is considered a BPAM macro. but works just fine with an :EXCP DCB for adding an alias and changing or deleting a :directory entry. I've never tried it on a PDS/E, or to add a :member, but at least the add could be done with proper data in :the DCB. READ/WRITE/NOTE/POINT is the same, i.e., processing a member or a sequential file uses the same code. BPAM adds BLDL/FIND/STOW but they are not part of the member processing. -- Binyamin Dissen bdis...@dissensoftware.com 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 fine with an EXCP DCB for adding an alias and changing or deleting a directory entry. I've never tried it on a PDS/E, or to add a member, but at least the add could be done with proper data in the DCB. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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:
Thanks for your understanding.
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 my experience, the reason code given is completely
valid but at the same time completely obfuscates the real problem because
the first hint of trouble (aka the problem) is NOT shown anywhere. You have
Several sides to this problem. The middle layer is only trying to
help you. In the case of the C RTL, trying to translate from z/OS
jargon to Unix/C jargon. I hear from one side:
What is this 'IEC143I 213-04', anyway!?
as from the other:
What is this 'broken pipe', anyway!?
And I know enough about both worlds that I cringe when I see:
128 rexx say BPXWDYN( 'alloc path(''/tmp/nonesuch'') msg(wtp)')
08.26.36 STC07821 IKJ56228I PATH /tmp/nonesuch NOT IN CATALOG OR CATALOG CAN
NOT BE ACCESSED
I'm confident that no CATALOG search was attempted and failed This is
either an attempt to convert a UNIX completion status to terms familiar
to legacy MVS programmers or an indolent inclination to recycle an existing
message rather than invent a proper one. I believe I even submitted a PMR
on the inaccuracy of the message. It went nowhere.
Conversion of completion status is generally pernicious. A FAQ on
TSO-REXX is, How can I force an ABEND from a Rexx EXEC? The
questioner wants either to flush remaining job steps or to force
a dump. Can't. The obvious technique, LINKMVS IEFDCH0, attempting
to force a SOC1 is trapped by the Rexx interpreter and reflected
to the caller as RC (-193).
to go and search for it, and to do that you must have some idea how things
work and/or work together. This is also why just about *any* problem (I have
seen) caused by some application code misusing some services unintentionally
goes in circles three hundred times until the customer escalates and finally
someone with my attitude to finding problems in USS comes along. (Guilty as
charged, I tend to escalate after the first circle. That is also why I know
more
about USS than I ever wanted to.)
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 in the dsname, the DISPOSITION is always for the full dataset, NOT any
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. Nowadays the only rationale, spurious, is that it's always
been that way. And ever shall be, as long as descendants of OS/360
endure. But such anomalies give me neither high expectations nor good
wishes for the destiny of z/OS.
member. What does the Language reference for remove() say what remove()
is applicable for? Is the dataset type (PDS/HFS/PS...) mentioned anywhere? Or
does the reference (however opaque) make it clear (what an oyxmoron) that
remove only works for a file in a USS file system? (And please check the
Language reference for z/OS, not any C or C++ reference). C/C++/Java 'in
nature' do not have a clue about the construct named PDS/E, as that is
unique to z/OS. And that distinction and the failure in the USS stuff to
clearly
say what you *cannot* do is another reason why I hate OMVS stuff.
Lately, I received in a reply to an RCF:
... The [...] book documents what is supported, not what is
not being supported. if something is not mentioned, it should
be assumed that it is not officially supported even though it
may work. ...
Here, I largely sympathize with IBM. what is not being supported
is an unbounded set, impossible to enumerate in a manual. My issue
is that IBM did not document what is being supported, but merely
supplied a handful of examples leaving the reader to extrapolate
often with wishful thinking and a probable inference of internal
implementation. (I need to ping IBM on this RCF again; it appears
to have gone idle.)
On the other side, IBM support once (attempted to) refute a PMR
with the assertion that my test case did not match any of the
examples in the manual. (I had invoked a utility (perhaps HLASM)
from a Rexx EXEC and all the examples showed invocation from JCL.)
Examples should not be considered restrictive.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Re: remove() of PDSE member leaves PDS locked
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, 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 BSAM or QSAM. So the above link is NOT what I meant. PDSE has a set of *internal* macros/interfaces (similar to the available BPAM macros) that *some* vendors have bought for in order to directly access PDSEs. Those interfaces are otherwise not documented, certainly not to the rest of the world. (This has been mentioned before on ibm-main.) Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 called BPAM, and that is not BSAM or QSAM. So the above link is NOT what I meant. 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. PDSE has a set of *internal* macros/interfaces (similar to the available BPAM macros) that *some* vendors have bought for in order to directly access PDSEs. Those interfaces are otherwise not documented, certainly not to the rest of the world. (This has been mentioned before on ibm-main.) I assume you're talking about media manager/FAMS. Maybe IBM doesn't trust it's customers to do the right thing unless they get to charge them $ ;^) Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 paragraphs). This type of inaccurate naming drives me nuts. And yes, the MVS STOW macro explicitly names both PDS and PDSE as working. So that piece of code (no idea if it can be ported to IBM C) would do the trick to implement what Etienne needs. That also says that SAS probably did not buy the interface docs (as the code behind STOW would know to call that interface.) I assume you're talking about media manager/FAMS. Maybe IBM doesn't trust it's customers to do the right thing unless they get to charge them $ ;^) yes, I think they were called FAMS. And *I* don't trust IBM to do the right thing, so that is probably mutual. :-) Except I don't get to charge IBM. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 bdis...@dissensoftware.com 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 it at this point I skip the remove() altogether, the fopen() still fails. So maybe remove() just upgraded a shared-read lock (ENQ?) to an exclusive lock (EXC?) and the real problem is the presence of this shared-read lock. So by way of experiment I placed a remove() plus fopen() at the start of the program, and lo, the fopen does not fail! So I think I must conclude that remove() is not causing this lock, but something else. So I will now place remove() + fopen() pairs along the execution path in my code, until the point where fopen starts failing. Between the last successful fopen and the first unsuccessful one, there I should (hopefully) find the cause... Thanks for thinking with me about this problem, I have learned a lot about ENQ's and latches now :-) Etienne -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 directories are serialized. And the reopen just hits the latch, not the ENQ. 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...? (And yes, I have performed open-heart-surgery in the OMVS asid by terminating a tcb there via callrtm when absolutely NO logon to uss or access to any new HFS file was possible anymore. That tcb held the needed latch. It was preferable to reIPL a production system during the day.) Interestingly, I have run into the same logon / HFS file access problems twice now, while debugging my remove() code with dbx... Technical support had to intervene both times to get my uss logon to work again. They said it is a latch contention problem. This seems to point to a latch problem, like you said. If only I know what a latch was... Maybe you can explain or point to some doc about latches? 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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 (and HFS) members and directories are serialized. And the reopen just hits the latch, not the ENQ. 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...? TSO RMFMON SENQ D M goes back to menu. Z exits the utility. (And yes, I have performed open-heart-surgery in the OMVS asid by terminating a tcb there via callrtm when absolutely NO logon to uss or access to any new HFS file was possible anymore. That tcb held the needed latch. It was preferable to reIPL a production system during the day.) Interestingly, I have run into the same logon / HFS file access problems twice now, while debugging my remove() code with dbx... Technical support had to intervene both times to get my uss logon to work again. They said it is a latch contention problem. This seems to point to a latch problem, like you said. If only I know what a latch was... Maybe you can explain or point to some doc about latches? Thanks, Etienne -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 is a SHR request [if it is an EXC do not run the code])? Agreed. This is a long-standing complaint. It's doable, but not yet done for some reason. Perhaps there is no formal requirement? I would think that the ability to release convert an EXC ENQ (due to a DISP=OLD) into a SHR ENQ (due to all the references to the DSN in subsequent steps being DISP=SHR) would be enough of a formal requirement. I know that that capability has been requested for a long time also. It is a pain you-know-where that the EXC ENQ is propagated to the last step using the dataset when there is no VALID need (beyond the refusal of IBM to fix this design flaw/bug) to not 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 valid assumption that there is only one instance of a DSN per computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 valid assumption that there is only one instance of a DSN per computer. That sentence no verb. Except in subordinate clauses. As I see it, that assumption ceased to be valid as soon as there was the possibility of more than one volume per computer. Including tapes. (Me too no verb. Five times.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 have a major name of SYSDSN, with minor name of your dataset. *That* ENQ is exclusive whenever there was a DISP=OLD, either in JCL or via dynamic allocation. (The ISPF stuff talked that serializes the member access about would have a different major name.) Then there is the D GRS,CONTENTION command, which *would* show contention. Again unfortunately, that won't help you, as there probably will not be any contention. An ENQ SVC/macro can be issued 'conditionally', which means 'give a return code when I cannot get it', and that is what LE runtime does, as far as I know. At the time you do the command, neither D GRS nor any of the commands that you had been given will show contention, I think. Interestingly, I have run into the same logon / HFS file access problems twice now, while debugging my remove() code with dbx... Technical support had to intervene both times to get my uss logon to work again. They said it is a latch contention problem. This seems to point to a latch problem, like you said. If only I know what a latch was... Maybe you can explain or point to some doc about latches? An ENQ is a rather huge way of serializing access. A latch is a much more granular way. There is also the equvalent of a major and a minor name. My unscientific guess for this is that some of your remove() code (or rather, what the underlying codes does when applied to a PDSE) has basically locked down access to the dataset and/or member, then terminated the process(?) without doing proper cleanup like releasing the latch. Since the owner of the latch (a TCB in MVS terms) is gone, that latch/serialization is held forever, and your next attempt to log in hits the 'latch held' (and in the case I had seen, it was the highest level directory latch for the HFS). --- Contention, as logon is NOT a 'give me the latch conditionally' thing. Latches can be shown with the system command D GRS,LATCH,JOB=jobname [,CONTENTION]. I am unsure what would be the jobname in this case, your current jobname or OMVS. In the case of access to an HFS, it would definitely be the OMVS address space. There are tons more of ways to display latches via D GRS. HFS latches and what they serialize I had seen in one of the USS books, but I don't remember which one it was. How to program latches is described (only?) in the macro reference/guide. Knowing how to program them would not help you at this point, I think, though. 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 that I have observed), so please do not take the following as an attack on you: 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 my experience, the reason code given is completely valid but at the same time completely obfuscates the real problem because the first hint of trouble (aka the problem) is NOT shown anywhere. You have to go and search for it, and to do that you must have some idea how things work and/or work together. This is also why just about *any* problem (I have seen) caused by some application code misusing some services unintentionally goes in circles three hundred times until the customer escalates and finally someone with my attitude to finding problems in USS comes along. (Guilty as charged, I tend to escalate after the first circle. That is also why I know more about USS than I ever wanted to.) 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 in the dsname, the DISPOSITION is always for the full dataset, NOT any member. What does the Language reference for remove() say what remove() is applicable for? Is the dataset type (PDS/HFS/PS...) mentioned anywhere? Or does the reference (however opaque) make it clear (what an oyxmoron) that remove only works for a file in a USS file system? (And please check the Language reference for z/OS, not any C or C++ reference). C/C++/Java 'in nature' do not have a clue about the construct named PDS/E, as that is unique to z/OS. And that distinction and the failure in the USS stuff to clearly say what you *cannot* do is another reason why I hate OMVS stuff. 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
Re: remove() of PDSE member leaves PDS locked
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 DISP=OLD, either in JCL or via dynamic allocation. (The ISPF stuff talked that serializes the member access about would have a different major name.) You do not need to know the major name to use the D GRS command: D GRS,RES=(*,SYS1.LINKLIB) ISG343I 22.53.25 GRS STATUS 351 S=SYSTEMS SYSDSN SYS1.LINKLIB SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS MVSA0 XCFAS 0006 00AFF890 SHARE OWN MVSA0 LLA001C 00AFF890 SHARE OWN MVS70 XCFAS 0006 00AFF890 SHARE OWN MVS70 LLA001C 00AFF890 SHARE OWN MVS60 XCFAS 0006 00AFF890 SHARE OWN MVS60 LLA001C 00AFF890 SHARE OWN -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 in it using fopen() in the same program. The PDSE only gets unlocked after the program has ended. The C RTL is a moron. It ought to use ISPF-style serialization rather than doing a blanket RESERVE. (I know; Shmuel will say that wouldn't be safe. Tell that to the ISPF designers.) And it ought to know the rules are different for PDSEs. If remove() fails to close the data set when it finishes, this ought to be cause for a PMR. But is there another stream that might be holding the data set open? -- gil 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. I think I will try some other methods to remove it, maybe a dynalloc() with __DISP_DELETE followed by dynfree() will remove it without locking up the PDSE. Or maybe if I first allocate the PDSE with dynalloc and then remove() the member using the DDNAME, and then dynfree() the DDNAME; maybe that will work. 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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 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. The C RTL is a moron. It ought to use ISPF-style serialization rather than doing a blanket RESERVE. (I know; Shmuel will say that wouldn't be safe. Tell that to the ISPF designers.) And it ought to know the rules are different for PDSEs. If remove() fails to close the data set when it finishes, this ought to be cause for a PMR. But is there another stream that might be holding the data set open? -- gil 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. I think I will try some other methods to remove it, maybe a dynalloc() with __DISP_DELETE followed by dynfree() will remove it without locking up the PDSE. Or maybe if I first allocate the PDSE with dynalloc and then remove() the member using the DDNAME, and then dynfree() the DDNAME; maybe that will work. What is a real shame is that ISPF LMM services were not built on top of a services layer. In the 21st century the last thing a programmer wants to do is hack about with assembler macros. SAS/C has a nice BSAM low-level layer which has an osstow() function which is just what we need on z/OS. Unfortunately, it's time to RYO. 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 the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 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. The C RTL is a moron. It ought to use ISPF-style serialization rather than doing a blanket RESERVE. (I know; Shmuel will say that wouldn't be safe. Tell that to the ISPF designers.) And it ought to know the rules are different for PDSEs. If remove() fails to close the data set when it finishes, this ought to be cause for a PMR. But is there another stream that might be holding the data set open? -- gil 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. I think I will try some other methods to remove it, maybe a dynalloc() with __DISP_DELETE followed by dynfree() will remove it without locking up the PDSE. Or maybe if I first allocate the PDSE with dynalloc and then remove() the member using the DDNAME, and then dynfree() the DDNAME; maybe that will work. What is a real shame is that ISPF LMM services were not built on top of a services layer. In the 21st century the last thing a programmer wants to do is hack about with assembler macros. SAS/C has a nice BSAM low-level layer which has an osstow() function which is just what we need on z/OS. Unfortunately, it's time to RYO. The previous version of our product was in fact written in SAS/C, and it did not have these problems; its PDS(E) support was a lot better. It had its own limitations, however, which forced us to go to the IBM compiler. Now I see myself faced with the task of implementing 'missing functionality', things that SAS/C could and IBM C can't. Anyway, I tried the dynalloc way with __DISP_DELETE, but it throws away the whole PDSE, not just the member; I must be doing something wrong... still investigating. The other option, allocating the PDSE, then removing DDNAME: (member) and dynfree the PDSE again works only partly: ISPF no longer reports the PDSE is in use, but fopen() to create a new member still fails. If anyone has an idea about how this can be fixed, that would be great. Or maybe you know of another method...? 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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 that there's an outstanding ENQ SHR due ta another stream, or even an allocation in another job step. 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). (BTW, what happens if you attempt the remove() while a different job holds ENQ SHR on the DSN?) What is a real shame is that ISPF LMM services were not built on top of a services layer. In the 21st century the last thing a programmer wants to do is hack about with assembler macros. SAS/C has a nice BSAM low-level layer which has an osstow() function which is just what we need on z/OS. Unfortunately, it's time to RYO. I thougnt ISPF services were available from Rexx address ISPEXEC and various other languages via CALL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 to the remove() statement; when I step over it, it is locked. It's yet possible that there's an outstanding ENQ SHR due ta another stream, or even an allocation in another job step. 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). (BTW, what happens if you attempt the remove() while a different job holds ENQ SHR on the DSN?) What is a real shame is that ISPF LMM services were not built on top of a services layer. In the 21st century the last thing a programmer wants to do is hack about with assembler macros. SAS/C has a nice BSAM low-level layer which has an osstow() function which is just what we need on z/OS. Unfortunately, it's time to RYO. I thougnt ISPF services were available from Rexx address ISPEXEC and various other languages via CALL. 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. At the moment I am contemplating creating a separate executable, DELMBR, that will use remove() to delete it, thereby locking the PDSE, but when it finishes, the PDSE is unlocked. If I use system() to call this program then maybe the PDSE won't be locked when DELMBR finishes and fopen() succeeds... hopefully. 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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 contemplating creating a separate executable, DELMBR, that will use remove() to delete it, thereby locking the PDSE, but when it finishes, the PDSE is unlocked. If I use system() to call this program then maybe the PDSE won't be locked when DELMBR finishes and fopen() succeeds... hopefully. Is your C program holding an ENQ SHR on the DSN? You can probe this prior to the remove() by submitting a batch job that attempts to allocate the PDSE with DISP=OLD. If you hold the ENQ SHR, then: o If system(DELMBR) runs in the same address space, it will upgrade the ENQ to EXC and leave the PDSE locked. o If system(DELMBR) runs in a separate address space, it will attempt to obtain an ENQ EXC and fail. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 all else fails. The best I can say is that it's in the book. At the moment I am contemplating creating a separate executable, DELMBR, that will use remove() to delete it, thereby locking the PDSE, but when it finishes, the PDSE is unlocked. If I use system() to call this program then maybe the PDSE won't be locked when DELMBR finishes and fopen() succeeds... hopefully. Is your C program holding an ENQ SHR on the DSN? You can probe this prior to the remove() by submitting a batch job that attempts to allocate the PDSE with DISP=OLD. If you hold the ENQ SHR, then: o If system(DELMBR) runs in the same address space, it will upgrade the ENQ to EXC and leave the PDSE locked. o If system(DELMBR) runs in a separate address space, it will attempt to obtain an ENQ EXC and fail. Any idea how to get rid of this ENQ SHR ? 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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 FREE that. You probably don't want to do any of those. It's not nice to deceive the C RTL. FREE will fail if there's a DCB open on the DDNAME. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 to DYNALLOC or BPXWDYN. Use TSO LISTALC STATUS SYSNAMES and find the DDNAME and FREE that. You probably don't want to do any of those. It's not nice to deceive the C RTL. FREE will fail if there's a DCB open on the DDNAME. -- gil 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... 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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 probably only trying to help you.) 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 authorized. PITA. I hate MVS! I tried an experiment. It appears that FTP can delete a member while a PDS (I didn't try PDSE) is allocated SHR. Can you FTP LOCALHOST from your C program? Have you considered z/OS Unix files as an alternative to PDSE? Even though it is MVS, it's remarkably free of the allocation mickeymouse. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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. :-( So that didn't work... Was it SHR? Why does C RTL have it OPEN? (It's probably only trying to help you.) 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 authorized. PITA. I hate MVS! I tried an experiment. It appears that FTP can delete a member while a PDS (I didn't try PDSE) is allocated SHR. Can you FTP LOCALHOST from your C program? Have you considered z/OS Unix files as an alternative to PDSE? Even though it is MVS, it's remarkably free of the allocation mickeymouse. Its not SHR. I think because remove() has to update its directory. Why it is left open... beats me. Maybe because a subsequent remove() or rename() will go faster... (rename() has the same problem, by the way). APF authorized is bad. The program must be able to run without. So no ISPF... FTP is a nice twist :-) that may work (although performance will suck.., but beter something than nothing). Unix files work fine, I know. But I need to enable everything that worked in the previous version, the SAS/C one, which version worked fine with PDS's and PDSE's, but did not support Unix files. People that upgrade to the new version I am working on won't like it if I was to tell them PDS's are not supported anymore... 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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
-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 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 authorized. PITA. SNIPPAGE APF authorized is bad. The program must be able to run without. So no ISPF... FTP is a nice twist :-) that may work (although performance will suck.., but beter something than nothing). SNIPPAGE If you run under ISPF, you do not have to be APF authorized. You don't even have to run from an APF library. When you invoke PDF services (now integral to ISPF, right?), the service communicates with ISPF as needed and so the cross-over between the TCB you are running under (applications run as a daughter task to ISPF as I recall) and ISPF will deal with authorization issues. SO, you can use ISPF services in a TSO Batch environment (or online for that matter). And probably get done what you need to do. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
On Tue, 27 Jul 2010 13:49:30 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: -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 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 authorized. PITA. SNIPPAGE APF authorized is bad. The program must be able to run without. So no ISPF... FTP is a nice twist :-) that may work (although performance will suck.., but beter something than nothing). SNIPPAGE If you run under ISPF, you do not have to be APF authorized. You don't even have to run from an APF library. When you invoke PDF services (now integral to ISPF, right?), the service communicates with ISPF as needed and so the cross-over between the TCB you are running under (applications run as a daughter task to ISPF as I recall) and ISPF will deal with authorization issues. SO, you can use ISPF services in a TSO Batch environment (or online for that matter). And probably get done what you need to do. Regards, Steve Thompson That is interesting, but requiring the program to run under ISPF just so I can delete a PDSE member without locking it seems overkill a cannon to kill a fly. There must be a simpler way... Thanks anyway, Etienne -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 design that does not allow an EXC to be downgraded to a SHR. I fail to see why it is not allowed. The EXC is the first entry in the queue and may be followed by another EXC request or SHR requests in a wait state. Right now if I do the DEQ of the EXC it is removed and the waiting ENQs are taken out of wait status in queued order until an EXC request is found or the queue is exhausted. 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])? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
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 is a SHR request [if it is an EXC do not run the code])? Agreed. This is a long-standing complaint. It's doable, but not yet done for some reason. Perhaps there is no formal requirement? -- Edward E Jaffe Chief Technology Officer Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 yes, I have performed open-heart-surgery in the OMVS asid by terminating a tcb there via callrtm when absolutely NO logon to uss or access to any new HFS file was possible anymore. That tcb held the needed latch. It was preferable to reIPL a production system during the day.) Regards, Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
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 program has ended. The C RTL is a moron. It ought to use ISPF-style serialization rather than doing a blanket RESERVE. (I know; Shmuel will say that wouldn't be safe. Tell that to the ISPF designers.) And it ought to know the rules are different for PDSEs. If remove() fails to close the data set when it finishes, this ought to be cause for a PMR. But is there another stream that might be holding the data set open? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
remove() of PDSE member leaves PDS locked
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 has an allocation named SYS00035, so I thought I might unlock the PDSE by doing a dynfree() on that DDNAME, but that fails with reason 1056, which means the dataset is open and must first be closed. But how can I close a dataset that I didn't open, but seems to have been opened implicitly by the remove() statement? Thanks for any insight you may have, Etienne -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
