IBM Support

OW05287: THE V NET,XXX,UPDATE=ALL WAS ISSUED TO CHANGE THE IDNUM BUT THE UPDATE WAS NOT PERFORMED.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • V NET,xxx,UPDATE=ALL was issued to change the IDNUM on a
    switched major node. The command executed ok but the update
    was not done. This resulted in ABEND0C4 in ISTACCQ3 at
    offset X'27A2' level UY91902. During recreation the
    UPDATE=ALL continued to fail but the subsequent abend was
    not seen.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All using V NET,ACT,ID=swnode,UPDATE=ALL     *
    *                 to change IDBLK or IDNUM.                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: Station ID (IDBLK/IDNUM) is not         *
    *                      changed when dynamic reconfiguration    *
    *                      is done with V NET,ACT,ID=swmajnode,    *
    *                      UPDATE=ALL. Subsequent ABEND0C4s        *
    *                      can occur in ISTACCQ3 + X'27A2'         *
    *                      attempting to establish a dial-in       *
    *                      connection using the old station ID.    *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    An attempt was made to change IDNUM using the enhanced
    dynamic reconfiguration introduced in V4R1 by changing the
    value of IDNUM on a PU in a switched major node and issuing
    the V NET,ACT,ID=swmajnode,UPDATE=ALL command. There were no
    error messages issued. However, when a dial-in connection
    was attempted using the OLD station ID (IDBLK/IDNUM), ABEND0C4
    in ISTACCQ3 at X'27A2' occurred.
    
    ISTSDCDR, in doing the dynamic change, put the new station ID
    in the PU's RDTE, but it was not SRTADDed and the original
    station ID, which was SRTADDed when the major node was
    originally activated, was not SRTDELed. The switched major node
    was then inactivated, freeing the RDTE storage. When a REQUEST
    CONTACT (REQCONT) came in with the original station ID, a
    SRTFIND was done for that station ID and it was found since it
    never got deleted. The entry that was found still pointed to
    the RDTE that had since been freed. That storage no longer
    belonged to VTAM so an ABEND0C4 occurred.
    
    An additional symptom is that an attempt to establish a dial-in
    connection using the new station ID fails with MSGIST690I and
    MSGIST081I:
      IST690I CONNECTION REQUEST DENIED - INVALID STATION ID
      IST081I LINE NAME = xxxxx LINE GROUP = yyyyy MAJNOD = zzzzz
    because the new station ID was never SRTADDed.
    

Problem conclusion

  • ISTSDCDR has been changed to SRTDEL the old station ID and
    SRTADD the new station ID when IDBLK or IDNUM are changed
    with enhanced dynamic reconfiguration. If the new station
    ID is the same as one already in the network, the V NET,ACT,
    ID=swmajnode,UPDATE=ALL command will fail with MSGIST886I
    and MSGIST523I:
      IST886I VARY ACT swmajnode CHANGE puname FAILED
      IST523I REASON = DUPLICATE STATION ID
    
    VTAM V4R2 Messages and Codes (SC31-6493-0) will be changed on
    page 5-231 under message IST886I for the VARY ACT command to
    add the following new reason value for message IST523I:
      DUPLICATE STATION ID
        An attempt was made to perform a DR CHANGE of IDBLK or
        IDNUM for a switched PU, but the resulting Station ID was
        not unique in the network.
    

Temporary fix

Comments

APAR Information

  • APAR number

    OW05287

  • Reported component name

    VTAM V4 MVS/ESA

  • Reported component ID

    569511701

  • Reported release

    101

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    1994-05-20

  • Closed date

    1994-06-10

  • Last modified date

    1994-10-31

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UW08125 UW08126

Modules/Macros

  • ISTMSGCN ISTSDCDR IST500C
    

Publications Referenced
SC31649300    

Fix information

  • Fixed component name

    VTAM V4 MVS/ESA

  • Fixed component ID

    569511701

Applicable component levels

  • R101 PSY UW08125

       UP94/07/29 P F407

  • R201 PSY UW08126

       UP94/07/29 P F407

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":"101","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":"101","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
31 October 1994