[Default] On 16 Jan 2019 02:57:29 -0800, in bit.listserv.ibm-main 000001a0403c5dc1-dmarc-requ...@listserv.ua.edu (Jousma, David) wrote:
>Wayne, you need to free up region below the line. We run with an 11M PVT below >the line. Here is our memory map from tasid. > > 0 | PSA .............. 8K | 1FFF > 2000 | System .......... 16K | 5FFF > 6000 | PVT .......... 11240K | AFFFFF > B00000 | CSA ........... 2276K | D38FFF > D39000 | PLPA .......... 1380K | E91FFF > E92000 | SQA ........... 1284K | FD2FFF > FD3000 | R/W Nucleus ..... 43K | FDD877 > FDE000 | R/O Nucleus .. 13483K | 1D08B2F > 1D09000 | Ext R/W Nuc .... 320K | 1D58FFF > 1D59000 | Ext SQA ...... 90304K | 7588FFF > 7589000 | Ext PLPA ..... 65844K | B5D5FFF > B5D6000 | Ext CSA ..... 389288K | 231FFFFF > 23200000 | Ext PVT .... 1521664K | 7FFFFFFF > >One way we make a bunch of room below the line is to move little used ISPF >modules out of LPA in LINKLIST. > Why the &*^^%* in 2019 should anyone have to move these modules out of LPA? Other than inertia, is there any need for these to be 24 bit? What else is in 24 bit LPA that should have been upgraded to 31 bit long ago? Clark Morris > >++VER(Z038) FMID(HIF7R02). >++MOVE (FLM$CPI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMB ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMCPCS ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMDDL ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMIO24 ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPCBL) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPFRT) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPGEN) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLSS ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMP ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMPTC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRA ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRTLIB) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS$LNK) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS$SRV) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS7C ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTBMAP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCCPS) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCIDS) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCLGT) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCPC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCPP ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCVER) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTMMI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTMSI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTXFER) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMUM ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMVCSUP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMXE ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMXI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (ISRSUPC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. > >_________________________________________________________________ >Dave Jousma >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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of >Wayne Bickerdike >Sent: Tuesday, January 15, 2019 9:58 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Abend 106 (was Generic query on Region allocation failure) > >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or unexpected >emails** > >Mark Zeldens excellent IPLINFO shows: > >The real storage size at IPL time was 2048M. >The private area size <16M is 8192K. >The private area size >16M is 1628M. >The CSA size <16M is 4812K. >The CSA size >16M is 300652K. >The SQA size <16M is 1248K. >The SQA size >16M is 15792K. >The maximum V=R region size is 280K. >The default V=R region size is 140K. >The maximum V=V region size is 8168K. > >Based on this: >CVTGDA = C2d(Storage(D2x(CVT + 560),4)) /* point to GDA */ >GDACSA = C2d(Storage(D2x(CVTGDA + 108),4)) /* start of CSA addr */ >GDACSAH = D2x(GDACSA) /* display in hex */ >CSAEND = (GDACSASZ*1024) + GDACSA - 1 /* end of CSA */ >CSAEND = D2x(CSAEND) /* display in hex */ > >So CSA <16M is too small. > > > >On Wed, Jan 16, 2019 at 9:20 AM Tom Marchant < >0000000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >> On Tue, 15 Jan 2019 08:57:39 -0500, Peter Relson wrote: >> >> ><snip> >> >there is no excuse for such a large module requiring RMODE(24). >> ></snip> >> > >> >Sure there is -- if it doesn't cause a problem. But here it does >> >cause a problem. >> >So the real question is? what's the problem? >> >> DFHEISUP has been getting larger with each new release of CICS. >> Looking at the libraries on our system, I see: >> >> CTS 5.4 007D1410 >> CTS 5.3 007B6070 >> CTS 5.2 0078C7D0 >> CTS 5.1 00772608 >> CTS 4.2 00752958 >> CTS 4.1 00719EA8 >> >> Wayne's Fault Analyzer output showed the size of that module that had >> been loaded to be X'7B6070'. >> The IEF032I message in his job output showed below the line system >> usage to be 260K and private is 7908K. >> That doesn't leave much room if he only has 8M of below the line >> private area. >> >> It is not surprising to me that he has found that it fails more often >> with newer releases of CICS. >> >> I am a little surprised though if all three of the places that he has >> run this have only 8M of below the line private. >> >> -- >> Tom Marchant >> >> ---------------------------------------------------------------------- >> 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
