[comp.os.vms] VMS terminal port errors and Expir dates on dirs rather than volume

NSMCC@UHRCC2.BITNET (Howard Jares, CRCC Mgr 713-749-4612) (06/11/87)

Hello,
  Does anyone know what VMS counts as a error on a DMF32 or a DHU11? On
one of my systems I have begun seeing some errors but naturally they aren't
logged in the error log. I have been trying to get my communication guy
to track down the problems  but he hasn't been able to.
  The set volume expiration date feature works nice when you want to apply
it to a entire volume. Unfortunately, me and my system guys get to work
only on the system disk. I would like to use the expiration date in conjunction
with backup to archive old work. The question I have is: Can I selectively
turn on the expiration date (to be automatically modified when accessed)
only on a complete directory tree? I realize that I could do this by doing
the set volume/expire but this will be updating all my system file headers
as the system is used. I would like to avoid this overhead. My gut feeling
is that I get to wait for VMS V5...

Howard Jares, Manager                 Cannata Research Computation Center
NSMCC@UHRCC2 (BITNET)                 University of Houston
CRCC::HOWARD (TEXNET)                 4800 Calhoun SR1 Rm 221D
713-749-4612 (MABELL)                 Houston, Tx 77004

carl@CITHEX.CALTECH.EDU.UUCP (06/14/87)

 >   Does anyone know what VMS counts as a error on a DMF32 or  a  DHU11?   On
 > one of my systems I have begun seeing some errors but naturally they aren't
 > logged in the error log.  I have been trying to get my communication guy to
 > track down the problems but he hasn't been able to.

Try checking for unterminated terminal lines.  These can echo garbage back  at
the  DMF32  or DHU11, and I have reason to believe that such garbage generates
errors.

 >   The set volume expiration date feature works nice when you want to  apply
 > it  to  a  entire volume.  Unfortunately, me and my system guys get to work
 > only on the system disk.  I would  like  to  use  the  expiration  date  in
 > conjunction  with backup to archive old work.  The question I have is:  Can
 > I selectively turn on the expiration date  (to  be  automatically  modified
 > when  accessed)  only on a complete directory tree?  I realize that I could
 > do this by doing the set volume/expire but this will  be  updating  all  my
 > system  file  headers  as  the  system is used.  I would like to avoid this
 > overhead.  My gut feeling is that I get to wait for VMS V5...

What I've done on my system is to set the expiration date on all files in  the
system directory tree to a date far enough in the future that this field won't
need to be updated until a new version of VMS is installed.  This  should  cut
down  the  overhead  substantially.   Since  you're  interested  in  using the
expiration date for an archiving system, there's no need to make  the  minimum
and  maximum  retention  periods to nearly the same value.  On my system, they
differ by a day, which is much more precision than is really needed; thus  the
header of any file has the expiration date updated no more than once a day.

Arpanet:	CARL@CITHEX.CALTECH.EDU			Carl J Lydick
Bitnet:		CARL@CITHEX.BITNET			356-48 Caltech
HEPNet/SPAN:	CITHEX::CARL				Pasadena, CA 91125
							(818) 356-6660

LEICHTER-JERRY@YALE.ARPA.UUCP (06/18/87)

    ...

    The set volume expiration date feature works nice when you want to apply
    it to a entire volume.... Can I selectively turn on the expiration date
    (to be automatically modified when accessed) only on a complete directory
    tree? I realize that I could do this by doing the set volume/expire but
    this will be updating all my system file headers as the system is used. I
    would like to avoid this overhead. My gut feeling is that I get to wait
    for VMS V5...

Expiration date maintenance is done at low levels of the I/O system, below
the level where there's any real knowledge of directories.  It's whole-volume
or nothing.  I would be rather surprised if this changed in V5, or ever.

You can set the retention periods to minimize updates.  If, for example, you
set the retention period to (7-,8-), no file header will be updated more than
once a day - an overhead you aren't likely to notice - but your error in com-
puting what files have expired is at most one day.  (With this retention
period, no file will expire before 7 days have gone by, but some may survive
for 8.)

Alternatively, if you simply set the expiration dates for the system files
far into the future, they'll never get updated at all.  The SET FILE command
can do this for you....
							-- Jerry
-------