Techsys Mainframe Blog

z/OS Problem Determination Series - Day 13

One of the biggest changes in applications development in my 30 years in the mainframe business has been the drop in memory costs. Without this drop, there would be no C++, JAVA, or TCP/IP on the mainframe (or any other platform???). Memory, among other things, helps provide the infrastructure that we take for granted these days.

Today, medium complexity applications regularly use 1-2MB when written in C++ and JAVA. I have seen vendor applications that use upwards of 500MB in order to get acceptable performance. In contrast, a heavily loaded CICS with 500+ users ran on 8-10MB of storage 20 years ago. Perhaps a bit of a rant, but as long as memory is cheap and we are not running short of it, my desire to minimize storage utilization is a low priority issue.

Today's topic has to do with x78 abends. As we learned yesterday, abends are sometimes grouped by the SVC that generates the error. SVC 78, GETMAIN & FREEMAIN, is the source of all x78 abends.

First, a bit of a discussion on GETMAIN processing. The parameters required to complete a GETMAIN request are:

• Type of storage to allocate
• Where to allocate it
• Length of storage
• Where to return the storage address

For most applications, the type if storage is private storage either below or above the 16MB line. Typically, there is 8-10 MB of storage available below the 16MB line for application usage. The remainder of the storage below the 16MB line is reserved for the operating system. Above the 16MB line, the vast majority of the address range from 16MB to 2GB (31-bit addressing) is available for application usage.

Because the integrity of the z/OS operating system environment depends on it, there are a variety of system exits & parameters to control how much storage a single user can allocate. Typically, when you get an x78 abend while trying to GETMAIN memory, these artificial limitations are what is stopping you.

The parameters required to perform a FREEMAIN request are as follows:

• Type of storage
• Address of the storage
• Length of the storage

As a rule of thumb, I always try to maintain a 1:1 ratio between by GETMAIN & FREEMAIN requests. In other words, partial FREEMAINs are not a good idea, unless you have a really good memory management process in place. IBM may prevent you from doing this anyway, since the operating system has to maintain awareness of who owns all storage and what storage is free at any point in time.

Now that we have a better idea of how storage is obtained and freed, let's look at the errors that may occur during this process. The x78 abends that can occur during this process are:

• S078 - The master catalog cannot be opened. 
• S178 - Unable to satisfy system subpool GETMAIN request.
• S278 - There is no central storage availble to process a LSQA request. Not one that application programmers would ever see.
• S378 - An error occured during FREEMAIN processing. Double-check all values on the FREEMAIN to insure they match the associated GETMAIN request.
• S478 - You are attempting to FREEMAIN storage from a subpool that in ineligible for FREEMAIN
• S778 - A machine error has occurred. I would double-check everything, then contact your systems programmer. I have never seen this one.
• S878 - Hands down the most common x78 abend! Increasing region size is the most common remedy. I personally try to go to REGION=0M and run (virtually) unlimited. I say virtually since JES parameters, SMF exits, and z/OS exits can be in place to "limit" the amount of storage available. If you think you are being restricted, and need more memory, talk with your systems programmer to find out what your limits are.
• S978 - The storage you are attempting to FREEMAIN is not on a doubleword (8 byte) boundary. Double-check the address of the storage being freed.
• SA78 - Nine times out of ten,in my experience, the length of the storage being freed is incorrect and there is an overlap with freed storage. The system trace is sometimes useful in this case to make sure the GETMAIN & FREEMAIN lengths are identical.
• SB78 - The majority of the errors for this abend are related to invalid subpools, trying to free storage from a system subpool, or lack of authorization to free storage. See the corresponding return code in the MVS Systems Codes doc for more information.
• SC78 - A CPOOL get/free request failed (it is not likely that you will observe this in an application program)
• SD78 - A FREEMAIN request for LSQA storage is not owned by your task (you are attempting to free another tasks storage)

While this may be a good quick reference, the MVS Systems Codes (via LookAt) manual is the place to go when you receive any sort of x78 abend.

Tomorrow we will look at the final series of abends - the x22 series.