In <1994Dec2.164941.4251 AT draper DOT com>, MAINT%PUCC.BITNET AT vm.marist DOT 
edu (Melinda Varian) writes:
>On Fri, 2 Dec 1994 at 03:30:46 GMT, Bill Colwell said:
>
>> Export runs forever.  I estimate the elapsed time for 8.3m entries to
>> be in months.  Also it uses free database pages as a sort work area,
>> so to do your whole database you must start with a database less than
>> 50% full.  Export does a sort so that it can read tapes in order.
>> But is a very poor sort algorithm.  If you double the sort input you
>> quadruple the time.
>
>Well, that's certainly *very* discouraging, but it accords exactly with
>a note I received last evening from another ADSM customer and with the
>limited tests I have done myself.  I have tried exporting only our
>archived files (5022 files, 207M).  This was a very small test; the files
>all fit on one cartridge.  One run took 35 minutes; the other took 65
>minutes.  (The former was an EXPORT SERVER; the latter was an EXPORT
>NODE.)  In both cases, what appeared to be the sort phase accounted for
>most of the time, and during that phase the server used about 70% of one
>of the processors of our 3090-600E.
>
>It does appear that ADSM has serious problems with its sorting technology
>in general.  We have decided not to make the DOS client available to our
>users because of the incredible sort times during restores (i.e., 15
>minutes to sort a list of 2331 files on a PS/2 Model 80).  Worse, we are
>getting complaints about the CPUs on our Novell servers being pinned
>each evening when the scheduled backup is running and this appears to be
>a problem with their sort algorithm.  And now this problem with the ADSM
>server.  Sigh.
>
>Our server runs on a VM system that, of course, has a real sort package
>installed on it to provide high-performance sort capability.  This sort
>package has standard interfaces that could be exploited by ADSM.  And
>it knows how to allocate tdisk space for doing sorts.
>
>We view this problem as serious enough that we would be willing to
>undertake a joint study to enhance the server to use an external sort
>package.
>
I reported a problem to IBM on 93.293 about the bad performance of
export.  IBM closed it as a future requirement.  It was problem number
5x982 if IBM wants to review it.

In other discussions that I have had with ADSM developers, I got the
sense that they were writing to a common denominator - i.e. if a
feature that would be nice on MVS or VM wasn't also available on OS/2
or RS/6000 (and soon HP and Solaris), then it wasn't a hot item.  You
have to wonder how IBM in general and ADSM in particular feels about
the mainframe and if all the product planners are on the same page.
Exploiting mainframe sort packages is something I would think could
have been added to the MVS and VM servers over the past year.  The
other mainframe specific thing which I haven't seen any movement on is
exploitation of the concurrent copy feature of DFsms and integration
of such copies into the server backup plans.  (DB2 is on many
platforms but it supports concurrent copy on MVS).  Developers -
Please don't be offended!  I think you have done a terrific job and
ADSM is tops for the number of bugs.  I assume the problem is that you
have been working on some great stuff for release 3!
>
>> I take the server down twice a week and dump the server volumes and
>> disk bitfiles to tape (MVS server, FDR dump program, 5.0 million DB
>> entries, 20 3380k volumes, under 2hr elapsed time).  Tape bitfiles
>> are copied whenever a tape is written.
>
>What procedure do you use for "twinning" your tapes as they are written?
>
I use the console automation product AUTOMATE from Legent.  I key on
the message ANR5208I which is new in level 10 and was added for an
apar I submitted.  The message text give the volser of a tape which
ADSM is dismounting and if it was used rad-only or updated.  If it was
updated, AUTOMATE submits an iebgener job to copy the tape.

I don't use scratch tapes.  ADSM's volumes are predefined in blocks of
1000.  The output tape is simply volser + 1000, so keeping track of
the sibling relationship is easy.  To recover using the twin, I would
clip a new tape to the volser ADSM expects and copy the twin onto it.
>
>Another problem I am finding in setting up backup procedures is that ADSM
>is far more difficult to automate than I was expecting.  Given that we
>are using a VM server and have a CMS administrative client, I had been
>assuming that I could simply write some ADSM macros to run on CMS to
>do EXPORTs and such.  In fact, that isn't viable, because all of the
>commands I need run asynchronously and don't report their ending results
>to the administrative client.  Thus, I can't tell when an operation
>completes, whether it completed successfully, or which tapes it used.
>I can use VM's SCIF (secondary console interface) capability, but that
>adds a level of complexity to the project.
>
>This is all very disappointing.
>
>Melinda Varian,
>Princeton University


Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550