IBM Support

II07932: ADSM TAPE PROCESSING. SETTING UP ADSM TO WORK WITH A TAPE MANAGEMENT SYSTEM, TMS

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as canceled.

Error description

  • 564802001 ADSM MVS
    564802002 ADSM VM
                         ADSM Tape Volumes
    
        Each physical tape volume represents to ADSM a
    logical volume. This logical volume is know (defined)
    to ADSM by is volser as found in the tape volume label.
    Each logical volume is a single standard label data set.
    The ADSM data base keeps track of the files on a logical
    tape volume by the physical blockid of the file on the
    tape. The name of the data set on each volume is the same
    within a storage pool, the high level qualifier of which
    can be controlled by the prefix option in the device class
    of the storage pool to which the tape volume belongs.
    The data sets cannot be cataloged. ADSM manages his tape
    volumes based on the volser. Before ADSM can use a tape
    it must have a volser in the standard volume1 label.
    
        There are two ways in which ADSM can acquire a tape
    volume:
        1) The ADSM administrator can define tape volumes to
           ADSM with the define vol command.
        2) ASDM can request a scratch volume. This is done
           by specifying a maxscratch value in the ADSM tape
           storage pool.
        If no volumes are defined by the administrator and no
    value for maxscratch is specified then there will be no
    storage available in this storage pool.
    
    
           Setting up ADSM with your Tape Management System
    
         Since most MVS shops have a Tape Management System (TMS)
     of one flavor or another they will probably want ADSM to
     use scratch tapes from the scratch pool controlled by the
     (TMS). While each TMS may be a little bit different, the
     following are the basic steps needed to set up ADSM to
     work properly with the TMS:
        1) ADSM needs to be defined to the TMS as an external
           data manager (EDM).
        2) ADSM needs to tell the TMS that a volume needs to
           be permanently retained. The most common way this
           this is done via the expiration date which is set
           up in the device class definition within ADSM. The
           storage group to which your tape volumes belong then
           need to have this device class. An expiration date of
           99365 is the most common value used to indicate
           permanent retention. Although other values can be
           used as long as the TMS understands the value to
           mean permanent retention. The retention value may
           may also be used if this is what the TMS understands
           as meaning permanent retention.
             The following command will update the default
             cartridge device class with an expiration of 99356:
                    UPDATE DEV CARTRIDGE EXP=99356
        3) A deletion exit needs to be specified in the server
           options file. The exit shipped with HSM, ARCTVEXT
           can be used as well as any other exit shipped by the
           TMS for this purpose. The ADSM Admin Guide discusses
           the use of the deletion exit in chapter 16.
    For TMS (CA-1)system please use the TMSARCTV module which is
    shiped with by TMS for EXIT.
       When ADSM needs a new scratch volume he will ask for a
    private mount. The TMS can then give ADSM a volume from the
    scratch pool. ADSM uses the volser of this tape to define
    the volume to the storage pool. The data set labels are
    rewritten with the expiration date from the device class
    and the data set name. When the TMS sees this expiration
    date he flags this volume for permanent retention. The
    TMS also marks it as an EDM tape in his data base. When
    the tape volume becomes empty, usually due to reclamation
    it is deleted from ADSM. During the deletion process the
    deletion exit is driven which notifies the TMS that he
    can return this tape to the scratch pool.
    
                     Common Tape Problems
    
    1) ADSM data gets overwritten.
          This usually means that the expiration date is not
          set up in the device class. It may not be there at
          all or it may not be the value that a TMS
          recognizes as meaning permanent retention. Also
          make sure that ADSM is defined to the TMS as an
          EDM.
    2) An ADSM tape mount request fails with an indication
       that the tape is not scratch.
          ADSM opens empty tapes for output. If a defined
          tape is empty ADSM will make a specific request
          for this volume and open it for output. A TMS
          may not like this and fail the mount request.
          Since ADSM is an EDM it should have the right
          to open a tape it owns for output. CA1 is working
          on a fix for this problem with the key symptom
          being a TMS NOT SCRTCH (20) message.
       ******************** WARNING NOTE *******************
          CA1 had a fix for this problem that ended up in
          error. Please be sure to contact CA1 to make sure
          you have the right fix from them.
       *****************************************************
    3) A tape volume is not deleted after being reclaimed.
          This is an ADSM bug fixed at MVS server level 6
          (un57558/un57559) and above. This will often
          cause a defined empty tape to exist which can
          result in problem 2 above.
    4) IKJ56221 message indicating tape volume already in
       use and ADSM is the one using it.
          This is an ADSM bug and is fixed at MVS server
          level 7 (un59062/un50963) and above.
    5) Tape mount requests even though data going to disk
       storage pool.
          ADSM will bind client directories to the
          management class with the longest retention
          period. If two management classes exists in a
          given policy one with a copy group whose copy
          destination is to a tape pool and one with a
          copy group whose copy destination is to disk,
          and the retention of the class going to tape
          is longer then a tape mount will be requested
          for the backup of directories. If the
          retention of the two class is equal then the
          class to tape may also be chosen resulting
          in a tape mount. Since nothing is usually
          written to the storage pool for directories
          (with the exception of ACL data) the tape
          may end up empty and defined. To fix this
          problem use the dirmc option in the clients
          option file to make sure the directories are
          bound to the management class going to disk.
    

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

  • APAR number

    II07932

  • Reported component name

    PA LIB INFO ITE

  • Reported component ID

    INFOPALIB

  • Reported release

    001

  • Status

    CLOSED CAN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    1994-05-23

  • Closed date

    2015-12-17

  • Last modified date

    2015-12-17

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

    II07929

  • 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":"SG32M","label":"APARs - VSE\/ESA 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"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG27M","label":"APARs - z\/VM environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB16","label":"Mainframe HW"}}]

Document Information

Modified date:
14 December 2020