For the record, on a busy (95%+) machine, we backed up 13.3M records - 460M of
data in about 35 minutes.

Jerry Lawson
jlawson AT itthartford DOT com

________________________Forward Header________________________
Author: INTERNET.OWNERAD
Subject: Re: Holding Scheduled sessions
02-26-96 09:13 PM

At 12:31 PM 2/26/96 MST, you wrote:
>>We are getting ready to migrate to the Version 2 MVS server, and a queston
>>came up about holding activity while the Dump DB was taking place.  The ost
>>critical to us is probably the scheduled backups that might pop off whil the
>>dump was going on.  These same schedules might be interrupted when we tae
the
>>server down after the dump is complete.  A question was asked by the HSMguy
>>if ADSM had a hold command similar to HSM, but I did not find anything tat
>>obvious in a quick check of the manuals.  I did, however, find the
"maxshedul
>>edsessions" parm - can you set this to 0 and get the same effect?  Does
nyone
>>have a suggestion that they used?
>
>To preclude any new client sessions, including scheduled sessions, use
>the DISABLE command.
>
>Dave Cannon
>ADSM Development
>>

Hi,

I just recently (2 weeks ago) converted an mvs server to version 2.  What I
did was
essentially to issue the DISABLE command.  This prevents client-nodes from
logging on but administrators can still access the server.  Then I used
dfdss to dump all the adsm datasets to tape.  I then dumped the server with
the adsm dump db consistent=yes parm.

By the way, if you use consistent=yes this WILL quiesce any activity on the
server and will ensure that you have an intact database dump.

After the adsm dumpdb was done I shut the server down, renamed the startup
procs, put the upgrade parm in the proc and let 'er rip.  Everything went
fine.  The only caution I would suggest is to prevent folks from migrating
right away.  In the event that you do have to fallback to version one you
might lose migrated data.

Hope this helps,
Dave.