HP3000-L Archives

September 1998, Week 4

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:
"Stigers, Greg ~ AND" <[log in to unmask]>
Reply To:
Stigers, Greg ~ AND
Date:
Tue, 22 Sep 1998 16:29:37 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (28 lines)
Is there a pattern here?

We also need to automate quiescing the system before backups. We had an
unpleasant experience with trying to use LIMIT from a job stream. Didn't
work, flushed the job, stopped it all cold. Same problem using WARN, not
that this is our biggest worry. While we currently have MPEX, there are
involved reasons why we limit its use. We use Nobix JobPak for the
scheduling, and they have an internal JOBLIMIT mechanism that looks like
it would get us there from here, but that would apparently require human
intervention, which we are trying to avoid. So I need MPE solutions
wherever possible, that can be used in job streams and command files.

But this raises the question: if we are kicking everyone off anyway, and
it is deep night, how worried should we be that we are not resetting
LIMIT for the backup? The risk seems largely theoretical. If we are sure
that our user community are warm in their beds, how important it this?
Or, what other reasonable mechanisms will accomplish the same end?

For instance, I have seen jobs that altacct or altuser to add passwords
as lockouts where they would not be otherwise (if the normal policy is
to password users, the job would password the account to lock users and
jobs out). While I recall that one wants to postfix / to account names
in jobs to get invalid password instead of a hang, I wonder how
effective this is seen. And, if this is prebackup, how does this affect
restores?

Are their other reasonable means? Are their other issues?

ATOM RSS1 RSS2