| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 333.1 | SYS$COMMON:[sysmgr.mail] fails in the same way | UCXAXP::ZIELONKO | | Fri Mar 14 1997 12:33 | 16 |
| I just tried it by doing the submit like this:
$ submit /que=UCX$SMTP_UCXAXP_00/user=SYSTEM -
$_ sys$common:[sysmgr.mail]97031412015145_SYSTEM.UCX_UCXAXP
and got the same result. The filename that you see when you do a SHOW QUEUE is
"_UCXAXP$DKA0:[SYSCOMMON.SYSMGR.MAIL]97031412015145_SYSTEM.UCX_UCXAXP;1"
Oh yeah, I forgot to say:
UCXAXP> sho log sys$common/full
"SYS$COMMON" [exec] = "UCXAXP$DKA0:[SYS0.SYSCOMMON.]" [concealed,terminal]
(LNM$SYSTEM_TABLE)
Karol
|
| 333.2 | | BSS::JILSON | WFH in the Chemung River Valley | Fri Mar 14 1997 12:37 | 4 |
| See your nearest friendly STARS database or DSNlink and look for this
[OpenVMS] Incorrect File Specs Returned After BACKUP/IMAGE Restore
Jilly
|
| 333.3 | | AUSS::GARSON | DECcharity Program Office | Sun Mar 16 1997 18:22 | 21 |
| re .*
More specifically, when you submit a file for printing or execution the
only thing that the queue system stores is the name of the device
containing the file and unique (per device) file identifier. It derives
that information from the file spec that you supply.
When you do the SHOW command it attempts to translate the device + fileid
back into a file specification. This translation may fail - no result or
incorrect result - and SHOW QUEUE doesn't identify the latter case.
When the file comes to execute or print all should work regardless -
unless e.g. a command procedure relies on f$envi("PROCEDURE").
This feature has been discussed in previous incarnations of this notes
conference many times. (q.v.)
The problem, particularly as it applies to files in SYS$COMMON, can be
caused by BACKUP and a STARS article exists to tell you how to fix the
problem manually. (Note that you can also cause the problem manually if
you particularly try to.)
|
| 333.4 | SMTP symbiont needs to read submitted file | UCXAXP::ZIELONKO | | Mon Mar 17 1997 06:24 | 25 |
| Derek,
> When the file comes to execute or print all should work regardless -
> unless e.g. a command procedure relies on f$envi("PROCEDURE").
Thanks. As it turns out the UCX SMTP symbiont (which is processing the file)
needs to use that file specificaton. In the case of an SMTP queue the file that
is submitted is the UCX SMTP "control file" and contains the mail message to be
sent. The symbiont process gets the name of the file from the job controller in
the "start task" message and uses that filespec to open the file. Since the
filespec doesn't translate the symbiont signals an error.
> The problem, particularly as it applies to files in SYS$COMMON, can be
> caused by BACKUP and a STARS article exists to tell you how to fix the
> problem manually. (Note that you can also cause the problem manually if
> you particularly try to.)
I have heard of STARS but have no access to it. I will try to find someone with
access and ask them to dig this article up. I assume it not only says how to fix
the problem but also how to use BACKUP in a way so as not to cause it to happen
again.
Thanks again,
Karol
|
| 333.5 | | EVMS::MORONEY | | Mon Mar 17 1997 11:50 | 7 |
| If I remember correctly, this is often a backlink problem on the file
[000000]VMS$COMMON.DIR. If this is the problem, the fix was simple:
$ RENAME SYS$SYSDEVICE:[000000]VMS$COMMON.DIR SYS$SYSDEVICE:[000000]SYSCOMMON.DIR
$ RENAME SYS$SYSDEVICE:[000000]SYSCOMMON.DIR SYS$SYSDEVICE:[000000]VMS$COMMON.DIR
-Mike
|
| 333.6 | | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Mon Mar 17 1997 12:10 | 11 |
|
Instead of relying on the SMBMSG$K_FILE_SPECIFICATION, use
SMBMSG$K_FILE_IDENTIFICATION. This will provide you with a
Device name and File ID that you can use to open the file.
This will also prevent the user from 'spoofing' your symbiont
into using a name they have no access to (done by modifying
the file name in the headers).
Documentation on using the file identification can be found
with the FAB$V_NAM (in FAB$L_FOP) and with the NAM$T_DVI fields
in the RMS documentation.
|
| 333.7 | | AUSS::GARSON | DECcharity Program Office | Mon Mar 17 1997 16:32 | 10 |
| re .4
>I have heard of STARS but have no access to it.
Sure you do.(?) It's available via the Web.
http://aztech.cxo.dec.com:1999/stars
I would assume that BACKUP will not cause this problem unless you
restore. If you use a defragger then that isn't going to be very often.
|
| 333.8 | See note 10.* | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Mar 17 1997 17:02 | 14 |
|
:> The problem, particularly as it applies to files in SYS$COMMON, can be
:> caused by BACKUP and a STARS article exists to tell you how to fix the
:> problem manually. (Note that you can also cause the problem manually if
:> you particularly try to.)
:I have heard of STARS but have no access to it. I will try to find someone with
:access and ask them to dig this article up. I assume it not only says how to fix
:the problem but also how to use BACKUP in a way so as not to cause it to happen
:again.
Please see note 10.* for all sorts of good stuff...
COMET, STARS, various search engines, etc...
|
| 333.9 | | MOVIES::WIDDOWSON | Rod | Tue Mar 18 1997 04:13 | 9 |
| As a general warning, with an element of forward knowledge. It is
probably a bad idea to rely too much on LIB$FID_TO_SPEC, even now it
can produce files which may give RMS indigestion (as you have
discoverred). Device and FID is usually a better bet, use FID_TO_SPEC
to just display the name.
(As background, when files are printed from RMS or from the XQP
FID_TO_SPEC is used, and my memory is that this is how the print
command works....)
|