Re: Speaking of SCRT
W dniu 2010-04-12 22:45, Ted MacNEIL pisze: And, many disciplines, such as capacity planning. Example: type 30, type 110 do not have serial numbers, LPAR names, etc. Type 72, 74, etc don't have them either. So what? I don't see any relationship to 110 or 30. Then obviously you've never done Capacity Planning, Performance Management or Chargeback. Very far-fetched opinion, unjustified. To clarify: I don't see any relationship to SCRT. Without going into details, a standard methodology of allocating CPU usage for planning purposes is merging type 70, 72, and 30 (interval). Only one of those has hardware details. Simply put, 70 gives me the detail of overall usage, 72 allows for the breakdown by workload (with capture ratios applied), and 30 allows me to determine which application within workload. Type 110 allows for a merging of CICS transactions (for this example), along with other details. 74 gives me the I/O component. With other records (I've only given a few examples), I can end up with a profile vector, of CPU, LPAR, Workload, application, I/O, and other details. Without going into details I have SMF manual with all the records described (with exception for 110), some of them I even know. My performance management or capacity is not an issue here in this context and it's not a problem at all. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: Speaking of SCRT
Then obviously you've never done Capacity Planning, Performance Management or Chargeback. Very far-fetched opinion, unjustified. To clarify: I don't see any relationship to SCRT. My point was there are many records that are dependent on independent SMFIDs. I was giving examples and you said you didn't understand my examples, so we branched out a bit. But, back to my original point. There are many reasons for unique SMFIDs, so why is SCRT an issue? You have to do it anyways, so why get yourself upset over such a trivial issue? - Too busy driving to stop for gas! -- 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: Speaking of SCRT
W dniu 2010-04-13 11:05, Ted MacNEIL pisze: But, back to my original point. There are many reasons for unique SMFIDs, so why is SCRT an issue? No. There are many reasons where unique SMF ID would be advantage, but it's still not necessary. Convenient, not required. You have to do it anyways, so why get yourself upset over such a trivial issue? No, I don't have to do it anyways, and that why I'm upset. And it's not trivial issue, because SMFID is hardcoded in the software which I cannot change. Modification of SMF ID means re-installation of the software which is at least inconvenient. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: Speaking of SCRT
No. There are many reasons where unique SMF ID would be advantage, but it's still not necessary. Even one is enough. Once you have a single valid reason, all else pales in comparison. Convenient, not required. I disagree. There are many 'required'. And, one is enough. Convenience is in the eye of the beholder. I've had many reasons for unique IDs, and SCRT just came along for the ride. But, obviously, we disagree. I've never worked in a shop where more than one system had the same SMFID. Nor would I want to. In this case, convenience is being able to do my job without doing strange and unusual acts. And, if you restrict yourself to just the upper case alphabet, you still have 26 to the 4th possibilities. I'm at a loss as to why you would want two with the same SMFID, and that's after considering your DR example. - Too busy driving to stop for gas! -- 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
Speaking of SCRT
Has anyone else downloaded the new version (18.2) and tested it yet? I am getting errors and am wondering if anyone else is too. Maybe I got a bad download from the net or a corrupted upload to my mainframe. Errors are below: IEW2307E 1113 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA. IEW2553E 460A RECORD NUMBER 93 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 68 IEW2553E 460A RECORD NUMBER 93 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 69 IEW2553E 460A RECORD NUMBER 103 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 138 IEW2553E 460A RECORD NUMBER 106 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 226 IEW2553E 460A RECORD NUMBER 108 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 170 IEW2553E 460A RECORD NUMBER 108 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 171 IEW2307E 1032 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA. IEW2457E 9208 SYMBOL SCRTDATA UNRESOLVED. NO CALL LIBRARY SPECIFIED. IEW2672S 3934 ERROR ENCOUNTERED WITH SEVERITY GREATER THAN LET OPTION. IEW2008I 0F03 PROCESSING COMPLETED. RETURN CODE = 12. -- 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: Speaking of SCRT
It worked fine for me. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Monday, April 12, 2010 2:58 PM To: IBM-MAIN@bama.ua.edu Subject: Speaking of SCRT Has anyone else downloaded the new version (18.2) and tested it yet? I am getting errors and am wondering if anyone else is too. Maybe I got a bad download from the net or a corrupted upload to my mainframe. Errors are below: IEW2307E 1113 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA. IEW2553E 460A RECORD NUMBER 93 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 68 IEW2553E 460A RECORD NUMBER 93 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 69 IEW2553E 460A RECORD NUMBER 103 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 138 IEW2553E 460A RECORD NUMBER 106 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 226 IEW2553E 460A RECORD NUMBER 108 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 170 IEW2553E 460A RECORD NUMBER 108 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 171 IEW2307E 1032 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA. IEW2457E 9208 SYMBOL SCRTDATA UNRESOLVED. NO CALL LIBRARY SPECIFIED. IEW2672S 3934 ERROR ENCOUNTERED WITH SEVERITY GREATER THAN LET OPTION. IEW2008I 0F03 PROCESSING COMPLETED. RETURN CODE = 12. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Speaking of SCRT
Maybe I got a bad download from the net or a corrupted upload to my mainframe. If you think that's the case, did you try retrieving a fresh copy? - Too busy driving to stop for gas! -- 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: Speaking of SCRT
Not yet, but since Gadi replied with a good report, I'll grab it again. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Monday, April 12, 2010 8:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Speaking of SCRT Maybe I got a bad download from the net or a corrupted upload to my mainframe. If you think that's the case, did you try retrieving a fresh copy? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Speaking of SCRT
Okay, problem must be on my end then. I'll download/upload it again. Thanks! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of gad...@malam.com Sent: Monday, April 12, 2010 8:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Speaking of SCRT It worked fine for me. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Monday, April 12, 2010 2:58 PM To: IBM-MAIN@bama.ua.edu Subject: Speaking of SCRT Has anyone else downloaded the new version (18.2) and tested it yet? I am getting errors and am wondering if anyone else is too. Maybe I got a bad download from the net or a corrupted upload to my mainframe. Errors are below: IEW2307E 1113 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA. IEW2553E 460A RECORD NUMBER 93 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 68 IEW2553E 460A RECORD NUMBER 93 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 69 IEW2553E 460A RECORD NUMBER 103 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 138 IEW2553E 460A RECORD NUMBER 106 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 226 IEW2553E 460A RECORD NUMBER 108 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 170 IEW2553E 460A RECORD NUMBER 108 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 171 IEW2307E 1032 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA. IEW2457E 9208 SYMBOL SCRTDATA UNRESOLVED. NO CALL LIBRARY SPECIFIED. IEW2672S 3934 ERROR ENCOUNTERED WITH SEVERITY GREATER THAN LET OPTION. IEW2008I 0F03 PROCESSING COMPLETED. RETURN CODE = 12. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- 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: Speaking of SCRT
Still getting errors. I am connected remotely today, coming in through PCOM and using IND$FILE with Binary. Normally, I use HOD and FTP. I'll try tomorrow from the office and see if I am still having the same issues. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Monday, April 12, 2010 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: Speaking of SCRT Has anyone else downloaded the new version (18.2) and tested it yet? I am getting errors and am wondering if anyone else is too. Maybe I got a bad download from the net or a corrupted upload to my mainframe. Errors are below: IEW2307E 1113 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA. IEW2553E 460A RECORD NUMBER 93 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 68 IEW2553E 460A RECORD NUMBER 93 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 69 IEW2553E 460A RECORD NUMBER 103 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 138 IEW2553E 460A RECORD NUMBER 106 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 226 IEW2553E 460A RECORD NUMBER 108 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 170 IEW2553E 460A RECORD NUMBER 108 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 171 IEW2307E 1032 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA. IEW2457E 9208 SYMBOL SCRTDATA UNRESOLVED. NO CALL LIBRARY SPECIFIED. IEW2672S 3934 ERROR ENCOUNTERED WITH SEVERITY GREATER THAN LET OPTION. IEW2008I 0F03 PROCESSING COMPLETED. RETURN CODE = 12. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Speaking of SCRT
Call off the dogs...stupid user error. Somehow, the member I was copying into had gotten switched from CAPS OFF to CAPS ON. While this gives credence to Gadi's assertion that the update process is error-prone, I concur with those that want to keep this update process out of SMP/E's purview. Bob -Original Message- From: Richards, Robert B. Sent: Monday, April 12, 2010 8:51 AM To: 'IBM Mainframe Discussion List' Subject: RE: Speaking of SCRT Still getting errors. I am connected remotely today, coming in through PCOM and using IND$FILE with Binary. Normally, I use HOD and FTP. I'll try tomorrow from the office and see if I am still having the same issues. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Monday, April 12, 2010 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: Speaking of SCRT Has anyone else downloaded the new version (18.2) and tested it yet? I am getting errors and am wondering if anyone else is too. Maybe I got a bad download from the net or a corrupted upload to my mainframe. Errors are below: IEW2307E 1113 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA. IEW2553E 460A RECORD NUMBER 93 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 68 IEW2553E 460A RECORD NUMBER 93 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 69 IEW2553E 460A RECORD NUMBER 103 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 138 IEW2553E 460A RECORD NUMBER 106 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 226 IEW2553E 460A RECORD NUMBER 108 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 170 IEW2553E 460A RECORD NUMBER 108 OF THE CURRENT OBJECT MODULE REFERS TO UNKNOWN ESDID 171 IEW2307E 1032 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA. IEW2457E 9208 SYMBOL SCRTDATA UNRESOLVED. NO CALL LIBRARY SPECIFIED. IEW2672S 3934 ERROR ENCOUNTERED WITH SEVERITY GREATER THAN LET OPTION. IEW2008I 0F03 PROCESSING COMPLETED. RETURN CODE = 12. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Speaking of SCRT
On Mon, 12 Apr 2010 11:35:37 -0400, Richards, Robert B. wrote: Somehow, the member I was copying into had gotten switched from CAPS OFF to CAPS ON. It's a good idea to use mixed case in one's comments, so if CAPS ON corrupts your file, the change is visibly apparent. I suspect Shane will disagree. Of course, in this case you haven't control of the JCL. It's a very bad idea to lock CAPS ON in one's profile. Does one get a warning in this case? Did you touch a line in the binary SYSIN to cause the case to change? And IBM should provide checksums. -- gil -- 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: Speaking of SCRT
I have no clue as to when the profile was switched. The particular member I am alluding to is a member that has *only* the ESD object text. Because I do not normally try to read that grin, I missed the case change. I finally spotted what was happening and corrected the offending member's profile. For the record, the source code is mixed case. I just wasn't noticing the switch to uppercase. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, April 12, 2010 12:01 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Speaking of SCRT On Mon, 12 Apr 2010 11:35:37 -0400, Richards, Robert B. wrote: Somehow, the member I was copying into had gotten switched from CAPS OFF to CAPS ON. It's a good idea to use mixed case in one's comments, so if CAPS ON corrupts your file, the change is visibly apparent. I suspect Shane will disagree. Of course, in this case you haven't control of the JCL. It's a very bad idea to lock CAPS ON in one's profile. Does one get a warning in this case? Did you touch a line in the binary SYSIN to cause the case to change? And IBM should provide checksums. -- gil -- 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: Speaking of SCRT
My €0.02: 1. I *hate* CAPS ON, especially automatic switch when lowercase character is found (although this is NOT the case). I wish I would have option for CAPS in profile. 2. Method of SCRT delivery is error prone. IMHO it would be better at least to supply it as PDS, so the code would be in separate member, not a subject to accidental change. It would be also easier to customize. Such approach provides some control - RECEIVE will not work in case of some popular mistakes. 3. It would be nice to provide some verification procedure for the code, separate member would help here. 4. (unrelated to original problem, but related to SCRT). IMO requirement for unique SMF ID is silly and technically unfounded. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Speaking of SCRT
4. (unrelated to original problem, but related to SCRT). IMO requirement for unique SMF ID is silly and technically unfounded. I disagree. I've always had unique SMF id's, long before SCRT came out. As a Capacity Analyst, it's the simplest way to identify systems uniquely. So, I don't find SCRT's requirement a burden. Considering all the other requirements for unique SMF ids, why is this one a problem? - Too busy driving to stop for gas! -- 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: Speaking of SCRT
W dniu 2010-04-12 20:49, Ted MacNEIL pisze: 4. (unrelated to original problem, but related to SCRT). IMO requirement for unique SMF ID is silly and technically unfounded. I disagree. I've always had unique SMF id's, long before SCRT came out. As a Capacity Analyst, it's the simplest way to identify systems uniquely. No. The simplest way is to use identifier which is always unique, i.e. LPARname optionally qualified with CPC serial. So, I don't find SCRT's requirement a burden. Considering all the other requirements for unique SMF ids, why is this one a problem? Imagine the following scenario: you have to create a clone of existing system. Flashcopy and similar software makes it quick and easy. However what you get is really a clone - all the identifiers are the same. All except LPARname. Of course it doesn't hurt to change sysname or sysid UNLESS any of those identifiers is hardcoded in some software installed on the system. Just my €0.02 -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: Speaking of SCRT
No. The simplest way is to use identifier which is always unique, i.e. LPARname optionally qualified with CPC serial. None of those are in the type 89, iirc. The only guarantee is the SMFID, which is in the common header section for all SMF records, identifying which system cut the record. So, if I have duplicate SMFIDs I cannot effectively merge the type 70 and the type 89. Also, there are many other products that require unique SMFIDs. Example: JES XMIT/RECEIVE. And, many disciplines, such as capacity planning. Example: type 30, type 110 do not have serial numbers, LPAR names, etc. Type 72, 74, etc don't have them either. Do do a compare/merge we need a unique identifier, and the SMFID gives us one. Without that uniqueness, all we would have is chaos, unless we have only one system. Even then, we would still be merging by SMFID. I assumed that you would have run into issues before with multiple systems using non-unique SMFIDs. SCRT is just a drop in the ocean. - Too busy driving to stop for gas! -- 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: Speaking of SCRT
W dniu 2010-04-12 21:22, Ted MacNEIL pisze: No. The simplest way is to use identifier which is always unique, i.e. LPARname optionally qualified with CPC serial. None of those are in the type 89, iirc. Bad assumption. See documentation. Last, but not least: I see nothing wrong in CHANGE. It need not affect existing code (i.e. new type). The only guarantee is the SMFID, which is in the common header section for all SMF records, identifying which system cut the record. The same information can be logically added when really needed. Since I can provide entries in NO89 DD, I can also provide separate DDs for each system. i.e. ddname=LPARNAME (I mean SMF data). There are many ways to skin the cat. Providing restrictions to the user is probably the easiest, but not the only one. So, if I have duplicate SMFIDs I cannot effectively merge the type 70 and the type 89. Nowadays yes, at least when using SCRT. Also, there are many other products that require unique SMFIDs. Example: JES XMIT/RECEIVE. XMIT/RECEIVE is AFAIK tied to NJE nodename. It sometimes can be equal sysid, but need not to be and sometimes cannot be. Last, but not least: you don't need to have such facility in use, especially for all the systems you have. And, many disciplines, such as capacity planning. Example: type 30, type 110 do not have serial numbers, LPAR names, etc. Type 72, 74, etc don't have them either. So what? I don't see any relationship to 110 or 30. Do do a compare/merge we need a unique identifier, and the SMFID gives us one. I don't dispute the identifier itself or the need for it, I dispute the choice of the identifier. Without that uniqueness, all we would have is chaos, unless we have only one system. Even then, we would still be merging by SMFID. I assumed that you would have run into issues before with multiple systems using non-unique SMFIDs. SCRT is just a drop in the ocean. Bad assumption. No chaos, absolutely no issue because of duplicated sysids. SCRT is the only pain in the... -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: Speaking of SCRT
And, many disciplines, such as capacity planning. Example: type 30, type 110 do not have serial numbers, LPAR names, etc. Type 72, 74, etc don't have them either. So what? I don't see any relationship to 110 or 30. Then obviously you've never done Capacity Planning, Performance Management or Chargeback. Without going into details, a standard methodology of allocating CPU usage for planning purposes is merging type 70, 72, and 30 (interval). Only one of those has hardware details. Simply put, 70 gives me the detail of overall usage, 72 allows for the breakdown by workload (with capture ratios applied), and 30 allows me to determine which application within workload. Type 110 allows for a merging of CICS transactions (for this example), along with other details. 74 gives me the I/O component. With other records (I've only given a few examples), I can end up with a profile vector, of CPU, LPAR, Workload, application, I/O, and other details. Yes, you could re-write all the canned, homegrown, vendor, and other code to do something else. But, these tools all know about the existing SMFID and won't work without unique IDs. So, the choice is simple. Differing SMFIDs, and existing/working tools, chaos, or don't do Capacity Planning with SMF. As far as NJE is concerned, we used to get error messages whenever the SMFID of the sending system wasn't in a user table, and the acknowledgement wasn't able to be transmitted back. If this is still the case, which I don't know since I haven't seen it in years -- meaning people have been keeping it up to date or it's changed, then duplicate IDs would cause problems. I think that the fact there are other reasons for duplicate IDs negates the issue with SCRT. - Too busy driving to stop for gas! -- 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
