A fix is available
APAR status
Closed as program error.
Error description
Loop occurred in EZACA03P(MVPVTAMP) VTMDIDIT routine(around offs et 49E) while processing VTRQ on GCBVQEL@ queue. The VTRQ on GCBVQEL@ was already freed and on the Free_VTRQ chain. More than 30000 VTRQs were on the Free_VTRQ queue and caused high CPU usage for half an hour.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All, Telnet users. * **************************************************************** * PROBLEM DESCRIPTION: A loop occurred in MVPVTAMP (VTMDIDIT) * * while processing VTRQs on the GCBVQEL * * queue. The VTRQ was already freed and * * on the Free_VTRQ chain. When a VTRQ * * for a Reply_Sent_Op_Code was dequeue * * it brought with it more than 30,000 * * VTRQs resulting in high CPU usage. * **************************************************************** * RECOMMENDATION: * **************************************************************** The problem is timing related. While one procedure was in the process of dequeuing a work request(VTRQ), via a CS instruction. Another process was adding the VTRQ to the Freequeue chain. When this occurred all VTRQ's on the Free_Queue were moved by mistake to the GCBVQEL queue, thus causing the problem of running the long queue(loop). 90% of all VTRQs on the chain were for Reply_Sent_Op_Code requests. There are two modules that can free the Reply_Sent VTRQs (MVPVIVSP and MVPVTAMP). Currently there is no way of knowing which module will free the request. Thus the possibility exists where, MVPVIVSP frees the request and the VTRQ may be re-used and placed on the top of the GCBVQEL LIFO queue. When MVPVTAMP receives control it attempts to complete its processing of the original VTRQ by freeing it and placing it back on the free chain.
Problem conclusion
Modules MVPVTAMP(EZACA03P), MVPVIVSP(EZACA03s) and MVPVVECP (EZACA03T) were changed to verify if the VTRQ is on the VTRQ free chain before trying to use it. The MVPVCOM control block was changed to add a new bit within the VTRQ mapping to indicate when the VTRQ is placed on the Free_Chain. * Cross Reference between External and Internal Names EZACA02S (MVPVIVSP) EZACA03P (MVPVTAMP) EZACA03T (MVPVVECP) EZADD01O (MVPVCOM ) EZACA02S (MVPVIVSP) EZACA03P (MVPVTAMP) EZACA03T (MVPVVECP) EZADD01O (MVPVCOM )
Temporary fix
Comments
APAR Information
APAR number
PQ06182
Reported component name
TCP/IP V3 MVS
Reported component ID
5655HAL00
Reported release
310
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
1997-07-07
Closed date
1997-10-10
Last modified date
1997-11-02
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UQ10229 UQ10230
Modules/Macros
EZACA02S EZACA03P EZACA03T EZADD01O
Fix information
Fixed component name
TCP/IP V3 MVS
Fixed component ID
5655HAL00
Applicable component levels
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"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":"310","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCY4DZ","label":"DO NOT USE"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"310","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
02 November 1997