ADSM-L

Re: Expiration adsm 3.1.2.x

1999-04-05 15:00:16
Subject: Re: Expiration adsm 3.1.2.x
From: Bob Labrie <labrie AT US.IBM DOT COM>
Date: Mon, 5 Apr 1999 13:00:16 -0600
Hi,    3.1.2.20 ADSM for MVS PTF's UQ28270-UQ28275 and UQ28277-UQ28279 will
be COR closed tomorrow.
             Meanwhile,  the PTF's are available on the IBM anonymous FTP
server index.storsys.ibm.com in
              /adsm/fixes/v3r1/mvssrv/LATEST.SERVICE/service    directory.
   Thanks, and sorry for the delay.
    Bob La Brie   ADSM Development



Bill Colwell <bcolwell AT DRAPER DOT COM> on 04-05-99 11:38:24 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: Bob La Brie/Tucson/IBM)
Subject:  Re: Expiration adsm 3.1.2.x





The ptfs for the mvs server aren't available yet.  UQ28274 is the number
for one of them.  Ordering it via SRD in ibmlink should cause the reqs and
ifreqs to be shipped also.

In ibmlink, use sis to check on uq28274.  When it is available, you can
order
it in srd.

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <8525674A.006051D8.00 AT mail.nimo DOT com>, on 04/05/99
In <8525674A.006051D8.00 AT mail.nimo DOT com>, on 04/05/99
   at 01:23 PM, Jeff Connor <connorj AT NIMO DOT COM> said:

>Can someone tell me which PTF's I need to apply to my ADSM MVS server to
>update it from 3.1.2.1 to 3.1.2.20?  If not can you tell me how to find
>them on IBMLink?

>Thanks
>Jeff






>Colin Dawson <redhead AT US.IBM DOT COM> on 04/01/99 06:47:00 PM

>Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

>To:   ADSM-L AT VM.MARIST DOT EDU
>cc:    (bcc: Jeffrey P Connor/IT/NMPC)

>Subject:  Expiration adsm 3.1.2.x




>Hello,
>     There has been concern about the expiration processing and the
3.1.2.1
>level of the server.  The expiration processing in 3.1.2.1 was affected by
>two items.

>- The first item was the fix for apar IX81990.  This apar FIXED expiration
>to evaluate ALL possible files eligible for expiration.  There was an
error
>in the expiration algorithm that caused some files to be skipped by
>expiration when they should have actually been expired.  This fix causes
>these files to now be evaluated and if they are eligible, they will be
>expired.

>When 3.1.2.1 was applied, many customers would see expiration taking
longer
>to run.  The reason it takes longer to run once the 3.1.2.1. level is
>applied is because more files had to be evaluated and because there MAY be
>more files to expire as the files that were previously skipped are now
>being handled.

>- The other item that affected the 3.1.2.1 server is documented in apar
>IX85298.  This impacted the versioning of BACKUP files and how excess
>versions of a file were not marked for deletion as they should have been.
>This could cause the DB size to increase as files that would normally
>expire were not being marked as eligible for expiration.  An emergency fix
>for 3.1.2.1 was made available that incorporated this fix.  This fix is
>also in the 3.1.2.20 level of the server.

>It is recommended that customers apply the 3.1.2.20 level of the server as
>it has the fix for IX85298 as well as other fixes.

>ADSM Development
<Prev in Thread] Current Thread [Next in Thread>