Re: IRRUT200 and D37
Thanks to all who answered. The ACS routines were okay John - the Management Class as Scott suspected, specificially the use of 'Yes_Immediate' on the RELEASE option was the cause. On Sun, Aug 3, 2008 at 6:40 AM, Chase, John <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of james smith > > > > Folks > > > > I am experiencing a new problem using IRRUT200 which is used > > to make a copy of our RACF database. We have been running > > this job for eons then suddenly we started getting D37-04 > > abends. What appears to be happening is no matter what SPACE > > value we specify it is being 'clobbered' and we end up > > getting 1 unit of whatever we request - so either 1 CYLINDER > > or 1 TRACK followed logically by a D37. > > > > I have specified SPACE=(CYL,(150)) on my JCL - I have even > > pre-allocated the dataset with 150 CYLINDERS. > > > > After the job abends and I Check the dataset - the > > allocation is ONE CYLINDER. > > > > The strange part is that this only happens for SMS datasets. > > When I pre-allocate a NON-SMS dataset OR specify a non-sms > > dataset in my JCL - hey presto no problems - job works as intended. > > > > Any ideas would be appreciated > > Did somebody change your ACS rules? We routinely run IRRUT200 with > SYSUT1 allocating a temp dataset for database unloads, diagnostics, > etc., without problems. > >-jc- > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IRRUT200 and D37
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of james smith > > Folks > > I am experiencing a new problem using IRRUT200 which is used > to make a copy of our RACF database. We have been running > this job for eons then suddenly we started getting D37-04 > abends. What appears to be happening is no matter what SPACE > value we specify it is being 'clobbered' and we end up > getting 1 unit of whatever we request - so either 1 CYLINDER > or 1 TRACK followed logically by a D37. > > I have specified SPACE=(CYL,(150)) on my JCL - I have even > pre-allocated the dataset with 150 CYLINDERS. > > After the job abends and I Check the dataset - the > allocation is ONE CYLINDER. > > The strange part is that this only happens for SMS datasets. > When I pre-allocate a NON-SMS dataset OR specify a non-sms > dataset in my JCL - hey presto no problems - job works as intended. > > Any ideas would be appreciated Did somebody change your ACS rules? We routinely run IRRUT200 with SYSUT1 allocating a temp dataset for database unloads, diagnostics, etc., without problems. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IRRUT200 and D37
Scott Good call - that did the trick. I'm on vacation starting next week - I think my 'brain cells' must have already left :-) Thanks On Sat, Aug 2, 2008 at 3:15 PM, Scott Barry <[EMAIL PROTECTED]> wrote: > On Sat, 2 Aug 2008 13:28:20 +0300, james smith <[EMAIL PROTECTED]> > wrote: > > >Folks > > > >I am experiencing a new problem using IRRUT200 which is used to make a > copy > >of our RACF database. We have been running this job for eons then > suddenly > >we started getting D37-04 abends. What appears to be happening is no > matter > >what SPACE value we specify it is being 'clobbered' and we end up getting > 1 > >unit of whatever we request - so either 1 CYLINDER or 1 TRACK followed > >logically by a D37. > > > >I have specified SPACE=(CYL,(150)) on my JCL - I have even pre-allocated > the > >dataset with 150 CYLINDERS. > > > >After the job abends and I Check the dataset - the allocation is ONE > >CYLINDER. > > > >The strange part is that this only happens for SMS datasets. When I > >pre-allocate a NON-SMS dataset OR specify a non-sms dataset in my JCL - > hey > >presto no problems - job works as intended. > > > >Any ideas would be appreciated > > > >-- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > >Search the archives at http://bama.ua.edu/archives/ibm-main.html > > If the program is doing an OPEN/CLOSE prior to writing the file, you will > need to use a MGMTCLAS that does *NOT* have the PARTIAL_RELEASE=YES_IMMED > attribute. > > Scott Barry > SBBWorks, Inc. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IRRUT200 and D37
I would check you ACS routines to see if they have changed for this dataset. ACS can be coded so that no matter what the JCL says, the dataset only gets a specific amount. If you cannot preallocate the data set in an SMS pool with the space you want, it is like the space management tool (ACS routines or the like). Second, see if there are any productions like DTS or CA-DISK or the like that could also be controlling your JCL allocations. Lizette \> > Folks > > I am experiencing a new problem using IRRUT200 which is used to make a > copy > of our RACF database. We have been running this job for eons then > suddenly > we started getting D37-04 abends. What appears to be happening is no > matter > what SPACE value we specify it is being 'clobbered' and we end up > getting 1 > unit of whatever we request - so either 1 CYLINDER or 1 TRACK followed > logically by a D37. > > I have specified SPACE=(CYL,(150)) on my JCL - I have even pre- > allocated the > dataset with 150 CYLINDERS. > > After the job abends and I Check the dataset - the allocation is ONE > CYLINDER. > > The strange part is that this only happens for SMS datasets. When I > pre-allocate a NON-SMS dataset OR specify a non-sms dataset in my JCL - > hey > presto no problems - job works as intended. > > Any ideas would be appreciated -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IRRUT200 and D37
On Sat, 2 Aug 2008 13:28:20 +0300, james smith <[EMAIL PROTECTED]> wrote: >Folks > >I am experiencing a new problem using IRRUT200 which is used to make a copy >of our RACF database. We have been running this job for eons then suddenly >we started getting D37-04 abends. What appears to be happening is no matter >what SPACE value we specify it is being 'clobbered' and we end up getting 1 >unit of whatever we request - so either 1 CYLINDER or 1 TRACK followed >logically by a D37. > >I have specified SPACE=(CYL,(150)) on my JCL - I have even pre-allocated the >dataset with 150 CYLINDERS. > >After the job abends and I Check the dataset - the allocation is ONE >CYLINDER. > >The strange part is that this only happens for SMS datasets. When I >pre-allocate a NON-SMS dataset OR specify a non-sms dataset in my JCL - hey >presto no problems - job works as intended. > >Any ideas would be appreciated > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html If the program is doing an OPEN/CLOSE prior to writing the file, you will need to use a MGMTCLAS that does *NOT* have the PARTIAL_RELEASE=YES_IMMED attribute. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
