KEY8 CSA
Schiradin,Roland HG-Dir itb-db/dc
Apply PTF TR00891 and TR00922.
No more KEY8 CSA/SQA allocations for TMQ!!
TMON/MVS V4.0 just receently announced should also eliminates such kind of allocations.
Roland Schiradin
ALTE LEIPZIGER Lebensversicherung auf Gegenseitigkeit
IT Betrieb - DB/DC
Tel. (06171) 66-4095, Fax (06171) 66-7500-4095
mailto:Schir...@Alte-Leipziger.de
http://www.Alte-Leipziger.de
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Knutson, Sam
have "good intentions":
Compuware ABEND-AID (JEERS! To Compuware for adding this code into
10.1 apparently a poor kludge to implement the HotKey new function.
ABEND-AID was not previously not on the list till this new function was
added).
ASG-TMONCICS (PTFs are supposed to be in QA and available to us soon)
BMC XBM
CA-UNICENTER DETECTOR for DB2
SOFTEK LDMF (TDMF probably has the issue too we just don't run it since
we are an FDRPAS customer)
Best Regards,
Sam Knutson, GEICO
Performance and Availability Management
mailto:sknu...@geico.com
(office) 301.986.3574
Make the most of today. Translate your good intentions into actual
deeds. - Grenville Kleiser
The road to Hell is paved with good intentions. - Karl Marx
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
DASD...@ibm-main.lst
In a message dated 6/28/2006 9:33:28 A.M. Central Daylight Time,
SKnu...@GEICO.COM writes:
>The road to Hell is paved with good intentions. - Karl Marx
I think another road to Hell is paved with key 8 CSA. What were they
thinking?
Bill Fairchild
gil...@ibm-main.lst
> Date: Wed, 28 Jun 2006 10:32:47 -0400
>
> Compuware ABEND-AID (JEERS! To Compuware for adding this code into
> 10.1 apparently a poor kludge to implement the HotKey new function.
> ABEND-AID was not previously not on the list till this new function was
> added).
> ASG-TMONCICS (PTFs are supposed to be in QA and available to us soon)
> BMC XBM
> CA-UNICENTER DETECTOR for DB2
> SOFTEK LDMF (TDMF probably has the issue too we just don't run it since
> we are an FDRPAS customer)
>
Has IBM any intention of prohibiting obtaining KEY 8 CSA storage in
some future release? This would provide any of:
o Great motivation for ISVs to clean up their acts. Fixing this
shouldn't be comparable to Rocket Science, should it?
o Great deterrent for customers' upgrading.
o Great opportunity for YA ISV to market a patch disabling an
integrity feature.
-- gil
--
StorageTek
INFORMATION made POWERFUL
Edward Jaffe
> Has IBM any intention of prohibiting obtaining KEY 8 CSA storage in
> some future release? This would provide any of:
>
> o Great motivation for ISVs to clean up their acts. Fixing this
> shouldn't be comparable to Rocket Science, should it?
>
> o Great deterrent for customers' upgrading.
>
> o Great opportunity for YA ISV to market a patch disabling an
> integrity feature.
>
IBM has supported this since OS/390 V2R6 via the undocumented -- yet
heavily discussed here, at SHARE, and elsewhere -- TRAPS
NAME(IgvNoUserKeyCSA) statement in DIAGxx.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Jim Mulder
10:53:24 AM:
> Has IBM any intention of prohibiting obtaining KEY 8 CSA storage in
> some future release? This would provide any of:
>
> o Great motivation for ISVs to clean up their acts. Fixing this
> shouldn't be comparable to Rocket Science, should it?
>
> o Great deterrent for customers' upgrading.
>
> o Great opportunity for YA ISV to market a patch disabling an
> integrity feature.
When you see a z/OS 1.8 MVS Initialization and Tuning Reference,
under the DIAGxx parmlib member, it will say:
VSM ALLOWUSERKEYCSA(YES|NO)
NO prevents user key CSA from being allocated by failing any
attempt to obtain user key from a CSA subpool (via GETMAIN or
STORAGE OBTAIN) with a B04-5C, B0A-5C, or B78-5C abend. The
default is YES, but IBM recommends that you specify NO to prevent
user key CSA from being obtained. User key CSA creates a security
risk because any unauthorized program can modify it. IBM plans
to change the default to NO in a future release of z/OS.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Mark Zelden
<edj...@PHOENIXSOFTWARE.COM> wrote:
>Paul Gilmartin wrote:
>> Has IBM any intention of prohibiting obtaining KEY 8 CSA storage in
>> some future release? This would provide any of:
>>
>> o Great motivation for ISVs to clean up their acts. Fixing this
>> shouldn't be comparable to Rocket Science, should it?
>>
>> o Great deterrent for customers' upgrading.
>>
>> o Great opportunity for YA ISV to market a patch disabling an
>> integrity feature.
>>
>
>IBM has supported this since OS/390 V2R6 via the undocumented -- yet
>heavily discussed here, at SHARE, and elsewhere -- TRAPS
>NAME(IgvNoUserKeyCSA) statement in DIAGxx.
>
"Supported"? Isn't this really an unsupported method intended
for use by ISVs or test environments? What if you ran this way on
your production / mission critical LPAR and it caused an unforseen
problem or outage?
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: mark....@zurichna.com
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Mark Zelden
>
> When you see a z/OS 1.8 MVS Initialization and Tuning Reference,
>under the DIAGxx parmlib member, it will say:
>
>VSM ALLOWUSERKEYCSA(YES|NO)
>
> NO prevents user key CSA from being allocated by failing any
>attempt to obtain user key from a CSA subpool (via GETMAIN or
>STORAGE OBTAIN) with a B04-5C, B0A-5C, or B78-5C abend. The
>default is YES, but IBM recommends that you specify NO to prevent
>user key CSA from being obtained. User key CSA creates a security
>risk because any unauthorized program can modify it. IBM plans
>to change the default to NO in a future release of z/OS.
>
Now that's what I call "supported"!
Edward Jaffe
>> IBM has supported this since OS/390 V2R6 via the undocumented -- yet
>> heavily discussed here, at SHARE, and elsewhere -- TRAPS
>> NAME(IgvNoUserKeyCSA) statement in DIAGxx.
>>
>>
>
> "Supported"? Isn't this really an unsupported method intended
> for use by ISVs or test environments? What if you ran this way on
> your production / mission critical LPAR and it caused an unforseen
> problem or outage?
>
It wasn't my place (legally) to "spill the beans" on the z/OS 1.8
enhancement to DIAGxx. But, since the "skunkworks" developer himself has
done so, I'll add that ALLOWUSERKEYCSA(NO) is equivalent to specifying
TRAPS NAME(IgvNoUserKeyCSA) in DIAGxx and that Healthchecker will supply
a check to warn of the potential security risk when ALLOWUSERKEYCSA(YES)
is in effect. Naturally, since the z/OS 1.8 default will be
ALLOWUSERKEYCSA(YES) for compatibility, the Healthchecker check will be
shipped inactive, though you will be able to activate it if you so desire.
Supported? Yes. Any less risky than the existing "undocumented" support?
No. If you prohibit the allocation of user key CSA on a production /
mission critical LPAR running z/OS 1.8, you could still experience an
outage. And there is no short-term relief other than disabling the support.
When IBM finally changes the ALLOWUSERKEYCSA default (in that future
z/OS release) to NO, it will mean that -- as of the release date of that
future release -- IBM *believes* that none of *its* software allocates
user key CSA and that they will gladly take an APAR to remove any such
allocations that a customer might discover the "hard" way. It says
nothing about ISV or installation written software.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
Mark Zelden
<edj...@PHOENIXSOFTWARE.COM> wrote:
>Supported? Yes. Any less risky than the existing "undocumented" support?
>No.
While the code path may be virtually the exact same in z/OS 1.8
with the new support as the TRAP in prior versions, "supported" means
that I would have been able to specify TRAPS NAME(IgvNoUserKeyCSA) on
any release since OS/390 R6 up to z/OS 1.8 (while the OS was still
supported) and IBM would debug / APAR any problem I had by specifying it.
I don't think that is the case.
That is the difference. There are many things you *can* do (including
many other diag traps as you said "discussed here and at SHARE"), but
using them is still unsupported and not recommended for a production
environment.
Speaking of which... is the use of the various "D LLA" options
"supported" yet?
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: mark....@zurichna.com
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Peter Relson
>that I would have been able to specify TRAPS NAME(IgvNoUserKeyCSA)
Change "any problem I had" to "any problem I had in IBM code" and I'd
agree.
Peter Relson
z/OS Core Technology Design
Edward Jaffe
> While the code path may be virtually the exact same in z/OS 1.8
> with the new support as the TRAP in prior versions, "supported" means
> that I would have been able to specify TRAPS NAME(IgvNoUserKeyCSA) on
> any release since OS/390 R6 up to z/OS 1.8 (while the OS was still
> supported) and IBM would debug / APAR any problem I had by specifying it.
> I don't think that is the case.
>
Huh???! If you discover and report a user key CSA allocation in IBM
code, they *will* take an APAR because it represents a potential
integrity exposure. The issue is not which tool you use to find the
exposure. The issue is the exposure itself!!
When you report an exposure of this type, you don't say, "I enabled the
undocumented IgvNoUserKeyCSA trap and experienced a B78-5C abend at
PGMXYZ+2F3C." Rather, you say something like, "PGMXYZ acquires key 8
CSA, which introduces a potential integrity exposure to my system!" If
you're concerned about sending IBM an SVC dump of the "unsupported"
B78-5C abend, then just don't do it. Set an IF SLIP at PGMXYZ+2F3C with
A=SYNCSVCD instead. In both cases, the system trace clearly shows the
CSA GETMAIN request parameters, but the latter case uses only
"supported" tools.
The only time I ever saw this issue handled in a less than satisfactory
manner was with IXFP. And, I don't really consider IBM to be at fault.
IBM took APAR OW53788 (it's one of those "secret" integrity APARs that
doesn't show up on your IBMLink SIS screen). Karl Schmitz (IBM's
integrity expert) got involved. It took a while, but eventually he was
able to convince STK that their key 8 CSA allocation created an
exposure. The APAR was closed FIN, but there never was a new release of
IXFP. (I got my RVA very late in its life cycle. Had I discovered this
exposure when RVAs were still new technology, there almost certainly
would have been a more positive outcome.)
** Warning ** If you still run IXFP, be sure to specify
ALLOWUSERKEYCSA(YES) in z/OS 1.8 and higher!
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
Mark Zelden
<edj...@PHOENIXSOFTWARE.COM> wrote:
>Mark Zelden wrote:
>> While the code path may be virtually the exact same in z/OS 1.8
>> with the new support as the TRAP in prior versions, "supported" means
>> that I would have been able to specify TRAPS NAME(IgvNoUserKeyCSA) on
>> any release since OS/390 R6 up to z/OS 1.8 (while the OS was still
>> supported) and IBM would debug / APAR any problem I had by specifying it.
>> I don't think that is the case.
>>
>
>Huh???! If you discover and report a user key CSA allocation in IBM
>code, they *will* take an APAR because it represents a potential
>integrity exposure. The issue is not which tool you use to find the
>exposure. The issue is the exposure itself!!
>
Ed,
I was not referring to a problem discovered by the specification
(user key CSA), I was referring to any other (IBM) problem caused
by using an undocumented / unsupported traps in DIAGxx.
Cheers,
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: mark....@zurichna.com
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Imbriale, Don
early edition of the Health Checker except in our sandbox and in very
limited circumstances elsewhere. The code was provided as-is, without
warranty, and required APF authorization. Even though it was from IBM, we
would not run it except as indicated above.
Don Imbriale
On Thu, 29 Jun 2006 10:32:31 -0500, Mark Zelden <mark....@ZURICHNA.COM>
wrote:
Edward Jaffe
> I was not referring to a problem discovered by the specification
> (user key CSA), I was referring to any other (IBM) problem caused
> by using an undocumented / unsupported traps in DIAGxx.
>
Mark,
You specifically referred to problems that might occur when specifying
IgvNoUserKeyCSA. Perhaps I misunderstood what you said, but in my
experience, any such "problems" are a direct result of the B78-5C abend
suffered by the code that's attempting to introduce the integrity
exposure to your system. Others on this list use "supported" ISV
monitors and such to detect these user key CSA allocations. As I said,
the issue is the exposure itself, not the tool used to find it.
I never mentioned traps other than IgvNoUserKeyCSA. I agree that none of
them are supported. But that's common knowledge. UAYOR!
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
Mark Zelden
On Thu, 29 Jun 2006 09:13:37 -0700, Edward Jaffe
<edj...@PHOENIXSOFTWARE.COM> wrote:
>Perhaps I misunderstood what you said
<snip>
Perhaps. I think you are missing or misunderstanding my point.
>I never mentioned traps other than IgvNoUserKeyCSA. I agree that none of
>them are supported. But that's common knowledge. UAYOR!
Either is using IgvNoUserKeyCSA. That is my point! And although its
use is common knowledge to many of the IBM-MAINers, ISVs, and people who
have seen SHARE presentations, using it is not supported and never was.
The new support in z/OS 1.8 doesn't change that. It has always been
UAYOR. Just because there is new support in z/OS 1.8 doesn't mean I
can go to my mission critical z/OS 1.6 system and start using
IgvNoUserKeyCSA.
See Peter's post on this subject (darn, can no longer provide
archive URL since you have to sign in now).
Cheers,
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: mark....@zurichna.com
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Edward Jaffe
> Either is using IgvNoUserKeyCSA. That is my point! And although its
> use is common knowledge to many of the IBM-MAINers, ISVs, and people who
> have seen SHARE presentations, using it is not supported and never was.
>
You're just restating my last point! I said, "... none of them are
supported. But that's common knowledge. UAYOR!" The "common knowledge"
in this case is that _none_ of the DIAG traps are supported. And, in
case you don't know, UAYOR is net-speak for "Use At Your Own Risk". I
made no reference whatsoever to how ubiquitous or pervasive their usage
might be.
> The new support in z/OS 1.8 doesn't change that. It has always been
> UAYOR. Just because there is new support in z/OS 1.8 doesn't mean I
> can go to my mission critical z/OS 1.6 system and start using
> IgvNoUserKeyCSA.
>
And, by the same token, you should also definitely *not* go into a
mission critical z/OS 1.8 system and specify ALLOWUSERKEYCSA(NO). The
B78-5C abends you will encounter (if any) are the same either way. In
that future z/OS release (R9?) in which ALLOWUSERKEYCSA(NO) becomes the
default, your mission-critical systems will still encounter failures if
any IBM-, ISV-, or installation-written code tries to allocate user key
CSA. Exhaustive testing in less important environments is recommended.
If any failure is discovered, reverting back to ALLOWUSERKEYCSA(YES)
will be required.
In http://bama.ua.edu/cgi-bin/wa?A2=ind0301&L=ibm-main&D=0&I=1&P=275209
Chris Kendon said he used "Common Storage Monitor" in BMC's "Mainview
Sysprog Services" to search for key 8 CSA allocations. This product is
supported by BMC, not IBM. If you use this tool to locate key 8 CSA
allocations in IBM code, they will not be any less inclined to take the
APAR than if you use any other tool to discover the exposure, including
IEBEYEBALL against an IPCS VSMDATA or other similar report.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
Mark Zelden
On Thu, 29 Jun 2006 10:28:34 -0700, Edward Jaffe
<edj...@PHOENIXSOFTWARE.COM> wrote:
>Mark Zelden wrote:
>> Either is using IgvNoUserKeyCSA. That is my point! And although its
>> use is common knowledge to many of the IBM-MAINers, ISVs, and people who
>> have seen SHARE presentations, using it is not supported and never was.
>>
>
>You're just restating my last point! I said, "... none of them are
>supported.
Ed, that may have been what you meant, but it is not what you
wrote, and that is when I commented and this circular conversation
started. You wrote:
"IBM has supported this since OS/390 V2R6 via the undocumented..."
http://bama.ua.edu/cgi-bin/wa?A2=ind0606&L=ibm-main&D=1&O=D&P=219493
To which I responded:
http://bama.ua.edu/cgi-bin/wa?A2=ind0606&L=ibm-main&D=1&O=D&P=219894
And so on...
Semantics, poor choice of words, whatever. If you had said "IBM has
had an undocumented way of tracking this since..." with out using the
S word,I wouldn't have felt any need to comment.
Regards,
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: mark....@zurichna.com
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Edward Jaffe
> Semantics, poor choice of words, whatever.
Semantics indeed! Many words, including "support", have different
meanings in different contexts. For example, z/OS V1R2 _supports_
programs running in 64-bit addressing mode. But, as we all know, z/OS
V1R2 is an _unsupported_ operating system. My intended use of "support"
was in the former context, not the latter.
At least this gives us something to discuss over beers at SCIDS... :-)
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
Knutson, Sam
In the past I had recommended using the freeware MXI SP *-8 command to
review persistent allocations of Key 8 common storage. I still do! Get
it here http://www.rs.com/portfolio/mxi/download.php You do need to be
aware that in the currently available MXI free version there is a bug
and that some key 8 allocations may not be listed.
Rob is aware and this is a bug in MXI 4.3 only - there are certain
circumstances where MXI 4.3 does not correctly handle the VSMLIST return
area correctly - MXI G2 handles the situation just fine.
I understand he hopes to fix it in the next genlevel of free MXI 4.3.
Best Regards,
Sam Knutson, GEICO
Performance and Availability Management
mailto:sknu...@geico.com
(office) 301.986.3574
"Think big, act bold, start simple, grow fast..."
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
----------------------------------------------------------------------
Schiradin,Roland HG-Dir itb-db/dc
If you still believe this is an area I'll try to look at at it and provide
a solution for SHOWzOS.
Roland
Rob Scott
only fix the code in my spare time and I do not have much of that at the
moment!
My primary focus is MXI G2 and I am currently writing a CICS plug-in
(the DB2 plug-in goes GA very soon and the MQ plug-in is going into beta
test next month). As soon as I come up for air - I will try and provide
a fix for the SP issue in MXI 4.3.
The bug in SP only occurs when you drill down to list all of the entries
for a single subpool+key combination - MXI 4.3 has a logic problem when
catering for the multiple GQEs that can describe the storage in one
allocated block reported by VSMLIST. As Sam rightly says, this is a MXI
4.3 issue only - MXI G2 handles this situation correctly.
Rob Scott
Rocket Software, Inc
275 Grove Street
Newton, MA 02466
617-614-2305
rsc...@rs.com
http://www.rs.com/portfolio/mxi/
Roland
Hi,
Best Regards,
----------------------------------------------------------------------