&MAXSIZE parameter value calculation by ACS routines

vini m · New User Joined: 27 Nov 2008 Posts: 16 Location: singapore

Hello , I have a question on storage group selection as per ACS routine .
Dataset went to PRDSML instead of PRDLRG which it should not I believe.

Here is a gds creation with the below attributes.
SPACE=(0,(9600,9600),,DCB=(RECFM=VB,LRECL=20000,BLKSIZE=0) , UNIT=(SYSALLDA,59),VOL=(,,,59),

ACS routine got this logic.

WHEN ((&SIZE LT 212MB)
AND (&DSORG EQ 'VS' OR &MAXSIZE LT 848MB))

SET&STORGRP= 'PRDSML'
OTHERWISE
SET &STORGRP = 'PRDLRG'

Since BLKSIZE=0 the space value is around 225 cylinders (20000 X 9600 / 56664 / 15) for both primary and secondary

I Expect ACS should calculate the values as (considering 1cyl =0.81MB ) &SIZE = 182 MB (225 x 0.81mb) and MAXSIZE = 2916 MB (( 225+(225 x 15)) * 0.81mb) during dataset allocation.

MAXSIZE = 2916 MB ACS could think of it initially but in reality it may go beyond that as the jcl has coded VOL parameter. ( I believe maximum extents in EACH volume is 15)

So considering all these wondering how the dataset could fall under PRDSML logic as the MAXSIZE LT 848MB is not satisfied and should have fallen under PRDLRG ?

Also I read if BLKSIZE specified as Zero system would determine an optimal value and calculate . In either case the MAXSIZE is beyond 848MB.

May be I am missing something ?? could someone shed some light ?

Robert Sample · Posted: Fri Feb 21, 2014 1:40 am

Your post has quite a few errors and problems with it. From the DFSMSdfp Storage Administration Reference manual (emphasis added by me):

vini m · New User Joined: 27 Nov 2008 Posts: 16 Location: singapore

Robert ,

I aw aware of this constraint removal stuff .

The GDG I was talking about got ADDDSORG dataclas which is very default and it has EXTENT CONSTRAINT REMOVAL set to NO..

Also this EXTENT CONSTRAINT REMOVAL is applicable for VSAM datasets only as per my understanding not for sequential files. Let me know if that is not correct .

Pete Wilson · Posted: Fri Feb 21, 2014 7:02 pm

&MAXSIZE is a fairly useless variable since Extended Format QSAM files were allowed because it still thinks they're limited to 15 extents per volume rather than 123. I don't know why IBM haven't updated this to match the values it passes for VSAM. Very annoying.

You do have some other options available though. For example the &DSNTYPE variable indicates if a file is Extended Format or not and combined with the &SECOND_QTY and &SPACE_TYPE variables you can start to make some more informed decisions on what to do with the files. For example you can potentially assign different Dataclases that might have the Space Override option set to YES.

I don't understand your example space parameter...seems a bit strange as you haven't specified TRK or CYL but have a 0? Can't see how that would work. Also you have UNIT count and VOLUME count, it only needs to be one or the other. And in fact you shouldn't need either if the assigned Dataclas has Space Constraint Relief enabled because extra volumes would be dynamically added based on the DYNVOL value.

I'd suggest you look at the way your datasets are allocated. Try and move away from specifying in TRK or CYL if you can and use the Dataclases to assign space. If you can't use Dataclas for space then use the AVGREC keyword to request space in terms of the number of expected records in the file.

e.g.
This requests enough space for 10000 x 20000 byte records for both Primary and Secondary space.
SPACE=(20000,(10,10),RLSE),AVGREC=K,
RECFM=VB,LRECL=20000,VOL=(,,,59)

Even better, if you have a Dataclas with space set at a similar value, and it has Space Constraint Relief and DYNVOL you can just code as follows assuming the Dataclas is assigned in the ACS routines:
DSN=dataset.name,DISP=(,CATLG),
RECFM=VB,LRECL=20000

ps: You don't need the DCB= parameter anymore, just code LRECL & RECFM as above, and ommitting BLKSIZE is the same as coding BLKSIZE=0. And with the dataset being SMS managed you don't need to specify UNIT count, that was only necessary for pre-SMS allocations using esoteric pools.

vini m · New User Joined: 27 Nov 2008 Posts: 16 Location: singapore

Wilson , thanks for the info.

First of all I have to mention that this is not my coding and observed one of the application coded like this and as a storage admin I am trying to understand how their datasets falling under the small storage group instead of big pool so that I can reach out to the application group to standardize the code.

By the way this file is not extended format. I understand the info you are saying but I am trying to understand what had happened to those datasets to fall in to this small group.

Pete Wilson · Posted: Wed Feb 26, 2014 1:22 pm

From the example DD you have shown I would calculate &SIZE as ~183MB and &MAXSIZE as ~162048MB. So it gets a match on the &SIZE variable but is excluded because of the AND for &MAXSIZE.

e.g.
20000*9600=192000000 bytes, so 192000000 /1024/1024 = 183MB

The above is for one single extent, so 15 times that is 2746MB per volume, and that times maximum 59 volumes is 162048MB, well above your &MAXSIZE

I suggest you utilise the ACS Testcase facility in ISMF;7 to test what would happen when you have input the various SPACE options and the LRECL etc.

Pete Wilson · Posted: Wed Feb 26, 2014 2:09 pm

Actually I started to question myself over this and told myself RTFM, (which you could have done!), and found this:http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ickug00%2Fbuld.htm

Noet what it says for the RECALL environment. Your dataset may have found its way to the wrong pool if it had been migrated and then recalled because the &SIZE and &MAXSIZE variables have no value in that environment. It depends what else you have in your ACS routines. Again try out the various options using the Testcase facility for both the ALLOCATE and RECALL environments.

Ensuring correct values for &SIZE and &MAXSIZE
If you allocate a data set using the TSO/E ALLOCATE command and you do not explicitly specify space requirements, then &SIZE and &MAXSIZE do not contain the correct values. Instead they both contain a value of zero. If your ACS routines rely on the values of &SIZE or &MAXSIZE in this situation, the data set might be assigned to the wrong class or group.

For a VSAM data set definition, the &SIZE and &MAXSIZE read-only variables reflect the space value specified in the CLUSTER component. If one is not specified in the CLUSTER component, then the space value specified in the DATA component is used. If a space value also is specified for the INDEX component and it is of the same type of space unit; for example, both are in tracks, cylinders, KB or MB, it is added to what was specified for the DATA component. If the INDEX component space unit is not of the same type as specified for the DATA component, it is ignored and not added to &SIZE or &MAXSIZE. For DFSORT work data sets, &SIZE and &MAXSIZE are zero. In the RECALL environment, &SIZE and &MAXSIZE are zero for empty partitioned data set and PS data sets because the size of the existing data set is not known at the time that DFSMS runs its ACS routines.

As input to data class ACS routine, &SIZE and &MAXSIZE are calculated from space information from JCL or IDCAMS, as follows:

•For non-VSAM data sets:
◦&SIZE = P + Directory (if any).
◦&MAXSIZE = P + (S*15) + Directory (if any).
•For VSAM data sets:
◦&SIZE = P.
◦&MAXSIZE = P + (S*254).
After data class is derived by the data class ACS routine, &SIZE and &MAXSIZE are recalculated depending on whether Extent Constraint Removal is specified or not in the selected data class before calling subsequent data class routines, as follows:

•For non-VSAM data sets, if no space is specified on JCL, then the space values defined in the selected data class are used to recalculate &SIZE and &MAXSIZE as follows:
◦&SIZE = P + Directory (if any).
◦&MAXSIZE = P + (S*15) + Directory (if any).
•For VSAM data sets, regardless whether space is specified or not, &MAXSIZE is recalculated depending on the specification of Extent Constraint Removal attribute as follows:
◦If Extent Constraint Removal = NO, then &MAXSIZE = P + (S*122)*volcnt.
◦If Extent Constraint Removal = YES, and the ADD' '1 Volume Amount in Data Class = P, then &MAXSIZE = ((P+S*122))*volcnt.
◦If Extent Constraint Removal = YES, and the ADD' '1 Volume Amount in Data Class = S, then &MAXSIZE = ((P+S*122)) + ((S*123)*(volcnt-1)).

vini m · New User Joined: 27 Nov 2008 Posts: 16 Location: singapore

yes Wilson , Exactly this is what I read and calculated the values and posted.

First thing this is a GDS so nonvsam , it doesn't have extent constraint removal ,no directory blocks hence the straight formula is as above mentioned ◦&SIZE = P , ◦&MAXSIZE = P + (S*15) .

I already did the test case and found the result going to bigger pool with same values that is why not able to understand how this logic is satisfied
as you mentioned the AND for MAXSIZE . No other logic satisfied in acs routine except this which I am very sure.

I tried to create a dataset with same coding in jcl and went to big pool , also it got Block size as 27998

enrico-sorichetti · Posted: Wed Feb 26, 2014 3:31 pm

might not apply...
but allocation computations might be clobbered by an invalid/misleading
definition of the default device geometry ...

vini m · New User Joined: 27 Nov 2008 Posts: 16 Location: singapore

Good point Enrico ,though same values are there in my site too .

Default Device Geometry :
Bytes/track . . . . . : 56664
Tracks/cylinder . . . : 15

enrico-sorichetti · Posted: Wed Feb 26, 2014 3:39 pm

what happened when You tried to allocate without the volume count ???

vini m · New User Joined: 27 Nov 2008 Posts: 16 Location: singapore

Same thing I see , no difference.. With volume count or without its getting 59 volumes only .Tried the other way too having volcount and unit=sysalda same effect no difference I could see .

Pete Wilson · Posted: Wed Feb 26, 2014 6:59 pm

I ran a test allocation as per your example DD (fixing syntax error ...you missed a right bracket on the SPACE parm)

The size of the file allocated was 4800trks which is around 256-259MB depending how you calculate it. This exceeds your &SIZE value and &MAXSIZE values (assuming 15 * 256MB = 3844MB)

We can't see where this WHEN statement is in relation to other WHEN's or SELECT groups and their relative END and EXIT statements. There may be something else that takes precedence to this code, or later code is taking effect if you haven't coded an EXIT after your OTHERWISE. Is PRDSML assigned anywhere else in the code for example? You may need to get a few WRITE statements in the appropriate parts of the code to work out when the assignments are being made.

I'd also be inclined to change your criteria to the following as it would make more sense I believe:

WHEN ((&SIZE LT 212MB AND &MAXSIZE LT 848MB) OR
(&DSORG EQ 'VS' ))