ADSM-L

Re: upgrade from ADSM 3.1 to TSM 3.7

2000-12-14 10:30:35
Subject: Re: upgrade from ADSM 3.1 to TSM 3.7
From: Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU>
Date: Thu, 14 Dec 2000 10:28:45 -0500
> time is running to fast. The year will end in a few days and the support for
my
> ADSM too. So I have to upgrade mit ADSM 3.1 to TSM 3.7.
> Server is OS390.
>
> Are there any known problems??? I looked at ADSM.ORG but found nothing. Does
it
> mean that I will have no bad surprise after upgrade???

We just went through this upgrade with no major problems.

When we ordered TSM 3.7, we got a product tape for the initial release and a
cumulative PTF tape to bring the server up to a then recent service level. The
install documentation claimed that there was no PTF tape. We had to call IBM
just to get the volume serial number for the PTF tape that wasn't supposed to
exist. IBM initially argued that they couldn't help us because we were asking
for usage information rather than defect support. Ignoring the PTF tape was
not an option; the initial release had some serious bugs that were fixed in
the first few service levels.

Dataset names are changed. If a file created during an ADSM install had a DSN
that started with 'ADSM', the corresponding file created during a TSM install
will have a DSN starting with 'TSM'. We had to change started task JCL, batch
jobs that ran DSMADMC to automate administrative functions, and NetView
allocate commands needed to allow NetView CLISTs to execute DSMADMC.

TSM 3.7 introduces a new server option named FIXEDIOBUFSIZE, designed to
improve the performance of VSAM I/O. This was initially implemented
incorrectly and introduced a major data integrity exposure. Don't set this
option to a non-zero value unless you are very sure you have the fix for the
bug installed.

We use SQL-BackTrack on some of our Unix clients to back up Oracle databases.
Only very recent levels of the ADSM ODBC module are officially supported for
used with a TSM 3.7 server. Our tests indicated that older ODBC modules would
in fact work, but we upgraded to maintain vendor support for our configuration.
<Prev in Thread] Current Thread [Next in Thread>