 |
The Question is:
I have a number of clients who have the IDX (a hospital system). Man of the
applications print directly to a device spooled to SYS$SYSDEVICE:.
I understand that when you print to a spooled device the file is not entered in
a directory on the specified disk, and the disk device FDT routine enters
CLF_SPOOLFILE which causes the RMS create routines to set FCB$V_SPOOL in the
File Control Block.
It appears that the TCPIP$TELNETSYM (and it's predecessor UCX 4.2 eco xx) do
not always delete the spooled file upon completion/failure, and a monthly $
ANALYZE/DISK/REPAIR puts hundreds of these files (there are several hundred
concurrent users) into SYS
$SYSDEVICE:[SYSLOST].;* where we then delete them. (After typing quite a few of
them we were able to determine that they were mainly on-demand reports).
Unless you have something special up your sleeve, perhaps the appropriate
support unit should be made aware of this problem.
Thank you.
The Answer is :
This appears to be a known incompatibility with certain uses of the
OpenVMS spooled device capabilities and the underlying assumptions
-- some code assumes that the DELETE/ENTRY and similar commands can
be used on these spooled files, and OpenVMS (unfortunately) preserves
the contents of the spooled file in the file structure. The OpenVMS
Wizard has also heard of cases where an incorrectly configured queue
manager or cluster cannot access the files to delete them, due to
protections (use security alarm commands such as SET AUDIT/ALARM
/ENABLE=ACCESS=(FAILURE:DELETE), or set up the queue to retain jobs
on error) or due to (a lack of) access (privileges, not mounted, etc)
to the files stored on the intermediate (spooled) disk device. All
that said, the temporary file(s) on the intermediate device should
be automatically deleted -- under normal and typical circumstances.
RMS itself does not set the spooled attribute on the file, that is
something that is only set by the application, either directly or
when an $open operation is performed on a spooled device -- the
subsequent $close operation calls $sndjbc, which then (should) delete
the file. (The OpenVMS Wizard has encountered cases where a file is
not correctly closed, and thus the $sndjbc submission never occurs.)
Please consider an upgrade of your OpenVMS version to a more current
release -- though this upgrade will not likely alter nor address this
file-preserving behaviour of OpenVMS. Please also consider configuring
a (scratch) disk as the target for spooled file operations, for easier
clean-up ($ SET DEVICE /SPOOL=(telnet_queue, ddcu:) TNcu:). And please
check with the other software vendor(s), to determine if there are any
ECOs or workarounds within the (other) software involved here.
Alternatively, you could potentially use a null print symbiont -- jobs
queued will succeed of course, and should then be deleted. (There are
null symbionts available from various sources, including on the OpenVMS
Freeware distributions.)
If you wish to formally report a problem with OpenVMS or need/want a
formal resolution to a report, please consider direct contact with
the Compaq customer support center.
|
|
|
|
|
