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 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?

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