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 <[email protected]> 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 > [email protected] > 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:[email protected]] On > Behalf Of Mainframe Mainframe > Sent: Tuesday, September 09, 2014 5:28 AM > To: [email protected] > 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.) < > [email protected]> wrote: > > > In <[email protected]>, on 09/05/2014 > > at 02:45 PM, Ed Gould <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to [email protected] 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 [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
