If I remember correctly Z EOD doesn't stop the system, it just stops recording and flushes the records. Unless you follow with a QUIESCE (or deactivate), the system continues to idle along
> -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Radoslaw Skorupka > Sent: Friday, February 24, 2023 4:24 AM > To: [email protected] > Subject: Re: [EXTERNAL] Re: SCRT and not operating LPAR > > [EXTERNAL EMAIL] > > Gentlemen, > > First, thank you for the discussion. That also helps. > > Ad rem: > 1. The is no big reason to keep LPAR Activated, Not operating, except > short time between activation and IPL or re-IPL, etc. And SCRT is IMHO > not the most important reason for that. Good reasons were presented by > Martin. > 2. I asked mostly out of my curiosity. But it is not senseless at all, > it is good to know *severity* of results of mistaken scenario. Not to > say, the curiosity is good :-) > 3. I did some tests. > Test 1. I activated an LPAR and deactivated it few hours later. Result - > the LPAR is not visible in SCRT report. No "required" statement for the > LPAR. Same as for other deactivated LPARs. > Test 2. I shut down the system, but the LPAR remained Activated. 8 hours > later I IPLed another z/OS image in the LPAR. Result - SCRT report > claims there is 8-hour hole in the SMF reporting. > > I have some other ideas to test, but this is real customer production, > SCRT report is real, so I come off it. > > > Regards > -- > Radoslaw Skorupka > Lodz, Poland > > > > > W dniu 23.02.2023 o 23:31, Pommier, Rex pisze: > > Ignore my last question - you just answered it. > > > > Rex > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Pommier, Rex > > Sent: Thursday, February 23, 2023 4:30 PM > > To: [email protected] > > Subject: Re: [EXTERNAL] Re: SCRT and not operating LPAR > > > > Hi Radoslaw, > > > > I'm not denying your experience. You got me questioning my own so I had > to go back and make sure it was working like I had expected it to. :-) I did > also misspeak. You are correct, it was an e-mail with the CSV sent as an > attachment. This was the mechanism IBM took away and they're in essence > forcing us to submit the CSV manually thru the web site. We (as I'm sure > most every company submitting SCRT) had the e-mail completely automated > (except when we had to insert comments) and then they took that away. > > > > Is there a reason you have these LPARs active but not IPLed? Just curiosity > and if I'm getting nosy tell me. :-) Wouldn't deactivating them stop SCRT > from reporting on them? > > > > Rex > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Radoslaw Skorupka > > Sent: Thursday, February 23, 2023 4:21 PM > > To: [email protected] > > Subject: Re: [EXTERNAL] Re: SCRT and not operating LPAR > > > > As I noted things may have changed. I really tried to do it, but it was > > 10+ years ago. After that I did not come back to try it again and again. > > BTW: I was very first user of SCRT in Poland, it was January 2006, AFAIR. > > > > Actually I don't understand the way you submit reports. In the past few > ways were possible, one of them was webpage, another one was mail > attachment. Then mail was closed. > > LMS webpage analyze CSV content and (see above) reject amended file. I > cannot say for today, because I did not submit SCRT report personally for > several years. > > And in fact I don't care - for me there is no difference to put some > explanation in the file or on the webpage directly. I can imagine the > checksum now does cover only relevant fields, not whole file. It would make > sense. > > > > My current problem is Activated but not IPLed LPAR. I had discussion with > my coworker and that's why I'm asking about it. > > > > Regards > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > > > W dniu 23.02.2023 o 23:09, Pommier, Rex pisze: > >> With all due respect, I have to disagree. Granted I haven't had to > >> make any explanations to LMS since IBM took away the FTP transmission > >> and required us to go through the web site for transmissions, but > >> before that I would add my comments to the mainframe version of the > >> CSV and then directly FTP it from the mainframe to LMS, all without > >> any issues. I have the prior 12 months' worth of SCRT reports on the > >> mainframe and I found where I had commented in at least 3 of these > >> reports and didn't have IBM reject any of them. Unless, of course, > >> IBM was silently rejecting them > >> > >> Rex > >> > >> -----Original Message----- > >> From: IBM Mainframe Discussion List <[email protected]> On > >> Behalf Of Radoslaw Skorupka > >> Sent: Thursday, February 23, 2023 3:58 PM > >> To: [email protected] > >> Subject: Re: [EXTERNAL] Re: SCRT and not operating LPAR > >> > >> You cannot update CSV file. There is a checksum at the bottom. Any > update, including such comment causes the file will not be accepted by the > LMS. BTDT. > >> Of course it is possible to upload the file to LMS and then add > explanations. But then IBM knows the rest of file is not amended. > >> > >> > >> BTW: I'm pretty sure of the above. I had plenty Activated, but Not > operating LPARs in my former shop and the reports did not require any > explanation for that. It was kind of cloud or "on demand provisioning" - we > created system + application instances on demand. A lot of them, quite > frequently. The problem occured when someone forgot to archive SMF data > before system shutdown and scratch. However it was slightly another > scenario - LPAR was both Active and Operating, but some records were lost. > >> Of course the rules may have changed. For example in the past it was > acceptable to collect 95% (time) SMF data, but the SCRT tool could not accept > duplicate SMF IDs. Now it's the opposite - any SMF loss causes explanations > requirement, but SMF ID need not to be unique any longer. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> W dniu 23.02.2023 o 21:33, Pommier, Rex pisze: > >>> Hi John, > >>> > >>> Actually I think you remembered right the first time. :-) When our > sandbox is down for an extended period, I get the "(required)" in the CSV file > as well. I just change "(required)" with "LPAR down for refresh" or whatever > reason the LPAR isn't reporting SMF data and then send the CSV in. The only > times I recall having to fix the data once it gets to IBM is when I forgot to > update the CSV before submitting it. > >>> > >>> Rex > >>> > >>> -----Original Message----- > >>> From: IBM Mainframe Discussion List <[email protected]> > On > >>> Behalf Of John McKown > >>> Sent: Thursday, February 23, 2023 12:33 PM > >>> To: [email protected] > >>> Subject: [EXTERNAL] Re: SCRT and not operating LPAR > >>> > >>> Misremembered. The CVS file says "(required)". When uploaded to IBM > there is a prompt, in red, to fill the field in. That's when I enter "not in > use". > >>> > >>> On Thu, Feb 23, 2023, 04:52 John McKown > >>> <[email protected]> > >>> wrote: > >>> > >>>> We have this situation. There is a REMARKS field in the SCRT cvs file. > >>>> I put the sentence "No longer in use." in that field during the > >>>> generation of it on my Windows desktop. I've done that for years now > >>>> with no problems with IBM. > >>>> > >>>> On Thu, Feb 23, 2023, 04:05 Radoslaw Skorupka < > >>>> [email protected]> wrote: > >>>> > >>>>> As it is known, all the z/OS LPAR have to report SMF data to SCRT > >>>>> otherwise SCRT report would contain "data missing" field for given > >>>>> LPAR and explanation will be required. > >>>>> What about not operating LPARs? > >>>>> I mean an LPAR which is Activated, but not IPLed. Or the OS was > >>>>> shut down and LPAR was reset (but still remain active). > >>>>> > >>>>> AFAIR there was no problem with not operating LPARs in the past - > >>>>> that mean the LPARs were not included in the report. > >>>>> However It seems something changed and now such LPAR will cause > >>>>> "data missing" issue. > >>>>> > >>>>> Any clue? > >>>>> > >>>>> > >>>>> -- > >>>>> Radoslaw Skorupka > >>>>> Lodz, Poland > >>>>> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
