HP3000-L Archives

October 1999, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Glenn Cole <[log in to unmask]>
Reply To:
Date:
Fri, 1 Oct 1999 15:41:23 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (43 lines)
Robert Grimes writes:

> Our systems programmer is trying to have the $stdlist identify which
> tape drive the operator selected to backup to, by way of the reply,
> after they streamed it.

The problem with this (as I see it) is that you never have the opportunity
to check the device while it's open.  (I take it from the "to backup to"
phrase that you're performing a backup with STORE or a third-party app,
which means you don't have access to its source.)

Ideally, then, it would be nice to ask the backup program to note what it
can in the way of the devices being used.

This is further complicated by the fact that some backup apps allow you to
specify multiple drives, to be used either in parallel or sequentially.

However, in this particular case, it sounds like your operator is choosing
one specific device.  I see a couple possibilities here:

       1. Use MPEX to call PrintOpReply (or write your own custom program
          to call the PrintOpReply intrinsic), asking for the ldev# for
          the backup tape.

          Validate this, then set a variable with the value.  You can also
          display the value at this time.

          Issue a file equation for the backup program, using this var
          for the DEV= parm.

          This means the operator would reply TWICE to the backup job:
          once the specify the ldev#, and once to confirm with Y/N.


       2. The other option I see is to have the job check the system
          log file for activity under that job#.  This may not be so
          "elegant," but it means having only the one :REPLY, like it
          is now.

I'd like to hear the final solution!

--Glenn

ATOM RSS1 RSS2