|
HP OpenVMS Systemsask the wizard |
|
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.
|