Hi to all,
In thread 'Why is GRS ENQ needed in SMFDUMP program?' I described the GRS ENQ
in SMFDUMP and the resulting START PENDING problem. That was in June 2012 and
there was a very interesting discussion lasted a while.
This problem is now resolved at all. Thanks to all who replied, all
A nagging doubt since my earlier post compelled me to go look at the
UCB mapping. It seems that the bit is actually a one-byte count
which makes sense for concurrent RESERVE activity.
===
Date: Sun, 1 Jul 2012 00:28:04 -0400
From: shmuel+...@patriot.net
Subject: Re: SV: Why is GRS ENQ
In 67102dbd-8232-47d1-88be-9b62c0715...@comcast.net, on 06/25/2012
at 03:33 AM, Dale Miller dalelmil...@comcast.net said:
You might call the RESERVE macro a special form of ENQ,
but the actual reserve was a hardware feature on DASD.
There is no the actual reserve; there is a RESERVE macro
In bay145-w28ad40f15a4f1654e89483a3...@phx.gbl, on 06/25/2012
at 09:25 AM, J R jayare...@hotmail.com said:
The RESERVE macro did (still does?) not directly do the hardware
reserve. Rather, it set a bit in the UCB to tell the next IO to the
unit to prepend a reserve CCW to the channel
You might call the RESERVE macro a special form of ENQ, but the actual
reserve was a hardware feature on DASD. When a reserve was initiated
by a processor, I/O's from other processors were delayed until the
reserve was released. The use of the ENQ was (IIRC) to provide a finer-
grained
In
CAE1XxDHCLFzEm2DQ8i_rc3PA9tP=JKa576L=2j0uQ=kp9k6...@mail.gmail.com,
on 06/22/2012
at 09:16 AM, John Gilmore jwgli...@gmail.com said:
I have reviewed Shmuel's language, and it still seems to me that he
was equating a hardware RESERVE with an ENQ macro,
Try a remedial reading course.
My
Mark Zelden wrote:
It's not on my web site.
1) It is IBM copyrighted code.
2) My changes were done for a client.
But my comments that I posted told you exactly what I changed from the sample
and the IBM changes match exactly what you posted.
Thanks. I will look around, reread your kind comments
In
CAE1XxDFG9DZMu=+npbg4tc4pgc2wcydx2gnsrt8vnpke_qu...@mail.gmail.com,
on 06/20/2012
at 02:36 PM, John Gilmore jwgli...@gmail.com said:
Anciently, under OS/PCP and OS/MFT, the Linkage Editor issued a
RESERVE for the DASD volume on which the target PDS for its output
load module resided in much
I have reviewed Shmuel's language, and it still seems to me that he
was equating a hardware RESERVE with an ENQ macro, but the distinction
you make is of course a valid one.
My problem with Shmuel's posts is that they are often contentious for
trhe sake of contention, but this time he may well
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of John Gilmore
Sent: Friday, June 22, 2012 8:17 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Why is GRS ENQ needed in SMFDUMP program?
I have reviewed Shmuel's language
I don't know the history of SMFDUMP within samplib, but since it is
apparently not shipped in supported z/OS releases, I would guess that it
is not appropriate to use on said releases.
It is possible that the user of the sample is supposed to change
SMFRNAME to something like
In my previous post I mistyped in mentioning alternate security product.
I meant instead an alternate serialization product (e.g., MIM) which may
have rules different than GRS.
Peter Relson
z/OS Core Technology Design
--
For
is GRS ENQ needed in SMFDUMP program?
In my previous post I mistyped in mentioning alternate security product.
I meant instead an alternate serialization product (e.g., MIM) which may
have rules different than GRS.
Peter Relson
z/OS Core Technology Design
On 6/22/2012 5:37 AM, McKown, John wrote:
I am fairly sure that Shmuel's comment was about the RESERVE macro, not the
hardware function. The RESERVE macro is logically equivalent to a SYSTEMS level
ENQ plus a hardware reserve (unless the GRSRNL converts it to not do the
hardware RESERVE).
Mark Zelden wrote:
I'm not sure exactly. Maybe to keep 2 of them start are started at the same
time from causing a problem since nothing else uses that qname/rname.
This is what I also guessed. Prevent two or more 'I SMF' happening at the same
time in a Sysplex.
As for the RESERVEs done when
The reason is that we sometimes we get a deadly embrace where two SMFDUMP
issue those ENQs and then while the system is doing its 'I SMF' things,
it still scans the DASD despite that we do not record SMF type 19.
In the end I need to cancel one of those SMF jobs, let the other run and
retry
Peter Relson wrote:
You wrote about your SMFDUMP program. What is that? The one provided by z/OS
does not use that ENQ.
The one as supplied by IBM. See copyright statement:
MODULE NAME = SMFDUMP
DESCRIPTIVE NAME =
On Thu, 21 Jun 2012 07:54:22 -0400, Peter Relson wrote:
You wrote about your SMFDUMP program. What is that? The one provided by
z/OS does not use that ENQ.
I think the sample programs SMFDUMP and IEFU29 shipped with OS/390 (and
earlier) used that ENQ.
SMFDUMP is not shipped with z/OS, but
On Thu, 21 Jun 2012 08:17:33 -0500, Elardus Engelbrecht wrote:
Peter Relson wrote:
... the ENQ you show is a SYSTEM level ENQ, not a SYSTEMS level ENQ.
Indeed, from source this:
ENQ (SMFQNAME,SMFRNAME,E,,SYSTEM)
... holding of this ENQ on one LPAR will have no effect on another LPAR.
On Thu, 21 Jun 2012 04:25:48 -0500, Elardus Engelbrecht
elardus.engelbre...@sita.co.za wrote:
I also don't use RESERVEs. I forgot to mention that I get a lot of IOS071I
,**,SMS, START PENDING messages during a switch.
So, after my nightly jobs, I try to dump/clear all my SMF datasets
Doug Henry wrote:
This sounds to me like you are collecting SMF type 19 records. If this is the
case I would recommend not doing this.
D SMF,O on any LPAR show this:
SUBSYS(OMVS,NOTYPE(14,15,19,34:35,40,42,99)) -- PARMLIB
SUBSYS(TSO,NOTYPE(14,15,19,40,42,99)) -- SYS
:
www.rocketsoftware.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf
Of Tom Marchant
Sent: Thursday, June 21, 2012 9:10 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Why is GRS ENQ needed in SMFDUMP program?
On Thu, 21 Jun 2012 08:17:33
On Thu, 21 Jun 2012 04:25:48 -0500, Elardus Engelbrecht
elardus.engelbre...@sita.co.za wrote:
Mark Zelden wrote:
I'm not sure exactly. Maybe to keep 2 of them start are started at the same
time from causing a problem since nothing else uses that qname/rname.
This is what I also guessed.
Tom Marchant wrote:
Not the SYSTEM level ENQ that you have shown, unless you have added IPOSMF01
to the INCLude list in GRSRNKxx.
It is not there in GRSRNLxx (or GRSRNKxx which you wrote... ;-D ).
So, the problem is not a deadly embrace, but delays in processing. I think
you need to
On Thu, 21 Jun 2012 07:54:22 -0400, Peter Relson rel...@us.ibm.com wrote:
The reason is that we sometimes we get a deadly embrace where two SMFDUMP
issue those ENQs and then while the system is doing its 'I SMF' things,
it still scans the DASD despite that we do not record SMF type 19.
In the
IFASMFDP or IFASMFDL
SNIP
Thanks to all. I'm beginning to wonder if the SMFDUMP program may be
corrupt and need to be re-assembled from scratch. Or tryout file 686
from cbttape.org.
/SNIP
--
For IBM-MAIN subscribe / signoff
Mark Zelden wrote:
What do you mean you don't use reserves? You have commented them out in the
code, or your IODF/HCD isn't coded for shared DASD thus not issuing the
reserves?
Hmmm, interesting. I will have a talk with my HCD folks...
If you are seeing the start pendings, it looks like you
On Thu, 21 Jun 2012 09:59:13 -0500, Elardus Engelbrecht
elardus.engelbre...@sita.co.za wrote:
Mark Zelden wrote:
What do you mean you don't use reserves? You have commented them out in the
code, or your IODF/HCD isn't coded for shared DASD thus not issuing the
reserves?
Hmmm, interesting. I
Mark Zelden wrote:
As far as I can tell from one of your posts, I am using the same code you do.
I do asm/lnk with other usermods / exits for each OS upgrade.
These are the only changes I have, and the last change was in 2000 (discussed
on this list also IIRC):
All the sources I have, all
On Thu, 21 Jun 2012 10:20:56 -0500, Elardus Engelbrecht
elardus.engelbre...@sita.co.za wrote:
Mark Zelden wrote:
As far as I can tell from one of your posts, I am using the same code you
do. I do asm/lnk with other usermods / exits for each OS upgrade.
These are the only changes I have,
On Thu, 21 Jun 2012 09:45:05 -0500, Elardus Engelbrecht wrote:
IOS431I DEVICE 6F85 RESERVED TO CPU=.,LPAR ID=04 205
SYSTEM=
If it is not SMFDUMP that is issuing the reserve, who is?
--
Tom Marchant
--
For
On Thu, 21 Jun 2012 09:45:05 -0500, Elardus Engelbrecht
elardus.engelbre...@sita.co.za wrote:
. . .
Not the SYSTEM level ENQ that you have shown, unless you have added IPOSMF01
to the INCLude list in GRSRNKxx.
It is not there in GRSRNLxx (or GRSRNKxx which you wrote... ;-D ).
Any GRS exits?
Good day
I have reviewed our SMFDUMP program as well the one in CBTTAPE file 686.
Why is there a GRS ENQ? Is it needed? APAR? documentation? logic?
I see those names:
SMFQNAME DCCL8'IPOSMF01'
SMFRNAME DCCL7'DATASET'
and scope is SYSTEM?
What will break if I do not use GRS and
On Wed, 20 Jun 2012 09:44:57 -0500, Elardus Engelbrecht
elardus.engelbre...@sita.co.za wrote:
Good day
I have reviewed our SMFDUMP program as well the one in CBTTAPE file 686.
Why is there a GRS ENQ? Is it needed? APAR? documentation? logic?
I see those names:
SMFQNAME DCCL8'IPOSMF01'
34 matches
Mail list logo
