Re: ICSF Troubles
Both systems are at 1.11. Thanks!! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David Sent: Wednesday, March 09, 2011 7:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ICSF Troubles Hal, What FMID is on the 1.9 system, and what FMID on the 1.11 system?And the other question, if different, is any require toleration support applied to the 1.9 system? _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hal Merritt Sent: Tuesday, March 08, 2011 5:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ICSF Troubles Thanks for the replies so far! Rob: Here are my parms: CKDSN(My.CKDS) PKDSN(My.PKDS) COMPAT(NO) SSM(YES) DOMAIN(2) KEYAUTH(NO) CHECKAUTH(NO) TRACEENTRY(1000) USERPARM(USERPARM) COMPENC(DES) REASONCODES(ICSF) PKDSCACHE(64) Allen: The LRECL of the PKDS does not seem to be an issue. It occurs (or works) with either. John: No VM. There is nothing to suggest a real hardware issue. We use GRS for sharing. The member in SAMPLIB was used to define the clusters. The share options are 2,3. This was working just fine untill we upgraded from z/os 1.9 to z/os 1.11. Again, thanks all!! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of zSeries Systems Programmer Sent: Thursday, March 03, 2011 10:35 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ICSF Troubles Just a few items How are you sharing? GRS? CA-MIM? Etc. Were the files defined with the correct share options? Was this working before or new configuration? On Thursday, March 3, 2011, Ward, Mike S wrote: > We have one PKDS and one CKDS for all lpars. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Hal Merritt > Sent: Thursday, March 03, 2011 11:36 AM > To: IBM-MAIN@bama.ua.edu > Subject: ICSF Troubles > > We are z/os 1.11. We almost never IPL. The last time we IPL'd, we > received the following: > > 11.47.55 STC00014 CSFM450E UNEXPECTED ERROR PROCESSING PKDS, RETURN > CODE = 000C, REASON CODE = 1780. > 11.47.55 STC00014 CSFM401I CRYPTOGRAPHY - SERVICES ARE NO LONGER > AVAILABLE. > 11.47.55 STC00014 IEF352I ADDRESS SPACE UNAVAILABLE > 11.47.55 STC00014 $HASP395 CSF ENDED > > We don't use PKI and have no current plans to do so. However, the CSF > is critical. With a little experimentation in the testplex, I am > currently of the opinion that it is some sort of file sharing issue. > > When I allocate a fresh PKDS, CSF on LparA comes up just fine. > However, CSF on LparB sometimes fails with the above message. The FM > seems to say that the PKDS is not completely initialized until the > first key is stowed. Not sure how to do that. > > I'm thinking a PMR. But a user error is usually more likely. Right now > my workaround is to point each LPAR to its own PKDS. Of course, I'm a > bit nervous as I don't want to accidently break CSF. That would be > equivalent to a full outage. > > What I'd really like to do is to completely shut off PKDS. I've tried > starting with no PKDS specified, but CSF refuses to start. > > Thoughts? > > > NOTICE: This electronic mail message and any files transmitted with it > are intended exclusively for the individual or entity to which it is > addressed. The message, together with any attachment, may contain > confidential and/or privileged information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution is strictly prohibited. If you have received this message > in error, please immediately advise the sender by reply email and > delete all copies. > > -- > 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 > > == > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to which they > are addressed. If you have received this email in error please notify > the system manager. This message contains confidential information and > is intended only for the individual named. If you are not the named > addressee
Re: ICSF Troubles
Hal - Is this issue described by APAR OA29163? Larre Shiller US Social Security Administration -- 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
Re: ICSF Troubles
Hal, What FMID is on the 1.9 system, and what FMID on the 1.11 system?And the other question, if different, is any require toleration support applied to the 1.9 system? _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hal Merritt Sent: Tuesday, March 08, 2011 5:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ICSF Troubles Thanks for the replies so far! Rob: Here are my parms: CKDSN(My.CKDS) PKDSN(My.PKDS) COMPAT(NO) SSM(YES) DOMAIN(2) KEYAUTH(NO) CHECKAUTH(NO) TRACEENTRY(1000) USERPARM(USERPARM) COMPENC(DES) REASONCODES(ICSF) PKDSCACHE(64) Allen: The LRECL of the PKDS does not seem to be an issue. It occurs (or works) with either. John: No VM. There is nothing to suggest a real hardware issue. We use GRS for sharing. The member in SAMPLIB was used to define the clusters. The share options are 2,3. This was working just fine untill we upgraded from z/os 1.9 to z/os 1.11. Again, thanks all!! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of zSeries Systems Programmer Sent: Thursday, March 03, 2011 10:35 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ICSF Troubles Just a few items How are you sharing? GRS? CA-MIM? Etc. Were the files defined with the correct share options? Was this working before or new configuration? On Thursday, March 3, 2011, Ward, Mike S wrote: > We have one PKDS and one CKDS for all lpars. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Hal Merritt > Sent: Thursday, March 03, 2011 11:36 AM > To: IBM-MAIN@bama.ua.edu > Subject: ICSF Troubles > > We are z/os 1.11. We almost never IPL. The last time we IPL'd, we > received the following: > > 11.47.55 STC00014 CSFM450E UNEXPECTED ERROR PROCESSING PKDS, RETURN > CODE = 000C, REASON CODE = 1780. > 11.47.55 STC00014 CSFM401I CRYPTOGRAPHY - SERVICES ARE NO LONGER > AVAILABLE. > 11.47.55 STC00014 IEF352I ADDRESS SPACE UNAVAILABLE > 11.47.55 STC00014 $HASP395 CSF ENDED > > We don't use PKI and have no current plans to do so. However, the CSF > is critical. With a little experimentation in the testplex, I am > currently of the opinion that it is some sort of file sharing issue. > > When I allocate a fresh PKDS, CSF on LparA comes up just fine. > However, CSF on LparB sometimes fails with the above message. The FM > seems to say that the PKDS is not completely initialized until the > first key is stowed. Not sure how to do that. > > I'm thinking a PMR. But a user error is usually more likely. Right now > my workaround is to point each LPAR to its own PKDS. Of course, I'm a > bit nervous as I don't want to accidently break CSF. That would be > equivalent to a full outage. > > What I'd really like to do is to completely shut off PKDS. I've tried > starting with no PKDS specified, but CSF refuses to start. > > Thoughts? > > > NOTICE: This electronic mail message and any files transmitted with it > are intended exclusively for the individual or entity to which it is > addressed. The message, together with any attachment, may contain > confidential and/or privileged information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution is strictly prohibited. If you have received this message > in error, please immediately advise the sender by reply email and > delete all copies. > > -- > 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 > > == > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to which they > are addressed. If you have received this email in error please notify > the system manager. This message contains confidential information and > is intended only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. If you are not the > intended recipient you are not
Re: ICSF Troubles
Hal, Ok. Let's look at a couple of things DISPLAY GRS,RES=(SYSZPKT.*) DISPLAY GRS,RES=(SYSDSN.*) <<= look for anyone using My.PKDS I can tell you that weird things start to happen if you have something accessing the PKDS that is not the ICSF task. The ENQ scheme does not take non-participants into account. The safe thing would be to code SYSPLEXPKDS(YES,FAIL(YES)) and let the system do the heavy lifting. You might try the PKDSLIST program to make sure that your PKDS is indeed empty. http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1903 How many PKDS data sets are in your sysplex now? Rob Schramm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hal Merritt Sent: Tuesday, March 08, 2011 5:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ICSF Troubles Thanks for the replies so far! Rob: Here are my parms: CKDSN(My.CKDS) PKDSN(My.PKDS) COMPAT(NO) SSM(YES) DOMAIN(2) KEYAUTH(NO) CHECKAUTH(NO) TRACEENTRY(1000) USERPARM(USERPARM) COMPENC(DES) REASONCODES(ICSF) PKDSCACHE(64) Allen: The LRECL of the PKDS does not seem to be an issue. It occurs (or works) with either. John: No VM. There is nothing to suggest a real hardware issue. We use GRS for sharing. The member in SAMPLIB was used to define the clusters. The share options are 2,3. This was working just fine untill we upgraded from z/os 1.9 to z/os 1.11. Again, thanks all!! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of zSeries Systems Programmer Sent: Thursday, March 03, 2011 10:35 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ICSF Troubles Just a few items How are you sharing? GRS? CA-MIM? Etc. Were the files defined with the correct share options? Was this working before or new configuration? On Thursday, March 3, 2011, Ward, Mike S wrote: > We have one PKDS and one CKDS for all lpars. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Hal Merritt > Sent: Thursday, March 03, 2011 11:36 AM > To: IBM-MAIN@bama.ua.edu > Subject: ICSF Troubles > > We are z/os 1.11. We almost never IPL. The last time we IPL'd, we > received the following: > > 11.47.55 STC00014 CSFM450E UNEXPECTED ERROR PROCESSING PKDS, RETURN > CODE = 000C, REASON CODE = 1780. > 11.47.55 STC00014 CSFM401I CRYPTOGRAPHY - SERVICES ARE NO LONGER > AVAILABLE. > 11.47.55 STC00014 IEF352I ADDRESS SPACE UNAVAILABLE > 11.47.55 STC00014 $HASP395 CSF ENDED > > We don't use PKI and have no current plans to do so. However, the CSF > is critical. With a little experimentation in the testplex, I am > currently of the opinion that it is some sort of file sharing issue. > > When I allocate a fresh PKDS, CSF on LparA comes up just fine. > However, CSF on LparB sometimes fails with the above message. The FM > seems to say that the PKDS is not completely initialized until the > first key is stowed. Not sure how to do that. > > I'm thinking a PMR. But a user error is usually more likely. Right now > my workaround is to point each LPAR to its own PKDS. Of course, I'm a > bit nervous as I don't want to accidently break CSF. That would be > equivalent to a full outage. > > What I'd really like to do is to completely shut off PKDS. I've tried > starting with no PKDS specified, but CSF refuses to start. > > Thoughts? > > > NOTICE: This electronic mail message and any files transmitted with it > are intended exclusively for the individual or entity to which it is > addressed. The message, together with any attachment, may contain > confidential and/or privileged information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution is strictly prohibited. If you have received this message > in error, please immediately advise the sender by reply email and > delete all copies. > > -- > 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 > > == > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to which they > are addressed. If you have received this email in error please notify > the system manager. This message contains confidential information and > is intended only for the individual named. If you are not the named > addressee you should no
Re: ICSF Troubles
Hal - I'm a little late to this party, but I saw your post and I remembered that we had some changes to make when we converted to zOS 1.11 (seems like so long ago..). Based on my notes, it looks like we had to remove the COMPENC and PKDSCACHE parameters--I think they are no longer supported. Larre Shiller US Social Security Administration -- 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
Re: ICSF Troubles
Thanks for the replies so far! Rob: Here are my parms: CKDSN(My.CKDS) PKDSN(My.PKDS) COMPAT(NO) SSM(YES) DOMAIN(2) KEYAUTH(NO) CHECKAUTH(NO) TRACEENTRY(1000) USERPARM(USERPARM) COMPENC(DES) REASONCODES(ICSF) PKDSCACHE(64) Allen: The LRECL of the PKDS does not seem to be an issue. It occurs (or works) with either. John: No VM. There is nothing to suggest a real hardware issue. We use GRS for sharing. The member in SAMPLIB was used to define the clusters. The share options are 2,3. This was working just fine untill we upgraded from z/os 1.9 to z/os 1.11. Again, thanks all!! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of zSeries Systems Programmer Sent: Thursday, March 03, 2011 10:35 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ICSF Troubles Just a few items How are you sharing? GRS? CA-MIM? Etc. Were the files defined with the correct share options? Was this working before or new configuration? On Thursday, March 3, 2011, Ward, Mike S wrote: > We have one PKDS and one CKDS for all lpars. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Hal Merritt > Sent: Thursday, March 03, 2011 11:36 AM > To: IBM-MAIN@bama.ua.edu > Subject: ICSF Troubles > > We are z/os 1.11. We almost never IPL. The last time we IPL'd, we > received the following: > > 11.47.55 STC00014 CSFM450E UNEXPECTED ERROR PROCESSING PKDS, RETURN > CODE = 000C, REASON CODE = 1780. > 11.47.55 STC00014 CSFM401I CRYPTOGRAPHY - SERVICES ARE NO LONGER > AVAILABLE. > 11.47.55 STC00014 IEF352I ADDRESS SPACE UNAVAILABLE > 11.47.55 STC00014 $HASP395 CSF ENDED > > We don't use PKI and have no current plans to do so. However, the CSF > is critical. With a little experimentation in the testplex, I am > currently of the opinion that it is some sort of file sharing issue. > > When I allocate a fresh PKDS, CSF on LparA comes up just fine. > However, CSF on LparB sometimes fails with the above message. The FM > seems to say that the PKDS is not completely initialized until the > first key is stowed. Not sure how to do that. > > I'm thinking a PMR. But a user error is usually more likely. Right now > my workaround is to point each LPAR to its own PKDS. Of course, I'm a > bit nervous as I don't want to accidently break CSF. That would be > equivalent to a full outage. > > What I'd really like to do is to completely shut off PKDS. I've tried > starting with no PKDS specified, but CSF refuses to start. > > Thoughts? > > > NOTICE: This electronic mail message and any files transmitted with it > are intended exclusively for the individual or entity to which it is > addressed. The message, together with any attachment, may contain > confidential and/or privileged information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution is strictly prohibited. If you have received this message > in error, please immediately advise the sender by reply email and > delete all copies. > > -- > 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 > > == > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to which they > are addressed. If you have received this email in error please notify > the system manager. This message contains confidential information and > is intended only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. If you are not the > intended recipient you are notified that disclosing, copying, distributing or > taking any action in reliance on the contents of this information is strictly > prohibited. > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bam
Re: ICSF Troubles
Just a few items How are you sharing? GRS? CA-MIM? Etc. Were the files defined with the correct share options? Was this working before or new configuration? On Thursday, March 3, 2011, Ward, Mike S wrote: > We have one PKDS and one CKDS for all lpars. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Hal Merritt > Sent: Thursday, March 03, 2011 11:36 AM > To: IBM-MAIN@bama.ua.edu > Subject: ICSF Troubles > > We are z/os 1.11. We almost never IPL. The last time we IPL'd, we > received the following: > > 11.47.55 STC00014 CSFM450E UNEXPECTED ERROR PROCESSING PKDS, RETURN > CODE = 000C, REASON CODE = 1780. > 11.47.55 STC00014 CSFM401I CRYPTOGRAPHY - SERVICES ARE NO LONGER > AVAILABLE. > 11.47.55 STC00014 IEF352I ADDRESS SPACE UNAVAILABLE > 11.47.55 STC00014 $HASP395 CSF ENDED > > We don't use PKI and have no current plans to do so. However, the CSF is > critical. With a little experimentation in the testplex, I am currently > of the opinion that it is some sort of file sharing issue. > > When I allocate a fresh PKDS, CSF on LparA comes up just fine. However, > CSF on LparB sometimes fails with the above message. The FM seems to say > that the PKDS is not completely initialized until the first key is > stowed. Not sure how to do that. > > I'm thinking a PMR. But a user error is usually more likely. Right now > my workaround is to point each LPAR to its own PKDS. Of course, I'm a > bit nervous as I don't want to accidently break CSF. That would be > equivalent to a full outage. > > What I'd really like to do is to completely shut off PKDS. I've tried > starting with no PKDS specified, but CSF refuses to start. > > Thoughts? > > > NOTICE: This electronic mail message and any files transmitted with it > are intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or privileged > information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, > please > immediately advise the sender by reply email and delete all copies. > > -- > 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 > > == > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity > to which they are addressed. If you have received this email in error please > notify the system manager. This message > contains confidential information and is intended only for the individual > named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please notify the > sender immediately by e-mail if you > have received this e-mail by mistake and delete this e-mail from your system. > If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any action > in reliance on the contents of this > information is strictly prohibited. > > -- > 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 > -- 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
Re: ICSF Troubles
We have one PKDS and one CKDS for all lpars. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hal Merritt Sent: Thursday, March 03, 2011 11:36 AM To: IBM-MAIN@bama.ua.edu Subject: ICSF Troubles We are z/os 1.11. We almost never IPL. The last time we IPL'd, we received the following: 11.47.55 STC00014 CSFM450E UNEXPECTED ERROR PROCESSING PKDS, RETURN CODE = 000C, REASON CODE = 1780. 11.47.55 STC00014 CSFM401I CRYPTOGRAPHY - SERVICES ARE NO LONGER AVAILABLE. 11.47.55 STC00014 IEF352I ADDRESS SPACE UNAVAILABLE 11.47.55 STC00014 $HASP395 CSF ENDED We don't use PKI and have no current plans to do so. However, the CSF is critical. With a little experimentation in the testplex, I am currently of the opinion that it is some sort of file sharing issue. When I allocate a fresh PKDS, CSF on LparA comes up just fine. However, CSF on LparB sometimes fails with the above message. The FM seems to say that the PKDS is not completely initialized until the first key is stowed. Not sure how to do that. I'm thinking a PMR. But a user error is usually more likely. Right now my workaround is to point each LPAR to its own PKDS. Of course, I'm a bit nervous as I don't want to accidently break CSF. That would be equivalent to a full outage. What I'd really like to do is to completely shut off PKDS. I've tried starting with no PKDS specified, but CSF refuses to start. Thoughts? NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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
Re: ICSF Troubles
1) Check SYS1.PARMLIB(CSFPRM*). It may be pointing to the wrong place. 2) Check the LRECL of the PKDS. 1.11 changed the LRECL of the PKDS. See http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/E0Z2M17A/8.2. 6?DT=20090616151803 HTH. We are z/os 1.11. We almost never IPL. The last time we IPL'd, we received the following: 11.47.55 STC00014 CSFM450E UNEXPECTED ERROR PROCESSING PKDS, RETURN CODE = 000C, REASON CODE = 1780. 11.47.55 STC00014 CSFM401I CRYPTOGRAPHY - SERVICES ARE NO LONGER AVAILABLE. 11.47.55 STC00014 IEF352I ADDRESS SPACE UNAVAILABLE 11.47.55 STC00014 $HASP395 CSF ENDED We don't use PKI and have no current plans to do so. However, the CSF is critical. With a little experimentation in the testplex, I am currently of the opinion that it is some sort of file sharing issue. When I allocate a fresh PKDS, CSF on LparA comes up just fine. However, CSF on LparB sometimes fails with the above message. The FM seems to say that the PKDS is not completely initialized until the first key is stowed. Not sure how to do that. I'm thinking a PMR. But a user error is usually more likely. Right now my workaround is to point each LPAR to its own PKDS. Of course, I'm a bit nervous as I don't want to accidently break CSF. That would be equivalent to a full outage. What I'd really like to do is to completely shut off PKDS. I've tried starting with no PKDS specified, but CSF refuses to start. -- 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
Re: ICSF Troubles
Hal, The reason code of 1780 indicates that a DASD I/O error occurred when accessing the dataset. Have you checked EREP for any diagnostic information? Also, are you running under z/VM? John P. Baker Chief Software Architect HFD Technologies -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hal Merritt Sent: Thursday, March 03, 2011 12:36 PM To: IBM-MAIN@bama.ua.edu Subject: ICSF Troubles We are z/os 1.11. We almost never IPL. The last time we IPL'd, we received the following: 11.47.55 STC00014 CSFM450E UNEXPECTED ERROR PROCESSING PKDS, RETURN CODE = 000C, REASON CODE = 1780. 11.47.55 STC00014 CSFM401I CRYPTOGRAPHY - SERVICES ARE NO LONGER AVAILABLE. 11.47.55 STC00014 IEF352I ADDRESS SPACE UNAVAILABLE 11.47.55 STC00014 $HASP395 CSF ENDED We don't use PKI and have no current plans to do so. However, the CSF is critical. With a little experimentation in the testplex, I am currently of the opinion that it is some sort of file sharing issue. When I allocate a fresh PKDS, CSF on LparA comes up just fine. However, CSF on LparB sometimes fails with the above message. The FM seems to say that the PKDS is not completely initialized until the first key is stowed. Not sure how to do that. I'm thinking a PMR. But a user error is usually more likely. Right now my workaround is to point each LPAR to its own PKDS. Of course, I'm a bit nervous as I don't want to accidently break CSF. That would be equivalent to a full outage. What I'd really like to do is to completely shut off PKDS. I've tried starting with no PKDS specified, but CSF refuses to start. Thoughts? NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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 -- 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
Re: ICSF Troubles
Hal, Care to post your csfparm (minus the ckds data set name plz) ... or look for any SYSPLEX keywords and post them? Thanks, Rob Schramm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hal Merritt Sent: Thursday, March 03, 2011 12:36 PM To: IBM-MAIN@bama.ua.edu Subject: ICSF Troubles We are z/os 1.11. We almost never IPL. The last time we IPL'd, we received the following: 11.47.55 STC00014 CSFM450E UNEXPECTED ERROR PROCESSING PKDS, RETURN CODE = 000C, REASON CODE = 1780. 11.47.55 STC00014 CSFM401I CRYPTOGRAPHY - SERVICES ARE NO LONGER AVAILABLE. 11.47.55 STC00014 IEF352I ADDRESS SPACE UNAVAILABLE 11.47.55 STC00014 $HASP395 CSF ENDED We don't use PKI and have no current plans to do so. However, the CSF is critical. With a little experimentation in the testplex, I am currently of the opinion that it is some sort of file sharing issue. When I allocate a fresh PKDS, CSF on LparA comes up just fine. However, CSF on LparB sometimes fails with the above message. The FM seems to say that the PKDS is not completely initialized until the first key is stowed. Not sure how to do that. I'm thinking a PMR. But a user error is usually more likely. Right now my workaround is to point each LPAR to its own PKDS. Of course, I'm a bit nervous as I don't want to accidently break CSF. That would be equivalent to a full outage. What I'd really like to do is to completely shut off PKDS. I've tried starting with no PKDS specified, but CSF refuses to start. Thoughts? NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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 -- 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
ICSF Troubles
We are z/os 1.11. We almost never IPL. The last time we IPL'd, we received the following: 11.47.55 STC00014 CSFM450E UNEXPECTED ERROR PROCESSING PKDS, RETURN CODE = 000C, REASON CODE = 1780. 11.47.55 STC00014 CSFM401I CRYPTOGRAPHY - SERVICES ARE NO LONGER AVAILABLE. 11.47.55 STC00014 IEF352I ADDRESS SPACE UNAVAILABLE 11.47.55 STC00014 $HASP395 CSF ENDED We don't use PKI and have no current plans to do so. However, the CSF is critical. With a little experimentation in the testplex, I am currently of the opinion that it is some sort of file sharing issue. When I allocate a fresh PKDS, CSF on LparA comes up just fine. However, CSF on LparB sometimes fails with the above message. The FM seems to say that the PKDS is not completely initialized until the first key is stowed. Not sure how to do that. I'm thinking a PMR. But a user error is usually more likely. Right now my workaround is to point each LPAR to its own PKDS. Of course, I'm a bit nervous as I don't want to accidently break CSF. That would be equivalent to a full outage. What I'd really like to do is to completely shut off PKDS. I've tried starting with no PKDS specified, but CSF refuses to start. Thoughts? NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
