Re: Syslog missing (now: SCRT)
W dniu 2012-05-16 12:42, Elardus Engelbrecht pisze: [...] I changed sysid to meet SCRT requirements, otherwise SCRT cannot prepare correct report for the LPAR running this system. Yuck! Could you be kind to elaborate on this required change? I'm also using this SCRT toy every month. SCRT does require all systems to have uniques SYSID. This requirement is described in SCRT manual. SCRT is REALLY BAD product, I know several cases where it gives false results even if you fulfill all the requirement. SCRT does like: unique SYSIDs, *stable* SYSIDS (not changed during the reporting period). SCRT does not like: changing SYSIDs, SMF records out of the scope (i.e. from previous month) - I mean valid records PLUS older ones. SCRT hates: non-unique SYSIDs, or SMF70 with no SMF89 or vice versa - I mean scenario: you IPL system for 15 minutes, then you shut it down. It's unusual, but IMHO legal to start z/OS for short period of time. BTW: the requirement of uniques SYSIDs is simply STUPID. There is identifier which is really unique: LPAR name. From the other hand there are cases when you could need imple PiT copy, a CLONE of you z/OS system. You can clone everything except the SYSID. Reason: SCRT. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Syslog missing (now: SCRT)
R Skorupka wrote: SCRT does require all systems to have uniques SYSID. This requirement is described in SCRT manual. Oh yes, I now rereaded that part. Thanks for the reminder. SCRT is REALLY BAD product, I know several cases where it gives false results even if you fulfill all the requirement. Really bad? To add to your pain, look up the new paragraph 'Machine replacements and machine software model upgrades' and come back... SCRT does not like: changing SYSIDs, SMF records out of the scope (i.e. from previous month) - I mean valid records PLUS older ones. I hate it to add *NONE to each software product you're not using... but that is only me and my lazy typing... [1] :-/ BTW: the requirement of uniques SYSIDs is simply STUPID. There is identifier which is really unique: LPAR name. From the other hand there are cases when you could need imple PiT copy, a CLONE of you z/OS system. You can clone everything except the SYSID. Reason: SCRT. There must be a reason beside SCRT, but I'm too low in the food chain to challenge/question it... :-) Groete / Greetings Elardus Engelbrecht [1] - You just can't go on a C ALL '= ' '=*NONE' spree without breaking something ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Syslog missing (now: SCRT)
W dniu 2012-05-16 13:42, Elardus Engelbrecht pisze: [1] - You just can't go on a C ALL '= ' '=*NONE' spree without breaking something ... But you can split the job stream. I moved DD * content to separate members and DO NOT change them. Also the JCL itself is (almost) not changed. The only change is to replace object code. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Syslog missing (now: SCRT)
R Skorupka wrote: [1] - You just can't go on a C ALL '= ' '=*NONE' spree without breaking something ... But you can split the job stream. I moved DD * content to separate members and DO NOT change them. Also the JCL itself is (almost) not changed. The only change is to replace object code. Yes, you can do that good splitting work, but it is still a PITA to check all software (when using a new release of SCRT) to ensure you don't skip one. One can copy/sort all software numbers and then do a compare/editing in that DD *. Question for lazy ones: Is it possible [in the future] to feed SCRT a list of all IFAPRDxx members for all your LPARs, so no manual editing is needed? Or feed a list of RACF profiles in a new RACF class for all products used on what LPAR/machine? Then SCRT can just scan that class and apply it to your SMF recs? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Syslog missing (now: SCRT)
I moved the object code out of the job stream into a parmlib like PDS. My job scheduler was taking exception to the object code being in stream. The JCL changes have been uncommon and not hard to hand jive. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, May 16, 2012 6:57 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Syslog missing (now: SCRT) W dniu 2012-05-16 13:42, Elardus Engelbrecht pisze: [1] - You just can't go on a C ALL '= ' '=*NONE' spree without breaking something ... But you can split the job stream. I moved DD * content to separate members and DO NOT change them. Also the JCL itself is (almost) not changed. The only change is to replace object code. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Running a SYSPLEX - SCRT -what's needed
We collect the SMF70,89 records throughout the month and submit a Subcapacity Report each month based on MSU usage; we generally save a few dollars each month. We must report on all LPARS defined to our processor; in our case a production LPAR and a test LPAR. Our SCRT eligible products are: z/OS V1,5694-A01,33 CICS TS for z/OS V3,5655-M15,33 MQSeries for z/OS V6,5655-L82,33 IBM Enterprise Cobol for z/OS and OS/390 V3 In our installation parameters for SCRT Release 19.2 the following IMS products are eligible for SCRT: EDIT BDC2.SCRT.V19R2M0.NO89237 lines dele Command === Scroll === C ** * Top of Data ** 01 * IMS DATA COLLECTOR FOR WEBSPHERE STUDIO APPL MONITOR V3 02 * TIVOLI COMPOSITE APPLICATION MANAGER FOR IMS V6 ** Bottom of Data Suggest install the current SCRTool, collect the data over a month and see what you get... If the rolling average for MSU utilization in a given month is lower than the licensed capacity of your processor you may save a few dollars each month... -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of JT Sent: Thursday, May 19, 2011 5:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Running a SYSPLEX - what's needed Thanks for all the responses here and offline. Here are some answers to questions about our environment: - The 2096-T01 is our only processor. We are running z/OS 1.11. - We do not currently use sub-capacity processing. We do not submit monthly SCRT reports. - The T01 runs at 100% every night for 10 hours. - The IMS address space and MPRs are up from 6AM-8PM daily. These address spaces average LT 3% utilization during this time. The peak for a 30 minute interval is almost always under 5%. - There is a small amount batch IMS during the nightly cycle (after 8PM). - We run IMS TM/DM. Some IMS TM also use DB2. - We currently use CA-MIM when the TECH LPAR is up - not GRS. - IMS DM and TM are currently under EWLC pricing. The main IMS application is critical to our business. It is not scheduled to be replaced for at least 5 years. Several folks commented off-line that if we only use a single CEC there is no possibility of savings. Planning for Sub-capacity Pricing on z/OS indicates the sub-capacity pricing metric operates at the LPAR level. I did not see anything about CEC limitations. Did I miss something? Are there any small shops out there that have been successful at controlling IMS costs by creating a separate 'IMS LPAR'? Thanks for the responses. -- 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: Running a SYSPLEX - SCRT -what's needed
On Thu, 19 May 2011 09:04:17 -0700, Donnelly, John P john.p.donne...@nsc.com wrote: We collect the SMF70,89 records throughout the month and submit a Subcapacity Report each month based on MSU usage; we generally save a few dollars each month. We must report on all LPARS defined to our processor; in our case a production LPAR and a test LPAR. What are people doing for sandbox LPARs? Ones that may be up and down and may not even have tape or automated processes for collecting and storing SMF data. Most of the sandbox LPARs I have worked on in the past have SMFDUMPs going to DD DUMMY. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: Running a SYSPLEX - SCRT -what's needed
Hey Mark, We have a fairly sizable plex and I try to report on as many as I can...some of the sandbox stuff falls outside the plex. I've run the plex, MULC and SCRT reports and am always told to include everything that I possibly can. So typically I have a handful of sandbox LPAR's that have either partial or no data and I include what I can... --- On Thu, 5/19/11, Mark Zelden m...@mzelden.com wrote: From: Mark Zelden m...@mzelden.com Subject: Re: Running a SYSPLEX - SCRT -what's needed To: IBM-MAIN@bama.ua.edu Date: Thursday, May 19, 2011, 4:35 PM On Thu, 19 May 2011 09:04:17 -0700, Donnelly, John P john.p.donne...@nsc.com wrote: We collect the SMF70,89 records throughout the month and submit a Subcapacity Report each month based on MSU usage; we generally save a few dollars each month. We must report on all LPARS defined to our processor; in our case a production LPAR and a test LPAR. What are people doing for sandbox LPARs? Ones that may be up and down and may not even have tape or automated processes for collecting and storing SMF data. Most of the sandbox LPARs I have worked on in the past have SMFDUMPs going to DD DUMMY. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: Running a SYSPLEX - SCRT -what's needed
On Thursday, May 19, 2011 11:36 AM, Mark Zelden wrote: What are people doing for sandbox LPARs? Ones that may be up and down and may not even have tape or automated processes for collecting and storing SMF data. Most of the sandbox LPARs I have worked on in the past have SMFDUMPs going to DD DUMMY. When submitting the SCRT, there is a place to explain underreporting. So, we write a note stating that the Test LPAR was only up for x number of hours for testing the new release of whatever we're testing - or whatever is appropriate for that month's reporting. Greg Shirey Ben E. Keith Company -- 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: SCRT Copy List
Not everyone can do that. We wanted to use the email option, but IBM won't authorize us to use that path.. I believe that IBM once said that they really don't want customers automating the process. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dave Kopischke Sent: Wednesday, June 09, 2010 6:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SCRT Copy List On Fri, 4 Jun 2010 10:36:35 -0400, Ken Porowski ken.porow...@cit.com wrote: Somewhere on the SCRT website they state that the email list cannot be saved for future use. I just get the copy sent to me an forward it. Instead of uploading the report using the website, E-Mail it to them. That way you can script the whole thing. I create the CSV file and E-Mail it to myself. If it looks good, I update the JOB to point to a different E-Mail header file and rerun the E-Mail step. This sends it to IBM with the AUTO tag and our VAR who likes to keep track of it and to my boss and a whole list of others NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SCRT Copy List
I think you're right about IBM not wanting customers to *completely* automate the submission process, but Dave did not suggest that - he said he runs the SCRT program and emails the result to himself so he can check it. We do that here as well, but where our process differs from Dave's is that we simply forward the CSV file on to IBM if it is correct, rather than rerun the job with a different email ID. (But since he's CC'ing others, I understand why he does it..) I'm curious about your statement that IBM would not authorize your shop to email your SCRT output. Their website seems to indicate that it is up to the customer. From http://www-03.ibm.com/systems/z/resources/swprice/subcap/scrt/submit.htm l Unless you have been informed otherwise, all Sub-Capacity customers in countries where the License Management Support (LMS) application has been implemented must use LMS to submit your subcapacity reports to IBM. You may choose either of the following methods to send your subcapacity report to LMS: * LMS Web to upload and submit your subcapacity report using the LMS Web interface. * LMS eMail to send your subcapacity report to LMS as an e-mail attachment. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List On Behalf Of Hal Merritt Sent: Thursday, June 10, 2010 8:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SCRT Copy List Not everyone can do that. We wanted to use the email option, but IBM won't authorize us to use that path.. I believe that IBM once said that they really don't want customers automating the process. -- 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: SCRT Copy List
IIRC, we were using email but were told he had to convert to the interactive web submission. We did. Later, we applied to use the email again to have a way to submit when the web process failed. That was long ago, but we have heard nothing to date. OBTW, we also email the CSV to ourselves for vetting and approval. We used to simply forward the email, but now someone has to intervene. Not a big deal, just annoying and an opportunity for error. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Greg Shirey Sent: Thursday, June 10, 2010 9:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SCRT Copy List I think you're right about IBM not wanting customers to *completely* automate the submission process, but Dave did not suggest that - he said he runs the SCRT program and emails the result to himself so he can check it. We do that here as well, but where our process differs from Dave's is that we simply forward the CSV file on to IBM if it is correct, rather than rerun the job with a different email ID. (But since he's CC'ing others, I understand why he does it..) I'm curious about your statement that IBM would not authorize your shop to email your SCRT output. Their website seems to indicate that it is up to the customer. From http://www-03.ibm.com/systems/z/resources/swprice/subcap/scrt/submit.htm l Unless you have been informed otherwise, all Sub-Capacity customers in countries where the License Management Support (LMS) application has been implemented must use LMS to submit your subcapacity reports to IBM. You may choose either of the following methods to send your subcapacity report to LMS: * LMS Web to upload and submit your subcapacity report using the LMS Web interface. * LMS eMail to send your subcapacity report to LMS as an e-mail attachment. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List On Behalf Of Hal Merritt Sent: Thursday, June 10, 2010 8:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SCRT Copy List Not everyone can do that. We wanted to use the email option, but IBM won't authorize us to use that path.. I believe that IBM once said that they really don't want customers automating the process. -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SCRT Copy List
On Fri, 4 Jun 2010 10:36:35 -0400, Ken Porowski ken.porow...@cit.com wrote: Somewhere on the SCRT website they state that the email list cannot be saved for future use. I just get the copy sent to me an forward it. Instead of uploading the report using the website, E-Mail it to them. That way you can script the whole thing. I create the CSV file and E-Mail it to myself. If it looks good, I update the JOB to point to a different E-Mail header file and rerun the E-Mail step. This sends it to IBM with the AUTO tag and our VAR who likes to keep track of it and to my boss and a whole list of others -- 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: SCRT Copy List
Hi Tom, Your email support folks could set up a distribution list for you, with all of the entires you need. HTH, Linda - Original Message - From: Tom Kelman thomas.kel...@commercebank.com To: IBM-MAIN@bama.ua.edu Sent: Thursday, June 3, 2010 8:43:37 AM GMT -08:00 US/Canada Pacific Subject: SCRT Copy List I was wondering if anyone has tried to save a list of name to copy when the SCRT reports are sent to IBM. There is a spot where you can enter email addresses to receive a copy of the confirmation. I have to enter 7 addresses every time. Four of them are to managers in my company and three more are to OEM companies that we have sub-capacity pricing contracts with. While it isn't a lot of addresses, it is a hassle to have to enter them every time and make sure they are correct. Does anyone know of a way to save this list so it can just be recalled each time the SCRT report is sent in. * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: SCRT Copy List
Somewhere on the SCRT website they state that the email list cannot be saved for future use. I just get the copy sent to me an forward it. -Original Message- Kelman, Tom I was wondering if anyone has tried to save a list of name to copy when the SCRT reports are sent to IBM. There is a spot where you can enter email addresses to receive a copy of the confirmation. I have to enter 7 addresses every time. Four of them are to managers in my company and three more are to OEM companies that we have sub-capacity pricing contracts with. While it isn't a lot of addresses, it is a hassle to have to enter them every time and make sure they are correct. Does anyone know of a way to save this list so it can just be recalled each time the SCRT report is sent in. -- 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
SCRT Copy List
I was wondering if anyone has tried to save a list of name to copy when the SCRT reports are sent to IBM. There is a spot where you can enter email addresses to receive a copy of the confirmation. I have to enter 7 addresses every time. Four of them are to managers in my company and three more are to OEM companies that we have sub-capacity pricing contracts with. While it isn't a lot of addresses, it is a hassle to have to enter them every time and make sure they are correct. Does anyone know of a way to save this list so it can just be recalled each time the SCRT report is sent in. * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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
SCRT having trouble
Anyone else having trouble with the SCRT data submission website? Ken Porowski VP Mainframe Administration CIT Group -- 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: SCRT having trouble
I just submitte4d our stuff successfully - 13:00 CDT -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ken Porowski Sent: Wednesday, June 02, 2010 11:29 To: IBM-MAIN@bama.ua.edu Subject: SCRT having trouble Anyone else having trouble with the SCRT data submission website? Ken Porowski VP Mainframe Administration CIT Group -- 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: SCRT having trouble - OK now
Seems like it was hung for a little while, all appears OK now. -Original Message- Porowski, Ken Anyone else having trouble with the SCRT data submission website? -- 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: SCRT having trouble
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Ken Porowski Anyone else having trouble with the SCRT data submission website? The colleague who submitted ours at about 0800 CST this morning said that the website indicated it was processing, but so far we've not received the customary acknowledgement email. -jc- -- 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 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
SCRT Delivery
Hi, Today I received notification of a new version of SCRT. It would be a lot simpler (at least for me) if SCRT was distributed as a load module. Having the object embedded in JCL is a point a failure. It’s just too easy to make changes by mistake. I would really like SCRT to be distributed as part of the operating system and be updated by PTF. I sent this message to s...@us.ibm.commailto:s...@us.ibm.com, but I want to get the message out through this list as well. Gadi לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. -- 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: SCRT Delivery
It would be a lot simpler (at least for me) if SCRT was distributed as a load module. Having the object embedded in JCL is a point a failure. I agree. It’s just too easy to make changes by mistake. What we ended up doing was moving the job to production which had a standard of no instream data. So, we would manually separate the object module, and the parameter file into external datasets. It's still an error-prone procedure, but it's the best we couls do. - 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: SCRT Delivery
Gadi, I raised this issue over five years ago. I do not remember the exact reason they gave me, but I do remember thinking it was a wee bit lame. However, consider the process. They notify us weeks in advance that we need to download a new version of the tool. The new version is available from the internet, it has the object changes *and* sample NO89 entries embedded within it. That last part is just as important as the object portion as they provide the correct product IDs for us to use when running the report. I don't know about you, but as often as this product changes, it would make it a SMP/E nightmare for delivery unless everyone is already using internet delivery, which I am positive *everyone* is not. Finally, submitting SCRT is elective. Granted, you won't like your software bill if you don't submit the reports, but they make the rules. By playing the game, you agreed to use their bats, balls and playing field (to use a baseball analogy). I wish I could be more encouraging, but as I said, I raised this point a long time ago and have seen no movement on changing the process since then. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of gad...@malam.com Sent: Monday, April 12, 2010 2:53 AM To: IBM-MAIN@bama.ua.edu Subject: SCRT Delivery Hi, Today I received notification of a new version of SCRT. It would be a lot simpler (at least for me) if SCRT was distributed as a load module. Having the object embedded in JCL is a point a failure. It’s just too easy to make changes by mistake. I would really like SCRT to be distributed as part of the operating system and be updated by PTF. I sent this message to s...@us.ibm.commailto:s...@us.ibm.com, but I want to get the message out through this list as well. Gadi לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. -- 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: SCRT Delivery
Hi Bob, I just hope I will get a reply. Maybe someone there will think that changing the ball (or is it the bat), makes sense. 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 1:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SCRT Delivery Gadi, I raised this issue over five years ago. I do not remember the exact reason they gave me, but I do remember thinking it was a wee bit lame. However, consider the process. They notify us weeks in advance that we need to download a new version of the tool. The new version is available from the internet, it has the object changes *and* sample NO89 entries embedded within it. That last part is just as important as the object portion as they provide the correct product IDs for us to use when running the report. I don't know about you, but as often as this product changes, it would make it a SMP/E nightmare for delivery unless everyone is already using internet delivery, which I am positive *everyone* is not. Finally, submitting SCRT is elective. Granted, you won't like your software bill if you don't submit the reports, but they make the rules. By playing the game, you agreed to use their bats, balls and playing field (to use a baseball analogy). I wish I could be more encouraging, but as I said, I raised this point a long time ago and have seen no movement on changing the process since then. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of gad...@malam.com Sent: Monday, April 12, 2010 2:53 AM To: IBM-MAIN@bama.ua.edu Subject: SCRT Delivery Hi, Today I received notification of a new version of SCRT. It would be a lot simpler (at least for me) if SCRT was distributed as a load module. Having the object embedded in JCL is a point a failure. It’s just too easy to make changes by mistake. I would really like SCRT to be distributed as part of the operating system and be updated by PTF. I sent this message to s...@us.ibm.commailto:s...@us.ibm.com, but I want to get the message out through this list as well. Gadi לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. -- 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
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: SCRT Delivery
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of ??? ?? ??? Sent: Monday, April 12, 2010 1:53 AM To: IBM-MAIN@bama.ua.edu Subject: SCRT Delivery Hi, Today I received notification of a new version of SCRT. It would be a lot simpler (at least for me) if SCRT was distributed as a load module. Having the object embedded in JCL is a point a failure. It's just too easy to make changes by mistake. I would really like SCRT to be distributed as part of the operating system and be updated by PTF. I sent this message to s...@us.ibm.commailto:s...@us.ibm.com, but I want to get the message out through this list as well. Gadi Oh, my. If that were done, I'd be forced to update SCRT via a change request. Around here, that is a royal pain. It is much simplier, for me, to replace the JCL with a change notification (JCL changes are easier to make than installing a z/OS related PTF). If you want, you should be able to just link the given object code into a load library using IEWL with your own JCL. Or even make up your own USERMOD, if you really need to. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: SCRT Delivery
On Mon, 12 Apr 2010 07:06:20 +, Ted MacNEIL wrote: It would be a lot simpler (at least for me) if SCRT was distributed as a load module. Having the object embedded in JCL is a point a failure. I agree. Its just too easy to make changes by mistake. What we ended up doing was moving the job to production which had a standard of no instream data. I guess I see the rationale for the rule. So, we would manually separate the object module, and the parameter file into external datasets. But, does adding a processing step lessen the likelihood of error? It's still an error-prone procedure, but it's the best we couls do. Does IBM suppy a checksum for this thing? It's easy enough to verify a checksum with: cp -B //'JCL.DATA.SET(MEMBER' /dev/fd/0 | cksum and to use SuperC to verify that changes are made only in the JCL or by removing the JCL. -- 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: SCRT Delivery
I agree with John. Since I, as the performance analyst/capacity planner here, am responsible for sub-capacity pricing processes, I can easily install SCRT into libraries that I control. Since it has no affect on external customers, I don't have to go through heavy duty change control. If it were a part of the OS then I'd have to rely on system programmers and their schedule to get it installed. I have nothing against system programmers mind you. I was one once. It's just that they have other fish to fry, and the SCRT is updated more often then the OS. Also, if it is a new version, as opposed to a new release, you have to use it for the next report submission, and you usually have about 2-3 weeks to get it installed. If I had to go through a full change control process to get it in I probably couldn't get it installed in time. With the way I put it in currently, I can get it installed in a day if I need to. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, April 12, 2010 7:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SCRT Delivery -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of ??? ?? ??? Sent: Monday, April 12, 2010 1:53 AM To: IBM-MAIN@bama.ua.edu Subject: SCRT Delivery Hi, Today I received notification of a new version of SCRT. It would be a lot simpler (at least for me) if SCRT was distributed as a load module. Having the object embedded in JCL is a point a failure. It's just too easy to make changes by mistake. I would really like SCRT to be distributed as part of the operating system and be updated by PTF. I sent this message to s...@us.ibm.commailto:s...@us.ibm.com, but I want to get the message out through this list as well. Gadi Oh, my. If that were done, I'd be forced to update SCRT via a change request. Around here, that is a royal pain. It is much simplier, for me, to replace the JCL with a change notification (JCL changes are easier to make than installing a z/OS related PTF). If you want, you should be able to just link the given object code into a load library using IEWL with your own JCL. Or even make up your own USERMOD, if you really need to. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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
Re: z/OS SCRT NO89 Product Information
All literature about SCRT is posted on IBM pricing website, Al website and other doc issued from CMG as Italia from Ottaviani. Sure, a strong reporting monthly revised by using Al tools or others will be powerfull to adapt SCRT parameter's and to control well this process. A second way is to apply a relevant capacity palnning quaterly revised by integrating WLC a PSLC inside. More than Capacity Planner job is to add a new activity as Cost Planner to define the best plan. this approach will define a capacity cost planning by optimizing the sharing resources with a perfect design PR/SM. A next step could be to control WLC by using SoftCapping, Group Capcity Limit feature or our offer with AutoSoftCapping: a zCost Management product. Jacky Hofbauer - zCost Management - voice: +33240854810 - web: www.zcostmanagement.com - i...@zcostmanagement.com There are risks and costs to a program of action, but they are far less than the long-range risks and costs of comfortable inaction. John F. Kennedy -- 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: z/OS SCRT NO89 Product Information
Let me clarify one thing about the ugly suggestion that I made to Patrick. There is a big difference between running the SCRT JCL to get a report and then ACTUALLY SUBMITTING IT. Having never tried it as I said, I did not know what would be produced. I never intended that Patrick actually *submit* a SCRT report that was run using *ALL for all his products. As for Al's comments below about the TsCs, I can assure you that IBM does indeed treat detected, but unlicensed, products as an order. Bob - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: robert.richa...@opm.gov - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Al Sherkow Sent: Thursday, July 30, 2009 12:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information I believe the fine print TsCs indicate that if you specify that a product runs on one LPAR or any LPARs of a machine for which it is not licensed that IBM may view that as an order for the products. Similarly, for products that do generate SMF89 data, if SCRT detects a product on a machine where it is not licensed, that is an order for the product. You can correct this after the fact, but it's better to read the reports and be sure they are what you expect. (LCS highlights the discovery of products running where they are not expected to be running based on your licenses and/or history of product usage). This is the basis of Pat's original question. You are supposed to setup the NO89 parameters to reflect in which LPARs you actually use the NO89 products. This is why LCS detects this, to help sites properly report their usage to IBM. Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- 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: z/OS SCRT NO89 Product Information
Bob, I understood what you meant. I was basically trying to get a feel for what the different options implied, *none, *all, qualifying LPARs. My intention all along has been to get this right. There's potentially too much at stake here to get it wrong given the number of machines and LPARs. I've got to the point where I now know what machines and now what LPARs have the NO89 software and am preparing to turn this loose on our environment. And I've taken Mark's suggestion to ensure I'm using the Hardware LPAR name with regards to the qualifying products and their relative LPARs. As it turned out I did not take as many hits on the NO89's as I thought I might to a point that it is somewhat manageable but that's kind of a relative term. I'll give you a call. --- On Thu, 7/30/09, Richards, Robert B. robert.richa...@opm.gov wrote: From: Richards, Robert B. robert.richa...@opm.gov Subject: Re: z/OS SCRT NO89 Product Information To: IBM-MAIN@bama.ua.edu Date: Thursday, July 30, 2009, 10:43 AM Let me clarify one thing about the ugly suggestion that I made to Patrick. There is a big difference between running the SCRT JCL to get a report and then ACTUALLY SUBMITTING IT. Having never tried it as I said, I did not know what would be produced. I never intended that Patrick actually *submit* a SCRT report that was run using *ALL for all his products. As for Al's comments below about the TsCs, I can assure you that IBM does indeed treat detected, but unlicensed, products as an order. Bob - Robert B. Richards (Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: robert.richa...@opm.gov - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Al Sherkow Sent: Thursday, July 30, 2009 12:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information I believe the fine print TsCs indicate that if you specify that a product runs on one LPAR or any LPARs of a machine for which it is not licensed that IBM may view that as an order for the products. Similarly, for products that do generate SMF89 data, if SCRT detects a product on a machine where it is not licensed, that is an order for the product. You can correct this after the fact, but it's better to read the reports and be sure they are what you expect. (LCS highlights the discovery of products running where they are not expected to be running based on your licenses and/or history of product usage). This is the basis of Pat's original question. You are supposed to setup the NO89 parameters to reflect in which LPARs you actually use the NO89 products. This is why LCS detects this, to help sites properly report their usage to IBM. Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- 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: z/OS SCRT NO89 Product Information
With respect, don't go there. I have -no- complaints about working with IBM, but it is a s-l-o-w, time consuming process. IMHO it is well worth the effort to get it right. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joel Wolpert Sent: Wednesday, July 29, 2009 6:19 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information Correction: IBM is supposed to know what products you have. But even if you have *ALL for NO89 products that you do NOT have licenses to you can work with IBM to correct the billing. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS SCRT NO89 Product Information
Pat, A VERY ugly suggestion. Turn them all on with *ALL* and see what does not report anything. By the way, I have never tried this suggestion so I am not sure it is of any value except what you are paying me for it. Or, get Al's software. :-) Bob - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Falcone Sent: Tuesday, July 28, 2009 3:38 PM To: IBM-MAIN@bama.ua.edu Subject: z/OS SCRT NO89 Product Information I'm currently working with/on SCRT for quite a few physical machines and about triple the amount of LPARs. Is there any easy way for me to find out what products might be on what LPARs for inclusion in the NO89 section? I've got the process working fine but now need to tailor the NO89 section for validity. Or do I just need to read the fine book some more. Al, help!? -- 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: z/OS SCRT NO89 Product Information
Hey Bob, Hope all's well. Well, I actually thought about that, just coding *all, and will probably try it to see what happens. I'm currently running with *none for everything while I shake it out for all the machines and LPAR's. I gotta get with the billing guy and my boss to see how they want to handle this part. Nothings easy, especially when you have a large number of LPAR's to deal with. Al's great and has helped in the past but I doubt that we'll buy more software. I already checked and we don't have SoftAudit or whatever Mark suggested, IBM's re-branded name. So I'll probably be flying by the seat of my pants. Hope the landing isn't too bad. Thanks for your input. --- On Wed, 7/29/09, Richards, Robert B. robert.richa...@opm.gov wrote: From: Richards, Robert B. robert.richa...@opm.gov Subject: Re: z/OS SCRT NO89 Product Information To: IBM-MAIN@bama.ua.edu Date: Wednesday, July 29, 2009, 12:51 PM Pat, A VERY ugly suggestion. Turn them all on with *ALL* and see what does not report anything. By the way, I have never tried this suggestion so I am not sure it is of any value except what you are paying me for it. Or, get Al's software. :-) Bob - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Falcone Sent: Tuesday, July 28, 2009 3:38 PM To: IBM-MAIN@bama.ua.edu Subject: z/OS SCRT NO89 Product Information I'm currently working with/on SCRT for quite a few physical machines and about triple the amount of LPARs. Is there any easy way for me to find out what products might be on what LPARs for inclusion in the NO89 section? I've got the process working fine but now need to tailor the NO89 section for validity. Or do I just need to read the fine book some more. Al, help!? -- 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: z/OS SCRT NO89 Product Information
I can't resist jumping in here. Especially since the Patrick included Al, help!? in his original post. I think it's true as Mark wrote that Tivoli License Compliance Manager can help with this task. But in the US that's $2000 per MSU for the OTC alone with the VUE007 conversion table. TLCM will do a lot of things LCS does not attempt to do but LCS is what you need to audit, manage and optimize for SCRT. LPAR Capacity and Software Usage Analysis (LCS) Software is only $15,000/site. With TLCM $15,000 would only license 7.5 value units, only 15 MSUs of capacity. (Patrick also wrote quite a few physical machines and about triple the amount of LPARs so 15 MSUs probably isn't enough). The ROI on LCS is often achieved with next month's SCRT report. How many products can claim a one month ROI! LCS will identify the NO89s that typically not used in every LPAR like COBOL, PL/I. LCS will even generate the NO89 control cards for you. Read more at my website. Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- 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: z/OS SCRT NO89 Product Information
Setting the NO89s to *ALL will just indicate to SCRT that you are running those products in every LPAR on every machine. Probably true for products like NetView, IBM's System Automation and their Scheduler. Lots of products once you commit to using them you need to run them everywhere. But for COBOL, PL/I and development/testing products that may not be true. I don't think you'll learn anything by trying *ALL. Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- 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: z/OS SCRT NO89 Product Information
LOL! Well I did say that I had not tried it! And I did steer him to your product! You beat me to the punch with your comments about TLCM (SoftAudit). Unless it has changed drastically in the last few years, it does nothing for SCRT except let you know if a product was executing or not. Pat, I cannot recommend LCS strongly enough to people responsible for SCRT. When I was at SunTrust, the product paid for itself ten times over *every* year. Ask me what IBM has used in the past to audit SCRT? :-) Ask me if IBM *ever* challenged a submission of mine and I adjusted some values EVERY month for five years. Bob - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: robert.richa...@opm.gov - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Al Sherkow Digest Sent: Wednesday, July 29, 2009 9:49 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information Setting the NO89s to *ALL will just indicate to SCRT that you are running those products in every LPAR on every machine. Probably true for products like NetView, IBM's System Automation and their Scheduler. Lots of products once you commit to using them you need to run them everywhere. But for COBOL, PL/I and development/testing products that may not be true. I don't think you'll learn anything by trying *ALL. Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- 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: z/OS SCRT NO89 Product Information
On Wed, 29 Jul 2009 08:49:27 -0500, Al Sherkow Digest a...@sherkow.com wrote: Setting the NO89s to *ALL will just indicate to SCRT that you are running those products in every LPAR on every machine. Exactly. IBM will be very very happy if you send them that report! Your management won't be when they get the bill. Probably true for products like NetView, Not any more here. We got rid of it to save money on all LPARs except the ones the VTAM group said they absolutely had to have it on. IBM's System Automation and their Scheduler. Lots of products once you commit to using them you need to run them everywhere. But for COBOL, PL/I and development/testing products that may not be true. I don't think you'll learn anything by trying *ALL. NO89 reporting is the honor system. So you have to know where things run. Tools like Softaudit / TCLM and Al's software can help. Unfortunately our guy that used to run SCRT never understood how it really worked. He would wait to see usage from softaudit and then add NO89 records for those. He also had the wrong LPAR names in the NO89. He was using SMF SYSID / SYSNAME instead of the HW LPAR name. In matched in some cases, in others it doesn't. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: z/OS SCRT NO89 Product Information
That's not how it works. The NO89 covers products that do not cut SMF type 89 usage records. You are already paying for licensed products at full capacity. If you know you are not running a given product on LPARX, then include all of the others. Even if you are running it everywhere, you can still achieve sizable savings or, perhaps more importantly, make a good business case for a much bigger box you can grow into instead of a too small box you grow out of. You may not see any savings if your box is too small. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Wednesday, July 29, 2009 7:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information Pat, A VERY ugly suggestion. Turn them all on with *ALL* and see what does not report anything. By the way, I have never tried this suggestion so I am not sure it is of any value except what you are paying me for it. Or, get Al's software. :-) Bob - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Falcone Sent: Tuesday, July 28, 2009 3:38 PM To: IBM-MAIN@bama.ua.edu Subject: z/OS SCRT NO89 Product Information I'm currently working with/on SCRT for quite a few physical machines and about triple the amount of LPARs. Is there any easy way for me to find out what products might be on what LPARs for inclusion in the NO89 section? I've got the process working fine but now need to tailor the NO89 section for validity. Or do I just need to read the fine book some more. Al, help!? -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS SCRT NO89 Product Information
Thanks for all your input. You'll have to excuse my ignorance with this stuff since my main charge is tuning and I just started to read the manual, like yesterday. OK, if I have this right and I code *all for the NO89 products it may be possible to be billed additionally if that's possible. If I code *none for NO89 products we may not be able to take advantage of where the software is running to get additional SubCapacity savings. And if I code the LPARs where the NO89 products run this might/would be factored into potential SubCapacity savings. My plan is to get this right and so I will be including LPAR's that are part of the NO89 hit list but wanted to understand what the options actually mean from a savings viewpoint. Again, appreciate all your input (and you to Al - thanks) --- On Wed, 7/29/09, Hal Merritt hmerr...@jackhenry.com wrote: From: Hal Merritt hmerr...@jackhenry.com Subject: Re: z/OS SCRT NO89 Product Information To: IBM-MAIN@bama.ua.edu Date: Wednesday, July 29, 2009, 3:11 PM That's not how it works. The NO89 covers products that do not cut SMF type 89 usage records. You are already paying for licensed products at full capacity. If you know you are not running a given product on LPARX, then include all of the others. Even if you are running it everywhere, you can still achieve sizable savings or, perhaps more importantly, make a good business case for a much bigger box you can grow into instead of a too small box you grow out of. You may not see any savings if your box is too small. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Wednesday, July 29, 2009 7:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information Pat, A VERY ugly suggestion. Turn them all on with *ALL* and see what does not report anything. By the way, I have never tried this suggestion so I am not sure it is of any value except what you are paying me for it. Or, get Al's software. :-) Bob - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Falcone Sent: Tuesday, July 28, 2009 3:38 PM To: IBM-MAIN@bama.ua.edu Subject: z/OS SCRT NO89 Product Information I'm currently working with/on SCRT for quite a few physical machines and about triple the amount of LPARs. Is there any easy way for me to find out what products might be on what LPARs for inclusion in the NO89 section? I've got the process working fine but now need to tailor the NO89 section for validity. Or do I just need to read the fine book some more. Al, help!? -- 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: z/OS SCRT NO89 Product Information
Pat, As far as coding *ALL for NO89 products that you do NOT have licenses to, I can't tell for certain, but I wouldn't do that. You might or might not get billed for these products, or you might get a call from your friendly IBM sales rep thanking you for licensing it all! :-) As far as coding *ALL for NO89 products that you DO have licenses for, you will be billed for the total SCRT usage on the boxes, regardless of how much you actually use the products. As others have stated, NO89 means that IBM doesn't cut SMF records to tell them how much is actually being used, so they bill for the products based on the system utilization. As far as coding *NONE for products you are using, IBM frowns on that, because you're telling them that you aren't using the software. If you're not actually using it, drop the licenses to the product(s) and save the money. If you are using the products but telling IBM you aren't, that's being dishonest. As far as giving IBM a list of LPARs you actually are running software on instead of *ALL, you can save money by not being billed for the software on LPARs you aren't running the software on. In my case, I have 3 LPARs, 1 production a test, and a sandbox. I only have 1 product that is in the NO89 list, COBOL. I don't use this on my sandbox (named MVSTECH), so my entry for this is: 5655-G53=MVSPROD,MVSTEST When I get my SCRT report and subsequent bill, I don't get invoiced for the 1 MSU that typically shows up on the sandbox. On the other LPARs, even though COBOL is used very little, I get billed for the MSUs that the LPARs consume, not that COBOL consumes. HTH Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Falcone Sent: Wednesday, July 29, 2009 1:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information Thanks for all your input. You'll have to excuse my ignorance with this stuff since my main charge is tuning and I just started to read the manual, like yesterday. OK, if I have this right and I code *all for the NO89 products it may be possible to be billed additionally if that's possible. If I code *none for NO89 products we may not be able to take advantage of where the software is running to get additional SubCapacity savings. And if I code the LPARs where the NO89 products run this might/would be factored into potential SubCapacity savings. My plan is to get this right and so I will be including LPAR's that are part of the NO89 hit list but wanted to understand what the options actually mean from a savings viewpoint. Again, appreciate all your input (and you to Al - thanks) --- On Wed, 7/29/09, Hal Merritt hmerr...@jackhenry.com wrote: From: Hal Merritt hmerr...@jackhenry.com Subject: Re: z/OS SCRT NO89 Product Information To: IBM-MAIN@bama.ua.edu Date: Wednesday, July 29, 2009, 3:11 PM That's not how it works. The NO89 covers products that do not cut SMF type 89 usage records. You are already paying for licensed products at full capacity. If you know you are not running a given product on LPARX, then include all of the others. Even if you are running it everywhere, you can still achieve sizable savings or, perhaps more importantly, make a good business case for a much bigger box you can grow into instead of a too small box you grow out of. You may not see any savings if your box is too small. -- 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: z/OS SCRT NO89 Product Information
Rex, Thanks for the information, it's becoming clearer. I was basically trying to understand the options and implications. And I surely don't want to mislead IBM with this information. At this point I know what software runs on what machines but I'll need to figure out by machine what LPAR's are running the NO89 software that I get hits on. I certainly have a firmer handle on this than I did at this time yesterday. Thanks again for all your input. --- On Wed, 7/29/09, Pommier, Rex R. rex.pomm...@cnasurety.com wrote: From: Pommier, Rex R. rex.pomm...@cnasurety.com Subject: Re: z/OS SCRT NO89 Product Information To: IBM-MAIN@bama.ua.edu Date: Wednesday, July 29, 2009, 6:38 PM Pat, As far as coding *ALL for NO89 products that you do NOT have licenses to, I can't tell for certain, but I wouldn't do that. You might or might not get billed for these products, or you might get a call from your friendly IBM sales rep thanking you for licensing it all! :-) As far as coding *ALL for NO89 products that you DO have licenses for, you will be billed for the total SCRT usage on the boxes, regardless of how much you actually use the products. As others have stated, NO89 means that IBM doesn't cut SMF records to tell them how much is actually being used, so they bill for the products based on the system utilization. As far as coding *NONE for products you are using, IBM frowns on that, because you're telling them that you aren't using the software. If you're not actually using it, drop the licenses to the product(s) and save the money. If you are using the products but telling IBM you aren't, that's being dishonest. As far as giving IBM a list of LPARs you actually are running software on instead of *ALL, you can save money by not being billed for the software on LPARs you aren't running the software on. In my case, I have 3 LPARs, 1 production a test, and a sandbox. I only have 1 product that is in the NO89 list, COBOL. I don't use this on my sandbox (named MVSTECH), so my entry for this is: 5655-G53=MVSPROD,MVSTEST When I get my SCRT report and subsequent bill, I don't get invoiced for the 1 MSU that typically shows up on the sandbox. On the other LPARs, even though COBOL is used very little, I get billed for the MSUs that the LPARs consume, not that COBOL consumes. HTH Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Falcone Sent: Wednesday, July 29, 2009 1:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information Thanks for all your input. You'll have to excuse my ignorance with this stuff since my main charge is tuning and I just started to read the manual, like yesterday. OK, if I have this right and I code *all for the NO89 products it may be possible to be billed additionally if that's possible. If I code *none for NO89 products we may not be able to take advantage of where the software is running to get additional SubCapacity savings. And if I code the LPARs where the NO89 products run this might/would be factored into potential SubCapacity savings. My plan is to get this right and so I will be including LPAR's that are part of the NO89 hit list but wanted to understand what the options actually mean from a savings viewpoint. Again, appreciate all your input (and you to Al - thanks) -- 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: z/OS SCRT NO89 Product Information
See below; HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Falcone Sent: Wednesday, July 29, 2009 1:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information Thanks for all your input. You'll have to excuse my ignorance with this stuff since my main charge is tuning and I just started to read the manual, like yesterday. OK, if I have this right and I code *all for the NO89 products it may be possible to be billed additionally if that's possible. Yes, if you weren't licensed for that product on that box. If I code *none for NO89 products we may not be able to take advantage of where the software is running to get additional SubCapacity savings. Correct. You will continue to pay based on the box size. And if I code the LPARs where the NO89 products run this might/would be factored into potential SubCapacity savings. Correct. My plan is to get this right and so I will be including LPAR's that are part of the NO89 hit list but wanted to understand what the options actually mean from a savings viewpoint. Again, appreciate all your input (and you to Al - thanks) --- On Wed, 7/29/09, Hal Merritt hmerr...@jackhenry.com wrote: From: Hal Merritt hmerr...@jackhenry.com Subject: Re: z/OS SCRT NO89 Product Information To: IBM-MAIN@bama.ua.edu Date: Wednesday, July 29, 2009, 3:11 PM That's not how it works. The NO89 covers products that do not cut SMF type 89 usage records. You are already paying for licensed products at full capacity. If you know you are not running a given product on LPARX, then include all of the others. Even if you are running it everywhere, you can still achieve sizable savings or, perhaps more importantly, make a good business case for a much bigger box you can grow into instead of a too small box you grow out of. You may not see any savings if your box is too small. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Wednesday, July 29, 2009 7:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information Pat, A VERY ugly suggestion. Turn them all on with *ALL* and see what does not report anything. By the way, I have never tried this suggestion so I am not sure it is of any value except what you are paying me for it. Or, get Al's software. :-) Bob - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Falcone Sent: Tuesday, July 28, 2009 3:38 PM To: IBM-MAIN@bama.ua.edu Subject: z/OS SCRT NO89 Product Information I'm currently working with/on SCRT for quite a few physical machines and about triple the amount of LPARs. Is there any easy way for me to find out what products might be on what LPARs for inclusion in the NO89 section? I've got the process working fine but now need to tailor the NO89 section for validity. Or do I just need to read the fine book some more. Al, help!? -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS SCRT NO89 Product Information
Pat, If you code *ALL for NO89 products that you do NOT have licenses to there should be no implication because IBM knows what products you are licensed for. The bigger issue is if you code *ALL for NO89 products that you DO have licenses for but are not running on all of the lpars. In this case you will be billed for lpars that are not using the product; thereby increasing your costs. - Original Message - From: Pommier, Rex R. rex.pomm...@cnasurety.com Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Wednesday, July 29, 2009 2:38 PM Subject: Re: z/OS SCRT NO89 Product Information Pat, As far as coding *ALL for NO89 products that you do NOT have licenses to, I can't tell for certain, but I wouldn't do that. You might or might not get billed for these products, or you might get a call from your friendly IBM sales rep thanking you for licensing it all! :-) As far as coding *ALL for NO89 products that you DO have licenses for, you will be billed for the total SCRT usage on the boxes, regardless of how much you actually use the products. As others have stated, NO89 means that IBM doesn't cut SMF records to tell them how much is actually being used, so they bill for the products based on the system utilization. As far as coding *NONE for products you are using, IBM frowns on that, because you're telling them that you aren't using the software. If you're not actually using it, drop the licenses to the product(s) and save the money. If you are using the products but telling IBM you aren't, that's being dishonest. As far as giving IBM a list of LPARs you actually are running software on instead of *ALL, you can save money by not being billed for the software on LPARs you aren't running the software on. In my case, I have 3 LPARs, 1 production a test, and a sandbox. I only have 1 product that is in the NO89 list, COBOL. I don't use this on my sandbox (named MVSTECH), so my entry for this is: 5655-G53=MVSPROD,MVSTEST When I get my SCRT report and subsequent bill, I don't get invoiced for the 1 MSU that typically shows up on the sandbox. On the other LPARs, even though COBOL is used very little, I get billed for the MSUs that the LPARs consume, not that COBOL consumes. HTH Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Falcone Sent: Wednesday, July 29, 2009 1:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS SCRT NO89 Product Information Thanks for all your input. You'll have to excuse my ignorance with this stuff since my main charge is tuning and I just started to read the manual, like yesterday. OK, if I have this right and I code *all for the NO89 products it may be possible to be billed additionally if that's possible. If I code *none for NO89 products we may not be able to take advantage of where the software is running to get additional SubCapacity savings. And if I code the LPARs where the NO89 products run this might/would be factored into potential SubCapacity savings. My plan is to get this right and so I will be including LPAR's that are part of the NO89 hit list but wanted to understand what the options actually mean from a savings viewpoint. Again, appreciate all your input (and you to Al - thanks) --- On Wed, 7/29/09, Hal Merritt hmerr...@jackhenry.com wrote: From: Hal Merritt hmerr...@jackhenry.com Subject: Re: z/OS SCRT NO89 Product Information To: IBM-MAIN@bama.ua.edu Date: Wednesday, July 29, 2009, 3:11 PM That's not how it works. The NO89 covers products that do not cut SMF type 89 usage records. You are already paying for licensed products at full capacity. If you know you are not running a given product on LPARX, then include all of the others. Even if you are running it everywhere, you can still achieve sizable savings or, perhaps more importantly, make a good business case for a much bigger box you can grow into instead of a too small box you grow out of. You may not see any savings if your box is too small. -- 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: z/OS SCRT NO89 Product Information
IBM knows what products you are licensed for. Since when? You don't want to know how many audits I have gone through with IBM Canada over the last 30 years!n - 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: z/OS SCRT NO89 Product Information
Correction: IBM is supposed to know what products you have. But even if you have *ALL for NO89 products that you do NOT have licenses to you can work with IBM to correct the billing. - Original Message - From: Ted MacNEIL eamacn...@yahoo.ca Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Wednesday, July 29, 2009 5:52 PM Subject: Re: z/OS SCRT NO89 Product Information IBM knows what products you are licensed for. Since when? You don't want to know how many audits I have gone through with IBM Canada over the last 30 years!n - 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: z/OS SCRT NO89 Product Information
I believe the fine print TsCs indicate that if you specify that a product runs on one LPAR or any LPARs of a machine for which it is not licensed that IBM may view that as an order for the products. Similarly, for products that do generate SMF89 data, if SCRT detects a product on a machine where it is not licensed, that is an order for the product. You can correct this after the fact, but it's better to read the reports and be sure they are what you expect. (LCS highlights the discovery of products running where they are not expected to be running based on your licenses and/or history of product usage). This is the basis of Pat's original question. You are supposed to setup the NO89 parameters to reflect in which LPARs you actually use the NO89 products. This is why LCS detects this, to help sites properly report their usage to IBM. Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- 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: z/OS SCRT NO89 Product Information
In a message dated 7/29/2009 11:14:31 P.M. Central Daylight Time, a...@sherkow.com writes: believe the fine print TsCs indicate that if you specify that a product runs on one LPAR or any LPARs of a machine for which it is not licensed that IBM may view that as an order for the products. Curiosity question. What about the unordered but installed products like DCF? Seems like .BOO enables it for printing even if it's disabled in PRODnn. **Hot Deals at Dell on Popular Laptops perfect for Back to School (http://pr.atwola.com/promoclk/100126575x1223105306x1201716871/aol?redir=http:%2F%2Faltfarm.mediaplex.com%2Fad%2Fck%2F12309%2D81939%2D1629%2D9) -- 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
z/OS SCRT NO89 Product Information
I'm currently working with/on SCRT for quite a few physical machines and about triple the amount of LPARs. Is there any easy way for me to find out what products might be on what LPARs for inclusion in the NO89 section? I've got the process working fine but now need to tailor the NO89 section for validity. Or do I just need to read the fine book some more. Al, help!? -- 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: z/OS SCRT NO89 Product Information
On Tue, 28 Jul 2009 12:37:31 -0700, Patrick Falcone patrick.falco...@verizon.net wrote: I'm currently working with/on SCRT for quite a few physical machines and about triple the amount of LPARs. Is there any easy way for me to find out what products might be on what LPARs for inclusion in the NO89 section? I've got the process working fine but now need to tailor the NO89 section for validity. Or do I just need to read the fine book some more. Al, help!? Products like Tivoli License Compliance Manager (TLCM - formerly SoftAudit) can help with something like this. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: IBM SCRT Reports Cobol Usage
Lizette, Your situation is precisely why I recommend Al Sherkow's LCS product (www.sherkow.com) to audit SCRT. In the four years I did SCRT reporting, I never once had IBM question any of my submissions *and* I always caught those pesky situations that led to the problem you described before the SCRT cutoff date. As to Ted's suggestion, I would not trust my local rep to know that information. Al Sherkow - Yes, David Chase - Yes, Kay Adams - Yes.anyone else - prove to me you know what you are talking about. Finally, Mark is entirely correct about the reference to the web pages. I had to get this point across to the legal department when the WLC and VWLC contracts were signed. IBM changed the game when they started using standard Ts Cs for all companies that wanted to participate *and* used their web pages to convey that information. At that point, IBM was legally liable for the content they conveyed. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, May 06, 2009 3:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM SCRT Reports Cobol Usage One ramification is that IBM can bill you big time. We made an error like this (NO89 DDs issue) in our SCRT and it was going to cost us several 100,000 of dollars. However, we reran our SCRT process to correct the numbers and IBM gave us a Credit. Apparently they don't do refunds. Lizette The OP doesn't need to ask his IBM rep. All the information is publicly available from this web site: http://www-03.ibm.com/servers/eserver/zseries/swprice/index.html http://www-03.ibm.com/servers/eserver/zseries/swprice/wlc/ -- 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: IBM SCRT Reports Cobol Usage
As to Ted's suggestion, I would not trust my local rep to know that information. A rep is better than the (always out of date) web pages. Finally, Mark is entirely correct about the reference to the web pages. Unless things have changed, the web pages were useless in our case of CBU/Cood/DR testing. - 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
IBM SCRT Reports Cobol Usage
Hi, I need clarity on the following Cobol issue please. We are currently running Cobol programs on some of our Z9 LPAR's. The compilation of Cobol programs are however restricted to only one development LPAR. Should only this LPAR be specified in our monthly IBM SCRT reports or the names of all LPAR's in which Cobol programs run? Kind Regards, Sarel Swanepoel Service Availability: Capacity Management South African Revenue Services Office: +27 (0)12 422 5033 Mobile: +27 (0)82 4927 321 Fax: +27 (0)12 422 6068 Email: sswanep...@sars.gov.za blocked::mailto:sswanep...@sars.gov.za Please Note: This email and its contents are subject to our email legal notice which can be viewed at http://www.sars.gov.za/Email_Disclaimer.pdf -- 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: IBM SCRT Reports Cobol Usage
If you are only compiling on the development lpar, then you should only specify that lpar in the NO89 statement for COBOL. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sarel Swanepoel Sent: Wednesday, May 06, 2009 6:17 AM To: IBM-MAIN@bama.ua.edu Subject: IBM SCRT Reports Cobol Usage Hi, I need clarity on the following Cobol issue please. We are currently running Cobol programs on some of our Z9 LPAR's. The compilation of Cobol programs are however restricted to only one development LPAR. Should only this LPAR be specified in our monthly IBM SCRT reports or the names of all LPAR's in which Cobol programs run? Kind Regards, Sarel Swanepoel Service Availability: Capacity Management South African Revenue Services Office: +27 (0)12 422 5033 Mobile: +27 (0)82 4927 321 Fax: +27 (0)12 422 6068 Email: sswanep...@sars.gov.za blocked::mailto:sswanep...@sars.gov.za Please Note: This email and its contents are subject to our email legal notice which can be viewed at http://www.sars.gov.za/Email_Disclaimer.pdf -- 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: IBM SCRT Reports Cobol Usage
On Wed, 6 May 2009 12:16:38 +0200, Sarel Swanepoel sswanep...@sars.gov.za wrote: Hi, I need clarity on the following Cobol issue please. We are currently running Cobol programs on some of our Z9 LPAR's. The compilation of Cobol programs are however restricted to only one development LPAR. Should only this LPAR be specified in our monthly IBM SCRT reports or the names of all LPAR's in which Cobol programs run? You are reporting on the compiler, not the run time (Language Environment - which is part of z/OS). So only your development LPAR needs to be included in the NO89 DD for COBOL. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: IBM SCRT Reports Cobol Usage
Should only this LPAR be specified in our monthly IBM SCRT reports or the names of all LPAR's in which Cobol programs run? When I set up SCRT, I was told (by IBM), that they needed (wanted?) all LPARs. Not just the ones running products under sub-capacity licences. I would suggest that you ask your IBM rep this question, since IBM may have different terms in your country, than they have in Canada. - 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: IBM SCRT Reports Cobol Usage
On Wed, 6 May 2009 18:45:47 +, Ted MacNEIL eamacn...@yahoo.ca wrote: Should only this LPAR be specified in our monthly IBM SCRT reports or the names of all LPAR's in which Cobol programs run? When I set up SCRT, I was told (by IBM), that they needed (wanted?) all LPARs. Not just the ones running products under sub-capacity licences. The *SMF data* from all LPARs is required. But each customer has to manually code NO89 DDs for products that don't cut SMF89 records in order to show IBM where the product is used so they can bill you based on the max 4 hr rolling average. You are on the honor system to do this (I don't sign contracts so I don't know what the ramifications are if you screw up). I would suggest that you ask your IBM rep this question, since IBM may have different terms in your country, than they have in Canada. The OP doesn't need to ask his IBM rep. All the information is publicly available from this web site: http://www-03.ibm.com/servers/eserver/zseries/swprice/index.html http://www-03.ibm.com/servers/eserver/zseries/swprice/wlc/ -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: IBM SCRT Reports Cobol Usage
One ramification is that IBM can bill you big time. We made an error like this (NO89 DDs issue) in our SCRT and it was going to cost us several 100,000 of dollars. However, we reran our SCRT process to correct the numbers and IBM gave us a Credit. Apparently they don't do refunds. Lizette Should only this LPAR be specified in our monthly IBM SCRT reports or the names of all LPAR's in which Cobol programs run? When I set up SCRT, I was told (by IBM), that they needed (wanted?) all LPARs. Not just the ones running products under sub-capacity licences. The *SMF data* from all LPARs is required. But each customer has to manually code NO89 DDs for products that don't cut SMF89 records in order to show IBM where the product is used so they can bill you based on the max 4 hr rolling average. You are on the honor system to do this (I don't sign contracts so I don't know what the ramifications are if you screw up). I would suggest that you ask your IBM rep this question, since IBM may have different terms in your country, than they have in Canada. The OP doesn't need to ask his IBM rep. All the information is publicly available from this web site: http://www-03.ibm.com/servers/eserver/zseries/swprice/index.html http://www-03.ibm.com/servers/eserver/zseries/swprice/wlc/ -- 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: IBM SCRT Reports Cobol Usage
The OP doesn't need to ask his IBM rep. All the information is publicly available from this web site: Boy! You trust IBM's web sites? When I set it up, there were some differences between what the site said and what IBM Canada wanted. Our issues had to do with CBU/CooD and DR testing. They weren't mentioned as part of 'all the publicly available information', at that time. - 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: IBM SCRT Reports Cobol Usage
One ramification is that IBM can bill you big time. We made an error like
this (NO89 DDs issue) in our SCRT and it was going to cost us several 100,000
of dollars.
Unless it's changed in the last few years, the whole SCRT process is very error
prone.
That's why people like Al are in business. (8-{]}
However, we reran our SCRT process to correct the numbers and IBM gave us a
Credit. Apparently they don't do refunds.
Never have and never will.
Even when they make mistakes, it's still a credit. (8-{[}
-
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: SCRT (Sub-Capacity Reporting Tool)
I would suggest that you extract, from each lpar, the TYPE70 and TYPE89 SMF records on a daily basis into separate GDG datasets whose GDS bases are set to a limit of 45 or 75. When you run the SCRT program, just specify the GDS base names and pull in all generations for all lpars. No harm, no foul. This avoids a massive read of monthly SMF record types you don't care about. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Steely Sent: Wednesday, March 11, 2009 6:03 PM To: IBM-MAIN@bama.ua.edu Subject: SCRT (Sub-Capacity Reporting Tool) We are z/OS V1R9 and we are going to start using this tool. The tool requires that the input SMF data is to span from the second day of the month to the first day of the next month. Our SMF data is separated by the month. How are other shops performing this retrieval. I would like to automate this process and not have to enter dates times to pull the requested SMF data needed. Any help would be appreciated. Thank You -- 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: SCRT (Sub-Capacity Reporting Tool)
And I wouldn't even bother to separate them - I just got the 89's added to the 70-79's I had put aside for my RMF analysis. We usually found most of the SCRT data were already/still in the VTS cache when we ran the SCRT report. Shane ... On Thu, 2009-03-12 at 06:38 -0400, Richards, Robert B. wrote: I would suggest that you extract, from each lpar, the TYPE70 and TYPE89 SMF records on a daily basis into separate GDG datasets -- 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: SCRT (Sub-Capacity Reporting Tool)
Mark, I run a daily extract for the type 89s and accumulate that for each LPAR. This makes the end of month processing run in seconds instead of hours. We create a new GDG each month for this and have had no problems at all with the process. Should we destroy the GDG we can rebuild it from the monthly SMF data. Cheers, Paul -Original Message- Subject: SCRT (Sub-Capacity Reporting Tool) We are z/OS V1R9 and we are going to start using this tool. The tool requires that the input SMF data is to span from the second day of the month to the first day of the next month. Our SMF data is separated by the month. How are other shops performing this retrieval. I would like to automate this process and not have to enter dates times to pull the requested SMF data needed. Any help would be appreciated. Thank You -- 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: SCRT (Sub-Capacity Reporting Tool)
Hi Shane! Valid point. I did not want to presume anything about Mark's setup, so I suggested what I did. My current environment mirrors yours, but I am using logstreams and not MANx datasets...creating separate logstreams for Performance (70:79,89) and RACF (80,81,83) to go along with a default. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shane Sent: Thursday, March 12, 2009 6:57 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SCRT (Sub-Capacity Reporting Tool) And I wouldn't even bother to separate them - I just got the 89's added to the 70-79's I had put aside for my RMF analysis. We usually found most of the SCRT data were already/still in the VTS cache when we ran the SCRT report. Shane ... On Thu, 2009-03-12 at 06:38 -0400, Richards, Robert B. wrote: I would suggest that you extract, from each lpar, the TYPE70 and TYPE89 SMF records on a daily basis into separate GDG datasets -- 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: SCRT (Sub-Capacity Reporting Tool)
Hi Folks, On the CBT Tape, File 789 (only use the UPDATES page), there is a setup by Al Ferguson to automate the SCRT report production into a batch job, so as not to occupy system programmer time too much, in producing the monthly report. I hope that you'll find this material helpful. All the best of everything to all of you. Sincerely,Sam Golob -- 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: SCRT (Sub-Capacity Reporting Tool)
On Thu, 12 Mar 2009 20:56:45 +1000, Shane ibm-m...@tpg.com.au wrote: And I wouldn't even bother to separate them - I just got the 89's added to the 70-79's I had put aside for my RMF analysis. We usually found most of the SCRT data were already/still in the VTS cache when we ran the SCRT report. Ditto. When we started doing this years ago it was much easier to add the 89s to the same file then create a new one. I also have them as part of the SMF/RMF logstream in my sandbox (no, I'm not use SMF logstream in production and probably won't look at it again until z/OS 1.11). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: SCRT (Sub-Capacity Reporting Tool)
Here we roll up our SMF data weekly. We don't do a monthly roll up. We just keep 2 years (108 weeks) of weekly rollups. We also separate the data by SMF record type into DB2 (100-102), MQ (115 and 116), WLC (30, 70-79, and 89), and everthing else. I run the job to create the SCRT reports early on the morning of the 3rd of the month. The job is submitted by our scheduling package. The SMF input DD statement has more than enough generations of the WLC weekly tape to cover the previous month (6 generations). I have specified Report_Period=Last_Month in the SCRTPARM member. That way SCRT pulls the correct information without my having to change dates every month. If you want to email me offline I'll send you my job stream and SCRT parms. By the way, I highly recommend that you get the product LPAR Capacity and Software Usage Analysis (LCS(tm)) Software from I/S Management Strategies, Ltd (www.sherkow.com). It really helps in analyzing the sub-capacity pricing charges, and it is inexpensive for what it does. It is written in SAS and uses the MXG database as its input data. So you need both of those products. MXG is also inexpensive, but SAS is another matter. With the purchase of LCS you also get excellent over the phone consulting help from Al Sherkow. This product has save my company much more than its cost when we've been able to use it to analyze unusual increases in software costs and then enter exceptions into the SCRT reports. Note that I don't work for Al. I'm just a very satisfied customer. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Wednesday, March 11, 2009 5:28 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SCRT (Sub-Capacity Reporting Tool) SCRT is smart enough to pick the data for the correct time period if you supply it. We concatenate however many weeklys and dailys it takes to get it right. This is automated via CA-7 '#' JCL manipulation cards. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Steely Sent: Wednesday, March 11, 2009 3:03 PM To: IBM-MAIN@bama.ua.edu Subject: SCRT (Sub-Capacity Reporting Tool) We are z/OS V1R9 and we are going to start using this tool. The tool requires that the input SMF data is to span from the second day of the month to the first day of the next month. Our SMF data is separated by the month. How are other shops performing this retrieval. I would like to automate this process and not have to enter dates times to pull the requested SMF data needed. Any help would be appreciated. Thank You -- 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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: SCRT (Sub-Capacity Reporting Tool)
We do something similar: we hook the SMF dump process that runs as needed then at again at midnight. Security and billing information is selected to a separate file as GDG's for each LPAR. The data is FTP's to a central LPAR if needed. The GDG's are gathered on the third and a monthly file is created for input to the SCRT. The regular SMF process is the data backup. The scheduler supplies any date control cards. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Thursday, March 12, 2009 5:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SCRT (Sub-Capacity Reporting Tool) I would suggest that you extract, from each lpar, the TYPE70 and TYPE89 SMF records on a daily basis into separate GDG datasets whose GDS bases are set to a limit of 45 or 75. When you run the SCRT program, just specify the GDS base names and pull in all generations for all lpars. No harm, no foul. This avoids a massive read of monthly SMF record types you don't care about. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Steely Sent: Wednesday, March 11, 2009 6:03 PM To: IBM-MAIN@bama.ua.edu Subject: SCRT (Sub-Capacity Reporting Tool) We are z/OS V1R9 and we are going to start using this tool. The tool requires that the input SMF data is to span from the second day of the month to the first day of the next month. Our SMF data is separated by the month. How are other shops performing this retrieval. I would like to automate this process and not have to enter dates times to pull the requested SMF data needed. Any help would be appreciated. Thank You -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SCRT (Sub-Capacity Reporting Tool)
On Thu, 12 Mar 2009 01:26:06 -0400, Clark, Kevin wrote: Mark, We will be starting this process next month. Our monthly SMF tape is produced on the 2nd day of the next month already, so all days of the previous month are account for. The cost saving dictate changing your business collection process. keep in mind you could cut a tape with just the records that SCRT needs seperatly from the your normal SMF process. Don't work about extra dates , the product will select the right grouping for the report. You need to be careful though. The process defaults to current month when you run it. If you automate it, the programs might make interesting determinations of what current month means. We keep weekly SMF backups with a daily GDG series that rolls up into the weekly. Since you can never tell where a week ends in relation to an IBM month, our process takes 5 generations of weekly backups and the whole daily series every time it runs (3rd calendar day of every month). I also supply the PARM Report_Period=Last_Month so there is no ambiguity. I can re-run it anytime within the month following without having to mess with the PARMs. And since you have to run it after the 1st completes, Last_Month always works for the normally scheduled JOB too. -- 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
SCRT (Sub-Capacity Reporting Tool)
We are z/OS V1R9 and we are going to start using this tool. The tool requires that the input SMF data is to span from the second day of the month to the first day of the next month. Our SMF data is separated by the month. How are other shops performing this retrieval. I would like to automate this process and not have to enter dates times to pull the requested SMF data needed. Any help would be appreciated. Thank You -- 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: SCRT (Sub-Capacity Reporting Tool)
SCRT is smart enough to pick the data for the correct time period if you supply it. We concatenate however many weeklys and dailys it takes to get it right. This is automated via CA-7 '#' JCL manipulation cards. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Steely Sent: Wednesday, March 11, 2009 3:03 PM To: IBM-MAIN@bama.ua.edu Subject: SCRT (Sub-Capacity Reporting Tool) We are z/OS V1R9 and we are going to start using this tool. The tool requires that the input SMF data is to span from the second day of the month to the first day of the next month. Our SMF data is separated by the month. How are other shops performing this retrieval. I would like to automate this process and not have to enter dates times to pull the requested SMF data needed. Any help would be appreciated. Thank You -- 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: SCRT (Sub-Capacity Reporting Tool)
Mark, We will be starting this process next month. Our monthly SMF tape is produced on the 2nd day of the next month already, so all days of the previous month are account for. The cost saving dictate changing your business collection process. keep in mind you could cut a tape with just the records that SCRT needs seperatly from the your normal SMF process. Don't work about extra dates , the product will select the right grouping for the report. Kevin From: IBM Mainframe Discussion List on behalf of Mark Steely Sent: Wed 3/11/2009 6:02 PM To: IBM-MAIN@bama.ua.edu Subject: SCRT (Sub-Capacity Reporting Tool) We are z/OS V1R9 and we are going to start using this tool. The tool requires that the input SMF data is to span from the second day of the month to the first day of the next month. Our SMF data is separated by the month. How are other shops performing this retrieval. I would like to automate this process and not have to enter dates times to pull the requested SMF data needed. Any help would be appreciated. Thank You -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail message and any attachments transmitted with it are confidential and are intended solely for the use of its authorized recipient(s). If you are not an intended or authorized recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the information contained in this e-mail is prohibited. If you have received this message in error or are not authorized to receive it, please immediately notify the sender and delete the original message and all copies of it from your computer. -- 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: ESP Schedular and the SCRT job
Would inserting a //*ESPSYMBOL @ (or some other character) in the JCL to change the ESP symbol substitution character address that? Bill On Wed, 4 Jun 2008 17:16:13 -0500, Hal Merritt [EMAIL PROTECTED] wrote: Is anyone besides us using the ESP scheduler and doing sub capacity billing? The latest version of the load and go module appears to be triggering ESP's rather powerful symbol substitution engine and is going bonkers. Anyone else seen that, and, if so, what did you do about it? I have a query into the SCRT folks. Thanks!! NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ESP Schedular and the SCRT job
Is anyone besides us using the ESP scheduler and doing sub capacity billing? The latest version of the load and go module appears to be triggering ESP's rather powerful symbol substitution engine and is going bonkers. Anyone else seen that, and, if so, what did you do about it? I have a query into the SCRT folks. Thanks!! NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESP Schedular and the SCRT job
When I production-ized SCRT, I created the following JCL stream in my production job. //JS0010 EXEC PGM=LOADER //SYSLOUT DDSYSOUT=* //SMF DD DSN=SYS2.SMF.WEEK.ALLSYS.TYPE7089(-4),DISP=SHR // DD DSN=SYS2.SMF.WEEK.ALLSYS.TYPE7089(-3),DISP=SHR // DD DSN=SYS2.SMF.WEEK.ALLSYS.TYPE7089(-2),DISP=SHR // DD DSN=SYS2.SMF.WEEK.ALLSYS.TYPE7089(-1),DISP=SHR // DD DSN=SYS2.SMF.WEEK.ALLSYS.TYPE7089(0),DISP=SHR // DD DSN=SYS2.SMF.DAY.ALLSYS.TYPE7089,DISP=SHR //SYSPRINT DD DISP=(,CATLG),DSN=SYS2.SCRT.SYSPRINT, // SPACE=(TRK,(1,1)),UNIT=SYSDA //OUTPUT DD DISP=(,CATLG),DSN=SYS2.SCRT.REPORT, // SPACE=(TRK,(15,15,15)),UNIT=SYSDA //PARMSDD DSN=SYS2.SCRT.PDS(PARMS),DISP=SHR //NO89 DD DSN=SYS2.SCRT.PDS(NO89),DISP=SHR //SYSLIN DD DSN=SYS2.SCRT.PDS(PROGRAM),DISP=SHR I extract all of the 'in stream' elements from the SCRT download into a PDS with three members (PARMS, NO89 and PROGRAM). This way, my production JCL never (or hardly ever) changes, while I can replace the SCRT code and parms for each SCRT release as needed. The next step in this job uses XMITIP to automatically email me the SCRT spreadsheets the above JCL generated. No muss, no fuss. Works every month, automatically. Perhaps something like this would assist you. If it was me, I wouldn't bother waiting for SCRT support to change their object deck for compatability with your scheduling software Brian On Wed, 4 Jun 2008 17:16:13 -0500, Hal Merritt wrote: Is anyone besides us using the ESP scheduler and doing sub capacity billing? The latest version of the load and go module appears to be triggering ESP's rather powerful symbol substitution engine and is going bonkers. Anyone else seen that, and, if so, what did you do about it? I have a query into the SCRT folks. Thanks!! -- 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
SCRT Error
Hello, I have a customer who is running SCRT for the first time and is having some trouble with the NO89 DD. He does not have many of the products in the list, so for the first one, he specifies: 5655-043=*NONE and receives the following error message: SCRTTOOL047: LPAR *NONEIN NO89 DD FOR 5655-043 NOT FOUND IN SMF/SCRT89 DATA. The job ends with CC 16. He is on z/OS 1.4 and is using SCRT 15.x. Thanks. Alan Bain ISAM Office - 952-440-4726 Cell - 952-200-7096 Fax - 952-216-0124 [EMAIL PROTECTED] www.isamgroup.com http://www.isamgroup.com/ We search. You save. -- 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
Re: SCRT Error
Hi. I have had a similar error and the problem wasin Report_Period format... * OPTIONALLY UNCOMMENT ONE OF THESE LINES TO SELECT A REPORT PERIOD Report_Period=2008/04 ---that is O.K. * Report_Period=Mayo * Review the before statement... may be that.. Atte. Alvaro Quintupray. [EMAIL PROTECTED] Ingenieria de Sistema. Fono: (562) 420-8149 Fax:(562) 420-8017 -Mensaje original- De: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] En nombre de Alan Bain Enviado el: Miércoles, 28 de Mayo de 2008 14:58 Para: IBM-MAIN@BAMA.UA.EDU Asunto: SCRT Error Hello, I have a customer who is running SCRT for the first time and is having some trouble with the NO89 DD. He does not have many of the products in the list, so for the first one, he specifies: 5655-043=*NONE and receives the following error message: SCRTTOOL047: LPAR *NONEIN NO89 DD FOR 5655-043 NOT FOUND IN SMF/SCRT89 DATA. The job ends with CC 16. He is on z/OS 1.4 and is using SCRT 15.x. Thanks. Alan Bain ISAM Office - 952-440-4726 Cell - 952-200-7096 Fax - 952-216-0124 [EMAIL PROTECTED] www.isamgroup.com http://www.isamgroup.com/ We search. You save. -- 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 -- 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
Re: SCRT Error
The syntax of the NO89 statement looks correct. I'd look at the data. SCRT may have not found any applicable type 70 or 89 RMF records. I'd also check to see if the enabling APAR's are applied as well as applicable processor microcode. When I first started under 1.4, I seem to recall having to specify a 'soft cap' value to get the whole process to start. I also seem to recall a number of corrective fixes needed for early versions of 1.4. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Alan Bain Sent: Wednesday, May 28, 2008 1:58 PM To: IBM-MAIN@BAMA.UA.EDU Subject: SCRT Error Hello, I have a customer who is running SCRT for the first time and is having some trouble with the NO89 DD. He does not have many of the products in the list, so for the first one, he specifies: 5655-043=*NONE and receives the following error message: SCRTTOOL047: LPAR *NONEIN NO89 DD FOR 5655-043 NOT FOUND IN SMF/SCRT89 DATA. The job ends with CC 16. He is on z/OS 1.4 and is using SCRT 15.x. Thanks. Alan Bain ISAM Office - 952-440-4726 Cell - 952-200-7096 Fax - 952-216-0124 [EMAIL PROTECTED] www.isamgroup.com http://www.isamgroup.com/ We search. You save. -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SCRT LMS site problems?
Hi All, Is anybody else having problems submitting SCRT reports via the LMS website this morning? We _think_ we submitted ours, but have not received any response yet (it's been 3 hours so far). Earlier we had received notification of a scheduled outage for Sunday, May 4, but . TIA, -jc- -- 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
Re: SCRT LMS site problems?
John, Yes, I'm having difficulties with the SCRT LMS site also. Getting 'page not found' during at signin. Paul -- 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
SCRT Release 14.2.0 problems
Cross-posted to IBM-Main and LPAR-PRICING_L Today, in testing SCRT 14.2 and its new functionality, I discovered a bug: PRODUCT_ID=*ALL gives an error that the id is not equal in length to 8 positions. That keyword is optional and DEFAULTS to *ALL. So if you are testing this out and want *ALL, omit the keyword entirely. Specifying an actual product id that is not the operating system or a NO89 product DOES work (i.e. 5625-DB2). I have emailed the SCRT team on this issue. I'll repost if/when I get a reply from them. Bob Richards VP, Enterprise Technologist - - Enterprise Technology Infrastructure- - Mainframe Services Capacity Performance Mgmt - - Office: 404-575-2798Mobile: 610-246-2943 - - email: [EMAIL PROTECTED] - LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- 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
SCRT and IMS V7 question
Last month (May 14th, 2007 to be precise) we moved all our remaining CICS- , MQseries- and IMS-regions from our test lpar to our prod lpar. When I run SCRT with the june SMF files I have collected so far, the output for CICS (TS 1.3) and MQSeries (V5.3.1) for the test lpar is 0 MSU, like I expect it to be. However, while I am pretty sure there is no IMS activity left in the test lpar, SCRT still reports a significant amount of MSUs for IMS V7. Why is that and what should I do to make SCRT report 0 MSUs for IMS V7 in our test lpar ? -- 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 ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e m e s s a g e c o n t e n t . A l t h o u g h t h e s e n d e r e n d e a v o u r s t o m a i n t a i n a c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n i s v i r u s - f r e e a n d w i l l n o t b e l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m a n y v i r u s t r a n s m i t t e d . O n a l l o f f e r s a n d a g r e e m e n t s u n d e r w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s o f D e l i v e r y f r o m A t o s O r i g i n e x c l u s i v e l y a p p l y . T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y s u b m i t t e d t o y o u o n y o u r r e q u e s t . A t o s O r i g i n N e d e r l a n d B . V . / U t r e c h t K v K U t r e c h t 3 0 1 3 2 7 6 2
