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
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
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
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.