In p06240821c965fb79762c@[192.168.1.11], on 01/26/2011
at 11:42 AM, Robert A. Rosenberg hal9...@panix.com said:
What complex issues do you see if you COULD ensure that everyone
switched from DSN to DSN+VOLSER (with or without the MEMBER NAME if
it exists in the current RNAME)?
A deadly
In listserv%201101251611342249.0...@bama.ua.edu, on 01/25/2011
at 04:11 PM, Bill Godfrey yak36...@yahoo.com said:
... when writing to a data set on a DASD (COPY/MOVE) that has a RECFM
of 'U', ISPF serializes with the linkage editor using the following
macro to protect the entire partitioned
In listserv%201101252258050073.0...@bama.ua.edu, on 01/25/2011
at 10:58 PM, Paul Gilmartin paulgboul...@aim.com said:
ISPF inherits from TSO a catalog tunnel vision.
Not quite.
If the DSNs are the same, they must be on the same volume.
Not even close.
When I pointed that deficiency here,
On 26 Jan 2011 10:52:46 -0800,
m42tom-ibmm...@yahoo.com (Tom Marchant) wrote:
That is not correct. SYSDSN is not an authorized QNAME, as Jim Mulder
posted yesterday.
You might want to take a second look at Jim's list: sixth entry from
the top, I see SYSDSN in the list of QNAMEs that only
On Thu, 27 Jan 2011 09:07:02 -0600, Eric Chevalier wrote:
You might want to take a second look at Jim's list: sixth entry from
the top, I see SYSDSN in the list of QNAMEs that only authorized
callers may specify.
Yes, John Gilmore corrected me and I acknowledged that I had it wrong
yesterday.
At 13:08 -0600 on 01/26/2011, Tom Marchant wrote about Re:
Long-running jobs, PDS, and DISP=SHR:
x-charset ISO-8859-1On Wed, 26 Jan 2011 11:42:46 -0500, Robert A.
Rosenberg wrote:
Remember we
are talking about ENQs that occur as the programs execute (and thus
where the VOLSER is known
At 22:58 -0600 on 01/25/2011, Paul Gilmartin wrote about Re:
Long-running jobs, PDS, and DISP=SHR:
But still, realistically, what need has anyone to perform concurrent
link edits to identical SYSLMOD DSNs on different volumes, or to
edit with ISPF identically named members of identically named
A. Rosenberg hal9...@panix.comwrote:
At 22:58 -0600 on 01/25/2011, Paul Gilmartin wrote about Re: Long-running
jobs, PDS, and DISP=SHR:
But still, realistically, what need has anyone to perform concurrent
link edits to identical SYSLMOD DSNs on different volumes, or to
edit with ISPF identically named
At 09:14 -0500 on 01/26/2011, Scott Rowe wrote about Re: Long-running
jobs, PDS, and DISP=SHR:
That's all fine and good, but it is far more complex an issue than just
having ISPF and/or linkedit change their ENQs, right?
I am not saying to change the ENQ but only answering the question
Tom Marchant writes:
begin snippet
It is a straw man only if you can guarantee that there is no code outside of
IBM code that serializes by issuing their own ENQ on SYSDSN.
/end snippet
Now to use ENQ with the qname SYSDSN a task must be in supervisor state, system
key [0-7], or
John,
It is nice to see that you trust all your ISVs and any local/shareware code
so implicitly, but I would certainly not want to bet my job on that.
How about any code that uses GQSCAN to query SYSDSN ENQs?
How exactly are you going to put a volser in a SYSDSN ENQ when the dataset
has not been
On Wed, 26 Jan 2011 17:16:40 +, john gilmore wrote:
Now to use ENQ with the qname SYSDSN a task must be in supervisor
state, system key [0-7], or Authorized;
That is not correct. SYSDSN is not an authorized QNAME, as Jim Mulder
posted yesterday.
--
Tom Marchant
On Wed, 26 Jan 2011 11:42:46 -0500, Robert A. Rosenberg wrote:
Remember we
are talking about ENQs that occur as the programs execute (and thus
where the VOLSER is known at ENQ issuance time)
The volser is not always available when the ENQ is issued. All of the
data sets for a job are ENQ'ed at
then how can we be sure that TWO people won't try to update it at the same
time DISP=SHR?
I believe that concurrent updates to a PDS result in an S213-30 abend.
Bob Shannon
Rocket Software
--
For IBM-MAIN subscribe / signoff /
On Tue, 2011-01-25 at 08:09 -0500, Bob Shannon wrote:
I believe that concurrent updates to a PDS result in an S213-30 abend.
A very long time ago this was because OPEN unconditionally enqueued
against SYSZDSCB (RNAME=volser||A||dsn). The operating system has
been renamed three times since then.
On Tue, 25 Jan 2011 00:53:25 -0500, Robert A. Rosenberg wrote:
As a side note: Since the ENQ is done as the program executes, I
think that the ENQ is not granular enough to target the correct
RNAME since it probably uses just the DSN not the more focused
DSN+VOLSER that would not lockout updates
On 01/25/2011 07:09 AM, Bob Shannon wrote:
then how can we be sure that TWO people won't try to update it at the same time
DISP=SHR?
I believe that concurrent updates to a PDS result in an S213-30 abend.
Bob Shannon
Rocket Software
...
That's correct. In order to write to a PDS, before
But I'm curious: an expert once told me that APF authorization
is required for QNAME=SYS*. But I believe Binder can operate
unauthorized and use QNAME=SYSIEWLP. How?
From z/OS V1R12.0 MVS Planning: Global Resource Serialization:
1.2.2 Authorized qnames
An authorized caller of the ENQ
In 45e5f2f45d7878458ee5ca6796973355b85...@usdaexch01.kbm1.loc, on
01/24/2011
at 08:58 AM, Staller, Allan allan.stal...@kbmg.com said:
All three of the OP's scenarios involve the update of a PDS/Directory
while the information in that PDS/Directory is in a state of flux.
No. None of his
In p06240807c96411a60f5d@[192.168.1.11], on 01/25/2011
at 12:53 AM, Robert A. Rosenberg hal9...@panix.com said:
As a side note: Since the ENQ is done as the program executes, I
think that the ENQ is not granular enough to target the correct
RNAME since it probably uses just the DSN not the
In 00a801cbbc26$b1c0e8e0$1542baa0$@org, on 01/24/2011
at 04:27 PM, Charles Mills charl...@mcn.org said:
Ah. Thanks (again). Doesn't IEBCOPY use the binder under the covers
for load modules, or am I thinking of a different problem?
IEBCOPY uses the binder for program objects in a PDSE, not for
In p06240802c9623b64a64c@[192.168.1.11], on 01/23/2011
at 03:26 PM, Robert A. Rosenberg hal9...@panix.com said:
NO. It reloads from the PDS(E).
No it doesn't.
REFRESHing occurs by reloading the
load module not by just paging it back into memory.
That may be true for program objects in a
In 02f701cbba40$e153cd30$a3fb6790$@org, on 01/22/2011
at 06:30 AM, Charles Mills charl...@mcn.org said:
Let's assume the program does not dynamically load any components
from MYLIBE on an ongoing basis
That assumption may be dicey for PDSE.
(and is not an overlay structure --
those don't
shmuel+ibm-m...@patriot.net (Shmuel Metz , Seymour J.) writes:
No. None of his scenarios involved concurrent updates. The danger
comes from scenarios other than the ones he presented. Of course, the
ABEND S213 will prevent corruption of the directory in that case.
for a long time, CKD disks
At 11:57 -0500 on 01/25/2011, Shmuel Metz (Seymour J.) wrote about
Re: Long-running jobs, PDS, and DISP=SHR:
In p06240807c96411a60f5d@[192.168.1.11], on 01/25/2011
at 12:53 AM, Robert A. Rosenberg hal9...@panix.com said:
As a side note: Since the ENQ is done as the program executes, I
On Tue, 25 Jan 2011 11:57:19 -0500, Shmuel Metz (Seymour J.) wrote:
In p06240807c96411a60f5d@[192.168.1.11], on 01/25/2011
at 12:53 AM, Robert A. Rosenberg said:
As a side note: Since the ENQ is done as the program executes, I
think that the ENQ is not granular enough to target the correct
On Tue, 25 Jan 2011 22:13:52 -0500, Robert A. Rosenberg wrote:
Since there is a UCB= on the RESERVE the acknowledges that it knows
(ie: should know) the VOLSER, IMO not adding the VOLSER to the RNAME
is a case of Foolish Consistency (ie: Acting like SYSDSN). I think
Cui malo?
The EXC ENQ is
On 1/25/2011 10:13 PM, Robert A. Rosenberg wrote:
Since there is a UCB= on the RESERVE the acknowledges that it
knows (ie: should know) the VOLSER, IMO not adding the VOLSER to
the RNAME is a case of Foolish Consistency (ie: Acting like
SYSDSN). I think the ISPF EDIT ENQ (which adds the Member
Officially, the answer to all three is *NO*. IBM does not vouch for
integrity in these situations. (update while open w/DISP=SHR).
Experience indicates the actual answer to all three is yes (with
cautions). This should not be attempted by a sysprog wannabe).
In some cases (e.g. SYS1.PROCLIB,
At 07:33 -0600 on 01/24/2011, Staller, Allan wrote about Re:
Long-running jobs, PDS, and DISP=SHR:
Officially, the answer to all three is *NO*. IBM does not vouch for
integrity in these situations. (update while open w/DISP=SHR).
Experience indicates the actual answer to all three is yes
snip
I assume that the potential exposure in case 1 when adding as opposed
to replacing a program is that the directory is in a state of flux
involving moving entries from one block to the next (a replace would
usually only rewrite a single block up update the TTR). I know that
there is an EXC
On 1/24/2011 7:58 AM, Staller, Allan wrote:
snip
I assume that the potential exposure in case 1 when adding as opposed
to replacing a program is that the directory is in a state of flux
involving moving entries from one block to the next (a replace would
usually only rewrite a single block up
: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Staller, Allan
Sent: Monday, January 24, 2011 6:59 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long-running jobs, PDS, and DISP=SHR
snip
I assume that the potential exposure in case 1 when adding as opposed
to replacing
.)
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Charles Mills
Sent: Sunday, January 23, 2011 12:51 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long-running jobs, PDS, and DISP=SHR
Hey, thanks much!
Bottom line is that only #1
Integrity is ensured by requiring the updater to have exclusive control
(for the duration) of the resource being updated.
If *ANY* other entity in the SYS(tem or plex) is accessing whatever is
being updated, the item is in flux and a potential for
invalid/corrupted data is present.
This can be a
At 09:43 -0800 on 01/24/2011, Charles Mills wrote about Re:
Long-running jobs, PDS, and DISP=SHR:
A problem that no one has pointed out is that if a job is using a STEPLIB
DISP=SHR and we say it is okay to update that library DISP=SHR, then how can
we be sure that TWO people won't try
PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long-running jobs, PDS, and DISP=SHR
At 09:43 -0800 on 01/24/2011, Charles Mills wrote about Re:
Long-running jobs, PDS, and DISP=SHR:
A problem that no one has pointed out is that if a job is using a STEPLIB
DISP=SHR and we say it is okay to update
: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf
Of Robert A. Rosenberg
Sent: Monday, January 24, 2011 1:25 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long-running jobs, PDS, and DISP=SHR
At 09:43 -0800 on 01/24/2011, Charles Mills wrote about Re:
Long-running jobs, PDS
At 22:42 + on 01/24/2011, john gilmore wrote about Re: Long-r
unning job s, PDS, an d DISP=SHR =?windows-1256?:
Robert A. Rosenberg wrote
begin snippet
As I noted, if the updating is being done by Linkedit/Binder (as
opposed to IEBCOPY) there is an ENQ lock (QNAME=SYSIEWL [I think]
with
At 16:27 -0800 on 01/24/2011, Charles Mills wrote about Re:
Long-running jobs, PDS, and DISP=SHR:
Ah. Thanks (again). Doesn't IEBCOPY use the binder under the covers for load
modules, or am I thinking of a different problem?
Charles
I think only for PDSEs. There is no need for the BINDER
At 06:30 -0800 on 01/22/2011, Charles Mills wrote about Long-running
jobs, PDS, and DISP=SHR:
I've kind of muddled around this issue for years. I thought I would ask here
and get some more real answers. I know what I am asking about seems to work
but I don't know if it is technically correct
Sent: Sunday, January 23, 2011 12:26 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long-running jobs, PDS, and DISP=SHR
At 06:30 -0800 on 01/22/2011, Charles Mills wrote about Long-running
jobs, PDS, and DISP=SHR:
I've kind of muddled around this issue for years. I thought I would ask
here
and get some
At 12:51 -0800 on 01/23/2011, Charles Mills wrote about Re:
Long-running jobs, PDS, and DISP=SHR:
Hey, thanks much!
You're Welcome.
Bottom line is that only #1 is completely safe (given my caveat does not
dynamically load any components from MYLIBE on an ongoing basis).
I'm sure
If I made an error in giving my analysis, there will soon be a correction
from someone here.
:-)
Charles
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message:
I've kind of muddled around this issue for years. I thought I would ask here
and get some more real answers. I know what I am asking about seems to work
but I don't know if it is technically correct.
Given a long-running program executing out of a PDS named MYLIBE:
//STEP1 EXEC PGM=PROGA
On Sat, 22 Jan 2011 06:30:12 -0800, Charles Mills wrote:
1. Is it safe to copy or link/bind another program into the same PDS
specifying DISP=SHR?
//SYSLMOD DD DSN=MYLIBE(PROGB),DISP=SHR
2. Is it safe to copy or link/bind PROGA into the same PDS?
//SYSLMOD DD DSN=MYLIBE(PROGA),DISP=SHR
3. Is
46 matches
Mail list logo
