HP OpenVMS Systems

Setting up SYS$SCRATCH area?

» close window

The Question is:

 
How can I make SYS$SCRATCH truely a "scratch" area.  I remember on an old
 Honeywell system running CP5 a pseudo-directory that is for each user process
 and gets deleted when they log out.
 
Also, I would also like SYS$LOGIN to be similar to SYS$SYSROOT - a sys$specific
 like area that log files and other stuff get sent to and then the sys$common
 area that the command files would reside it.  This is so log files can be
 better identified and ma
naged (maybe to a separate disk than the sys$login disk)
 
I tried redefining the SYS$LOGIN logical, but without much success (or ability
 to login).
 

The Answer is :

 
  There is no automatic deletion of a process or system scratch area
  provided within OpenVMS.
 
  Implementation of deletion via manual commands or site-specific and
  automated means is, however, trivial.  Such deletion can occur if
  the files are older than, say, 72 hours, or such deletion can occur
  "automatically" during a normal process logout via:
 
    LO*GOUT :== @SYS$LOGIN:CLEANUP
 
  or similar.  If you choose to alias the LOGOUT command with a DCL
  symbol, make sure you check to ensure the deletion occurs only when
  the master process in the job tree logs out and not when each
  subprocess logs out.
 
  Fully automatic deletion on logout does not strike the OpenVMS Wizard
  as a particularly good idea, and is not something that the OpenVMS
  Wizard can generally recommend, whether it is implemented on some
  other operating system or on an OpenVMS system.
 
  Information on setting up shared areas (for scratch storage or for
  projects) and the associated resource identifier mechanism is listed
  in the Security Manual.  Periodic deletion of either the process local
  or shared scratch area via, say, a nightly batch job that resubmits
  itself and that then performs a DCL command such as
 
    DELETE/BEFORE="-3-"
 
  or similar would be a somewhat more appropriate approach.
 
  Redefinition of SYS$LOGIN as a search list is not generally recommended.
 
  Redefinition of SYS$SCRATCH to a scratch area (during LOGIN.COM) is
  generally recommended.
 
  Common file activation (for both images and executable procedures) would
  be more commonly implemented via definition of the DCL$PATH logical
  name; via the Automatic Foreign Command mechanism.
 

  

     

     
answer written or last revised on ( 7-AUG-2000 )
     
» close window