Week long AMODE 32 thread? Only a week on IBM main, I think. Wrong idea for sure. Running with 32 bit literals and AMODE 64 would work, but since address literals are such a small part of programs it does not make sense and I think would risk branching out of your 4GB memory area. The 380 group has been arguing with Paul for months.
On Fri, May 31, 2019 at 12:20 PM Mike Hochee <[email protected]> wrote: > > Thanks for all the responses on this one, especially Jim and Peter, and all > the links. I unsubscribed from this list some months ago and re-subscribed > last night, now realizing how much I might have missed (week-long AMODE32 > threads notwithstanding) > > The info I initially received was from an IBM gent in the z processor group, > and was consistent with the Processor Optimization doc pg 31. Some time ago I > converted most of our MVCL*s over to MVC and XC instructions, resulting in > modest cpu savings. Since that time, I began checking for page alignment of > source and target addresses and routing to MVCL* rtns when page aligned, and > lastly tried to make things more eligible for ADM or the 'near-memory engine' > with BNDRY=PAGE which may have run headlong into fragmentation issue > described or... > > > Whether use of the near-memory engine helps or hurts your performance > > depends on how/when you were using the storage before the MVCL/MVCLE, > > and how/when you use it after the MVCL/MVCLE. > > Thanks again! > Mike > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Don Poitras > Sent: Friday, May 31, 2019 10:58 AM > To: [email protected] > Subject: Re: BNDRY=PAGE possible CPU hit? > > Expanding the ... leads one to (there might be more, but this is the one I > found): > > https://www.ibm.com/developerworks/community/files/form/anonymous/api/library/ff4563be-756e-49bf-9de9-6a04a08026f1/document/07c69512-ac74-4394-87b9-a61ea201347e/media/IBMzSystemsProcessorOptimizationPrimerv2.pdf > > Gratuitous wrap noted. > > Other files in this "community" can be found at: > > https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=9a17556c-6094-4201-acd0-d8125a3fa0db > > > > In article > <of5917c456.92910c5f-on0025840b.004f9464-8525840b.004f9...@notes.na.collabserv.com> > you wrote: > > See page 31 in this document: > > > https://www.ibm.com/.../IBMzSystemsProcessorOptimizationPrimerv2.pdf > > > Whether use of the near-memory engine helps or hurts your performance > > depends on how/when you were using the storage before the MVCL/MVCLE, > > and how/when you use it after the MVCL/MVCLE. > > > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > > Poughkeepsie NY > > > "IBM Mainframe Discussion List" <[email protected]> wrote on > > 05/30/2019 11:12:13 PM: > > > > From: "Michael Hochee" <[email protected]> > > > To: [email protected] > > > Date: 05/31/2019 12:31 AM > > > Subject: BNDRY=PAGE possible CPU hit? > > > Sent by: "IBM Mainframe Discussion List" <[email protected]> > > > > > > Hi, > > > I recently added the BNDRY=PAGE parameter to a set of STORAGE > > > OBTAINS which acquire storage areas of various sizes from several > > > low private subpools. My intent was a reduction of CPU used by > > > subsequent MVCLE instructions, as ADM would more likely be employed > > > for MVCLE executes, since the storage areas involved were page > > > aligned (apparently an ADM pre-req.) Unfortunately my initial > > > testing revealed a significant increase in CPU consumption, rather > > > than a reduction. > > > > > > I did a few searches of the IBM-MAIN archive and found nothing > > > involving increased CPU overhead resulting from BNDRY=PAGE usage. > > > Any thoughts on what might be causing the elevated CPU? Again, the > > > only change made was adding BNDRY=PAGE. (I have since backed the > > > change off, tested, reapplied the change and tested with the same > > results) > > -- > Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive > [email protected] (919) 531-5637 Cary, NC 27513 > > ---------------------------------------------------------------------- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
