NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/vms/19774

Internet Message Format | 1992-12-23 | 4.6 KB

Path: sparky!uunet!news.claremont.edu!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
From: [e-mail] (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Writeback Cache and other trivia
Date: 23 Dec 1992 12:24:19 GMT
Organization: HST Wide Field/Planetary Camera
Lines: 81
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <[e-mail]>, [e-mail] (Jerry Weiss) writes:
=During a regular test of my backup procedures (ie: my system crashed and
=when it came back up a few things didn't work ;-( )

But for it to be a REAL test of you BACKUP procedures, it had to happen while
you were doing a BACKUP:
    FIRST RULE OF SYSTEM MANAGEMENT:  You system WILL crash while you're
    doing a BACKUP, especially if it's the first BACKUP in 6 months!

=I discovered that I did
=not have a copy of jbsysqueue.dat on my daily incremental backups
=[backup/mod/since=backup....].

A suggestion:  Use:
    BACKUP/MOD/SINCE=BACKUP/IGNORE=INTERLOCK
unless you've got a lot of relational database stuff going.  When BACKUP comes
across JBCSYSQUE.DAT, it'll WARN you that someone else (JOBCTL) has the file
open for WRITE, but it'll STILL make a copy of it.  For JBCSYSQUE.DAT, the only
problem you're risking is that when you reboot after restoring from the BACKUP,
an old batch job might get restarted.

=I pulled a slightly older copy off my full
=image backup and sat down and tried to understand why.  Jbsysqueue.dat is
=one of those files that is always open and the modified field in the
=directory header is not updated.

Yup.  That's why I recommend /IGNORE=INTERLOCK unless you've got files where
that qualifier would cause problems.

=Is there a standard way to mark the file as modified so it gets picked
=up normally in this situation?  I've RTFM but it doesn't give me any
=insight into this particular situation.

You can't "mark" it.  But, if your system doesn't have applications that put
files in inconsistent states across QIOs, /IGNORE=INTERLOCK will solve your
problem.

=Should I just make a copy before my daily backups ?
=[backup/ignore=(interlock) jbsysqueue.dat copy_of_jbsysqueue.dat]

That's one way to do it.  In fact, if you've got other applications that might
not like the /IGNORE=INTERLOCK qualifier, that's the BEST way to do it;  for a
vanilla VMS system, JBCSYSQUE.DAT is the *ONLY* file that you'd really want to
back up that needs this qualifier (well, OK, if you're REALLY
security-conscious, things like OPERATOR.LOG should also be backed up, but I'm
assuming the querant isn't working for the NSA).

=Does the mount/cache=writethrough option have any bearing on this problem?
=If so, how does one set this for the system disk?

No.  Caching is "transparent to the user."  Including a user running BACKUP.
Caching only becomes non-transparent when, e.g. you have a power failure, and
the stuff you "wrote" to disk during the last few minutes turns out only to
have been written to cache, but never actually made it to the disk.

=Any there other files in VMS (not counting 3rd party software) that
=require special attention?

For vanilla VMS, at least through v5.4-2, JBCSYSQUE.DAT is the only special
file, if you're concerned mostly about rebooting and having everything work
right.  If your real security-conscious, there are a couple of other files
(OPERATOR.LOG, and at least one AUDIT file) that you've got to worry about.

=Thanks for any help, pointers or suggestions you may offer.

Once again, I beg Jerry's pardon for using him as a good example.  Here is a
man who's taken the trouble to learn everything that the on-line HELP facility
can tell him, and even to RTFM.  He's now wondering about some items that TFM
wasn't very clear on.  He's stated his question clearly, and shown that if he
gets an answer, he's capable of understanding it.  He's clearly demonstrated a
willingness to take the trouble to learn about VMS.  It's my fervent hope that
he'll become a long-time participant in this newsgroup.  We need more people
like him!
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: [e-mail] | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.