I am not sure you can restrict how much storage SMP/E will use. I think you need to look at several elements to see what you need. But over the years, I have only seen the requirements grow not shrink.
If you looked at Marna Walle's Migration documents you can see that the SMP/E and operating system environment is growing. So you will need to get with your management and explain why you need more storage to do your work. You need to increase your MCS dataset. The only way you can shrink the base SMP/E datasets (PTS, SCDS, MCS, GLOBAL, etc...) is to do ACCEPT of the maintenance. However, that may not fix the issue. Questions I think you need to consider. How many products are managed in this SMP/E environment? Only IBM or IBM + OEM etc... How often do you do ACCEPT of maintenance? I see you are not using SMS to manage your SMP/E environment. Is that due to SMS is not used in your shop? Or do you just not want SMP/E to be under SMS control? How much storage are you allowed to have? These do not necessarily need to be answered to the list, but you should consider what you will need for now and in the future for install maintenance. If your shops says you can only use X MB of storage for SMP/E functions, then at some point you will not be able to do maintenance. And that means whether you are installing RSUs or implementing a full system upgrade. During RECEIVE processing, the MCS for each SYSMOD is copied to an SMP/E temporary storage area called the SMPPTS data set. The MCS entry contains the MCS and any inline element replacements or updates for the SYSMOD. Relative files, however, are stored in another temporary storage area called the SMPTLIB data sets. During ACCEPT processing, Global zone SYSMOD entries and MCS statements in the SMPPTS data set are deleted for those SYSMODs that have been accepted into the distribution zone. Any SMPTLIB data sets created during RECEIVE processing are also deleted. If you do not want SMP/E to do this global zone clean-up, you have the option to indicate this to SMP/E, and the information is saved. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mainframe Mainframe > Sent: Tuesday, December 09, 2014 10:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RSU UNZIP space issue. > > Hello, > Yes, This time I created size with with 10GB of > /u/SLE/RSU1410/temp space > and now I encountered with different space issue for SMPMCS file. > > IEC031I D37-04,IFG0554P,UNZIPRSU,UNZIP,SYSUT1,8B0A, > SMPE.ZOS1D.RSU.S2654213.SMPMCS > IEA995I SYMPTOM DUMP OUTPUT 143 > SYSTEM COMPLETION CODE=D37 REASON CODE=00000004 > TIME=08.53.19 SEQ=00838 CPU=0000 ASID=002F > > > IEC031I D37-04,IFG0554P,UNZIPRSU,UNZIP,SYSUT1,8B0A, > SMPE.ZOS1D.RSU.S2654213.SMPMCS > > But I have already allocated max space for this dataset. > > . . . . . . . . . . . . . . . . . . . . . . . . . > . . > Data Set Information Command ===> > More: > + > Data Set Name . . . . : SMPE.ZOS1D.RSU.S2654213.SMPMCS > > General Data Current Allocation > Management class . . : **None** Allocated cylinders : 4,300 > Storage class . . . : **None** Allocated extents . : 1 > Volume serial . . . : TEMP01 > Device type . . . . : 3390 > Data class . . . . . : **None** > Organization . . . : PS Current Utilization > Record format . . . : FB Used cylinders . . : 4,300 > Record length . . . : 80 Used extents . . . : 1 > Block size . . . . : 27920 > 1st extent cylinders: 4300 > Secondary cylinders : 0 Dates > Data set name type : Creation date . . . : 2014/12/04 > SMS Compressible. . : NO Referenced date . . : 2014/12/09 > Expiration date . . : ***None*** > > > Unzip JCL, > > //UNZIPRSU JOB 'MAINFRAME',CLASS=A,MSGCLASS=A,NOTIFY=&SYSUID > //UNZIP EXEC PGM=GIMUNZIP,PARM='HASH=NO' > //SYSUT3 DD UNIT=3390,SPACE=(CYL,(400,100)) > //SYSUT4 DD UNIT=3390,SPACE=(CYL,(400,100)) > //SMPOUT DD SYSOUT=* > //SYSPRINT DD SYSOUT=* > //SMPDIR DD PATH='/u/SLE/RSU1410/', > // PATHDISP=KEEP > //SMPWKDIR DD PATH='/u/SLE/RSU1410/temp', > // PATHDISP=KEEP > //SYSIN DD DATA,DLM=$$ > <GIMUNZIP> > <ARCHDEF > name="SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z" > volume="TEMP01" > newname="SMPE.ZOS21.RSU.S2654213.SMPMCS" > replace="yes"> > </ARCHDEF> > <ARCHDEF > name="SMPHOLD/S0002.SHOPZ.S2654213.SMPHOLD.pax.Z" > volume="TEMP01" > newname="SMPE.ZOS21.RSU.S2654213.SMPHOLD" > replace="yes"> > </ARCHDEF> > </GIMUNZIP> > $$ > > > > As we cant create dataset bigger then this because of restriction. Please > suggest. > > On Tue, Dec 9, 2014 at 10:18 PM, Lizette Koehler <stars...@mindspring.com> > wrote: > > > To make sure I understand. > > > > OMVS.SYS5.RSU.TEMP is mounted on /u/SLE/RSU1410/temp which is used > > on SMPWKDIR. Is that correct? > > and all of your SMP/E processes use this one file for SMPWKDIR, is > > that correct? > > > > And this file uncompressed will be 5,085,091,600 bytes or 5085M. > > > > So, with all the processes going on 7000M may not be enough. Each > > time a pax happens, storage is used and released (IIRC). > > > > You will probably need to adjust your SMPWKDIR as needed. > > > > You may need to check and see what the largest file for pax will be > > and size according to it. This may not be the largest one. > > > > Review the SMP/E manual on SMPWKDIR and see if there are any > > recommendations. I tend to oversize this file based on the largest > > file for pax. > > > > If this is a zFS file, I would allow aggrow to happen for it. If HFS > > secondary allocation would be large. > > > > > > Lizette > > > > > > -----Original Message----- > > >From: Mainframe Mainframe <mainframe1...@gmail.com> > > >Sent: Dec 9, 2014 9:25 AM > > >To: IBM-MAIN@LISTSERV.UA.EDU > > >Subject: Re: RSU UNZIP space issue. > > > > > >Yes, I am already using temp dataset with size of 7000MB. > > > > > > Data Set Information Command ===> > > > > > > Data Set Name . . . : OMVS.SYS5.RSU.TEMP > > > > > > 1st extent megabytes: 7000 > > > Secondary megabytes : 0 > > > Data set name type : HFS Dates > > > Creation date . . . : 2014/12/04 > > > Referenced date . . : 2014/12/04 > > > Expiration date . . : > > > ***None*** > > > > > >Current Allocation > > > Allocated megabytes : 7,000 > > > Allocated extents . : 1 > > > Maximum dir. blocks : NOLIMIT > > > > > > > > >Current Utilization > > > Used pages . . . . : 1,241,552 > > > % Utilized . . . . : 69 > > > Number of members . : 4 > > > > > >Do I need to create still bigger space for this temp as I am getting > > >same issue. > > > > > >On Tue, Dec 9, 2014 at 7:59 PM, Kurt Quackenbush <ku...@us.ibm.com> > > wrote: > > > > > >> On 12/9/2014 9:08 AM, Mainframe Mainframe wrote: > > >> > > >>> Hello Kurt, > > >>> Thanks for response. I just checked this > > >>> /u/SLE/RSU1410/GIMPAF.XML file and found below entry. > > >>> > > >>> <ARCHDEF > > >>> name="SMPPTFIN/S0001.SHOPZ.S2654303.SMPMCS.pax.Z" > > >>> type="SMPPTFIN" > > >>> originalsize="5085091600" > > >>> size="2760339456" > > >>> hash="1C69AA496915DB08EF19DBC53C0A0221D6EC7D39"> > > >>> </ARCHDEF> > > >>> > > >>> By looking at this, can you please suggest, what should be the size of > > >>> /u/SLE/RSU1410/temp > > >>> for SMPWKDIR DD. > > >>> > > >> > > >> You can do the math, right? 56,664 bytes per track, and 15 tracks > > >> per cylinder. So 5,085,091,600 bytes == 89,742 tracks == 5983 cylinders. > > But > > >> I'd go bigger to be safe. Try 6500 cylinders. > > >> > > >> > > >> Kurt Quackenbush -- IBM, SMP/E Development > > >> > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
