Re: IBM support portal Broken?
Something happened just broke loose. I can now get to IBMLINK. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Jousma, David Sent: Wednesday, August 30, 2017 1:37 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: IBM support portal Broken? Well, honestly, I bet this wasn’t planned by IBM, and we'll probably see them fix this, but they did me a big favor. IE 11 on our shop workstations was a real dog, having to restart it multiple times per day due to lockups. Running Chrome at work (in a sanctioned fashion) is like a breath of fresh air. Typical non-business related websites like cnn.com foxnews.com, etc would constantly cause brower to stop unexpectedly, but I couldn’t call the helpdesk for those... _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dan Little Sent: Wednesday, August 30, 2017 1:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM support portal Broken? **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** IE11 here too and people are having to use Chrome. On Aug 30, 2017, 1:01 PM -0400, Turner Cheryl L , wrote: > Some of us don't have the leisure of changing our browser option or version, > so I certainly hope that's not the fix. > > Right now IBMLINK prompts for userid/password but after supplying, just sits > there like it didn't understand (no spinning/thinking wheel). I reported the > problem we are experiencing to IBM. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] > On Behalf Of Jousma, David > Sent: Wednesday, August 30, 2017 11:04 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: IBM support portal Broken? > > Oh, and I should have added that some of my team mates noticed it already > last week, but neglected to tell anyone, they just moved over to Firefox > which works. > > _ > Dave Jousma > Manager Mainframe Engineering, Assistant Vice President > david.jou...@53.com > 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f > 616.653.2717 > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jousma, David > Sent: Wednesday, August 30, 2017 11:02 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM support portal Broken? > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > We have been running into this. At the bank we are still on IE 11. > Servicelink and ShopZ both don't work. Had to get Chrome installed. The newer > MS Edge seems to work, but my workstation is still Win7. > > _ > Dave Jousma > Manager Mainframe Engineering, Assistant Vice President > david.jou...@53.com > 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f > 616.653.2717 > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Allan Staller > Sent: Wednesday, August 30, 2017 9:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IBM support portal Broken? > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > Get partial display of support portal Home Page. > > https://www.ibm.com/support/home/entry/portal/support > > > > ::DISCLAIMER:: > -- > -- > > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > E-mail transmission is not guaranteed to be secure or error-free as > information could be intercepted, corrupted, lost, destroyed, arrive late or > incomplete, or may contain viruses in transmission. The e mail and its > contents (with or without referred errors) shall therefore not attach any > liability on the originator or HCL or its affiliates. > Views or opinions, if any, presented in this email are solely those of the > author and may not necessarily reflect the views or opinions of HCL or its > affiliates. Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and
Re: IBM support portal Broken?
Some of us don't have the leisure of changing our browser option or version, so I certainly hope that's not the fix. Right now IBMLINK prompts for userid/password but after supplying, just sits there like it didn't understand (no spinning/thinking wheel). I reported the problem we are experiencing to IBM. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Jousma, David Sent: Wednesday, August 30, 2017 11:04 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: IBM support portal Broken? Oh, and I should have added that some of my team mates noticed it already last week, but neglected to tell anyone, they just moved over to Firefox which works. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Wednesday, August 30, 2017 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM support portal Broken? **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** We have been running into this. At the bank we are still on IE 11. Servicelink and ShopZ both don't work. Had to get Chrome installed. The newer MS Edge seems to work, but my workstation is still Win7. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Wednesday, August 30, 2017 9:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM support portal Broken? **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Get partial display of support portal Home Page. https://www.ibm.com/support/home/entry/portal/support ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in er
Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)
Not sure what is being planned but is this an all or nothing proposal? Meaning you either have to use it for installation or the order doesn't get installed? I don't know if others here may agree with me, but I, and some others in my shop, would prefer to use our existing local installation process. However, I would not impede an alternative from being developed, if my future replacement may find it a better alternative and want to use it. We, like others, use z/OSMF purely because of the Communication Server requirement. In our shop, fortunate or no, one person is also not responsible for installing key components (i.e. z/OS is by itself. CICS/DB2/MQ and various vendor and IBM supplemental products are installed by several other individuals and their migration may happen after the z/OS install is complete.) Has this post installation separation of components also been taken into consideration/discussed with the z/OSMF process? Might DB2/CICS/etc. have their own predefined workflows or would the CBPDO or like process still be applicable in that situation? Thanks, Cheryl -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of John Eells Sent: Tuesday, July 11, 2017 7:36 AM To: IBM-MAIN@listserv.ua.edu Subject: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES) Peter Hunkeler wrote: > Topic change due? Possibly more opinions if people understand it is about > z/OSF now. > > Peter, good idea. Everyone: IBM is headed toward using z/OSMF Software Management as the installer. Please go back to near the beginning of this thread with the old topic name to catch up on the discussion thus far. More on the SHARE website, here: https://share.confex.com/data/handout/share/128/Session_20728_handout_10028_0.pdf -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EREP Symptom and/or Software Records
I understand why you may have thought that but no I understand it is not the slip that spawns the records. But couldn't it be said that the slip parms are indicating IBM's view of the severity of the event? I am so new to this that heck I may not be even asking the questions right. For that I'm sorry. For example. Here is one symptom record in particular we are constantly seeing (there are others but let's use this as an example): PIDS/5695DF105 RIDS/IGG0CLA9 RIDS/IGG0CLX0#L PRCS/00F6 PRCS/ PRCS/ JOBN/DBP1DBM1< the JOBN changes but they all seem to be DB2 related tasks. All the other information is the same. SYSTEM ENVIRONMENT: CPU MODEL: 2964 DATE: 166 17 CPU SERIAL: 0207C7 TIME: 01:06:27.72 SYSTEM: MBI2 BCP: MVS RELEASE LEVEL OF SERVICE ROUTINE: HBB77A0 SYSTEM DATA AT ARCHITECTURE LEVEL: 10 COMPONENT DATA AT ARCHITECTURE LEVEL: 10 SYSTEM DATA: || COMPONENT INFORMATION: COMPONENT ID: 5695DF105 COMPONENT RELEASE LEVEL: 220 SERVICE RELEASE LEVEL:UA82137 DESCRIPTION OF FUNCTION: CATPROB DATA PRIMARY SYMPTOM STRING: PIDS/5695DF105 RIDS/IGG0CLA9 RIDS/IGG0CLX0#L PRCS/00F6 PRCS/ JOBN/DBP3DBM1 SYMPTOMSYMPTOM DATA EXPLANATION ------- PIDS/5695DF105 5695DF105COMPONENT IDENTIFIER RIDS/IGG0CLA9 IGG0CLA9 ROUTINE IDENTIFIER RIDS/IGG0CLX0#LIGG0CLX0#L ROUTINE IDENTIFIER PRCS/00F6 00F6 RETURN CODE PRCS/ RETURN CODE JOBN/DBP3DBM1 DBP3DBM1 JOB NAME THE SYMPTOM RECORD DOES NOT CONTAIN A SECONDARY SYMPTOM STRING. FREE FORMAT COMPONENT INFORMATION: And then there appears to be a snap dump of storage on each one. Nothing on IBMLINK matching anything that I can think to search on from the fields. In the syslog we see IBM slip trap x91A taken about the time of each record. 2017166 01:06:27.72 0284 IEA989I SLIP TRAP ID=X91A MATCHED. JOBNAME=CATALOG , ASID=0086. And there are sometimes 100s of this particular symptom records on a given lpar, per day. Slip settings are: ID=X91A,NONPER,ENABLED ACTION=NODUMP,SET BY CONS INTERNAL,RBLEVEL=ERROR,COMP=91A 91A Explanation: A request to abnormally end the catalog address space (CAS) service task was issued either through the MODIFY CATALOG,RESTART command, or through catalog analysis task processing. System Action: The system re-drives the catalog request currently in process. We are not issuing a MODIFY CATALOG RESTART command at the time of any of the logrecs being cut. SO might there something wrong with the catalog process that all these redrives are necessary? Is it normal behavior? So many questions and I'm clueless, unfortunately. So what I guess I was trying to wrap my head around is: if there isn't a need to take a dump, etc. (as specified in the SLIP setting) then why have logic to cut 100's of symptom records at all for that particular issue? And if we're cutting 100's of records - is it really a problem? And like Ed said, it's noise, and I don't know enough to know it's a problem or not and sometimes how to go about diagnosing. So I was hoping to get some help (which I have) in how to handle these and others going forward. Thanks for your and others responses, though. It's much appreciated and I'm taking it all in as much as I can. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Peter Hunkeler Sent: Thursday, June 15, 2017 4:20 PM To: IBM-MAIN@listserv.ua.edu Subject: AW: Re: EREP Symptom and/or Software Records >But I still can't ge
Re: EREP Symptom and/or Software Records
Thank you Bruce. A coworker had downloaded the Logrec Viewer many moons ago, but I wasn't aware of it or that we had it. Your post reminded him to tell me about it and confirm it still works :) We are not currently exploiting PFA. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Bruce Hewson Sent: Thursday, June 15, 2017 1:20 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: EREP Symptom and/or Software Records Hello Cheryl, check out the Logrec Viewer exec - https://www.ibm.com/systems/z/os/zos/tools/downloads/logrec-viewer.html also you can monitor the PFA_LOGREC_ARRIVAl_RATE healthcheck to tell you when you get a burst of LOGREC events. Regards Bruce On Tue, 13 Jun 2017 16:24:34 -0500, Turner Cheryl L wrote: >Greetings. >Our former sysprog, who paid attention to the more finer system details, has >left the building for greener pastures. So now we seem to have to step up our >game. However, I'm not sure what to do or how. > >We are running several EREP reports to see what software or symptom records >are being cut per LPAR (mostly just HISTORY reports for now). We are finding >that a lot of records are being cut at the time an IBM supplied SLIP trap is >taken (for example X13E, X47B, X91A). Some of these records can exceed >hundreds on a given day. > >What should we/I be doing? Reporting them to IBM? I just don't understand why >IBM would set the SLIP yet cut a symptom or software record too. We can't be >the only shop seeing these. Yet I've tried to research a few on IBMLINK but >can't find any hits for known problems. Or maybe there is a way to turn of >the creation of the software/symptom record? Though I can't wrap my head >around that either, thinking why are they then being cut at all if it's not >anything to look into? > >Any schooling you can give, would be most appreciated! But please, be gentle. >I'm out of my element. Many thanks to you all. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EREP Symptom and/or Software Records
I was hoping you'd chime in John (and I appreciate the responses from Skip, Lizette and EdG, as well). Since I am the person that does the maintenance and OS upgrades now, I was taking it upon myself to be a bit proactive (or creating busy work?) and looking at the EREP reports for potential problems where there may be PTFs available but maybe we just didn't have them on at the time due to our maintenance windows. We are still in the process of fine tuning which reports to generate and we are unloading the reports to GDGs . So I will summarize the advice as this: Look at them, as you have time. Decide if any of them are a true problem or something worth investigating further, check out IBMLINK and/or look for a way to fix it. Open a PMR to IBM/vendor if really unsure. But I still can't get my head around, why cut 100's of symptom/software records a day at all for a particular problem, if we're just going to ignore them - abend or not. But I'll try to let that not keep me awake at night. Thanks everyone. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of John Eells Sent: Wednesday, June 14, 2017 9:10 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: EREP Symptom and/or Software Records Turner Cheryl L wrote: > Greetings. > Our former sysprog, who paid attention to the more finer system details, has > left the building for greener pastures. So now we seem to have to step up > our game. However, I'm not sure what to do or how. > > We are running several EREP reports to see what software or symptom records > are being cut per LPAR (mostly just HISTORY reports for now). We are finding > that a lot of records are being cut at the time an IBM supplied SLIP trap is > taken (for example X13E, X47B, X91A). Some of these records can exceed > hundreds on a given day. > > What should we/I be doing? Reporting them to IBM? I just don't understand why > IBM would set the SLIP yet cut a symptom or software record too. We can't be > the only shop seeing these. Yet I've tried to research a few on IBMLINK but > can't find any hits for known problems. Or maybe there is a way to turn of > the creation of the software/symptom record? Though I can't wrap my head > around that either, thinking why are they then being cut at all if it's not > anything to look into? > > Any schooling you can give, would be most appreciated! But please, be gentle. > I'm out of my element. Many thanks to you all. If you care to research these, look up the abends and see whether you really care. Using 13E as an example: Explanation: The task that created a subtask issued a DETACH macro for that subtask, specifying STAE=NO, before the subtask ended. This may or may not be an error, depending on the intent of the user. Consequently, the system does not abnormally end the task issuing the DETACH macro. With no proof to back my assumptions, I nonetheless suspect that, if you look at these, you will find that most or all of those are from application programs that summarily shot their subtasks rather than signaling them to complete or waiting for them to complete. You can discuss such things with the application owner, but you might find most of them reluctant to "fix" the problem when what they are doing is working from their perspective and the net ill effect is "noise" in EREP reports. I will observe, though, that the system programmer action for ABEND13E could use some updates... -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
EREP Symptom and/or Software Records
Greetings. Our former sysprog, who paid attention to the more finer system details, has left the building for greener pastures. So now we seem to have to step up our game. However, I'm not sure what to do or how. We are running several EREP reports to see what software or symptom records are being cut per LPAR (mostly just HISTORY reports for now). We are finding that a lot of records are being cut at the time an IBM supplied SLIP trap is taken (for example X13E, X47B, X91A). Some of these records can exceed hundreds on a given day. What should we/I be doing? Reporting them to IBM? I just don't understand why IBM would set the SLIP yet cut a symptom or software record too. We can't be the only shop seeing these. Yet I've tried to research a few on IBMLINK but can't find any hits for known problems. Or maybe there is a way to turn of the creation of the software/symptom record? Though I can't wrap my head around that either, thinking why are they then being cut at all if it's not anything to look into? Any schooling you can give, would be most appreciated! But please, be gentle. I'm out of my element. Many thanks to you all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Paging subsystems in the era of big&^% memory
We have a totally different issue but I feel still related. I even opened a service request with IBM, whom sent us off to the manuals and it as clear as mud to read the fine manual, techdocs, etc. and get a precise answer. Our problem is we have constrained ESQA/ECSA on one of our LPARs. We are a large DB2 shop. Recent retirements and lost years of knowledge in this arena have left those of us that remain scratching our heads. Years ago Sam Knutson said something to the list to the effect of "DASD is cheap so back up real 1:1", if I'm remembering it right. And we have been doing that for many, many years in addition to adding IBM recommendations of 30% and having at least 3 local datasets (one techdoc mentions 5 min) whether needed or not. Every time we have ever added real storage, we upped the number of locals. If we were to follow the 1:1 ratio now, we would be increasing ESQA even more. For example: Our MAXSPACE=16000M and have allocated 512 G real memory. We currently have 9 3390-27 local page datasets defined for that system. Our past rule of thumb would suggest that 11 entire 3390-54 local page datasets are actually required. What we aren't sure of is if we are extremely oversized and can and should back our current paging subsystem allocation down some to recover some of the ESQA currently in use. Did I mention, we hardly, if ever, page? I know, that's a good thing and if it ain't broke don't fix it but the ESQA issue really has us looking at every little savings. How do I get a handle on what really is needed when we increase real storage to ensure we: 1) don't constrain our virtual storage any more, 2) continue successfully not paging, 3) understand why and when we will need to up the sizing of our subsystem. I'm glad I too was following this thread so that I was able to send our DB2 sysprogs the recommendation that Art Gutowski (THANK YOU!!) forwarded to the group below to possibly help with our problem. Appreciate any assistance anyone has or if anyone has ran into this situation in the past. From reading and internet trolling, it looks like not many have a handle on what it takes to get this right and is well, downright confusing. Cheryl -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Jesse 1 Robinson Sent: Thursday, April 13, 2017 3:27 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Paging subsystems in the era of bigass memory This thread did seem to morph into a focus on DB2, but the paging problem for us is not confined to DB2. We have one utility system that was set up years ago to be a 'CMC'. It's still dedicated to 'network stuff', which for some time has narrowed down to CA-TPX, the SNA session manager. Very little else runs there. Certainly no DB2 or CICS. Absolutely no end-user apps. We've sort of ignored this system recently as we turned attention elsewhere. It was last IPLed in January 2016, well over a year ago! It runs great except for this burr under the saddle. The local volumes are all Mod-3. Whatever we decide to do about DB2 will not help here. - IEE200I 11.29.28 DISPLAY ASM - TYPE FULL STAT - PLPA 100%FULL - COMMON 36% OK - LOCAL53% OK - LOCAL49% OK - LOCAL43% OK . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Wednesday, April 12, 2017 8:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Paging subsystems in the era of bigass memory Here is an IBM presentation on how to tune z/OS and DB2 memory, including some parameters to set. http://www.mdug.org/Presentations/Large%20Memory%20DB2%20Perf%20MDUG.pdf On Wed, Apr 12, 2017 at 2:55 PM, Art Gutowski wrote: > Did someone on this thread say DB2?? > > We have been experiencing similar AUX storage creep on our DB2 systems, > particularly during LARGE reorgs (more of a gallop than a creep). Our DB2 > guys did some research, opened an ETR with IBM, and found this relic: > > Q: > "[Why was] set realstorage_management to OFF when that zPARM was introduced > in DB2 version 10? > > "Details > "IBM z/OS implemented a Storage Management Design change after DB2 v10 was > released. > "• Before the design change, DB2 used KEEPREAL(NO), virtual storage > pages were really (physically) freed, high CPU cost if YES > DISCARDDATA KEEPREAL(NO