Techsys Mainframe Blog

z/OS Problem Determination Series - Day 12

Today we look at the most common of the x37 type abends. All are related to EOV (end of volume) processing and can typically be avoided by proper dataset allocation.

Did you know?

Before we get into proper dataset allocation techniques, note that the "37" in all the x37 abends is related to EOV processing. This also corresponds to the EOV SVC being x'37'. Sometimes knowing the SVC function when looking at an abend code can help determine the function that was being performed when the failure occured. For instance, x78 abends all have to do with GETMAIN/FREEMAIN (SVC 78) as we will focus on tomorrow.

A word on dataset allocation!

OK, back to dataset allocation problems... z/OS allocates non-VSAM datasets much differently than files are allocated on other platforms. Some will argue this is better, others say it is much worse. Once you figure it out, the only thing that matters - it works.

Each time we allocate a dataset, we should consider the following:

* How many records will be placed in the dataset?
* What is the record length?
* What kind of growth is anticipated in the dataset?

Once this information is gathered, we can determine how to allocate the dataset. For an example, I want to build a dataset with 80 byte records, with 50,000 records, and a 20% annual growth.

First we need to decide how many tracks or cylinders that we need to hold the dataset. A 3390 model 3 track holds 56,664 bytes. I personally always use 56,000 as a maximum because I can remember this value. This means that 700 records could fit on each track. Since we cannot place partial records on tracks, always round this down to the next lowest whole even number. Based on 700 records per track, it appears it will take 71.42 tracks to hold our anticipated 50,000 records (50K / 700 = 71.42). We want to round this number up to 72 tracks.

Anytime the number of tracks is greater than 15, which is the number of tracks per cylinder, I typically try to convert my allocations to cylinders. In this case, I would want 5 (72 / 15 = 4.8, then rounded up) cylinders to hold my primary extent.

Based upon my anticipated growth of 20% annually, I would allocate the the secondary extents at 1 cylinder each. z/OS will take up to 16 extents to extend a non-VSAM dataset. Once z/OS has exhausted the 16 extents, you will receive a x37 abend.

Another thing to remember is that z/OS will take up to 4 extents to satisfy the primary allocation. This can happen when disk volumes become highly fragmented, and there is not enough contiguous space to satisfy the primary allocation request. Therefore, highly fragmented disks can and will cause premature x37 abends as a result of this "feature".

So, to avoid problems I recommend:

* Always attempt to fit the file in one extent.
* Occaisionally review extent counts if you don't have a full-time storage administrator
* Re-allocate, or modify the JCL for new allocations, once datasets get over 8-10 extents

I know all this is a hassle, but it has serious performance & recovery implications.

Common x37 Abends

The most common x37 abends are as follows:

• B37 - The error was detected by the end-of-volume routine. This system completion code is accompanied by message IEC030I. When reviewing the IEC030I message, the most common problem is the Rc=4 condition. In most cases this is as a result of the "The data set already had 16 extents, but required more space" condition. The solution is to re-calculate the values for the primary & secondary extents, then re-submit the job.
• D37 - The error occurred when an output operation to a direct access device was requested. This system completion code is accompanied by message IEC031I. After reviewing the IEC031I message is that the dataset was allocated with no secondary extent. In this case, reallocate the dataset with a larger primary extent, or add secondary extents. Keep in mind that some applications cannot handle secondary extents, but these are rare.
• E37 - The error occurred when an output operation was requested. The data set was on a direct access or magnetic tape device. This system completion code is accompanied by message IEC032I. The RC=4 is the most common here also. Typically, you have either hit the 16 extent limit or the volume was full and could not create another extent on the volume.
  

While it seems to be a lot of work to keep the primary and secondary extent information optimized, the time to fix x37 abends and recover your batch processing is far greater. There are tools to make this much easier. There are numerous tools to report file extent information before problems occur. There is also system software to intercept the x37 abends and correct them automatically, allowing batch processing to continue without the need for a recovery scenario.

Tomorrow, we will look into the X78 GETMAIN/FREEMAIN related failures...