IBM Mainframe Forum

Hello,

Because this is how you specified the secondaries be alocated . . .

For more complete information, suggest you read about secondary allocations in the JCL Reference manual.

samb01 wrote:Hello steve-myers,

could you explain me why ?

It's a secondary extent, isn't it? As far as I know, the intended the primary allocation is not a data set attribute, so it cannot be retrieved. Only the specified secondary allocation can be retrieved.

The B37 occured just after the reduce :



i can't anderstand why the dataset didn't extent it'self to other volume... In the JCL i wrote :

since the add-on product(*) used changes the standard space allocation behavior
the best place to look for an explanation is the add-on documentation
or try to run the same jcl using datasets NOT controlled by the add-on

(*) the thing that issues the VAM.... messages

Hello,

93 was used because 1000 was not available.

Suggest you do as mentioned earlier and change the 30 to 59.

If your output is so large why not write it to tape? You can always write it back to dasd later.

samb01 wrote:... could you explain me why ?

The primary space allocation for a data set is not retained as a data set attribute. While it might be possible to retrieve the size of the first extent of a data set and call it the "primary" allocation, it may not reflect the true value of the primary space specified when the data set was allocated for several reasons.

• The primary allocation may be split into 4 addition extents. For example, your 5000 cylinder primary allocation could be allocated as 5 1000 cylinder extents, or, perhaps 1 4000 cylinder extent and 4 250 cylinder extents.
• Parts of the initial allocation could be released after the allocation, though that seems unlikely for your example.

Another suggestion made in this thread is to replace disk storage with tape storage. After all, we can get an operator or tape robot to mount tapes seemingly forever, can't we? Another suggestion: replace the volume limit with the maximum of 30 to 59,the maximum number of volumes that can be specified. Of course, we don't know how many volumes are available.

Just to go somewhat off topic.

The true age of the concepts for space management are really reflected in the continued use of very device dependent concepts. *nix heads and Windoze heads will proudly tell us "... we don't have any of that cylinder and track c*** in our system, nor do we restrict space for our files like you MVS dinosaurs do." On the other hand, *nix and Windoze do not have the ability to extend a very large file to a new "mount point" in *nix (the nearest equivalent to a volume in MVS) or some other place in Windoze. In the middle 1960s, when most of this stuff was planned, disk storage was seen as temporary storage for bulk data stored on tape. Disk storage was regarded as very expensive, and less reliable than magnetic tape.

With the advent of System Managed Storage in the 1990s, it appeared IBM was trying to use default space requests to replace the JCL specified SPACE parameter. IBM's users never seemed to embrace this concept, perhaps because it denied the flexibility of the direct use of the SPACE parameter.