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

Reply via email to