APAR status
Closed as canceled.
Error description
*************************************************************** * PROLOG: * *************************************************************** This is one of the APARs in a series of INFO APARs created to assist you in the initial diagnosis of VTAM storage problems. There are currently four INFO APARs in this series and others may be added if needed. The current APARs are as follows: II06752 VTAM Storage Diagnosis - An Introduction/Overview II04548 VTAM Storage Diagnosis - Documentation Requirements II07563 VTAM Storage Diagnosis - Private Storage Problems II07564 VTAM Storage Diagnosis - Common Storage (CSA) Problems II09086 VTAM Storage Diagnosis - ABEND0C4 in ISTORCFB II09095 VTAM Storage Diagnosis - MSGIST565I During Activation -------------------------------------------------------------- This APAR discusses the diagnosis of VTAM Private storage problems. You have reached this point as a result of being guided here from II06752 or by knowing from prior experience that you have a Private storage problem. You also should have gathered the necessary documentation as stated in II04548. It is also assumed you have used the VTAM Storage Estimates Worksheet and have set the RGN= parameter in your VTAM PROC to the proper size for your network configuration. Experience has proven you can spend a lot of hours trying to diagnose a problem when there really is no problem and VTAM has validly ran of storage because the requirements were underestimated. *************************************************************** * OVERVIEW: * *************************************************************** VTAM consists of OCO code which is considered IBM Confidential. Therefore, the following subject matter will discuss only the information that is available in the customer copies of the VTAM manuals. The main intent here is to help you identify what is filling up storage so search arguments can be created to find the fixing APAR/PTF in IBMLINK or RETAIN. We have found it is much more efficient to MVS GETMAIN a pool of storage, consisting of one or more pages, and internally manage it within VTAM. These pools of storage can be expanded and contracted as needed. To accomplish this, we have a set of VTAM Storage Management routines which are called using the following internal macros: GETBLK/FREEBLK to acquire and release storage in the SPANC pools. These pools are internal to VTAM and the user does not define them in any way. SPANC pools reside in both Private and CSA storage. REQSTORE/RELSTORE to acquire and release a buffer from one of the fixed length buffer pools that reside in CSA only. These buffer pools are user defined in the VTAM START list, ATCSTRxx. VTALLOC/VTFREE to acquire and release all other variable length pieces of storage used internally by VTAM. In this case only, each VTALLOC or VTFREE does expand into an MVS GETMAIN or MVS FREEMAIN and the storage resides in both Private and CSA. The invocation of each of these macros creates an entry in the VTAM Internal Trace (VIT) if the SMS option has been specified. The format of these entries can be found in the VTAM Diagnosis manual under REQS, RELS, GBLK, FBLK, VTAL and VTFR. The SMS VIT entries can prove useful in determining if storage is being acquired and never being freed. They also point to the module requesting or freeing the storage. We will start the diagnosis with the easiest area of storage first and work our way on through, saving the most difficult for last. It is suggested you have a copy of the VTAM Data Areas, VTAM Diagnosis and IPCS Command Reference manuals handy for reference as needed. *************************************************************** * Fixed length buffer pools - REQSTORE/RELSTORE * *************************************************************** There are no fixed length buffer pools in Private storage, so your problem lies elsewhere. Continue on. *************************************************************** * SPANC Pool Storage - GETBLK/FREEBLK * *************************************************************** SPANC storage is allocated in both PRIVATE and CSA. The first thing to do is access the dump and run the SPANC CLIST from the IPCS command screen. From the output, you will be able to see how many pages are allocated to each SPANC. If you see any of them with a high page count you will want to look into them in greater detail. This page count will vary from one system to another based on network size and activity. As a general rule of thumb, anything with a page count over 1000 for any one pool could indicate a problem and should be investigated. If none of the SPANC pools appear to be out of line, leave the SPANC Pool section and go on to the next topic. Let's say, for instance, you are diagnosing a PVT problem and you see there are 2500 pages allocated to the RUPEPRIV SPANC. From this, you might guess this pool contains RUPE control blocks and resides in Private storage. This would be a true assumption. However, some of the SPANC names are not descriptive as to what control blocks they contain nor where they reside in storage. The SPANC CLIST in VTAM VER3 does not provide information about which area of storage the pool resides. VTAM VER4 and above does tell you where the pool resides. Take note of the pool(s) with the largest page count. If the page count for any of the pools is well over 1000 pages, you have probably found a problem area. You now have enough information to do an initial search to see if you have encountered a known problem. You will want to use the VTAM Release and SPANC pool name in your search. If you don't see any good hits on your search with the information known at this point, continue on to broaden your search. The next thing to do is run a more granular version of the SPANC CLIST which will list out the beginning address of each extent that is allocated to the pool in question. Extents for SPANC pools will be either x'1000' or x'10000' bytes depending on the pool involved. Enter: SPANC POOL(poolname) MAP You will now need to know how to lay out the storage pointed to by the output of the above command. Please refer to the VTAM Data Areas manual for the layout of the control blocks in the following discussion. SPANC storage is GETMAINed using the VTAM VTALLOC macro. This will cause a x'8' byte SCHDR to be added to storage beginning at the page boundary. If you feel you need more information on VTALLOC processing at this point, it is contained in the topic following this one. Immediately following the SCHDR is a PGHDR. It contains a forward and backward pointer to other pages of this pool if any exist. This is followed by two halfword fields. The first one is a relative byte offset to the first FBQE representing an available piece of free storage in this extent. The offset is relative to the beginning of the PGHDR in VER3 and relative to the first byte following the PGHDR in VER4 and above. The second halfword is a counter of elements in use in this extent. You should always expect to see a value in this counter. When it goes to zero, the pool will contract and this extent will be freed. Once the SCHDR and PGHDR has been added, a SPANC processing module will go through and set up the rest of the extent for future use. This consists of carving the extent into elements of a predefined length for each given pool and building a FBQE at the beginning of each element. FBQEs are x'8' bytes long and are easy to spot. They will always start at a doubleword boundary and the second word will contain x'FFFFFFFF'. The first word is a relative offset to the next FBQE. When one of these freed elements is allocated as the result of a GBLK request, the first FBQE pointed to by the PGHDR is then converted to a GBHDR. GBHDRs are also easy to spot in a dump. They are x'8' bytes long. The first word points back to the PGHDR for this extent and the second word contains x'80000000', indicating it is now allocated. When diagnosing the contents of the extent, it is a good idea to start by locating the SMHDR, PGHDR and all of the allocated GBHDRs. The storage immediately following the GBHDR now needs to be looked at in greater detail. This is the key to finding what is filling up storage and completing your search argument to find the fixing APAR/PTF. The storage could contain a VTAM control block. Check the first byte after the GBHDR against the list of VTAM Control Block Id Codes in the Appendix of the VTAM Data Areas. If you get a match on an ID Code and the storage matches up with the layout of that control block, you likely have founr the problem. Add that control block name to your search argument. However, the storage could contain control vectors, RU data, sense data or something else totally unrecognizable to you, especially if the SPANC name begins with 'UTIL'. Utility pools are just what their name implies, someplace to put stuff that needs to be in SPANC storage, but a specifically named SPANC has not yet been created for this purpose. You may need to call the VTAM Support Center for further assistance. LVL2 may require a VIT with OPT=SMS in order to identify the elements filling storage. *****
Local fix
Problem summary
Problem conclusion
Temporary fix
Comments
closing cancel
APAR Information
APAR number
II07563
Reported component name
V2 LIB INFO ITE
Reported component ID
INFOV2LIB
Reported release
001
Status
CLOSED CAN
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
1994-02-01
Closed date
1997-05-05
Last modified date
2008-05-13
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19N","label":"APARs - OS\/390 environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
14 December 2020