ISPF Profile Sharing Under z/OS 1.10
Rob Zenuk
Sysplexes under z/OS 1.10. Here are the ISPF Config file KEYWORD options in use
for Sharing:
PROFILE_SHARING = YES
PROFILE_ENQLOCK_WAIT = 1000
PROFILE_ENQLOCK_RETRY_COUNT = 1
PROFILE_ENQLOCK_PROMPT = YES
PROFILE_SYSPROF_CONFLICT = KEEP
PROFILE_ISPPROF_CONFLICT = KEEP
PROFILE_APPPROF_CONFLICT = KEEP
PROFILE_REFLIST_CONFLICT = KEEP
PROFILE_EDIT_CONFLICT = KEEP
PROFILE_BATCH_CONFLICT = DISCARD
PROFILE_OTHER_CONFLICT = KEEP
RESET_PROFILE_SHARING_SETTINGS = NO
We found several documented sources describing the limitations and
applications known to have issues. However, we are seeing a conflict with several
of the *PROF members. We use MIM and will get the standard MIM1038I and
MIM1039I messages whenever we force a profile update. For example, I will
use the KEYS command and update a value from LPAR1. From LPAR1, this works
fine. Later from LPAR2, when I attempt to update the same value, I get the
MIM messages for ISRPROF about the conflict then the ISPF Enqueue Failure
popup. It almost seems like as soon as an update occurs from an LPAR, the
other LPAR's are subject to these ENQ disruptions.
Another example involves SDSF. We are aware of the ULOG/EMCS issue and
have a local ULOG command that launches SDSF, sets a unique CONSOLE and
starts ULOG, so no problem there. Like above when I start the ID on multiple
LPAR's every is OK and the only issue is the ULOG/EMCS console conflict.
However, if I start SDSF on LPAR1 after a profile update (for an unrelated
*PROF member - different APPLID), when I attempt to start SDSF on LPAR2, it
complains about the ISFPROF member not being available and fails to load it...
I did not see anything that resembled this in IBMLink. From the Share
session I attended I was expecting different behavior. Anyone else had these
issues? Is this normal behavior for Profile Sharing? Are there some MIM
specific things that need to be done to avoid the MIM messages? We did the
SYSIKJUA RNLDEF change.
Thanks in Advance,
Rob
Pinnacle
Rob,
What are the specific ENQ's MIM is having a problem with? Are they the SPF
enq's, SYSDSN, something else? Are they SYSTEM or SYSTEMS? Maybe MIM is
passing around a SYSTEM enq that shouldn't be passed around? We need the
other Z to weigh in.
Tom
Mark Zelden
I guess I'm "the other Z" since Tom BCCed me on his reply.
Rob, are you sure you have the customization in place on all the
sharing LPARs? From LPAR2 I would expect the the ECMF message
but then the KEEP option should allow the update without the ENQ failure.
I haven't played with profile sharing yet... not even in my sandbox. I meant
to after 1.9 was installed, but never got a round tuit (tm).
In general, this shouldn't work any different under MIM than GRS and I
don't see any doc about excluding SPFEDIT so no real changes should
be *required* for MII. However, since ENQs may be issued just
as a test (which they probably are as part of the processing), then
you will probably want to turn ECMF for SPFEDIT so you don't see
the "bogus" conflict messages. Even without profile sharing these
are optional since ISPF will report on its own that a member is
in use when it finds the enq.
I would have to review all the customization table settings to see if I have
other recommendations, but CA MIM support is really good so the first Z
may want to open an issue with them also to see if they have something
to say about this.
Regards,
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Rob Zenuk
MIM1038I ROB contention with ROB OWNS EXCL on XX12 CN(INTERNAL)
MIM1039I ROB needs EXCL SPFEDIT ROB.ISPPROF(ISRPROF) CN(INTERNAL)
Table in use
TBCLOSE issued for table ISFPROF that is in use, ENQUEUE failed.
MIM1038I ROB contention with ROB OWNS EXCL on XX12 CN(INTERNAL)
MIM1039I ROB needs EXCL SPFEDIT ROB.ISPPROF(ISFPROF) CN(INTERNAL)
MIM ENQ recognition messages from the other system...
MIM1098I Contention with ROB needs EXCL on XX02 CN(INTERNAL)
MIM1099I ROB holds SPFEDIT ROB.ISPPROF(ISRPROF) EXCL CN(INTERNAL)
MIM1098I Contention with ROB needs EXCL on XX02 CN(INTERNAL)
MIM1099I ROB holds SPFEDIT ROB.ISPPROF(ISFPROF) EXCL CN(INTERNAL)
MIM1098I Contention with ROB needs EXCL on XX02 CN(INTERNAL)
MIM1099I ROB holds SPFEDIT ROB.ISPPROF(ISPSPROF) EXCL CN(INTERNAL)
Rob
In a message dated 10/29/2009 7:46:26 A.M. US Mountain Standard Time,
Mark Zelden
wrote:
<snip>
>>> RESET_PROFILE_SHARING_SETTINGS = NO
>>>
>
>Rob, are you sure you have the customization in place on all the
>sharing LPARs? From LPAR2 I would expect the the ECMF message
>but then the KEEP option should allow the update without the ENQ failure.
>
<snip>
Assuming you do have the customization everywhere you are sharing,
do the settings under "Settings --> Environ --> Shared Profile settings..."
match the config table on each system (perhaps during testing some
were set different)? You may want to change
"RESET_PROFILE_SHARING_SETTINGS" to YES.
If that pull down option is not available (like it is on my system), it
would mean the customization is not in place on that LPAR for
profile sharing.
Pinnacle
From: "Rob Zenuk" <Robz...@AOL.COM>
Newsgroups: bit.listserv.ispf-l
Sent: Thursday, October 29, 2009 1:40 PM
Subject: Re: ISPF Profile Sharing Under z/OS 1.10
> It is always an SPFEDIT ENQ.
>
> MIM1038I ROB contention with ROB OWNS EXCL on XX12 CN(INTERNAL)
> MIM1039I ROB needs EXCL SPFEDIT ROB.ISPPROF(ISRPROF) CN(INTERNAL)
>
> Table in use
> TBCLOSE issued for table ISFPROF that is in use, ENQUEUE failed.
>
> MIM1038I ROB contention with ROB OWNS EXCL on XX12 CN(INTERNAL)
> MIM1039I ROB needs EXCL SPFEDIT ROB.ISPPROF(ISFPROF) CN(INTERNAL)
>
> MIM ENQ recognition messages from the other system...
>
> MIM1098I Contention with ROB needs EXCL on XX02 CN(INTERNAL)
> MIM1099I ROB holds SPFEDIT ROB.ISPPROF(ISRPROF) EXCL CN(INTERNAL)
> MIM1098I Contention with ROB needs EXCL on XX02 CN(INTERNAL)
> MIM1099I ROB holds SPFEDIT ROB.ISPPROF(ISFPROF) EXCL CN(INTERNAL)
> MIM1098I Contention with ROB needs EXCL on XX02 CN(INTERNAL)
> MIM1099I ROB holds SPFEDIT ROB.ISPPROF(ISPSPROF) EXCL CN(INTERNAL)
>
>
> Rob
>
Rob,
I read the profile sharing doc, and there is no mention of how to handle the
SPFEDIT enq. Obviously, you can't just EXCLUDE SPFEDIT SYSTEMS enq's, so
this will either have to be handled in the ISPF code or in another way
that's not documented yet. I would open a PMR with IBM to either fix the
bug or clarify the doc on what we need to do.
Regards,
Tom Conley
Mark Zelden
It would be nice if the process was documented, but I'm sure it has
to issue ENQs with RET=TEST (which will cause the MII ECMF messages).
I don't have time to test this today (I don't think), but I will turn it on in
my sandbox (at least for me via config in a private lib) and see how it
works. I know I'll at least be updating my doc on my web site / CBT
file to indicate that ECMF should be turned off for SPFEDIT in an MIIplex
when you enable the support.
Mark Zelden
wrote:
>It would be nice if the process was documented, but I'm sure it has
>to issue ENQs with RET=TEST (which will cause the MII ECMF messages).
>
>I don't have time to test this today (I don't think), but I will turn it on in
>my sandbox (at least for me via config in a private lib) and see how it
>works. I know I'll at least be updating my doc on my web site / CBT
>file to indicate that ECMF should be turned off for SPFEDIT in an MIIplex
>when you enable the support.
>
I just did some quick testing using all the same settings as Rob Z, and
it seems to be working just fine. I didn't see any ECMF
messages either. I then went into SETTINGS and changed the "keep"
options to prompt on both sandbox LPARs, updated my keys, went to
the other LPAR and issued keys, and was prompted as documented.
(If RET=TEST on the ENQ is used, RET=TEST doesn't cause ECMF
messages. That makes sense now that I think about it)
BTW, at first I changed ISPF_TEMPORARY_DATA_SET_QUALIFIER
incorrectly. The dialogs warned me it needed to be changed to be
unique within the sysplex and I misunderstood. I changed
it from "SYS&SYSNAME" to "&SYSPLEX". And then I ran into problems
because the same log file was getting allocated on both LPARs.
The default is ISP&SEQ when profile sharing is active, so I changed it
to that and did not run into that problem afterwords.
Since I have the config table in my own "TSOLIB" so it only affects me,
will keep it this way until next week and test more, but I'm not seeing
a problem.
So I have to ask Rob again... are you sure you had the correct customization
module on all sharing LPARs?
BTW, I am running z/OS 1.10 RSU0906 and MIM 11.6 SP3.
Regards,
Rob Zenuk
all your posts on ISPF-L on this topic. However, I was beginning to suspect
the same thing... I was realizing I was seeing better behavior on one LPAR
than the others. I was also noticing that certain LPAR's were more
disruptive than others for sharing. So, I checked the ISPCFIGU module on all
systems and it was not the same everywhere... Since I did not do the install,
I have sent an email to the installing Sysprog.
Thanks for the help,
Rob
____________________________________
From: LIST...@LISTSERV.ND.EDU
Reply-to: ISP...@LISTSERV.ND.EDU
To: ISP...@LISTSERV.ND.EDU
Sent: 10/30/2009 8:00:40 P.M. US Mountain Standard Time
Subj: ISPF-L Digest - 29 Oct 2009 to 30 Oct 2009 (#2009-136)
Date: Fri, 30 Oct 2009 23:00:16 -0400
Reply-To: ISPF discussion list <ISP...@LISTSERV.ND.EDU>
Sender: ISPF discussion list <ISP...@LISTSERV.ND.EDU>
From: ISPF-L automatic digest system <LIST...@LISTSERV.ND.EDU>
Subject: ISPF-L Digest - 29 Oct 2009 to 30 Oct 2009 (#2009-136)
To: ISP...@LISTSERV.ND.EDU
Message-ID: <ISPF-L%20091030230...@LISTSERV.ND.EDU>
Precedence: list
List-Help: <http://listserv.nd.edu/cgi-bin/wa?LIST=ISPF-L>,
<mailto:LIST...@LISTSERV.ND.EDU?body=INFO%20ISPF-L>
List-Unsubscribe: <mailto:ISPF-L-unsubs...@LISTSERV.ND.EDU>
List-Subscribe: <mailto:ISPF-L-subsc...@LISTSERV.ND.EDU>
List-Owner: <mailto:ISPF-L-...@LISTSERV.ND.EDU>
List-Archive: <http://listserv.nd.edu/cgi-bin/wa?LIST=ISPF-L>
There are 2 messages totalling 128 lines in this issue.
Topics of the day:
1. ISPF Profile Sharing Under z/OS 1.10 (2)
Date: Fri, 30 Oct 2009 10:46:00 -0400
From: Mark Zelden <mark....@ZURICHNA.COM>
Subject:
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
It would be nice if the process was documented, but I'm sure it has
to issue ENQs with RET=TEST (which will cause the MII ECMF messages).
I don't have time to test this today (I don't think), but I will turn it
on in
my sandbox (at least for me via config in a private lib) and see how it
works. I know I'll at least be updating my doc on my web site / CBT
file to indicate that ECMF should be turned off for SPFEDIT in an MIIplex
when you enable the support.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at
http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Date: Fri, 30 Oct 2009 16:10:56 -0400
From: Mark Zelden <mark....@ZURICHNA.COM>
Subject: Re: ISPF Profile Sharing Under z/OS 1.10
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Rob Zenuk
Yup. That's where I learned to do that stuff a few years ago. Great
presentation and great material. Unfortunately, ISPF is not one of my areas
of responsibility here. Very rigid Change Control here with severe
penalties for undocumented/unapproved changes/fixes (up to and including castration
and death) so I can't fix it myself. To be fair to the Sysprog, the
complication on this Test Sysplex is this is where we maintain one copy of all
the OS releases currently in use. Since we are still rolling out z/OS 1.10
and still have some LPAR's at z/OS 1.9, the module was not rolled out
correctly to the z/OS 1.9 LPAR. Additionally, it was not rolled out at all to
our GDPS LPAR in that Sysplex. The Controlling GDPS LPAR does not use
Shared DASD since it has to be able to manage/survive a Hiperswap (Metro Mirror)
and/or Site swap (Global Mirror)... So, moving the new ISPCFIGU module to
SYS1.LINKLIB on a z/OS 1.10 system only hit 1 of the 3 LPAR's in that
Sysplex.
I used TSOLIB with the good ISPCFIGU member (copied to a dataset that
existed on all LPAR's) and it all worked as expected. I should have kept at it
and looked for the patterns before writing the note... Hopefully this
helps someone in the future to avoid our stumble on this.
While obvious to many (hence the word "shared"), it might be worthwhile to
reiterate in the manuals that the Configuration module must be the same for
all participating LPAR's (or at least the sharing values). Maybe this
would have reminded our Sysprog to consider all our extenuating
circumstances....
Thanks Tom, Thanks Mark,
Rob
In a message dated 10/30/2009 10:21:52 P.M. US Mountain Standard Tim,
pinn...@rochester.rr.com writes:
Rob,
Those freakin' sysprogs will get you every time ;-) In the meantime, you
can use TSOLIB before invoking ISPF to test your own ISPCFIGU on each
LPAR.
If you don't know how to run the config dialog, you can grab my
Configuring
ISPF for Fun and Profit at my web site below.
Regards,
Thomas Conley, President/CEO
Pinnacle Consulting Group, Inc.
59 Applewood Drive
Rochester, NY 14612-3501
P: (585)720-0012
F: (585)723-3713
http://home.roadrunner.com/~pinncons/
Mark Zelden
wrote:
>Since I have the config table in my own "TSOLIB" so it only affects me,
>will keep it this way until next week and test more, but I'm not seeing
>a problem.
>
So I am doing some more testing this morning using PROMPT.
First, I think there may be a bug or bugs. At least with application profile
sharing. I didn't always get prompts when I updated ISRPROF
for application profile updates. I also did testing using the KEYS
command as Rob was doing.
I really don't know that I like the support for profile sharing as I think it
is designed. It doesn't seem to add much more than anyone would
have had before if they shared profiles by excluding SPFEDIT just for
the minor name of the ISPF profile data set. You still lose updates
the other system did (although you may be prompted if you wish).
Here is an example prompt:
==========================================
Profile Data Set userid.MPLEX.ISPPROF
Table . . . . . : ISRPROF
Accessed Date . : 2009/11/02 Time . : 09:57:40
Modified Date . : 2009/11/02 Time . : 10:00:46
A change has been detected in the ISPF profile member since being
read by this ISPF session.
Enter "/" to select option
Disable prompt for Application Profile conflicts
Instructions:
Press Enter to KEEP the changes and update the ISPF profile member.
Enter END or EXIT to DISCARD the changes to the ISPF profile member.
===========================================
Now, what would be really useful is if the there was a 3rd option here
to re-read the profile with the values that were updated from the other
system. Then you could have everything back in sync and move on.
But since there isn't an option for that, I would have thought I could
get those updates by exiting ISPF and getting back in. So I tried that.
So when I saw the above prompt I did "end" to discard the changes.
But when I exited ISPF and re-invoked it again, I still saw the update
I made from the 2nd system that prompted me. Then I updated the
keys again from that system, and wasn't prompted at all. So I went
back to the 1st system, and did KEYS. It detected the update and I told
it to keep it. I then went to the 2nd system, exited ISPF, entered it
again and still saw my original updated... not the one I just made from
the 1st system that I told it to keep.
So I understand what is going on (sort of). The profile is not re-written
until you exit ISPF (that is the way it has worked before if the table
was open). But now, you have to exit ISPF on ALL SHARING SYSTEMS.
At least that is what I think. To me, it seems that if you tell ISPF to KEEP
the changes from whatever system you tell it do that, it should re-write
the changes (harden them) at that point.
Also, in addition to the prompt on write (if prompting is on), when you
read it should prompt you that you are possible reading obsolete or
updated information from another system. But I guess it can't do that
if nothing is actually written until you exit ISPF (on all systems?).
If all of the above isn't written clearly and is confusing... you are correct.
I'm almost more confused now. I would have to spend more time
(which I don't have at the moment) to clearly document what is happening,
but without the ISPF documentation spelling out exaclty how these sharing
scenarios should work, how can I open a defect PMR?
Paul Gilmartin
you expect it would merge modified values on the screen with
unmodified values from the other system?
The prompt should be issued when you begin to modify the profile
member, not when you attempt to SAVE it, even as ISPF EDIT
fails with MEMBER IN USE (whatever) when I attempt to edit a
member that another user is editing.
Journal the changes and sync the journal periodically?
Keep the profile in a VSAM data set with suitable sharing
options?
None of these work very well under the assumption that the
profile values must be cached for performance.
-- gil
Mark Zelden
Yes, so what. I told it to do that. And I also know what I just changed.
So I can read the other profile back and then keep that change or decide
to change it again or add onto it.
> Or do
>you expect it would merge modified values on the screen with
>unmodified values from the other system?
No.
>
>The prompt should be issued when you begin to modify the profile
>member, not when you attempt to SAVE it, even as ISPF EDIT
>fails with MEMBER IN USE (whatever) when I attempt to edit a
>member that another user is editing.
Agree. That would be better.
>
>Journal the changes and sync the journal periodically?
>
>Keep the profile in a VSAM data set with suitable sharing
>options?
>
>None of these work very well under the assumption that the
>profile values must be cached for performance.
>
It can continue to be cached. It just has to written if/when there is a
conflict
and KEEP is used by default or chosen via prompt.