SE37 with reason code 8.

[Mainframe help]

Hi,

We are getting SE-37 with reason code 8. I 've looked at the reason behind it:

08
A multi-volume physical sequential data set was being written on a direct
access device. All space was filled on the volume, and an attempt was made
to obtain space on the next specified volume. Either the space was not
available on that volume, the data set already existed on that volume, or
there is no space available in the VTOC or the VTOC index. The message
contains the volume serial number of the last volume used.
0C
An exit routine (such as IGGPRE00) associated with the IGGPRE00_EXIT
preprocessing dynamic exit, rejected the extend request.

System action
~~~~~~~~~~~~~

The task is ended unless the error is to be ignored as specified in the DCB
ABEND exit routine. If the error is to be ignored, the system will attempt to
close the DCB before returning to the user.
Operator response
~~~~~~~~~~~~~~~~~
Start a generalized trace facility (GTF) trace, and re-create the problem.
Reply to message AHL100A with:

TRACE=SYS,USR,SLIP

On the DD statement for the data set in error, specify:

DCB=DIAGNS=TRACE

System programmer response
~~~~~~~~~~~~~~~~~~~~~~~~~~
If the error recurs and the program is not in error, look at the messages in
the job log for more information. Search problem reporting data bases for a
fix for the problem. If no fix exists, contact the IBM Support Center. Provide
the SYSOUT output for the job.

Programmer response
~~~~~~~~~~~~~~~~~~~

Probable user error. Correct the errors causing the abnormal end as indicated
by the return code in the message text as follows:

For return code 04, case 1, specify at least one more volume than the number
of volumes previously used for the data set. For case 2, specify a different
volume for the partitioned data set or specify more space for the VIO data
set.
For case 3, either specify a volume for the data set, use a utility program to
reorganize the volume so that data sets will not be fragmented (that is, no
more than 16 extents used for this data set), or change the program so that a
device will be free when a volume must be mounted.

For return code 08, either specify a new volume to continue the data set or
make sure that enough space is available on the volumes already specified.
Ensure that the data set does not already exist on the volumes to be used. In
all cases, rerun the job.

For return code 0C, consult your installation procedures.

That means the if I add more volumes it'll help? Instead of just increasing the space (CYL(?,?)), right?

[Robert Sample]

Increasing the space will do little, if anything, to your error. The message is telling you that space was not available on the NEXT volume, or the data set already exists on the NEXT volume, or there is no space on the NEXT volume's VTOC / VTOC INDEX -- none of these conditions will be helped by increasing the space parameter. Adding volumes MAY help -- if there additional volumes that can be added in the storage group, or if the data set is not SMS-managed. If the data set is on every volume in the storage group then you won't be able to add volumes.

[Mainframe help]

Thank you.

Actually there is a business logic behind which is lie this:

This is a VSAM file and there is a screen using which business will add the entries in this file. Now the file is loaded in a table in a COBOL program where table OCCURS 2000 times. While the program abended by displaying the counter of 5001. The counter in the COBOL program adds 1 to every read from the table. Because of that I see there are two problems:

1. They are checking on the subscript of the table.
2. Even if I increase the volume, which you said is not going to help, then it might not help.

In this situation, what is the best approach to solve it?

I was thiking that we should create a process which will limit the entires in the file somehow? They are Tax values in the file actually, and they keep on adding it but there is no timestamp using which I could delete the entries. Is there any way to know when the data was entered in the file using the screen? That way I can say the business that if the entry is old by these many days, they might be deleted.

[Robert Sample]

In order to know when a particular record was added to a VSAM data set, the application MUST add a timestamp of some sort to the record. Without a timestamp, there is no way to determine when a particular record was added. So you've got the first application logic error right there.

It is not clear from your post how the COBOL program got to a count of 5000 -- does it read each record multiple times, or are there actually 5000 records in the data set? If the table is set to 2000 entries and the COBOL program placed 5000 entries in the table, that would be application logic error number 2.

The third application logic error is that there should be some way in the application to limit the number of records, or to archive old ones out of the VSAM data set.

It is not clear from your post how many records are actually in the VSAM data set -- have you done a LISTCAT to see what it looks like? If not, why not -- that should be one of the FIRST things you do to figure out the problem.

The best solution would be an application rewrite to include a timestamp on the records, an archival method for old records, and a realistic calculation about just how big the VSAM data set needs to be. Barring that, the next best solution would be to work with your site support group to determine where to place this data set to minimize growing pains and ensure it is adequately sized.

[Mainframe help]

If the data set is on every volume in the storage group then you won't be able to add volumes.

What does 'being on every volume' mean?

[nicc]

It means it has space allocated on every volume because it had to use every volume to find enough space to meet the SPACE+ request.

[Robert Sample]

A data set is limited to 59 volumes. If the storage pool has 59 or fewer volumes in it, a large data set could place data on every volume in the storage pool. If such a case happened, the site support group would have to add volumes to the storage pool or the data set could be moved to a different storage pool or the data set could not grow past its current limit. If the storage pool has more than 59 volumes, it would be possible for the data set to use 59 volumes. However, in such a case I do not think you'd get an SE37-8 ABEND (I'm not sure what ABEND code you'd get).

[Pragya]

A data set is limited to 59 volumes. 

Is it a rule for Mainframe?

[Robert Sample]

Per the MVS JCL Reference manual, a DASD data set is limited to 59 volumes -- period. A tape data set can use up to 255 volumes. Since the original post referenced DASD volumes, I put the limit into my post.

[Pragya]

Thanks Robert. I was trying to understand that statement. Got it now.