RSU APPLY ISSUE
Hello, We are installing RSU on z/OS 1.13 system and in apply check process we encountered below issue. GIM38201E ** THERE IS A MODID ERROR FOR SRC ENTRY ASMADOPT IN SYSMOD UK81531. GIM31901ISYSMOD UK81531 DOES NOT SPECIFY SP1BAB0 ON THE PRE OR SUP OPERAND. SP1BAB0 IS THE RMID FOR SRC ASMADOPT THAT IS CURRENTLY INSTALLED. GIM22601IAPPLY PROCESSING FAILED FOR SYSMOD UK81531. SP1BAB0 is the user MOD we applied before. Can you please suggest. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE
RESTORE the usermod APPLY the PTF Correct the usermod with PRE(UK81531) and any other logical changes REEIVE the updated usermod Apply the usermod Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Tuesday, 21 July 2015 8:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RSU APPLY ISSUE Hello, We are installing RSU on z/OS 1.13 system and in apply check process we encountered below issue. GIM38201E ** THERE IS A MODID ERROR FOR SRC ENTRY ASMADOPT IN SYSMOD UK81531. GIM31901ISYSMOD UK81531 DOES NOT SPECIFY SP1BAB0 ON THE PRE OR SUP OPERAND. SP1BAB0 IS THE RMID FOR SRC ASMADOPT THAT IS CURRENTLY INSTALLED. GIM22601IAPPLY PROCESSING FAILED FOR SYSMOD UK81531. SP1BAB0 is the user MOD we applied before. Can you please suggest. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I think I found the root cause of this issue. During z/OS 2.1 installtion SYS1.SCEELKED was overwritten by SYS1.SEDCBASE on RES001 because the DDDEF entry references it - REP DDDEF(*SEDCBASE*) DA(Z21.SYS1.*SCEELKED*) SHR . When I compared with my old z/OS 1.13 system Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES1301 Number of members . : *10,640* Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES001 Number of members . : *11,017* Data Set Name . . . : SYS1.SEDCBASE Volume serial . . . : RES1301 Number of members . : *751* Data Set Name . . . : SYS1.SEDCBASE Volume serial . . . : RES001 Number of members . : *0* *So, my SYS1.*SEDCBASE is empty and SYS1.SCEELKED is with unwanted data. Now, the question is, how can I correct this mistake rather then installing z/OS 2.1 from scratch. By mistake these two libraries are messed up now. FMID HCLB201 belong to C/370 LIBRARY, which we recently installed. To isolate this issue, I am planning to restore C/370 with having DDDEF( *SEDCBASE*) pointed to SYS1.*SCEELKED*(ZS21T1). This should remove all data populated during last apply and should clean SYS1. *SCEELKED. *But the issue is,If we restore SCEELKED from initial tape then it will reach to initial state and we applied many other FMID and installed CICS after that. So, all will be affected. I am working out to find to alternate solution . On Sun, Sep 7, 2014 at 4:47 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 031c0cdc-b61c-42f2-a377-97478031b...@comcast.net, on 09/05/2014 at 02:45 PM, Ed Gould edgould1...@comcast.net said: I guess we will have to disagree on what holds can be bypassed. What he wrote was You should never (unless told by IBM who probably never will) BYPASS error holds. Dropping the word error changes its meaning drastically. In summary I think its OK to bypass *SOME* hold errors What do you mean by hold errors? The OP is referring to error holds, and you have not given a case where it is advisable to bypass an error hold. That has nothing to do with bypassing, e.g., DOC. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On my 1.13 system that is how mine is, not sure that is your problem. DDDEF ENTRY SEDCBASE - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. DDDEF ENTRY SCEELKED - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 5:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I think I found the root cause of this issue. During z/OS 2.1 installtion SYS1.SCEELKED was overwritten by SYS1.SEDCBASE on RES001 because the DDDEF entry references it - REP DDDEF(*SEDCBASE*) DA(Z21.SYS1.*SCEELKED*) SHR . When I compared with my old z/OS 1.13 system Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES1301 Number of members . : *10,640* Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES001 Number of members . : *11,017* Data Set Name . . . : SYS1.SEDCBASE Volume serial . . . : RES1301 Number of members . : *751* Data Set Name . . . : SYS1.SEDCBASE Volume serial . . . : RES001 Number of members . : *0* *So, my SYS1.*SEDCBASE is empty and SYS1.SCEELKED is with unwanted data. Now, the question is, how can I correct this mistake rather then installing z/OS 2.1 from scratch. By mistake these two
Re: RSU APPLY ISSUE GIM23911E
I would not even try to repair the situation. Bite the bullet and re-install. snip I think I found the root cause of this issue. During z/OS 2.1 installtion SYS1.SCEELKED was overwritten by SYS1.SEDCBASE on RES001 because the DDDEF entry references it - REP DDDEF(*SEDCBASE*) DA(Z21.SYS1.*SCEELKED*) SHR . ***snippage *So, my SYS1.*SEDCBASE is empty and SYS1.SCEELKED is with unwanted data. Now, the question is, how can I correct this mistake rather then installing z/OS 2.1 from scratch. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Hello David, How can SEDBASE DDDEF can point to SCEELKED library. It should point to SYS1.SCEELKED target library. But still not sure. On Tue, Sep 9, 2014 at 7:42 PM, Jousma, David david.jou...@53.com wrote: On my 1.13 system that is how mine is, not sure that is your problem. DDDEF ENTRY SEDCBASE - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. DDDEF ENTRY SCEELKED - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 5:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I think I found the root cause of this issue. During z/OS 2.1 installtion SYS1.SCEELKED was overwritten by SYS1.SEDCBASE on RES001 because the DDDEF entry references it - REP DDDEF(*SEDCBASE*) DA(Z21.SYS1.*SCEELKED*) SHR . When I compared with my old z/OS 1.13 system Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES1301 Number of members . : *10,640* Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES001 Number of members . : *11,017* Data Set Name . . . : SYS1.SEDCBASE Volume serial . . . : RES1301 Number of members . : *751* Data Set Name . . . : SYS1.SEDCBASE Volume serial . . . : RES001 Number of members . : *0* *So, my SYS1.*SEDCBASE is empty and SYS1.SCEELKED is with unwanted data. Now, the question is, how can I correct this mistake rather then installing z/OS 2.1 from scratch. By mistake these two libraries are messed up now. FMID HCLB201 belong to C/370 LIBRARY, which we recently installed. To isolate this issue, I am planning to restore C/370 with having DDDEF( *SEDCBASE*) pointed to SYS1.*SCEELKED*(ZS21T1). This should remove all data populated during last apply and should clean SYS1. *SCEELKED. *But the issue is,If we restore SCEELKED from initial tape then it will reach to initial state and we applied many other FMID and installed CICS after that. So, all will be affected. I am working out to find to alternate solution . On Sun, Sep 7, 2014 at 4:47 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 031c0cdc-b61c-42f2-a377-97478031b...@comcast.net, on 09/05/2014 at 02:45 PM, Ed Gould edgould1...@comcast.net said: I guess we will have to disagree on what holds can be bypassed. What he wrote was You should never (unless told by IBM who probably never will) BYPASS error holds. Dropping the word error changes its meaning drastically. In summary I think its OK to bypass *SOME* hold errors What do you mean by hold errors? The OP is referring to error holds, and you have not given a case where
Re: RSU APPLY ISSUE GIM23911E
It came from Serverpac that way. I did not modify it. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 10:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Hello David, How can SEDBASE DDDEF can point to SCEELKED library. It should point to SYS1.SCEELKED target library. But still not sure. On Tue, Sep 9, 2014 at 7:42 PM, Jousma, David david.jou...@53.com wrote: On my 1.13 system that is how mine is, not sure that is your problem. DDDEF ENTRY SEDCBASE - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. DDDEF ENTRY SCEELKED - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 5:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I think I found the root cause of this issue. During z/OS 2.1 installtion SYS1.SCEELKED was overwritten by SYS1.SEDCBASE on RES001 because the DDDEF entry references it - REP DDDEF(*SEDCBASE*) DA(Z21.SYS1.*SCEELKED*) SHR . When I compared with my old z/OS 1.13 system Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES1301 Number of members . : *10,640* Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES001 Number of members . : *11,017* Data Set Name . . . : SYS1.SEDCBASE Volume serial . . . : RES1301 Number of members . : *751* Data Set Name . . . : SYS1.SEDCBASE Volume serial . . . : RES001 Number of members . : *0* *So, my SYS1.*SEDCBASE is empty and SYS1.SCEELKED is with unwanted data. Now, the question is, how can I correct this mistake rather then installing z/OS 2.1 from scratch. By mistake these two libraries are messed up now. FMID HCLB201 belong to C/370 LIBRARY, which we recently installed. To isolate this issue, I am planning to restore C/370 with having DDDEF( *SEDCBASE*) pointed to SYS1.*SCEELKED*(ZS21T1). This should remove all data populated during last apply and should clean SYS1. *SCEELKED. *But the issue is,If we restore SCEELKED from initial tape then it will reach to initial state and we applied many other FMID and installed CICS after that. So, all will be affected. I am working out to find to alternate solution . On Sun, Sep 7, 2014 at 4:47 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net
Re: RSU APPLY ISSUE GIM23911E
Here is the output from the Serverpac installation job that updates the DDDEFS ¢¢¢ BROWSESMPE.OS210254.SCPPOENU(JOB24465) Command === REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RSM02A) UNIT(3390) WAITFORDSN SHR . GIM56501ITHE UNIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT EXIST. GIM56501ITHE WAIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 10:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Hello David, How can SEDBASE DDDEF can point to SCEELKED library. It should point to SYS1.SCEELKED target library. But still not sure. On Tue, Sep 9, 2014 at 7:42 PM, Jousma, David david.jou...@53.com wrote: On my 1.13 system that is how mine is, not sure that is your problem. DDDEF ENTRY SEDCBASE - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. DDDEF ENTRY SCEELKED - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 5:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I think I found the root cause of this issue. During z/OS 2.1 installtion SYS1.SCEELKED was overwritten by SYS1.SEDCBASE on RES001 because the DDDEF entry references it - REP DDDEF(*SEDCBASE*) DA(Z21.SYS1.*SCEELKED*) SHR . When I compared with my old z/OS 1.13 system Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES1301 Number of members . : *10,640* Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES001
Re: RSU APPLY ISSUE GIM23911E
Does it mean that your SYS1.SEDBASE or CEE.SEDBASE target dataset is empty. This dataset gets defined when you install C/370 library. Can you please check once. On Tue, Sep 9, 2014 at 7:56 PM, Jousma, David david.jou...@53.com wrote: Here is the output from the Serverpac installation job that updates the DDDEFS ¢¢¢ BROWSESMPE.OS210254.SCPPOENU(JOB24465) Command === REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RSM02A) UNIT(3390) WAITFORDSN SHR . GIM56501ITHE UNIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT EXIST. GIM56501ITHE WAIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 10:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Hello David, How can SEDBASE DDDEF can point to SCEELKED library. It should point to SYS1.SCEELKED target library. But still not sure. On Tue, Sep 9, 2014 at 7:42 PM, Jousma, David david.jou...@53.com wrote: On my 1.13 system that is how mine is, not sure that is your problem. DDDEF ENTRY SEDCBASE - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. DDDEF ENTRY SCEELKED - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 5:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I think I found the root cause of this issue. During z/OS 2.1 installtion SYS1.SCEELKED was overwritten by SYS1.SEDCBASE on RES001 because the DDDEF entry references it - REP DDDEF(*SEDCBASE*) DA(Z21.SYS1.*SCEELKED*) SHR . When I compared with my old z/OS 1.13 system Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES1301 Number of members . : *10,640* Data Set Name . . . : SYS1.SCEELKED Volume serial . . . : RES001 Number of members . : *11,017* Data Set Name . . . : SYS1.SEDCBASE Volume serial . . . : RES1301 Number of members . : *751* Data Set Name . . . : SYS1.SEDCBASE Volume serial . . . : RES001 Number of members . : *0* *So
Re: RSU APPLY ISSUE GIM23911E
I also noticed one more thing is I could find backup earlier backup of my RES volume, which I took before applying HCLB201 and this looks to be good. I run Job AMBLIST I Basically restored SYS1.SCEELKED from from backup and placed in different HQL dataset to cross verify the issue. Now Bit 15 show REFR in older backup. PUT=XREF 00060001 M O D U L E S U M M A R Y * MAIN ENTRY POINT: AMODE OF MAIN ENTRY POINT: 31 AMODE 31 31 --- IBUTES OF MODULE BIT STATUS BIT STATUS BIT STATUS ** 1 REUS 2 NOT-OVLY 3 NOT-TEST 5 BLOCK6 EXEC 7 1-TXT 9 ZERO-ORG 10 EP-ZERO 11 NO-RLD 13 NO-SYMS 14 F-LEVEL *15 REFR* But After this FMID HCLB201 applied, all backups have same issue.This is making me to think more that why its all happening . and both have same issue as earlier. On Tue, Sep 9, 2014 at 8:07 PM, Mainframe Mainframe mainframe1...@gmail.com wrote: Does it mean that your SYS1.SEDBASE or CEE.SEDBASE target dataset is empty. This dataset gets defined when you install C/370 library. Can you please check once. On Tue, Sep 9, 2014 at 7:56 PM, Jousma, David david.jou...@53.com wrote: Here is the output from the Serverpac installation job that updates the DDDEFS ¢¢¢ BROWSESMPE.OS210254.SCPPOENU(JOB24465) Command === REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RSM02A) UNIT(3390) WAITFORDSN SHR . GIM56501ITHE UNIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT EXIST. GIM56501ITHE WAIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 10:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Hello David, How can SEDBASE DDDEF can point to SCEELKED library. It should point to SYS1.SCEELKED target library. But still not sure. On Tue, Sep 9, 2014 at 7:42 PM, Jousma, David david.jou...@53.com wrote: On my 1.13 system that is how mine is, not sure that is your problem. DDDEF ENTRY SEDCBASE - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. DDDEF ENTRY SCEELKED - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save
Re: RSU APPLY ISSUE GIM23911E
Isn't the C library and compiler shipped and installed with all serverpacs? It just isn't activated until you do so in IFAPRDxx? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 9:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Does it mean that your SYS1.SEDBASE or CEE.SEDBASE target dataset is empty. This dataset gets defined when you install C/370 library. Can you please check once. On Tue, Sep 9, 2014 at 7:56 PM, Jousma, David david.jou...@53.com wrote: Here is the output from the Serverpac installation job that updates the DDDEFS ¢¢¢ BROWSESMPE.OS210254.SCPPOENU(JOB24465) Command === REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RSM02A) UNIT(3390) WAITFORDSN SHR . GIM56501ITHE UNIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT EXIST. GIM56501ITHE WAIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 10:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Hello David, How can SEDBASE DDDEF can point to SCEELKED library. It should point to SYS1.SCEELKED target library. But still not sure. On Tue, Sep 9, 2014 at 7:42 PM, Jousma, David david.jou...@53.com wrote: On my 1.13 system that is how mine is, not sure that is your problem. DDDEF ENTRY SEDCBASE - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. DDDEF ENTRY SCEELKED - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 5:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I think I found the root cause of this issue. During z/OS 2.1 installtion SYS1.SCEELKED was overwritten by SYS1.SEDCBASE on RES001 because the DDDEF entry references it - REP DDDEF(*SEDCBASE*) DA(Z21.SYS1.*SCEELKED*) SHR . When I compared with my old z/OS 1.13 system Data Set Name . . . : SYS1.SCEELKED
Re: RSU APPLY ISSUE GIM23911E
There is no SEDCBASE file on my system. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Does it mean that your SYS1.SEDBASE or CEE.SEDBASE target dataset is empty. This dataset gets defined when you install C/370 library. Can you please check once. On Tue, Sep 9, 2014 at 7:56 PM, Jousma, David david.jou...@53.com wrote: Here is the output from the Serverpac installation job that updates the DDDEFS ¢¢¢ BROWSESMPE.OS210254.SCPPOENU(JOB24465) Command === REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RSM02A) UNIT(3390) WAITFORDSN SHR . GIM56501ITHE UNIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT EXIST. GIM56501ITHE WAIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 10:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Hello David, How can SEDBASE DDDEF can point to SCEELKED library. It should point to SYS1.SCEELKED target library. But still not sure. On Tue, Sep 9, 2014 at 7:42 PM, Jousma, David david.jou...@53.com wrote: On my 1.13 system that is how mine is, not sure that is your problem. DDDEF ENTRY SEDCBASE - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. DDDEF ENTRY SCEELKED - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 5:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I think I found the root cause of this issue. During z/OS 2.1 installtion SYS1.SCEELKED was overwritten by SYS1.SEDCBASE on RES001 because the DDDEF entry references it - REP DDDEF(*SEDCBASE
Re: RSU APPLY ISSUE GIM23911E
THanks .But my initial serverpac came without C/370 product and we installed like below REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RES001) UNIT(3390) WAITFORDSN SHR . But later when I received CBPDO from from IBM for C/370, it allocated SEDBASE dataset but as DDDEF was pointing to SCEELKED, so data related to this FMID went to SCEELKED and SEDBASE is empty for me . On Tue, Sep 9, 2014 at 8:15 PM, Jousma, David david.jou...@53.com wrote: There is no SEDCBASE file on my system. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Does it mean that your SYS1.SEDBASE or CEE.SEDBASE target dataset is empty. This dataset gets defined when you install C/370 library. Can you please check once. On Tue, Sep 9, 2014 at 7:56 PM, Jousma, David david.jou...@53.com wrote: Here is the output from the Serverpac installation job that updates the DDDEFS ¢¢¢ BROWSESMPE.OS210254.SCPPOENU(JOB24465) Command === REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RSM02A) UNIT(3390) WAITFORDSN SHR . GIM56501ITHE UNIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT EXIST. GIM56501ITHE WAIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 10:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Hello David, How can SEDBASE DDDEF can point to SCEELKED library. It should point to SYS1.SCEELKED target library. But still not sure. On Tue, Sep 9, 2014 at 7:42 PM, Jousma, David david.jou...@53.com wrote: On my 1.13 system that is how mine is, not sure that is your problem. DDDEF ENTRY SEDCBASE - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. DDDEF ENTRY SCEELKED - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. _ Dave Jousma Assistant Vice
Re: RSU APPLY ISSUE GIM23911E
HCLB201 appears to be C/370 version 2.2 from 1999. Is there a specific reason you're installing what appears to be a very old C? If you need this old version of C for some reason, you may need to build a completely separate SMP/E environment to install it. I think your problem may be that you are installing an old C on top of the one that IBM ships with z/OS as part of the ServerPac. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I also noticed one more thing is I could find backup earlier backup of my RES volume, which I took before applying HCLB201 and this looks to be good. I run Job AMBLIST I Basically restored SYS1.SCEELKED from from backup and placed in different HQL dataset to cross verify the issue. Now Bit 15 show REFR in older backup. PUT=XREF 00060001 M O D U L E S U M M A R Y * MAIN ENTRY POINT: AMODE OF MAIN ENTRY POINT: 31 AMODE 31 31 --- IBUTES OF MODULE BIT STATUS BIT STATUS BIT STATUS ** 1 REUS 2 NOT-OVLY 3 NOT-TEST 5 BLOCK6 EXEC 7 1-TXT 9 ZERO-ORG 10 EP-ZERO 11 NO-RLD 13 NO-SYMS 14 F-LEVEL *15 REFR* But After this FMID HCLB201 applied, all backups have same issue.This is making me to think more that why its all happening . and both have same issue as earlier. On Tue, Sep 9, 2014 at 8:07 PM, Mainframe Mainframe mainframe1...@gmail.com wrote: Does it mean that your SYS1.SEDBASE or CEE.SEDBASE target dataset is empty. This dataset gets defined when you install C/370 library. Can you please check once. On Tue, Sep 9, 2014 at 7:56 PM, Jousma, David david.jou...@53.com wrote: Here is the output from the Serverpac installation job that updates the DDDEFS ¢¢¢ BROWSESMPE.OS210254.SCPPOENU(JOB24465) Command === REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RSM02A) UNIT(3390) WAITFORDSN SHR . GIM56501ITHE UNIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT EXIST. GIM56501ITHE WAIT SUBENTRY WAS ADDED INSTEAD OF REPLACED BECAUSE IT DID NOT _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 10:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Hello David, How can SEDBASE DDDEF can point to SCEELKED library. It should point to SYS1.SCEELKED target library. But still not sure. On Tue, Sep 9, 2014 at 7:42 PM, Jousma, David david.jou...@53.com wrote: On my 1.13 system that is how mine is, not sure that is your problem. DDDEF ENTRY SEDCBASE - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW) FINAL DISP === (KEEP,DELETE,CATALOG) UNIT === 3390 (unit type if not cataloged) VOLUME === RSM02A(volume serial) SPACE UNITS=== (TRK, CYL, or block length) PRIMARY=== (primary space) SECONDARY === (secondary space) DIR=== (Number of directory blocks) SYSOUT === (SYSOUT class) WAITFORDSN === YES (YES or NO) PROTECT=== NO(YES or NO) SMS OPTIONS=== NO(YES or NO to edit SMS Options) Press ENTER to save the changes. DDDEF ENTRY SCEELKED - LIBRARY TYPE === Enter Library DDDEF data to allocate DD statements for data sets to be dynamically allocated during SMP/E processing. Values must conform to JCL conventions. However, no parenthesis can be entered. DATA SET NAME === 'CEE.SCEELKED' (data set name, maximum 44 characters) INITIAL DISP === SHR (OLD,SHR,MOD,NEW
Re: RSU APPLY ISSUE GIM23911E
I don't know if this helps, but APAR OW36048 contains the following information: If you found incorrect data set names for any DDDEFs in your primary target zone and have already installed maintenance on the new system, IBM recommends that you run the SMP/E REPORT CALLLIBS command against this zone now. Then run the CALLLINK job generated by SMP/E. This will ensure that load modules containing external references are link-edited correctly on your system. This APAR was closed in 1998, but may still be applicable. By the way, it specifically notes that if your serverpac order did not have C/370 that the DDDEF for SEDCBASE would be directed to CEE.SCEELKED. I've never run CALLLIBS or CALLLINK, so I don’t know what they do, so proceed with caution. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E THanks .But my initial serverpac came without C/370 product and we installed like below REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RES001) UNIT(3390) WAITFORDSN SHR . But later when I received CBPDO from from IBM for C/370, it allocated SEDBASE dataset but as DDDEF was pointing to SCEELKED, so data related to this FMID went to SCEELKED and SEDBASE is empty for me . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Yea, I saw that same APAR. At this point we are all guessing, but it seems like maybe he tried to apply the native c/370 FMID ontop of serverpac.At this point, I think the best advice would be for the OP to open a PMR with IBM on how to proceed. I was honestly surprised that the C/370 compiler has not been sunsetted yet. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Tuesday, September 09, 2014 12:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I don't know if this helps, but APAR OW36048 contains the following information: If you found incorrect data set names for any DDDEFs in your primary target zone and have already installed maintenance on the new system, IBM recommends that you run the SMP/E REPORT CALLLIBS command against this zone now. Then run the CALLLINK job generated by SMP/E. This will ensure that load modules containing external references are link-edited correctly on your system. This APAR was closed in 1998, but may still be applicable. By the way, it specifically notes that if your serverpac order did not have C/370 that the DDDEF for SEDCBASE would be directed to CEE.SCEELKED. I've never run CALLLIBS or CALLLINK, so I don’t know what they do, so proceed with caution. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, September 09, 2014 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E THanks .But my initial serverpac came without C/370 product and we installed like below REP DDDEF(SEDCBASE) DA(CEE.SCEELKED) VOLUME(RES001) UNIT(3390) WAITFORDSN SHR . But later when I received CBPDO from from IBM for C/370, it allocated SEDBASE dataset but as DDDEF was pointing to SCEELKED, so data related to this FMID went to SCEELKED and SEDBASE is empty for me . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On 09/07/2014 06:17 AM, Shmuel Metz (Seymour J.) wrote: In 031c0cdc-b61c-42f2-a377-97478031b...@comcast.net, on 09/05/2014 at 02:45 PM, Ed Gould edgould1...@comcast.net said: I guess we will have to disagree on what holds can be bypassed. What he wrote was You should never (unless told by IBM who probably never will) BYPASS error holds. Dropping the word error changes its meaning drastically. In summary I think its OK to bypass *SOME* hold errors What do you mean by hold errors? The OP is referring to error holds, and you have not given a case where it is advisable to bypass an error hold. That has nothing to do with bypassing, e.g., DOC. There were rare occasions where we bypassed a specific ERROR hold: * where we had a known exposure to a problem which had actually affected our production system adversely and the only available resolving PTF also had an ERROR hold, but its potential error was less of an exposure than the other problem fixed by the PTF in error. * where the ERROR hold sounded like an issue that didn't apply to us and prevented ACCEPT of maintenance prior to a new round of maintenance, where the PTF now in error had been APPLYed and running in production without problems for many months and some error hold had been issued after the previous round of maintenance. In this case we had empirical evidence the ERROR was not a serious exposure for us and we preferred to expend our resources to moving and testing a new maintenance level rather than resolving a non-issue. It made sense to get the distribution libraries to a level that would allow a potential RESTORE to return to a level that had successfully run without failure in our environment, even if IBM now regarded one of those modules in error. But, bypassing an arbitrary ERROR HOLD without understanding the APAR involved or its implications for your installation is always a bad idea. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
In 031c0cdc-b61c-42f2-a377-97478031b...@comcast.net, on 09/05/2014 at 02:45 PM, Ed Gould edgould1...@comcast.net said: I guess we will have to disagree on what holds can be bypassed. What he wrote was You should never (unless told by IBM who probably never will) BYPASS error holds. Dropping the word error changes its meaning drastically. In summary I think its OK to bypass *SOME* hold errors What do you mean by hold errors? The OP is referring to error holds, and you have not given a case where it is advisable to bypass an error hold. That has nothing to do with bypassing, e.g., DOC. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
The target and distribution libraries are not mirrors of each other. The target libraries could have modules different than the distribution. Will your management allow you to find a class on SMP/E? If so, that could help. You can open a PMR to a vendor so long as the product is still supported. You do not need to hesitate. And sometimes you can get a faster resolution but opening a problem ticket to them. As one of my coworkers likes to point out - we pay them for support, why not use it when needed? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Saturday, September 06, 2014 4:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Yes. I do agree that in my z/OS 2.1 system @@CBL2C with an alias of EDCCBL2C but in my z/OS 1.13 and other system is part of EDC4$006 and it is RF RN RU. But I am not able to understand how this is causing this problem and is there any way to solve before I take further step to raise PMR. On Sat, Sep 6, 2014 at 5:17 PM, Mainframe Mainframe mainframe1...@gmail.com wrote: In distribution Library... ZOS21D.AEDCMOD1 @@CBL2C EDC4$006RF RN RU EDC@@248EDC4$09ERF RN RU EDC4$09DRF RN RU In my Target library, EDC@@248 is a module or not an alias of another module. EDC@@248 RN RU On Sat, Sep 6, 2014 at 1:24 AM, Ed Gould edgould1...@comcast.net wrote: On Sep 5, 2014, at 9:01 AM, Tom Marchant wrote: -SNIP Not refreshable. That's what the Binder told you. You need to find out why. You may need to contact IBM. Tom, I agree. the module somehow got linked incorrectly either from the last PTF that hit it or it got linked outside of SMPE. What the author should do is look at what the last PTF that hit the module and see what the link parms were. There may have been a PTF that did it by mistake and no ones caught it untillthe PTF that was going on was caught. In either case make sure through SMPE what the last PTF went on and look at retain to see if it was in error and do the research on previous PTF's to see eho caused the problem and open a PMR if everything is Kosher. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I was getting errors while doing apply check for these HOLDERROR, so, I used by pass to move ahead for apply.Is there any issues you see in this. Do you suggest to change acceptable value for CEEPLPKA or any other clue. On Fri, Sep 5, 2014 at 10:39 AM, Lizette Koehler stars...@mindspring.com wrote: There were two things in the job run I was able to see. Let me know if this might be part of the issue First - should you code BYPASS(HOLDS(...) HOLDE(...) )?? I always thought you should let HOLDERROR alone unless you have a fixing PTF from IBM. Though I could be wrong. BYPASS(HOLDSYS(DOC,IPL,RESTART,ACTION,ENH,DEP,AO,MSGSKEL,MULTSYS, DYNACT,EC,DB2BIND,EXIT,DELETE,DDDEF) HOLDERROR(AA45207,AA45706,AA45113,AA44153,AA45166,AA44844,AA45744)) Second IEW2322I 1220 923NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 IEW2454W 9203 SYMBOL CEEARLU UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL CEEBLLST UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL STRFTIME UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL LOCALECO UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. I think the fact that CEEPLPKA sets max cc as 0 is the issue for UI18451 Let me know if I am closer to the resolution. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, September 04, 2014 9:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E On Thu, 4 Sep 2014 21:55:32 +0530, Mainframe Mainframe wrote: I see some more warning message before this error message like ... GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA72482 WAS SUCCESSFUL FOR MODULE CBRICMMN IN LMOD CBRINIT0 IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:21 - SEQUENCE NUMBER 87 SYSPRINT FILE SMP00040. ... That's from SMPOUT, not Binder SYSPRINT. Are you viewing your output with SDSF? If so, open the job with ? rather than S and go directly to SMP00040 (I believe (E)JES has a similar feature, perhaps different syntax). Try FIND p'IEWW' (IIRC correctly the ISPF syntax -- help!?) On Thu, Sep 4, 2014 at 9:44 PM, Paul Gilmartin wrote: On Thu, 4 Sep 2014 21:13:31 +0530, Mainframe Mainframe wrote: Hello Rob, In my case LKED entry in SMPE is set to 04. Binder SYSPRINT (perhaps in your case SMP00030) should tell you: Oops! I meant SMP00040. o The maximum RC specified on the NAME statement (IIRC, SMP/E converts that to a comment). o The actual return code from the bind operation (look near the bottom). o Message codes, , of Warning severity. Search backward for IEWW. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
You should never (unless told by IBM who probably never will) BYPASS error holds. They have the hold because they are in error. The error could be minor or it could crash your entire system. Use EXCLUDE of the PTF with the error if you wish to get a successful APPLY. INMO. you shouldn't be APPLY without having achieved a successful APLYCHECK run, but other here just run and let the PTFs with error holds fail. But, either way, intentionally putting broken software on your system is not a good practice. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Thursday, September 04, 2014 11:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I was getting errors while doing apply check for these HOLDERROR, so, I used by pass to move ahead for apply.Is there any issues you see in this. Do you suggest to change acceptable value for CEEPLPKA or any other clue. On Fri, Sep 5, 2014 at 10:39 AM, Lizette Koehler stars...@mindspring.com wrote: There were two things in the job run I was able to see. Let me know if this might be part of the issue First - should you code BYPASS(HOLDS(...) HOLDE(...) )?? I always thought you should let HOLDERROR alone unless you have a fixing PTF from IBM. Though I could be wrong. BYPASS(HOLDSYS(DOC,IPL,RESTART,ACTION,ENH,DEP,AO,MSGSKEL,MULTSYS, DYNACT,EC,DB2BIND,EXIT,DELETE,DDDEF) HOLDERROR(AA45207,AA45706,AA45113,AA44153,AA45166,AA44844,AA45744)) Second IEW2322I 1220 923NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 IEW2454W 9203 SYMBOL CEEARLU UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL CEEBLLST UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL STRFTIME UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL LOCALECO UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. I think the fact that CEEPLPKA sets max cc as 0 is the issue for UI18451 Let me know if I am closer to the resolution. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, September 04, 2014 9:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E On Thu, 4 Sep 2014 21:55:32 +0530, Mainframe Mainframe wrote: I see some more warning message before this error message like ... GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA72482 WAS SUCCESSFUL FOR MODULE CBRICMMN IN LMOD CBRINIT0 IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:21 - SEQUENCE NUMBER 87 SYSPRINT FILE SMP00040. ... That's from SMPOUT, not Binder SYSPRINT. Are you viewing your output with SDSF? If so, open the job with ? rather than S and go directly to SMP00040 (I believe (E)JES has a similar feature, perhaps different syntax). Try FIND p'IEWW' (IIRC correctly the ISPF syntax -- help!?) On Thu, Sep 4, 2014 at 9:44 PM, Paul Gilmartin wrote: On Thu, 4 Sep 2014 21:13:31 +0530, Mainframe Mainframe wrote: Hello Rob, In my case LKED entry in SMPE is set to 04. Binder SYSPRINT (perhaps in your case SMP00030) should tell you: Oops! I meant SMP00040. o The maximum RC specified on the NAME statement (IIRC, SMP/E converts that to a comment). o The actual return code from the bind operation (look near the bottom). o Message codes, , of Warning severity. Search backward for IEWW. --gil - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Fri, 5 Sep 2014 09:18:39 +0530, Mainframe Mainframe
mainframe1...@gmail.com wrote:
Below Output,
LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF
00060001
* M O D U L E S U M M A R Y *
MEMBER NAME: EDC@@248
LIBRARY: SCEELKED
** ALIASES ** ENTRY POINTAMODE
** STRXFRM 31
ATTRIBUTES OF MODULE
** BIT STATUS BIT STATUS BIT STATUS
0 RENT 1 REUS 2 NOT-OVLY
4 NOT-OL 5 BLOCK6 EXEC
8 NOT-DC 9 ZERO-ORG 10 EP-ZERO
12 EDIT 13 NO-SYMS 14 F-LEVEL
MODULE SSI:NONE
APFCODE:
RMODE: ANY
LONGPARM: NO
This output is incomplete as you cut off the part to the right of bits 2,6,10
and 14 (that part that is cut of shows bits 3,7,11, and 15.)
Doug
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Sorry, Please find correct output. 1 J E S 2 J O B L O G -- S Y S T E M M V S 9 -- N O D E J E S S U P 0 20.47.06 JOB00311 THURSDAY, 04 SEP 2014 20.47.06 JOB00311 IRR010I USERID DEVP001 IS ASSIGNED TO THIS JOB. 20.47.06 JOB00311 ICH70001I DEVP001 LAST ACCESS AT 20:31:59 ON THURSDAY, SEPTEMBER 4, 2014 20.47.06 JOB00311 $HASP373 AMBLIST STARTED - INIT BASE - CLASS A - SYS MVS9 20.47.06 JOB00311 IEF403I AMBLIST - STARTED - TIME=20.47.06 20.47.07 JOB00311 - -TIMINGS (MINS.)-- -PAGING COUNTS 20.47.07 JOB00311 -STEPNAME PROCSTEPRC EXCP CONN TCB SRB CLOCK SERV WORKLOAD PAGE SWAP VIO SWAPS 20.47.07 JOB00311 -LIST 00 1966292 .00 .00 .0 16719 SYSTEM 0 0 0 0 20.47.07 JOB00311 IEF404I AMBLIST - ENDED - TIME=20.47.07 20.47.07 JOB00311 -AMBLIST ENDED. NAME- TOTAL TCB CPU TIME= .00 TOTAL ELAPSED TIME=.0 20.47.07 JOB00311 $HASP395 AMBLIST ENDED 0-- JES2 JOB STATISTICS -- - 04 SEP 2014 JOB EXECUTION DATE -6 CARDS READ - 78 SYSOUT PRINT RECORDS -0 SYSOUT PUNCH RECORDS -5 SYSOUT SPOOL KBYTES - 0.01 MINUTES EXECUTION TIME 1 //AMBLIST JOB 'MAINFRAME',CLASS=A,MSGCLASS=A,NOTIFY=SYSUID JOB00311 IEFC653I SUBSTITUTION JCL - 'MAINFRAME',CLASS=A,MSGCLASS=A,NOTIFY=DEVP001 2 //LIST EXEC PGM=AMBLIST 00020001 3 //SYSPRINT DD SYSOUT=* 00030001 4 //SCEELKED DD DSN=SYS1.SCEELKED,DISP=SHR,VOL=SER=RES001,UNIT=3390 00040001 5 //SYSINDD * 00050001 ICH70001I DEVP001 LAST ACCESS AT 20:31:59 ON THURSDAY, SEPTEMBER 4, 2014 IEF236I ALLOC. FOR AMBLIST LIST IEF237I JES2 ALLOCATED TO SYSPRINT IEF237I 376A ALLOCATED TO SCEELKED IEF237I JES2 ALLOCATED TO SYSIN IEF142I AMBLIST LIST - STEP WAS EXECUTED - COND CODE IEF285I DEVP001.AMBLIST.JOB00311.D102.? SYSOUT IEF285I SYS1.SCEELKEDKEPT IEF285I VOL SER NOS= RES001. IEF285I DEVP001.AMBLIST.JOB00311.D101.? SYSIN IEF373I STEP/LIST/START 2014247.2047 IEF032I STEP/LIST/STOP 2014247.2047 CPU: 0 HR 00 MIN 00.02 SECSRB: 0 HR 00 MIN 00.01 SEC VIRT: 4096K SYS: 308K EXT:4K SYS:11800K ATB- REAL:12K SLOTS: 0K VIRT- ALLOC: 2M SHRD: 0M IEF375I JOB/AMBLIST /START 2014247.2047 IEF033I JOB/AMBLIST /STOP 2014247.2047 CPU: 0 HR 00 MIN 00.02 SECSRB: 0 HR 00 MIN 00.01 SEC 1 LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF 00060001 1 * M O D U L E S U M M A R Y * 0MEMBER NAME: EDC@@248 MAIN ENTRY POINT: 0LIBRARY: SCEELKED AMODE OF MAIN ENTRY POINT: 31 0** ALIASES ** ENTRY POINTAMODE ** STRXFRM 31 - 0 ATTRIBUTES OF MODULE 0** BIT STATUS BIT STATUS BIT STATUS BIT STATUS ** 0 0 RENT 1 REUS 2 NOT-OVLY 3 NOT-TEST 4 NOT-OL 5 BLOCK6 EXEC 7 1-TXT 8 NOT-DC 9 ZERO-ORG 10 EP-ZERO 11 NO-RLD 12 EDIT 13 NO-SYMS 14 F-LEVEL 15 NOT-REFR 0 -MODULE SSI:NONE APFCODE: RMODE: ANY LONGPARM: NO 0 *LOAD MODULE PROCESSED EITHER BY VS LINKAGE EDITOR OR BINDER 1 NUMERICAL MAP AND CROSS-REFERENCE LIST OF LOAD MODULE EDC@@248PAGE 0001 - CONTROL SECTION ENTRY LMOD LOC NAME LENGTH TYPE LMOD LOC CSECT LOC NAME 0 00STRXFRM 0A SD 0LENGTH OF LOAD MODULE 10 1ALPHABETICAL MAP OF LOAD MODULE EDC@@248 PAGE 0002 - CONTROL SECTIONENTRY NAME LMOD LOC LENGTH TYPE NAME LMOD LOC CSECT LOC CSECT NAME 0 STRXFRM 000A SD -**END OF MAP AND CROSS-REFERENCE LISTING
Re: RSU APPLY ISSUE GIM23911E
On Fri, 5 Sep 2014 11:36:46 +0530, Mainframe Mainframe wrote: I was getting errors while doing apply check for these HOLDERROR, It is not essential to have RC=0 from an APPLY. RC=4 is usually ok, but you do need to ascertain the reasons for it. PTFs that do not apply because there is an ERROR hold is not a problem, unless those PTFs are critical for your system. There has to be a specific problem that you have with your system. so, I used by pass to move ahead for apply. IF you have researched the APARs for these error holds, And IF you have determined that the PTF(s) that are held resolve a problem that you have been experiencing, And IF you have decided that the problem that you have that is corrected by the PTFs is more critical in your environment than the problems described by the APARs, Then, and only then, does it make sense to bypass the errors. Is there any issues you see in this. Yes. BYPASS(HOLDERROR(...)) tells SMP/E to introduce new errors to your system. Don't do it unless you REALLY know what you are doing. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Fri, 5 Sep 2014 19:21:41 +0530, Mainframe Mainframe mainframe1...@gmail.com wrote: Sorry, Please find correct output. ... 0 ATTRIBUTES OF MODULE 0** BIT STATUS BIT STATUS BIT STATUS BIT STATUS ** 0 0 RENT 1 REUS 2 NOT-OVLY 3 NOT-TEST 4 NOT-OL 5 BLOCK6 EXEC 7 1-TXT 8 NOT-DC 9 ZERO-ORG 10 EP-ZERO 11 NO-RLD 12 EDIT 13 NO-SYMS 14 F-LEVEL 15 NOT-REFR Not refreshable. That's what the Binder told you. You need to find out why. You may need to contact IBM. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I don't think, this could be a issue. Because, I tried this AMBLIST with my OTHER RES volume as well and bit 15 is NOT-REFR and system is running with this. On Fri, Sep 5, 2014 at 8:17 PM, Doug Henry doug_he...@usbank.com wrote: On Fri, 5 Sep 2014 19:21:41 +0530, Mainframe Mainframe mainframe1...@gmail.com wrote: Sorry, Please find correct output. 1 LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF 00060001 1 * M O D U L E S U M M A R Y * 0MEMBER NAME: EDC@@248 MAIN ENTRY POINT: 0LIBRARY: SCEELKED AMODE OF MAIN ENTRY POINT: 31 0** ALIASES ** ENTRY POINTAMODE ** STRXFRM 31 - 0 ATTRIBUTES OF MODULE 0** BIT STATUS BIT STATUS BIT STATUS BIT STATUS ** 0 0 RENT 1 REUS 2 NOT-OVLY 3 NOT-TEST 4 NOT-OL 5 BLOCK6 EXEC 7 1-TXT 8 NOT-DC 9 ZERO-ORG 10 EP-ZERO 11 NO-RLD 12 EDIT 13 NO-SYMS 14 F-LEVEL 15 NOT-REFR 0 So the problem is caused by bit 15 being not-refr instead of the proper setting for the module of bit 15 being refr. I am not sure how you broke your system. I noticed that you improperly bypass a lot of apars and that may be the source of the problem. I suggest you go back to the backup of your smpe/system environment and reapply correctly. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
You do not know if your system is good or not. It is better to open a case with IBM and ask for Language Environment to check. If you do not want to do this, then start over. That means you should have 1) Backed up your SMPE Environment (Both Tlibs, Dlibs and all associated SMPE libraries) before starting maintenance. 2) If not, you may need to delete your environment and start from scratch. Basically you have put your SMP/E environment in a bad state. I am sure many on this list has done this at one time or another. Therefore you need to get back to a good point in time and then start again. Do not bypass any HOLDERRORs in the future. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020-dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I would be VERY wary of restoring the SMPE environment. Unless it was backed up exactly right with every single SMPE-related data set, restoring over the current environment could result in a mess bigger than the one that (seems to) exist now. Instead I would recommend a 'fix forward' approach. 1. Check and recheck that every DDDEF points to the correct data set. This will take time. Don't shortcut. 2. RESTORE all PTFs that were applied since the ZONE EDIT exercise already noted. This will also take time. Crank through it. 3. Pull the latest HOLD data. 4. Reapply maintenance following the new and improved process: use only BYPASS(HOLDSYS) and nothing else. 5. Expect RC 8 on APPLY CHECK. Look at the CAUSER section. Missing sysmods are OK; ignore them. Any other error must be dealt with. 6. Expect RC 8 on the real APPLY. Once again check the CAUSER section. You should see only the same 'missing sysmod' messages that you saw in APPLY CHECK. Any other error must be dealt with. I agree with those who point out that conflicting LKED attributes are not necessarily a run-time problem, but you should consult IBM via SR to verify. The bigger problem here, as noted, is that your result differs from others (including me) who applied (more or less) the same PTFs. That fact is unsettling. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Doug Henry doug_he...@usbank.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/05/2014 08:37 AM Subject:Re: RSU APPLY ISSUE GIM23911E Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Fri, 5 Sep 2014 19:21:41 +0530, Mainframe Mainframe mainframe1...@gmail.com wrote: Sorry, Please find correct output. 1 LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF 00060001 1 * M O D U L E S U M M A R Y * 0MEMBER NAME: EDC@@248 MAIN ENTRY POINT: 0LIBRARY: SCEELKED AMODE OF MAIN ENTRY POINT: 31 0** ALIASES ** ENTRY POINTAMODE ** STRXFRM 31 - 0 ATTRIBUTES OF MODULE 0** BIT STATUS BIT STATUS BIT STATUS BIT STATUS ** 0 0 RENT 1 REUS 2 NOT-OVLY 3 NOT-TEST 4 NOT-OL 5 BLOCK6 EXEC 7 1-TXT 8 NOT-DC 9 ZERO-ORG 10 EP-ZERO 11 NO-RLD 12 EDIT 13 NO-SYMS 14 F-LEVEL 15 NOT-REFR 0 So the problem is caused by bit 15 being not-refr instead of the proper setting for the module of bit 15 being refr. I am not sure how you broke your system. I noticed that you improperly bypass a lot of apars and that may be the source of the problem. I suggest you go back to the backup of your smpe/system environment and reapply correctly. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
This is exactly how you resolve this issue. Don't deliberately put broken software on your system. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020-dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
While I also would not trust is system, I do trust SMP/E. After running the APPLY EXCLUDING the PTF(s) with errors, he can run the SMP/E report of errors on his system. He can research the errors and possibly RESTORE those he just put on if they sound like they cause aprolem he is likely to encounter, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, September 05, 2014 8:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E You do not know if your system is good or not. It is better to open a case with IBM and ask for Language Environment to check. If you do not want to do this, then start over. That means you should have 1) Backed up your SMPE Environment (Both Tlibs, Dlibs and all associated SMPE libraries) before starting maintenance. 2) If not, you may need to delete your environment and start from scratch. Basically you have put your SMP/E environment in a bad state. I am sure many on this list has done this at one time or another. Therefore you need to get back to a good point in time and then start again. Do not bypass any HOLDERRORs in the future. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020- dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Or what Skip says :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Friday, September 05, 2014 9:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I would be VERY wary of restoring the SMPE environment. Unless it was backed up exactly right with every single SMPE-related data set, restoring over the current environment could result in a mess bigger than the one that (seems to) exist now. Instead I would recommend a 'fix forward' approach. 1. Check and recheck that every DDDEF points to the correct data set. This will take time. Don't shortcut. 2. RESTORE all PTFs that were applied since the ZONE EDIT exercise already noted. This will also take time. Crank through it. 3. Pull the latest HOLD data. 4. Reapply maintenance following the new and improved process: use only BYPASS(HOLDSYS) and nothing else. 5. Expect RC 8 on APPLY CHECK. Look at the CAUSER section. Missing sysmods are OK; ignore them. Any other error must be dealt with. 6. Expect RC 8 on the real APPLY. Once again check the CAUSER section. You should see only the same 'missing sysmod' messages that you saw in APPLY CHECK. Any other error must be dealt with. I agree with those who point out that conflicting LKED attributes are not necessarily a run-time problem, but you should consult IBM via SR to verify. The bigger problem here, as noted, is that your result differs from others (including me) who applied (more or less) the same PTFs. That fact is unsettling. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Doug Henry doug_he...@usbank.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/05/2014 08:37 AM Subject:Re: RSU APPLY ISSUE GIM23911E Sent by:IBM Mainframe Discussion List IBM- m...@listserv.ua.edu On Fri, 5 Sep 2014 19:21:41 +0530, Mainframe Mainframe mainframe1...@gmail.com wrote: Sorry, Please find correct output. 1 LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF 00060001 1 * M O D U L E S U M M A R Y * 0MEMBER NAME: EDC@@248 MAIN ENTRY POINT: 0LIBRARY: SCEELKED AMODE OF MAIN ENTRY POINT: 31 0** ALIASES ** ENTRY POINTAMODE ** STRXFRM 31 -- --- 0 ATTRIBUTES OF MODULE 0** BIT STATUS BIT STATUS BIT STATUS BIT STATUS ** 0 0 RENT 1 REUS 2 NOT- OVLY 3 NOT-TEST 4 NOT-OL 5 BLOCK6 EXEC 7 1-TXT 8 NOT-DC 9 ZERO-ORG 10 EP- ZERO 11 NO-RLD 12 EDIT 13 NO-SYMS 14 F- LEVEL 15 NOT-REFR 0- --- So the problem is caused by bit 15 being not-refr instead of the proper setting for the module of bit 15 being refr. I am not sure how you broke your system. I noticed that you improperly bypass a lot of apars and that may be the source of the problem. I suggest you go back to the backup of your smpe/system environment and reapply correctly. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I've been watching this exchange from a distance. Are we now confusing 2 issues here? We have the original problem of CEEPLPKA and the secondary one of his running apply jobs bypassing holderrors without knowing what he was bypassing. The OP has gotten an apply check to run with RC=0 after removing the BYPASS(HOLDERROR) by eliminating the PTFs that were held by the error. This doesn't do anything about the original problem of the apply returning RC=4 on CEEPLPKA on the actual apply. Unless the OP eliminated additional PTFs from the apply (one at least of which would need to be installing a fix into CEEPLPKA), he will still have the issue with language environment. Unless I missed a part of the conversation, I believe he still needs to find out how to get the load module flags set correctly. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 05, 2014 11:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E This is exactly how you resolve this issue. Don't deliberately put broken software on your system. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020-dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained
Re: RSU APPLY ISSUE GIM23911E
On 2014-09-05, at 10:33, Gibney, Dave wrote: He can research the errors and possibly RESTORE those he just put on if they sound like they cause aprolem he is likely to encounter, I have once, perhaps twice, got in a situation where an attempt to APPLY a defective, perhaps chimeric, PTF left the CSI so damanged that an attempt to RESTORE failed. Subsequent attempts to APPLY REDO failed because SMP/E noted that the RESTORE had failed; further attempts to RESTORE failed because the PTF was not recorded as APPLYed. I re-installed. But I'm not our customer; we made the PTF right before it went to field. No one has much noted my suggestion to inspect the Binder SYSPRINT (SMP00040) for IEWW messages, or have we got beyond that point? GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. BYPASS(PRE) is not a solution; it usually makes things much worse. As does BYPASS(MODID). We have had competent customers review HOLDDATA comments; conclude correctly that the documented introduced defect was not relevant to their configurations; and APPLY BYPASS(HOLDERR(aparnum)) beneficially. Be informed, and be specific about the aparnum(s). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
And potentially a third problem that was mentioned by Anthony Thompson that has been overlooked as well. The OP posted an AMBLIST of module STRXFRM showing it as an ALIAS of EDC@@248. Anthony pointed out that on his 2.1 system, both STRXFRM and EDC@@248 are aliases of EDC4$09E. My 1.13 system matches Anthony's 2.1 system. Is the fact that the OP's system appears to be different in SCEELKED another problem? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Friday, September 05, 2014 11:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I've been watching this exchange from a distance. Are we now confusing 2 issues here? We have the original problem of CEEPLPKA and the secondary one of his running apply jobs bypassing holderrors without knowing what he was bypassing. The OP has gotten an apply check to run with RC=0 after removing the BYPASS(HOLDERROR) by eliminating the PTFs that were held by the error. This doesn't do anything about the original problem of the apply returning RC=4 on CEEPLPKA on the actual apply. Unless the OP eliminated additional PTFs from the apply (one at least of which would need to be installing a fix into CEEPLPKA), he will still have the issue with language environment. Unless I missed a part of the conversation, I believe he still needs to find out how to get the load module flags set correctly. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 05, 2014 11:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E This is exactly how you resolve this issue. Don't deliberately put broken software on your system. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020-dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant
Re: RSU APPLY ISSUE GIM23911E
On 09/05/14 13:19, Paul Gilmartin wrote: On 2014-09-05, at 10:33, Gibney, Dave wrote: He can research the errors and possibly RESTORE those he just put on if they sound like they cause aprolem he is likely to encounter, I have once, perhaps twice, got in a situation where an attempt to APPLY a defective, perhaps chimeric, PTF left the CSI so damanged that an attempt to RESTORE failed. Subsequent attempts to APPLY REDO failed because SMP/E noted that the RESTORE had failed; further attempts to RESTORE failed because the PTF was not recorded as APPLYed. I re-installed. But I'm not our customer; we made the PTF right before it went to field. No one has much noted my suggestion to inspect the Binder SYSPRINT (SMP00040) for IEWW messages, or have we got beyond that point? GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. BYPASS(PRE) is not a solution; it usually makes things much worse. As does BYPASS(MODID). We have had competent customers review HOLDDATA comments; conclude correctly that the documented introduced defect was not relevant to their configurations; and APPLY BYPASS(HOLDERR(aparnum)) beneficially. Be informed, and be specific about the aparnum(s). -- gil That's why Systems Programming is as much an art as it is a science. Knowing why you do things or even more importantly why you don't do something, has to be learned from experience. -- Mark Jacobs Time Customer Service Tampa, FL The standard you walk past is the standard you accept. Lt. Gen. David Morrison, Australian Army Chief -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I would also, having done this awhile, be comfortable with APPLY BYPASS(HOLDERR(specificapar)) is and only if I was 1. Actually experiencing the problem fixed by the PTF and 2. Confident the reason for error wasn't worse. At the beginning of my systems programmer career, I might have been naïve enough to try BYPSSS(HOLDERR but I had the benefit of more experienced mentors. Mr. Mainframe Mainframe is trying hard, but it is clear he has been tossed in the deep end without sufficient support and training. We have had competent customers review HOLDDATA comments; conclude correctly that the documented introduced defect was not relevant to their configurations; and APPLY BYPASS(HOLDERR(aparnum)) beneficially. Be informed, and be specific about the aparnum(s). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I think I saw a comment to the effect that the error in the PTF that needed to be excluded related to the rc=4, but I could be wrong. Actually, I don't know how far this system has evolved/mutated since the Serverpac install. I an stongly inclined to recommending a do over starting with a fresh order/install of a new Serverpac :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Friday, September 05, 2014 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I've been watching this exchange from a distance. Are we now confusing 2 issues here? We have the original problem of CEEPLPKA and the secondary one of his running apply jobs bypassing holderrors without knowing what he was bypassing. The OP has gotten an apply check to run with RC=0 after removing the BYPASS(HOLDERROR) by eliminating the PTFs that were held by the error. This doesn't do anything about the original problem of the apply returning RC=4 on CEEPLPKA on the actual apply. Unless the OP eliminated additional PTFs from the apply (one at least of which would need to be installing a fix into CEEPLPKA), he will still have the issue with language environment. Unless I missed a part of the conversation, I believe he still needs to find out how to get the load module flags set correctly. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 05, 2014 11:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E This is exactly how you resolve this issue. Don't deliberately put broken software on your system. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020- dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system
Re: RSU APPLY ISSUE GIM23911E
On Fri, 5 Sep 2014 17:32:19 +, Pommier, Rex rpomm...@sfgmembers.com wrote: And potentially a third problem that was mentioned by Anthony Thompson that has been overlooked as well. The OP posted an ?AMBLIST of module STRXFRM showing it as an ALIAS of EDC@@248. Anthony pointed out that on his 2.1 system, both STRXFRM and EDC@@248 are aliases of EDC4$09E. My 1.13 system matches Anthony's 2.1 system. Is the fact that the OP's system appears to be different in SCEELKED another problem? Rex Hi Rex, Using the wrong verion of SCEELKED is the entire problem of getting a return code 4 on the binder when the OP applied UI18451. As you noticed he is not using a z/OS V2R1 or a z/os V1R13 SCEELKED. I am not sure how far you have to back to get one like he is using. He is lucky that the apply required a return code of 0 to be successful ! Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Dave, I guess we will have to disagree on what holds can be bypassed. There are examples that IBM tells you in the hold why to do that its OK to bypass. Usually IME: action or others they tell you that you must do this ie link it outside of SMPE with special parms. Granted its not often but that is why its important to do as IBM instructs. SYSGEN (you wont see that now days) was another one that there was something special you had to do after applying the PTF. I know when I used to do SMP work by bypass was always on 2 lines. Yes I checked every PTF that was on the hold report to see anything I might need to do after those PTF's went on with an apply. A LONG time ago I was putting on a CBPDO there were 13000 PTF's going on and the hold list (IIRC 150 were held) was well researched. In fact IBM had not shipped all the PTF's on the tape and I finally got to do a full apply of those 13000 PTF's and it seemed to take forever (12+ hours). In summary I think its OK to bypass *SOME* hold errors of course not all. Ed On Sep 5, 2014, at 2:03 AM, Gibney, Dave wrote: You should never (unless told by IBM who probably never will) BYPASS error holds. They have the hold because they are in error. The error could be minor or it could crash your entire system. Use EXCLUDE of the PTF with the error if you wish to get a successful APPLY. INMO. you shouldn't be APPLY without having achieved a successful APLYCHECK run, but other here just run and let the PTFs with error holds fail. But, either way, intentionally putting broken software on your system is not a good practice. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Thursday, September 04, 2014 11:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I was getting errors while doing apply check for these HOLDERROR, so, I used by pass to move ahead for apply.Is there any issues you see in this. Do you suggest to change acceptable value for CEEPLPKA or any other clue. On Fri, Sep 5, 2014 at 10:39 AM, Lizette Koehler stars...@mindspring.com wrote: There were two things in the job run I was able to see. Let me know if this might be part of the issue First - should you code BYPASS(HOLDS(...) HOLDE(...) )?? I always thought you should let HOLDERROR alone unless you have a fixing PTF from IBM. Though I could be wrong. BYPASS(HOLDSYS(DOC,IPL,RESTART,ACTION,ENH,DEP,AO,MSGSKEL,MULTSYS, DYNACT,EC,DB2BIND,EXIT,DELETE,DDDEF) HOLDERROR(AA45207,AA45706,AA45113,AA44153,AA45166,AA44844,AA45744)) Second IEW2322I 1220 923NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 IEW2454W 9203 SYMBOL CEEARLU UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL CEEBLLST UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL STRFTIME UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL LOCALECO UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. I think the fact that CEEPLPKA sets max cc as 0 is the issue for UI18451 Let me know if I am closer to the resolution. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, September 04, 2014 9:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E On Thu, 4 Sep 2014 21:55:32 +0530, Mainframe Mainframe wrote: I see some more warning message before this error message like ... GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA72482 WAS SUCCESSFUL FOR MODULE CBRICMMN IN LMOD CBRINIT0 IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:21 - SEQUENCE NUMBER 87 SYSPRINT FILE SMP00040. ... That's from SMPOUT, not Binder SYSPRINT. Are you viewing your output with SDSF? If so, open the job with ? rather than S and go directly to SMP00040 (I believe (E)JES has a similar feature, perhaps different syntax). Try FIND p'IEWW' (IIRC correctly the ISPF syntax -- help!?) On Thu, Sep 4, 2014 at 9:44 PM, Paul Gilmartin wrote: On Thu, 4 Sep 2014 21:13:31 +0530, Mainframe Mainframe wrote: Hello Rob, In my case LKED entry in SMPE is set to 04. Binder SYSPRINT (perhaps in your case SMP00030) should tell you: Oops! I meant SMP00040. o The maximum RC specified on the NAME statement (IIRC, SMP/E converts that to a comment). o The actual return code from the bind operation (look near the bottom). o Message codes, , of Warning severity. Search backward for IEWW. --gil - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive
Re: RSU APPLY ISSUE GIM23911E
On Sep 5, 2014, at 9:01 AM, Tom Marchant wrote: -SNIP Not refreshable. That's what the Binder told you. You need to find out why. You may need to contact IBM. Tom, I agree. the module somehow got linked incorrectly either from the last PTF that hit it or it got linked outside of SMPE. What the author should do is look at what the last PTF that hit the module and see what the link parms were. There may have been a PTF that did it by mistake and no ones caught it untillthe PTF that was going on was caught. In either case make sure through SMPE what the last PTF went on and look at retain to see if it was in error and do the research on previous PTF's to see eho caused the problem and open a PMR if everything is Kosher. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Thu, 4 Sep 2014 16:00:06 +0530, Mainframe Mainframe mainframe1...@gmail.com wrote: I am in middle of applying RSU on z/OS 2.1 system and getting RC 08 with below issues. GIM23911E ** LINK-EDIT PROCESSING FOR SYSMOD UI18451 FAILED FOR MODULE CEEHDSP IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN CODE (04) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 02:35:37 - SEQUENCE NUMBER 92 - SYSPRINT FILE SMP00040. I just tested putting on UI18451 and it went on without a problem. I wonder if you are running out of space in SCEERUN ? I would look at the joblog of your smpe run and see if there are indications of that . Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
GIM23911E ** LINK-EDIT PROCESSING FOR SYSMOD UI18451 FAILED FOR MODULE
CEEZIDT
IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN CODE (04)
EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 02:35:37 -
SEQUENCE NUMBER 92 - SYSPRINT FILE SMP00040.
when I checked SMP00040, I didnt find much info except
IEW2322I 1220 1INCLUDE SMPWRK3(CEEHDSP) UI18451
IEW2322I 1220 2 IDENTIFY CEEHDSP('UI18451')
IEW2322I 1220 3 SETSSI 01118451
snip
The SMP/E messages are telling you there was a problem linking load
module CEEPLPKA. Find the binder output for that link edit operation
(literally, Find CEEPLPKA) and you should see something more meaningful
than you've pasted here.
Kurt Quackenbush -- IBM, SMP/E Development
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Thu, 4 Sep 2014 18:30:16 +0530, Mainframe Mainframe mainframe1...@gmail.com wrote: Hell Kurt, I also extracted below output I see these warning messages in the output for that particular PTF that are causing your RC4. Here is one of the modules in your list CEEYCBTS (snipped a bunch out) IEW2322I 1220 1272NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 IEW2609W 5104 SECTION STRXFRM USABILITY ATTRIBUTE OF REENTRANT CONFLICTS WITH REQUESTED USABILITY OF REFRESHABLE. For my apply of UI18451 (that works fine) I see for the bind of CEEPLPKA the options that smpe passed are : IEW2278I B352 INVOCATION PARAMETERS - LIST,LET,NCAL,XREF,RENT,REFR,AMODE=31,RMODE=ANY,CALL Then STRXFRM is autoincluded from STRXFRM 218260 STRXFRM * CSECT A SMP1 01 STRXFRM SMP101 SYS1.SCEELKED In SCEELKED STRXFRM is an alias for EDC4$09E and it attributes include refr and rent. AMODE == 31 AUTH == NO DC== NO EDIT == YES ENTRY == EXEC == YES LOADONLY == NO PAGE == NO REFR == YES RENT == YES REUS == YES RMODE == ANY I don't know if any of this helps you. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
For this type of error I look at the following
1) JOBLOB of the SMP/E Job
a.Are there any issues for the Datasets in the messages?
b.Are there any IGD messages or Space issues
2) SMPRPT
a.What messages are there for the PTF
b.UI18451 does it have any PTFs with it that did not go on?
3) What other error messages are found in and about that PTF? That
Library? That Load Module
a.If there are no supporting messages that make sense on why it Failed
b.Look through IBM Link (SR/ETR) and see if there has been an issue
reported for the PTF during SMP/E Processing
c.Open a CASE with IBM for that product to determine why it failed
Unless you post your entire JOB LOG and SMPRPT and LINK output, hard to say why
it failed.
I might also like to see the DDDEF report to make sure the files are on the
correct DD Statement.
The reason to open a CASE to Language Environment is because it is their SMPE
process. SMPE probably did exactly what it was supposed to do. However,
something failed in the process. You may need to ask Language Environment if
they have any issues with this PTF.
Why do LKED process fail? Many reasons, Space, Incorrect dataset type (PDSE vs
PDS), missing data set in SYSLMOD, and probably others.
There should be messages in the SMPE JOB output that can clarify for you what
is not quite correct.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Kurt Quackenbush
Sent: Thursday, September 04, 2014 5:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU APPLY ISSUE GIM23911E
GIM23911E ** LINK-EDIT PROCESSING FOR SYSMOD UI18451 FAILED
FOR MODULE
CEEZIDT
IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN
CODE (04)
EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 02:35:37
-
SEQUENCE NUMBER 92 - SYSPRINT FILE SMP00040.
when I checked SMP00040, I didnt find much info except
IEW2322I 1220 1INCLUDE SMPWRK3(CEEHDSP) UI18451
IEW2322I 1220 2 IDENTIFY CEEHDSP('UI18451')
IEW2322I 1220 3 SETSSI 01118451
snip
The SMP/E messages are telling you there was a problem linking load module
CEEPLPKA. Find the binder output for that link edit operation (literally,
Find
CEEPLPKA) and you should see something more meaningful than you've pasted
here.
Kurt Quackenbush -- IBM, SMP/E Development
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
The output shows this:
IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN CODE (04)
EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 02:35:37
It's not at all uncommon for the binder to return code 04 for various
reasons that are not actually 'problems'. In this case we see messages
about conflicting module attributes. This happens. Life goes on. It's way
less dangerous than, say, global warming.
The real problem here is that SMPE is being too prissy. If 04 'exceeded
the allowable value', then the allowable value is set too low. 04 is only
a warning after all. Go into the SMPE dialog and examine the GLOBAL
UTILITY options for entry LKED. If it says 'RETURN CODE: 0', you will
incur never ending grief now and in the future. Because of your LKED
entry, SMPE turns 04 into 08.
Our 2.1 SMPE environment has already been tailored for us, so I can't tell
how it came out of the box. Now it's set to 'RETURN CODE: 4', which we've
used for as long as I can remember. This way we get 08 only for real
problems.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: Lizette Koehler stars...@mindspring.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 09/04/2014 07:16 AM
Subject:Re: RSU APPLY ISSUE GIM23911E
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
For this type of error I look at the following
1) JOBLOB of the SMP/E Job
a. Are there any issues for the Datasets in the messages?
b. Are there any IGD messages or Space issues
2) SMPRPT
a. What messages are there for the PTF
b. UI18451 does it have any PTFs with it that did not go on?
3) What other error messages are found in and about that
PTF? That Library? That Load Module
a. If there are no supporting messages that make sense on
why it Failed
b. Look through IBM Link (SR/ETR) and see if there has been
an issue reported for the PTF during SMP/E Processing
c. Open a CASE with IBM for that product to determine why it
failed
Unless you post your entire JOB LOG and SMPRPT and LINK output, hard to
say why it failed.
I might also like to see the DDDEF report to make sure the files are on
the correct DD Statement.
The reason to open a CASE to Language Environment is because it is their
SMPE process. SMPE probably did exactly what it was supposed to do.
However, something failed in the process. You may need to ask Language
Environment if they have any issues with this PTF.
Why do LKED process fail? Many reasons, Space, Incorrect dataset type
(PDSE vs PDS), missing data set in SYSLMOD, and probably others.
There should be messages in the SMPE JOB output that can clarify for you
what is not quite correct.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Kurt Quackenbush
Sent: Thursday, September 04, 2014 5:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU APPLY ISSUE GIM23911E
GIM23911E ** LINK-EDIT PROCESSING FOR SYSMOD UI18451 FAILED
FOR MODULE
CEEZIDT
IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN
CODE (04)
EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME
02:35:37
-
SEQUENCE NUMBER 92 - SYSPRINT FILE SMP00040.
when I checked SMP00040, I didnt find much info except
IEW2322I 1220 1INCLUDE SMPWRK3(CEEHDSP) UI18451
IEW2322I 1220 2 IDENTIFY CEEHDSP('UI18451')
IEW2322I 1220 3 SETSSI 01118451
snip
The SMP/E messages are telling you there was a problem linking load
module
CEEPLPKA. Find the binder output for that link edit operation
(literally, Find
CEEPLPKA) and you should see something more meaningful than you've
pasted
here.
Kurt Quackenbush -- IBM, SMP/E Development
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Thu, 4 Sep 2014 07:32:54 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: The output shows this: IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN CODE (04) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 02:35:37 It's not at all uncommon for the binder to return code 04 for various reasons that are not actually 'problems'. In this case we see messages about conflicting module attributes. This happens. Life goes on. It's way less dangerous than, say, global warming. The real problem here is that SMPE is being too prissy. If 04 'exceeded the allowable value', then the allowable value is set too low. 04 is only a warning after all. Go into the SMPE dialog and examine the GLOBAL UTILITY options for entry LKED. If it says 'RETURN CODE: 0', you will incur never ending grief now and in the future. Because of your LKED entry, SMPE turns 04 into 08. Our 2.1 SMPE environment has already been tailored for us, so I can't tell how it came out of the box. Now it's set to 'RETURN CODE: 4', which we've used for as long as I can remember. This way we get 08 only for real problems. Hi Skip, If you read my previous reply's you will know that I sucessfully applied UI18451 just to test this for him this morning. However he is running into some fundamental problem . The bind of CEEPLPKA should result in a return code 0 (not 4). I also have my binder global option set to 4 but that is irrelevent in this problem because it is being overridden by the lmod Return Code subentry (it specifies 0). The problem seems to be with the entries that are autoinclude by the binder don't seem to have the proper rent reus flag set. As I said before an example is the module STRXFRM that should be RENT, REUS, REFR . IEW2322I 1220 1272NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Hello Rob,
In my case LKED entry in SMPE is set to 04.
On Thu, Sep 4, 2014 at 8:02 PM, Skip Robinson jo.skip.robin...@sce.com
wrote:
The output shows this:
IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN CODE (04)
EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 02:35:37
It's not at all uncommon for the binder to return code 04 for various
reasons that are not actually 'problems'. In this case we see messages
about conflicting module attributes. This happens. Life goes on. It's way
less dangerous than, say, global warming.
The real problem here is that SMPE is being too prissy. If 04 'exceeded
the allowable value', then the allowable value is set too low. 04 is only
a warning after all. Go into the SMPE dialog and examine the GLOBAL
UTILITY options for entry LKED. If it says 'RETURN CODE: 0', you will
incur never ending grief now and in the future. Because of your LKED
entry, SMPE turns 04 into 08.
Our 2.1 SMPE environment has already been tailored for us, so I can't tell
how it came out of the box. Now it's set to 'RETURN CODE: 4', which we've
used for as long as I can remember. This way we get 08 only for real
problems.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: Lizette Koehler stars...@mindspring.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 09/04/2014 07:16 AM
Subject:Re: RSU APPLY ISSUE GIM23911E
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
For this type of error I look at the following
1) JOBLOB of the SMP/E Job
a. Are there any issues for the Datasets in the messages?
b. Are there any IGD messages or Space issues
2) SMPRPT
a. What messages are there for the PTF
b. UI18451 does it have any PTFs with it that did not go on?
3) What other error messages are found in and about that
PTF? That Library? That Load Module
a. If there are no supporting messages that make sense on
why it Failed
b. Look through IBM Link (SR/ETR) and see if there has been
an issue reported for the PTF during SMP/E Processing
c. Open a CASE with IBM for that product to determine why it
failed
Unless you post your entire JOB LOG and SMPRPT and LINK output, hard to
say why it failed.
I might also like to see the DDDEF report to make sure the files are on
the correct DD Statement.
The reason to open a CASE to Language Environment is because it is their
SMPE process. SMPE probably did exactly what it was supposed to do.
However, something failed in the process. You may need to ask Language
Environment if they have any issues with this PTF.
Why do LKED process fail? Many reasons, Space, Incorrect dataset type
(PDSE vs PDS), missing data set in SYSLMOD, and probably others.
There should be messages in the SMPE JOB output that can clarify for you
what is not quite correct.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Kurt Quackenbush
Sent: Thursday, September 04, 2014 5:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU APPLY ISSUE GIM23911E
GIM23911E ** LINK-EDIT PROCESSING FOR SYSMOD UI18451 FAILED
FOR MODULE
CEEZIDT
IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN
CODE (04)
EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME
02:35:37
-
SEQUENCE NUMBER 92 - SYSPRINT FILE SMP00040.
when I checked SMP00040, I didnt find much info except
IEW2322I 1220 1INCLUDE SMPWRK3(CEEHDSP) UI18451
IEW2322I 1220 2 IDENTIFY CEEHDSP('UI18451')
IEW2322I 1220 3 SETSSI 01118451
snip
The SMP/E messages are telling you there was a problem linking load
module
CEEPLPKA. Find the binder output for that link edit operation
(literally, Find
CEEPLPKA) and you should see something more meaningful than you've
pasted
here.
Kurt Quackenbush -- IBM, SMP/E Development
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Thu, 4 Sep 2014 21:13:31 +0530, Mainframe Mainframe wrote: Hello Rob, In my case LKED entry in SMPE is set to 04. Binder SYSPRINT (perhaps in your case SMP00030) should tell you: o The maximum RC specified on the NAME statement (IIRC, SMP/E converts that to a comment). o The actual return code from the bind operation (look near the bottom). o Message codes, , of Warning severity. Search backward for IEWW. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I see some more warning message before this error message like GIM22701IAPPLY PROCESSING WAS SUCCESSFUL FOR SYSMOD UA72131. GIM22701IAPPLY PROCESSING WAS SUCCESSFUL FOR SYSMOD UA70978. GIM22701IAPPLY PROCESSING WAS SUCCESSFUL FOR SYSMOD UA72744. GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA72482 WAS SUCCESSFUL FOR MODULE CBRICMMN IN LMOD CBRINIT0 IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:21 - SEQUENCE NUMBER 87 - SYSPRINT FILE SMP00040. GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA71130 WAS SUCCESSFUL FOR MODULE IGG0191B IN LMOD IGG0191A IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:22 - SEQUENCE NUMBER 88 - SYSPRINT FILE SMP00040. GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA71462 WAS SUCCESSFUL FOR MODULE IGC0002A IN LMOD IGC0002A IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:22 - SEQUENCE NUMBER 88 - SYSPRINT FILE SMP00040. GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA72749 WAS SUCCESSFUL FOR MODULE IGG0201Z IN LMOD IGG0201Z IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:22 - SEQUENCE NUMBER 88 - SYSPRINT FILE SMP00040. On Thu, Sep 4, 2014 at 9:44 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On Thu, 4 Sep 2014 21:13:31 +0530, Mainframe Mainframe wrote: Hello Rob, In my case LKED entry in SMPE is set to 04. Binder SYSPRINT (perhaps in your case SMP00030) should tell you: o The maximum RC specified on the NAME statement (IIRC, SMP/E converts that to a comment). o The actual return code from the bind operation (look near the bottom). o Message codes, , of Warning severity. Search backward for IEWW. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Thu, 4 Sep 2014 21:55:32 +0530, Mainframe Mainframe wrote: I see some more warning message before this error message like ... GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA72482 WAS SUCCESSFUL FOR MODULE CBRICMMN IN LMOD CBRINIT0 IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:21 - SEQUENCE NUMBER 87 SYSPRINT FILE SMP00040. ... That's from SMPOUT, not Binder SYSPRINT. Are you viewing your output with SDSF? If so, open the job with ? rather than S and go directly to SMP00040 (I believe (E)JES has a similar feature, perhaps different syntax). Try FIND p'IEWW' (IIRC correctly the ISPF syntax -- help!?) On Thu, Sep 4, 2014 at 9:44 PM, Paul Gilmartin wrote: On Thu, 4 Sep 2014 21:13:31 +0530, Mainframe Mainframe wrote: Hello Rob, In my case LKED entry in SMPE is set to 04. Binder SYSPRINT (perhaps in your case SMP00030) should tell you: Oops! I meant SMP00040. o The maximum RC specified on the NAME statement (IIRC, SMP/E converts that to a comment). o The actual return code from the bind operation (look near the bottom). o Message codes, , of Warning severity. Search backward for IEWW. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Guilty as charged; I did not dwell on Doug's posts. Installing the same PTF and getting a different result raise other questions to be pursued. There may be a benign explanation that IBM could supply in an SR. I applied UI18451 in June and don't see any anomalies the sysout. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Doug Henry doug_he...@usbank.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/04/2014 09:30 AM Subject:Re: RSU APPLY ISSUE GIM23911E Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Thu, 4 Sep 2014 07:32:54 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: The output shows this: IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN CODE (04) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 02:35:37 It's not at all uncommon for the binder to return code 04 for various reasons that are not actually 'problems'. In this case we see messages about conflicting module attributes. This happens. Life goes on. It's way less dangerous than, say, global warming. The real problem here is that SMPE is being too prissy. If 04 'exceeded the allowable value', then the allowable value is set too low. 04 is only a warning after all. Go into the SMPE dialog and examine the GLOBAL UTILITY options for entry LKED. If it says 'RETURN CODE: 0', you will incur never ending grief now and in the future. Because of your LKED entry, SMPE turns 04 into 08. Our 2.1 SMPE environment has already been tailored for us, so I can't tell how it came out of the box. Now it's set to 'RETURN CODE: 4', which we've used for as long as I can remember. This way we get 08 only for real problems. Hi Skip, If you read my previous reply's you will know that I sucessfully applied UI18451 just to test this for him this morning. However he is running into some fundamental problem . The bind of CEEPLPKA should result in a return code 0 (not 4). I also have my binder global option set to 4 but that is irrelevent in this problem because it is being overridden by the lmod Return Code subentry (it specifies 0). The problem seems to be with the entries that are autoinclude by the binder don't seem to have the proper rent reus flag set. As I said before an example is the module STRXFRM that should be RENT, REUS, REFR . IEW2322I 1220 1272NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On 9/4/2014 7:32 AM, Skip Robinson wrote: The real problem here is that SMPE is being too prissy. If 04 'exceeded the allowable value', then the allowable value is set too low. 04 is only a warning after all. Go into the SMPE dialog and examine the GLOBAL UTILITY options for entry LKED. If it says 'RETURN CODE: 0', you will incur never ending grief now and in the future. Because of your LKED entry, SMPE turns 04 into 08. For many, Many, MANY years now, product packagers are supposed to set the maximum allowable return code for each LMOD directly in the JCLIN. For example (from some of our product packaging): ORDER EJESREXX INCLUDE AEJELMOD(EJESREXX) ENTRY EJESREXX NAME EJESREXX(R) RC=0 -- This is it! For this reason, a properly packaged product should never see msgGIM23911E unless there is a real problem. If RC=n is not specified at all in the JCLIN for a given LMOD, that would be a reason to complain to the lazy product packagers. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I could be way off base, but given that the OP just finished a thread where the solution was a mass/conditional zoneedit of his DDDEFs, I would look very closely at which libraries are actually being used and updated by this SMP/E running. An inadvertent mixing of LE levels is scary. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Thursday, September 04, 2014 11:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Guilty as charged; I did not dwell on Doug's posts. Installing the same PTF and getting a different result raise other questions to be pursued. There may be a benign explanation that IBM could supply in an SR. I applied UI18451 in June and don't see any anomalies the sysout. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Doug Henry doug_he...@usbank.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/04/2014 09:30 AM Subject:Re: RSU APPLY ISSUE GIM23911E Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Thu, 4 Sep 2014 07:32:54 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: The output shows this: IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN CODE (04) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 02:35:37 It's not at all uncommon for the binder to return code 04 for various reasons that are not actually 'problems'. In this case we see messages about conflicting module attributes. This happens. Life goes on. It's way less dangerous than, say, global warming. The real problem here is that SMPE is being too prissy. If 04 'exceeded the allowable value', then the allowable value is set too low. 04 is only a warning after all. Go into the SMPE dialog and examine the GLOBAL UTILITY options for entry LKED. If it says 'RETURN CODE: 0', you will incur never ending grief now and in the future. Because of your LKED entry, SMPE turns 04 into 08. Our 2.1 SMPE environment has already been tailored for us, so I can't tell how it came out of the box. Now it's set to 'RETURN CODE: 4', which we've used for as long as I can remember. This way we get 08 only for real problems. Hi Skip, If you read my previous reply's you will know that I sucessfully applied UI18451 just to test this for him this morning. However he is running into some fundamental problem . The bind of CEEPLPKA should result in a return code 0 (not 4). I also have my binder global option set to 4 but that is irrelevent in this problem because it is being overridden by the lmod Return Code subentry (it specifies 0). The problem seems to be with the entries that are autoinclude by the binder don't seem to have the proper rent reus flag set. As I said before an example is the module STRXFRM that should be RENT, REUS, REFR . IEW2322I 1220 1272NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Good Catch! I didn't make the connection. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Thursday, September 04, 2014 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I could be way off base, but given that the OP just finished a thread where the solution was a mass/conditional zoneedit of his DDDEFs, I would look very closely at which libraries are actually being used and updated by this SMP/E running. An inadvertent mixing of LE levels is scary. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Thursday, September 04, 2014 11:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Guilty as charged; I did not dwell on Doug's posts. Installing the same PTF and getting a different result raise other questions to be pursued. There may be a benign explanation that IBM could supply in an SR. I applied UI18451 in June and don't see any anomalies the sysout. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Doug Henry doug_he...@usbank.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/04/2014 09:30 AM Subject:Re: RSU APPLY ISSUE GIM23911E Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Thu, 4 Sep 2014 07:32:54 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: The output shows this: IN LMOD CEEPLPKA IN THE SCEERUN LIBRARY. THE RETURN CODE (04) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 02:35:37 It's not at all uncommon for the binder to return code 04 for various reasons that are not actually 'problems'. In this case we see messages about conflicting module attributes. This happens. Life goes on. It's way less dangerous than, say, global warming. The real problem here is that SMPE is being too prissy. If 04 'exceeded the allowable value', then the allowable value is set too low. 04 is only a warning after all. Go into the SMPE dialog and examine the GLOBAL UTILITY options for entry LKED. If it says 'RETURN CODE: 0', you will incur never ending grief now and in the future. Because of your LKED entry, SMPE turns 04 into 08. Our 2.1 SMPE environment has already been tailored for us, so I can't tell how it came out of the box. Now it's set to 'RETURN CODE: 4', which we've used for as long as I can remember. This way we get 08 only for real problems. Hi Skip, If you read my previous reply's you will know that I sucessfully applied UI18451 just to test this for him this morning. However he is running into some fundamental problem . The bind of CEEPLPKA should result in a return code 0 (not 4). I also have my binder global option set to 4 but that is irrelevent in this problem because it is being overridden by the lmod Return Code subentry (it specifies 0). The problem seems to be with the entries that are autoinclude by the binder don't seem to have the proper rent reus flag set. As I said before an example is the module STRXFRM that should be RENT, REUS, REFR . IEW2322I 1220 1272NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access
Re: RSU APPLY ISSUE GIM23911E
On Thu, 4 Sep 2014 19:23:25 +, Gibney, Dave gib...@wsu.edu wrote: I could be way off base, but given that the OP just finished a thread where the solution was a mass/conditional zoneedit of his DDDEFs, I would look very closely at which libraries are actually being used and updated by this SMP/E running. An inadvertent mixing of LE levels is scary. Hi Dave, Yes this might very well be the issue. Just concentrating on the first module that causes the problem, I suggest that OP do an amblist and send the output to the list. This output should have rent (bit 0), reuse (bit 1), and refr (bit 15) set. //LIST EXEC PGM=AMBLIST //SYSPRINT DD SYSOUT=* //SCEELKED DD DSN=SYS1.SCEELKED,DISP=SHR //SYSINDD * LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF /* Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Below O/P for AMBLIST On Fri, Sep 5, 2014 at 1:10 AM, Doug Henry doug_he...@usbank.com wrote: On Thu, 4 Sep 2014 19:23:25 +, Gibney, Dave gib...@wsu.edu wrote: I could be way off base, but given that the OP just finished a thread where the solution was a mass/conditional zoneedit of his DDDEFs, I would look very closely at which libraries are actually being used and updated by this SMP/E running. An inadvertent mixing of LE levels is scary. Hi Dave, Yes this might very well be the issue. Just concentrating on the first module that causes the problem, I suggest that OP do an amblist and send the output to the list. This output should have rent (bit 0), reuse (bit 1), and refr (bit 15) set. //LIST EXEC PGM=AMBLIST //SYSPRINT DD SYSOUT=* //SCEELKED DD DSN=SYS1.SCEELKED,DISP=SHR //SYSINDD * LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF /* Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Below Output,
LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF
00060001
* M O D U L E S U M M A R Y *
MEMBER NAME: EDC@@248
LIBRARY: SCEELKED
** ALIASES ** ENTRY POINTAMODE
** STRXFRM 31
ATTRIBUTES OF MODULE
** BIT STATUS BIT STATUS BIT STATUS
0 RENT 1 REUS 2 NOT-OVLY
4 NOT-OL 5 BLOCK6 EXEC
8 NOT-DC 9 ZERO-ORG 10 EP-ZERO
12 EDIT 13 NO-SYMS 14 F-LEVEL
MODULE SSI:NONE
APFCODE:
RMODE: ANY
LONGPARM: NO
*LOAD MODULE PROCESSED EITHER BY VS LINKAGE EDITOR
OR BIN
NUMERICAL MAP AND CROSS-REFERENCE LIST OF LOAD
MODU
CONTROL SECTION
ENTRY
LMOD LOC NAME LENGTH TYPE
LMOD LO
00STRXFRM 0A SD
LENGTH OF LOAD MODULE 10
ALPHABETICAL MAP OF LOAD MODULE EDC@
@248
CONTROL SECTIONENTRY
NAME LMOD LOC LENGTH TYPE NAME
LMO
STRXFRM 000A SD
**END OF MAP AND CROSS-REFERENCE LISTING
BOTTOM OF DATA
On Fri, Sep 5, 2014 at 9:18 AM, Mainframe Mainframe mainframe1...@gmail.com
wrote:
Below O/P for AMBLIST
On Fri, Sep 5, 2014 at 1:10 AM, Doug Henry doug_he...@usbank.com wrote:
On Thu, 4 Sep 2014 19:23:25 +, Gibney, Dave gib...@wsu.edu wrote:
I could be way off base, but given that the OP just finished a thread
where the solution was a mass/conditional zoneedit of his DDDEFs, I would
look very closely at which libraries are actually being used and updated by
this SMP/E running. An inadvertent mixing of LE levels is scary.
Hi Dave,
Yes this might very well be the issue. Just concentrating on the first
module that causes the problem, I suggest that OP do an amblist and send
the output to the list. This output should have rent (bit 0), reuse (bit
1), and refr (bit 15) set.
//LIST EXEC PGM=AMBLIST
//SYSPRINT DD SYSOUT=*
//SCEELKED DD DSN=SYS1.SCEELKED,DISP=SHR
//SYSINDD *
LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF
/*
Doug
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
There were two things in the job run I was able to see. Let me know if this might be part of the issue First - should you code BYPASS(HOLDS(...) HOLDE(...) )?? I always thought you should let HOLDERROR alone unless you have a fixing PTF from IBM. Though I could be wrong. BYPASS(HOLDSYS(DOC,IPL,RESTART,ACTION,ENH,DEP,AO,MSGSKEL,MULTSYS, DYNACT,EC,DB2BIND,EXIT,DELETE,DDDEF) HOLDERROR(AA45207,AA45706,AA45113,AA44153,AA45166,AA44844,AA45744)) Second IEW2322I 1220 923NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 IEW2454W 9203 SYMBOL CEEARLU UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL CEEBLLST UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL STRFTIME UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL LOCALECO UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. I think the fact that CEEPLPKA sets max cc as 0 is the issue for UI18451 Let me know if I am closer to the resolution. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, September 04, 2014 9:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E On Thu, 4 Sep 2014 21:55:32 +0530, Mainframe Mainframe wrote: I see some more warning message before this error message like ... GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA72482 WAS SUCCESSFUL FOR MODULE CBRICMMN IN LMOD CBRINIT0 IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:21 - SEQUENCE NUMBER 87 SYSPRINT FILE SMP00040. ... That's from SMPOUT, not Binder SYSPRINT. Are you viewing your output with SDSF? If so, open the job with ? rather than S and go directly to SMP00040 (I believe (E)JES has a similar feature, perhaps different syntax). Try FIND p'IEWW' (IIRC correctly the ISPF syntax -- help!?) On Thu, Sep 4, 2014 at 9:44 PM, Paul Gilmartin wrote: On Thu, 4 Sep 2014 21:13:31 +0530, Mainframe Mainframe wrote: Hello Rob, In my case LKED entry in SMPE is set to 04. Binder SYSPRINT (perhaps in your case SMP00030) should tell you: Oops! I meant SMP00040. o The maximum RC specified on the NAME statement (IIRC, SMP/E converts that to a comment). o The actual return code from the bind operation (look near the bottom). o Message codes, , of Warning severity. Search backward for IEWW. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Our apply of UI18451 got a binder RC of zero.
AMBLIST of STRXFRM is somewhat different, both it and EDS@@248 are aliases of
EDC4$09E:
LISTLOAD DDN=DD1,MEMBER=STRXFRM,OUTPUT=XREF
* M O D U L E S U M M A R Y *
MEMBER NAME: EDC4$09E
MAIN ENTRY POINT:
LIBRARY: DD1 (-- i.e. SYS1.SCEELKED Ant.)
AMODE OF MAIN ENTRY POINT: 31
** ALIASES ** ENTRY POINTAMODE
EDC@@248 31
** STRXFRM 31
---
ATTRIBUTES OF MODULE
** BIT STATUS BIT STATUS BIT STATUS
BIT STATUS **
0 RENT 1 REUS 2 NOT-OVLY
3 NOT-TEST
4 NOT-OL 5 BLOCK6 EXEC
7 1-TXT
8 NOT-DC 9 ZERO-ORG 10 EP-ZERO
11 NO-RLD
12 EDIT 13 NO-SYMS 14 F-LEVEL
15 REFR
---
MODULE SSI:NONE
APFCODE:
RMODE: ANY
LONGPARM: NO
*LOAD MODULE PROCESSED EITHER BY VS LINKAGE EDITOR OR
BINDER
NUMERICAL MAP AND CROSS-REFERENCE LIST OF LOAD
MODULE EDC4$09EPAGE 0001
CONTROL SECTIONENTRY
LMOD LOC NAME LENGTH TYPELMOD
LOC CSECT LOC NAME
00STRXFRM 0A SD
LENGTH OF LOAD MODULE 10
ALPHABETICAL MAP OF LOAD MODULE EDC4$09E
PAGE 0002
CONTROL SECTIONENTRY
NAME LMOD LOC LENGTH TYPE NAME
LMOD LOC CSECT LOC CSECT NAME
STRXFRM 000A SD
**END OF MAP AND CROSS-REFERENCE LISTING
Only z/OS 2.1 here, no prior z/OS to compare it to.
Ant.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mainframe Mainframe
Sent: Friday, 5 September 2014 1:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU APPLY ISSUE GIM23911E
Below Output,
LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF
00060001
* M O D U L E S U M M A R Y *
MEMBER NAME: EDC@@248
LIBRARY: SCEELKED
** ALIASES ** ENTRY POINTAMODE
** STRXFRM 31
ATTRIBUTES OF MODULE
