ADSM-L

Warning for MVS servers

1996-07-08 14:02:00
Subject: Warning for MVS servers
From: Bill Colwell <bcolwell AT CCLINK.DRAPER DOT COM>
Date: Mon, 8 Jul 1996 14:02:00 -0400
I found apar PN86338 on IBMlink this morning and was quite alarmed by it.
I have made the changes it recommends, but not restarted the server yet.
Here is the apar text.

Bill Colwell
The Charles Stark Draper Laboratory
Cambridge Ma.
- - apar PN86338 - - -
Item PN86338


  APAR Identifier ...... PN86338      Last Changed ........ 96/07/03
  ADSM SERVER PERFORMANCE PROBLEM ON START OR BACKUP DB WITH IF
  MOVEBATCHSIZE AND TXNGROUPMAX ARE SET VERY HIGH.
  Symptom ...... PR PERFM             Status ........... INTRAN
  Severity ................... 2      Date Closed .........
  Component .......... 565511901      Duplicate of ........
  Reported Release ......... 210      Fixed Release ............
  Component Name ADSM MVS SERVER      Special Notice
  Current Target Date ..              Flags
  SCP ...................
  Platform ............
  Status Detail: Not Available
  PE PTF List:
  PTF List:

  Parent APAR:
  Child APAR list:

  ERROR DESCRIPTION:
  The ADSM server was halted after an attempt to backup
  the database failed to respond for a long period of
  time.  A Backup DB command was issued to backup the
  database.  Before halting the server a cancel process
  was issued to cancel the backup db, the process never
  ended.  When they tried to re-start ADSM it just hung.
  The last message seen on the activity log was
  ' ANR0353I Recovery log analysis pass in progress. '.
  .
  It was determined that excessive MOVEBATCHSIZE and
  TXNGROUPMAX specifications on the ADSM server caused
  ADSM to encounter a boundary condition on checkpointing
  the server recovery log.  The situation was realized
  when an on-line database backup hung and the server
  would not restart (hung in the analysis pass) for
  an excessive amount of time.
  .
  While this causes a sever performance problem the
  server works OK.  You have two chooses to get past
  this problem occurs. 1) Allow the recovery log
  analysis to complete.  This can take a VERY long
  time. or 2) Restore a previous database backup and
  perform the audit volume command after the server
  is up to resync the database with the data volumes.
  .
  To keep from having the problem in the future IBM
  recommends that MOVEBATCHSIZE and TXNGROUPMAX size
  both be set to a moderate value like 100, for each
  specification.  We know that these values result in
  very good performance, but such gains are immediately
  lost when this problem is encountered.
  .
  If you have already experienced the performance problem
  and go back and modify MOVEBATCHSIZE AND TXNGROUPMAX
  and restart the server.  This will have no effect
  and you will still have a performance problem.
  The recommended changes to MOVEBATCHSIZE and TXNGROUPMAX
  need to be made prior to the known performance problem,
  to keep the performance problem from occurring.

  LOCAL FIX:
<Prev in Thread] Current Thread [Next in Thread>