Re: ICF, catalog reorg, error, cluster no longer attached to the data
You guys are the best! I'm off to try it. Thanks. Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ICF, catalog reorg, error, cluster no longer attached to the data
I need ICF catalog/VSAM information/assistance.
We have a DB2 table which spans 256 datasets. The cluster for partition 186
does not recognize the data component.
=3.4
Total Tracks:315 non-x:315 Data Sets:2 non-x:
-
Command - Enter "/" to select actionTracks %Used
-
DB2E.DSNDBC.DB0LCCR0.CCRSMG.I0001.A186
DB2E.DSNDBD.DB0LCCR0.CCRSMG.I0001.A186315?
A LC on the cluster says this:
IDC3012I ENTRY DB2E.DSNDBD.DB0LCCR0.CCRSMG.I0001.A186 NOT FOUND
IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42
IDC1566I ** DB2E.DSNDBD.DB0LCCR0.CCRSMG.I0001.A186 NOT LISTED
A LC on the data component says this:
LISTC ALL ENT('DB2E.DSNDBD.DB0LCCR0.CCRSMG.I0001.A186')
IDC3012I ENTRY DB2E.DSNDBD.DB0LCCR0.CCRSMG.I0001.A186 NOT FOUND
IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42
IDC1566I ** DB2E.DSNDBD.DB0LCCR0.CCRSMG.I0001.A186 NOT LISTED
Does anyone know a method to add the data component back to the cluster?
The DASD department was trying to reorg an ICF catalog and had errors,
including this one.
I'm looking for a method to restore the connection as opposed to
dropping/recreating, etc., considering it's DB2 data.
Any information or referral to doc is appreciated.
Thanks, Linda
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
DB2 Sysprog needs CF/XCF information
Hi, I need information about the journals/logs/console for the CF, or more simply, what resources are availble to mine about a system slowdown that affected my DB2s on two separate CECs. I have three CECs - A, B, and C. On CEC C, LPAR SYSB, we had IRA103I SQA/ESQA expanded into CSA/ECSA. The LPAR eventually crashed. This was a development LPAR. Correspondingly, to the minute, on CEC B, LPAR SYS1, DB2 member DB2A had a production slowdown that is being raised to upper management. I asked the performance guys to analyze any resource - CF, hardware, channels, dasd, tape - anything, that is shared between the CECs for delays, bottlenecks, or outages. The RMF reports have XCF delays at this time period of 100%. I'm looking for any information which can tell me more about the XCF delays, or speculation about why this happened. My DB2 resources are not relevant at this point; the slowdown was not due to DB2. Any information, disssertation on CF/XCF, or location of logs (other than LOGREC and the console log) or journals, would be appreciated. Does the CF have a physical console? Does it have a separate log? How do I find it? Thanks very much. Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 Sysprog needs CF/XCF information
Hi Hal, Thanks for the reply. I understand that everything would back up until the situation cleared; I need to prove it. I'll check the console logs for the LPAR where the backup occurred. I've been reading the manuals about CF/XCF and there's a transport class that collect messages into a buffer. Do you know if the buffer is backed up by a dataset (log/journal)? Is there a way to find this from system display messages or evidence in a started task? Thanks very much. Any information or referrals are appreciated. Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PROGxx, linklist, LLA and fetch performance
Thank you SO much!!! I've been trying to figure out how to do just that! Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PROGxx, linklist, LLA and fetch performance
Skip, Ted, Tom, Scott, Kees, Jon, Ed, Thank you for the explanations. I appreciate your time and the lively discussion. I knew IBM-Main was the place to find the answer. Best regards, Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PROGxx, linklist, LLA and fetch performance
On Mon, 9 Feb 2009 16:49:22 +, Ted MacNEIL wrote: >How I would handle/have handled it, is never have more than two active release running >(especially with DB2, that can get expensive after a year). >How you handle the release migration, is up to you. >You can have one or the other steplib'd, and the opposite lnklst'd. >But, when the dust settles, the current release should be in the lnklst. > Considering the micro-economics of sysprog time, the scenario described above requires I add and delete steplibs in every started task and programmer jcl in every migration, and handle linklist too. Instead, don't put DB2 in linklist. Keep the steplibs to a static named library and change the contents only. This simplifies migration (change the contents of the steplib'd SDSNLOAD). I never change linklist, never change the started task jcl, and never affect programmers JCL. This is the easiest way to manage the DB2 libraries - install, migration, and operation - and it eliminates the possibilities of typos too. All I ever change is the library contents. But that's just my opinion too. :) Back to LLA. Does anyone know the search mechanics of the LLA engine on a second request for a module? Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PROGxx, linklist, LLA and fetch performance
>Pardon me? >It builds an in-storage cache of directories and stages modules to VLF. >Modules are administrated per library, so is can manage duplicate >modules. > >Kees. Hi Kees, Thank you very much. Given duplicate modules exist in separate libraries, and LLA is making a determination based on fetch performance and not sequential order, do you know how the fetch performance is evaluated? I.e., how is one directory chose over another? Is it a function of the LLA search engine? I'm trying to understand this scenario: When job 1 is looking for a module, I presume the engine looks at LLA before LNKLST. Let's say it finds the module, and passes the address to the job. Job 2 is looking for a module, and LLA looks for it. Does the engine start at the beginning of the LLA in-storage cache of directories, or does it continue searching from where it was last? Please excuse me if this should be obvious; I'm not a MVS Sysprog. Thanks, Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PROGxx, linklist, LLA and fetch performance
On Mon, 9 Feb 2009 15:41:11 +, Ted MacNEIL wrote: >>In my experience, DB2 should not be in linklist; it does not need to be there. > >I disagree. It ensures everybody is running the same code. > >>and leaves operational holes particularly in TSO. > >Again, I disagree. >If somebody changes the release, via new libraries, you can end up with a maintenance headache. > >And, LNKLST is faster than STEP/JOB LIBs. > I have six lpars with four data sharing groups crossing the lpars, and having DB2 in linklist won't work. The migration to a new release, if in linklist only, would affect six lpars and four datasharing groups at once. Given short migration windows, and the change in the DB2 catalog to unicode between R710 and R810, I cannot migrate four production platforms in the window, not to mention management would not accept a risk of that magnitude. For a less complex platform, perhaps a single DB2 per lpar, having the code linklisted is manageable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PROGxx, linklist, LLA and fetch performance
On Mon, 9 Feb 2009 15:13:32 +, Ted MacNEIL wrote: >The first one. > >>I need to know which of these sentences is true: > >>The order the datasets were typed into PROGxx is the >>order the libraries will be searched, and the order they >>were typed can be relied upon. > >Yes. >Otherwise, who knows what will happen. >LLA is just an extension to BLDL, and preserves the order. >Anything else would be chaos. DB2 does LOAD, not BLDL. Do you know what LOAD does with LLA? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PROGxx, linklist, LLA and fetch performance
Yes, LNKLST searches top-to-bottom, but what is LLA doing? Do you have information about how LLA choses between two duplicate module names in linklist when it's making a determination for fetch performance? It's not searching in sequential order, it's searching in speed of fetch performance order and (I think) because it's not searching in sequential order, it could hit either one of the duplicate modules. Any information or referral to doc is appreciated. Thanks, Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PROGxx, linklist, LLA and fetch performance
This is precisely the point I'm trying to make. I have an inherited system and encountered belief systems that the PROGxx makes the determination of LLA search order, and therefor it's ok to run libraries with duplicate module names in linklist. In my experience, DB2 should not be in linklist; it does not need to be there, and leaves operational holes particularly in TSO. If libraries are allocated via clist and not the logon proc, from anywhere in TSO the DB2 DSN command processor can be executed and hit the code in linklist. It's an undesirable situation in migration, in my opinion. My concern is LLA and how it is chosing modules. Since I have duplicate modules in linklist, which one is LLA going to pick? Is PROGxx the order, or is LLA performing analysis and picking the one that's fastest? I've sat in classes twice saying the order cannot be relied upon, and to not put same-named modules in linklist. I'm hard pressed to remember where in the last decades those classes were, not to mention trying to find any class material. Which brings me to the great minds of IBM-Main, looking for help. :) Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
PROGxx, linklist, LLA and fetch performance
Hello, I need confirmation about search order between PROGxx linklisted libraries, LLA, and libraries with same-named modules at different releases. I'm hoping someone here can help me. In this case, DSN710.SDSNLOAD and DSN810.SDSNLOAD are both in PROGxx linklist. They are DB2 load libraries and both contain modules with the same names. The question is the search order within LLA. LLA is for speed of loading, not order. LLA will determine which modules will provide the best performance for fetch and therefore, I speculate LLA could chose either DSN710.SDSNLOAD or DSN810.SDSNLOAD first. In PROGxx, if DSN710.SDSNLOAD is specified first, does this influence LLA to pick the DSN710 modules? What if DSN810.SDSNLOAD modules would provide best performance for fetch? Wouldn't LLA pick DSN810.SDSNLOAD first? I need to know which of these sentences is true: The order the datasets were typed into PROGxx is the order the libraries will be searched, and the order they were typed can be relied upon. - or - LLA will determine which modules will provide the best performance for fetch and therefore, LLA could chose any library out of the typed (in PROGxx) sequence order. The order the datasets were type into PROGxx cannot be relied upon for search sequence. Any information or referral to doc is appreciated. Thanks, Linda Hagedorn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Looking for a copy of Advanced Assembler Language and MVS Interfaces : For IBM Systems and Application Programmers 1999
Will you will it to me? It may be the only way I can afford one. :) I wrote to the publisher; if they reply with any good info, I'll pass it along here. Best regards, Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Looking for a copy of Advanced Assembler Language and MVS Interfaces : For IBM Systems and Application Programmers 1999
Hi, Does anyone have a copy of 'Advanced Assembler Language and MVS Interfaces : For IBM Systems and Application Programmers (Paperback - 1999) by Carmine A. Cannatello' they'd like to sell? It's out of print. I'm in the NY/NJ/CT area. Thanks, Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
