topic Re: Wrong image name identified in IMGNAME error message in Operating System - OpenVMS

Wrong image name identified in IMGNAME error message

Richard J Maher — Sun, 05 Mar 2006 20:37:52 GMT

Hi,

If after running the attached DCL command file, (please also see brief documentation at EOF) you were to define LIBRTL to point to a non-INSTALLed copy in your local directory, before entering: -

$ run test_dir

You would be greeted with the following message: -

%DCL-W-ACTIMAGE, error activating image DIR_WATCH_EXEC
-CLI-E-IMGNAME, image file TIER3$DKA200:[SYS0.SYSCOMMON.][SYSLIB]DIR_WATCH_EXEC.EXE
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image

I, personally, think that's wrong and it should be reporting the error on LIBRTL as DIR_WATCH_EXEC is happily installed and doing all it has to.

FYI.

Cheers Richard

+
--------------------------------------------------------------------------------
WAITFR_FILE

Monitor an on-disk directory until the user-specified file has
been created. This service completes asynchronously.

For additional information about system service completion,
refer to the Synchronize ($SYNCH) service

--------------------------------------------------------------------------------
FORMAT SYS$WAITFR_FILE [efn] ,filespec ,resultant-filespec
[,iosb] [,astadr] [,astprm]

--------------------------------------------------------------------------------
ARGUMENTS efn
OpenVMS usage: ef_number
type: longword (unsigned)
access: read only
mechanism: by value

Event flag that SYS$WAITFR_FILE is to set once this service
detects that the user-specified file has been created. The efn
argument is a longword value containing the number of the event
flag; however, SYS$WAITFR_FILE uses only the low-order byte. If
you do not specify efn, event flag 0 is set.

When SYS$WAITFR_FILE begins execution, it clears the specified
event flag or event flag 0 if efn was not specified.

filespec
VMS usage: char_string
type: character-coded text
access: read only
mechanism: by descriptor--fixed length string descriptor

File specification, which may not contain wildcards, that
SYS$WAITFR_FILE uses to search for the desired file. The
filespec argument is the address of a descriptor pointing to
the file specification. The maximum length of the file
specification is 255 bytes.

Additionally, the file specification may not contain a search
list logical name, a node specification or a device name that
refers to a device other than a disk device.

SYS$WAITFR_FILE uses RMS to parse the filespec argument. If RMS
is unable to parse the file specification then SYS$WAITFR_FILE
will place the secondary RMS error status (STV) into the first
longword of the iosb argument.

+
resultant-filespec

OpenVMS usage: char_string
type: character string
access: modify
mechanism: by descriptor--fixed length string descriptor

Resultant file specification that SYS$WAITFR_FILE returns when
it has successfully parsed the specification in the filespec
argument. All concealed logical names will have been translated
in this expanded file specification.

iosb

OpenVMS usage: io_status_block
type: quadword (unsigned)
access: write only
mechanism: by 32-bit reference

I/O status block that is to receive the final completion status.
The iosb argument is the 32-bit address of the quadword I/O
status block.

SYS$WAITFR_FILE sets the quadword to 0 upon request initiation.
Upon request completion, a condition value is returned to the
first longword; the second longword is reserved for future use.

Though this argument is optional, TIER3 strongly recommends that
you specify it, for the following reasons:

. If you are using an event flag to signal the completion of the
service, you can test the I/O status block for a condition value
to be sure that the event flag was not set by an event other
than service completion.

. If you are using the $SYNCH service to synchronize completion
of the service, the I/O status block is a required argument for
$SYNCH.

. The condition value returned in R0 and the condition value
returned in the I/O status block provide information about
different aspects of the call to the SYS$WAITFR_FILE service.
The condition value returned in R0 gives you information about
the success or failure of the service call itself; the condition
value returned in the I/O status block gives you information
about the success or failure of the service operation.
Therefore, to accurately assess the success or failure of the
call to SYS$WAITFR_FILE, you must check the condition values
returned in both R0 and the I/O status block.

+
astadr

OpenVMS usage: ast_procedure
type: procedure value
access: call without stack unwinding
mechanism: by 32-bit reference

AST service routine to be executed when SYS$WAITFR_FILE
completes. The astadr argument is the 32-bit address of this
routine.

If you specify astadr, the AST routine executes at user mode
regardless of the access mode of the caller of the service.

astprm

OpenVMS usage: user_arg
type: longword (unsigned)
access: read only
mechanism: by value

AST parameter to be passed to the AST service routine specified
by the astadr argument. The astprm argument is the longword
parameter.

--------------------------------------------------------------------------------
DESCRIPTION
Control returns to your program immediately following successful
completion of this service. Once SYS$WAITFR_FILE detects that
the file specified by filespec has been created, this service
will inform your program by setting the event flag specified by
efn and, if specified, delivering the AST.

For each VMS Process, there can only be one SYS$WAITFR_FILE
service 'active' at any given time. Therefore it is not
currently possible to implement OR type waits with
SYS$WAITFR_FILE. That is, you can not choose to wait for this
file OR that file.

Required Privileges

You must have read access to the disk and directory that you are
monitoring.

Related Services

SYS$WAITFR_FILE_CANCEL

+
--------------------------------------------------------------------------------
CONDITION SS$_NORMAL The service completed successfully. The
VALUES directory watch has been initiated.
RETURNED SS$_INSFARG Insufficient call arguments specified.
Although astadr and astprm arguments are
optional they must still be specified as
zero.
SS$_ABORT A call to SYS$WAITFR_FILE is already
active. Only one call to this service
per process, is permitted at any given
time. Review your code or cancel the
outstanding directory watch with
SYS$WAITFR_FILE_CANCEL.
SS$_ACCVIO Filespec could not be read by the caller
or either the resultant-filespec or iosb
arguments could not be written to by the
caller.
SS$_BADPARAM One or more of the following conditions
is true: -
. filespec is longer than 255 characters
. filespec contained a wildcard * or %
. filespec contained a node name
. filespec contained a searchlist
SS$_UNSUPPORTED No FID could be obtained for the
directory specification or the specified
device is not a disk device.

Any errors returned by the following services:-
SYS$PARSE
SYS$ASSIGN
SYS$GETDVIW
SYS$ENQ
LIB$GET_EF

--------------------------------------------------------------------------------
CONDITION SS$_NORMAL The file that you have been waiting for
VALUES has been created.
RETURNED SS$_CANCEL The wait was cancelled by a call to
IN THE I/O SYS$WAITFR_FILE_CANCEL
STATUS fab$l_stv Secondary RMS error status. This will
BLOCK only occur if SYS$WAITFR_FILE failed
while attempting to call SYS$PARSE.

--------------------------------------------------------------------------------

+
--------------------------------------------------------------------------------
WAITFR_FILE_CANCEL

The cancel wait for file service will abort a file watch that
was previously set in motion by a call to SYS$WAITFR_FILE.

--------------------------------------------------------------------------------
FORMAT SYS$WAITFR_FILE_CANCEL

--------------------------------------------------------------------------------
ARGUMENTS
None.

--------------------------------------------------------------------------------
DESCRIPTION The cancel file wait service is used to prematurely terminate a
previous call to SYS$WAITFR_FILE.

SYS$WAITFR_FILE_CANCEL relinquishes all system resources
obtained by SYS$WAITFR_FILE, sets the specified event flag, and
delivers the AST to the calling process, if one was requested.

In order to identify the abnormal termination of the wait for
file service SYS$WAITFR_FILE_CANCEL sets the IOSB status to
SS$_CANCEL.

It is not a requirement of SYS$WAITFR_FILE that this routine be
called. The equivalent processing, except for AST delivery and
event flag setting is implied at image exit.

Required Privileges

None.

Related Services

SYS$WAITFR_FILE

--------------------------------------------------------------------------------
CONDITION SS$_NORMAL The service completed successfully.
VALUES
RETURNED

Re: Wrong image name identified in IMGNAME error message

Richard J Maher — Sun, 05 Mar 2006 20:45:34 GMT

Hi,

But I hasten to add, maybe dir_watch_exec should be linked with /PROTECT and shouldn't be calling out to LIBRTL at all? Maybe the LIB$*_EF calls should be moved to the dir_watch_user module? Who knows?

But then John says that MOVC3 translates to an OTS$ lib call? So should we code around that?

It's time to refer to "Them" rules. . . Doh!

Cheers Richard

Re: Wrong image name identified in IMGNAME error message

Phil.Howell — Sun, 05 Mar 2006 23:22:59 GMT

Opinion only - I disagree.
The error message isn't caused by librtl or a call to librtl, it is the image activator checking your image and finding problems.
You may think that "DIR_WATCH_EXEC is happily installed and doing all it has to",
but vms thinks that "I have a privileged image that may try to get around security restrictions by calling an untrusted image".
If you define your librtl as an executive logical name, then the vms image activator will allow dir_watch_exe to run.
(you probably knew this already)
Phil

Re: Wrong image name identified in IMGNAME error message

Richard J Maher — Mon, 06 Mar 2006 02:40:49 GMT

Phil,

Can you please include the output from the testing that you conducted on this, as I appear to get different results from you? Especially the bit where you have an unINSTALLED LIBRTL (albeit pointed to by a /SYS/EXEC logical name) being activated when called from a UWSS. I, for one, would really like to see that.

Please see the "User Action" bit below. If the local copy of LIBRTL is in fact installed then everything is peachy. So once again I submit to the panel that LIBRTL is the image that needs to be installed so LIBRTL is the image that needs to be in the error message.

As to the reason why the image activator is happy to pursue a non /sys/exec logical name for LIBRTL when it appears to bypass them for others is, at present, a mystery to me. The good news is, regardless of logical name resolution, VMS appears to insist on all images being installed. This is the mut's nuts!

Cheers Richard

PRIVINSTALL, shareable images must be installed to run privileged
image

Facility: SYSTEM, System Services

Explanation: Two possible reasons for this error are:

o An attempt was made to run a privileged image with
uninstalled shareable images.

o An uninstalled shareable image was referenced when the main
program was installed with the /EXECUTE_ONLY qualifier.

User Action: Ask the system manager to install all shareable images used by
executable images.

Re: Wrong image name identified in IMGNAME error message

John Gillings — Mon, 06 Mar 2006 16:48:15 GMT

Richard,

> I, personally, think that's wrong and
>it should be reporting the error on LIBRTL

A reasonable opinion, and one that I tend to agree with, but unfortunately for us, the person who implemented the code didn't.

The error is, technically correct. We failed to activate "DIR_WATCH_EXEC" and the reason was "PRIVINSTAL":

"o An attempt was made to run a privileged image with uninstalled shareable images."

Obviously it would be more informative to name the image which caused the problem rather than the victim, but that's just semantics.

A little history... there are (were?) two camps of opinion in issuing error messages. I call them the "paranoids" and the "pragmatists".

The philosophy of the paranoids was to LIMIT the amount of information revealed by an error message in order to hinder hackers. Hence "NOPRIV" and "EXQUOTA" -"Don't actually TELL them which privilege or quota, then they know what to shoot for. Any legitimate user should already know"

The pragmatists say that's a crock, and complain about the hours of wasted time by legitimate users trying to figure out WHICH quota or privilege was missing.

For many years the paranoids held on, but around V6, the pragmatists finally won through, and a whole set of new, more specific messages were created NOPRIV_CMKRNL, EXQUOTA_BYTLM etc... All new code is supposed to use the more informative status codes.

However, old code paths still use the old, paranoid codes. As code is revised, some MAY be updated, but the stuff that's deep down in the kernel will probably remain (especially if everyone stops paying support contracts and starves OpenVMS engineering of funding).

To debug this kind of error, try IMAGETREE.COM from the freeware, it displays the shareable image dependence tree for a given image. It's then a matter of checking each image in the path.

Trusted logical names are EXEC mode in the EXEC mode path of LNM$FILE_DEV

$ SHOW LOG/TABLE=*DIRECTORY LNM$FILE*/FULL

So, you can set up a process specific redirection.

Re: Wrong image name identified in IMGNAME error message

John Gillings — Mon, 06 Mar 2006 17:46:21 GMT

Richard,

Note that you're not supposed to call user mode routines from inner modes. You might be able to, BUT beware that you may be opening security holes or creating system crashers. Once you're inside a protected image, you OWN the system. Security and system integrity is entirely in your hands. For a start, I'd want to see some far more extensive validation of arguments before deploying your code on one of my systems.

Please check your assumptions carefully. I've tried that approach before. It's very expensive as your lock will be triggered by many more events than just file creations. My conclusion was it was actually cheaper, and certainly safer to just poll the directory. It also tells you when the file was created, not when it gets closed (which is presumably far more interesting and useful). I'm also certain that you can do all that without resorting to inner mode.

See:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=940030

Re: Wrong image name identified in IMGNAME error message

Richard J Maher — Mon, 06 Mar 2006 17:57:22 GMT

Hi John,

Thanks for the reply. (It's not that I stopped paying a support contract, I just never had one :-) I do have a SDK license and a DSPP membership and I'm a nice bloke.

I think I follow your argument, but that should leave us with either a message with *no* image name or a message with the *correct* image name. We currently have neither of those options.

Anyway, who cares? I honestly couldn't give two proverbials as to what image name shows up, and it was really only another chance to extract more information from you and to show off some code I had lying around but please answer me this: -

Why do you discuss "trusted" logical names at EXEC mode when the image activator is clearly *and evidently* happy to persue SUPERVISOR mode logical names for LIBRTL?

TIER3> @dir_watch
%COPY-S-COPIED, TIER3_SYSMAN:[MAHER_R.TRASH]DIR_WATCH_EXEC.EXE;2 copied to SYS$COMMON:[SYSLIB]DIR_WATCH_EXEC.EXE;4 (20 blocks)
%COPY-S-COPIED, TIER3_SYSMAN:[MAHER_R.TRASH]DIR_WATCH_USER.EXE;2 copied to SYS$COMMON:[SYSLIB]DIR_WATCH_USER.EXE;4 (7 blocks)
TIER3> define librtl TIER3_SYSMAN:[MAHER_R.UWSS]librtl
TIER3> run test_dir
%DCL-W-ACTIMAGE, error activating image DIR_WATCH_EXEC
-CLI-E-IMGNAME, image file TIER3$DKA200:[SYS0.SYSCOMMON.][SYSLIB]DIR_WATCH_EXEC.EXE
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image
TIER3> sh log librtl/full
"LIBRTL" [super] = "TIER3_SYSMAN:[MAHER_R.UWSS]LIBRTL" (LNM$PROCESS_TABLE)

Not trying to be funny John, but do you see the bit that says *[SUPER]*? Am I misunderstanding something?

If only developers could look up "Them" rules then we could save us all a lot of time! Where are they?

Cheers Richard

PS. Do you stop looking at threads once the little rabbit has been assigned? Should I hold off assigning points until a thread has been exhausted?

Re: Wrong image name identified in IMGNAME error message

Richard J Maher — Mon, 06 Mar 2006 18:34:03 GMT

Hi,

[ For a start, I'd want to see some far more extensive validation of arguments before deploying your code on one of my systems.]

Oh really? Which ones? (Specifically) I'm going out the door right now but I think "them" rules of coutesy and far play require some substantiation and a right-of-reply on my behalf. If it needs fixing then please let me know.

I'll address your other points when I get back, but can we try to leave the "there be dragons" arguments outside and try to concentrate on the science? If we can move forward on the premise that everyone has lay prostrate in from of the EXEC alter and UWSSs are an essential part of VMS functionality *and* that it is in *everyone's* best interest that they get written properly, then that would be just peachy!

Cheers Richard.

Re: Wrong image name identified in IMGNAME error message

Phil.Howell — Tue, 07 Mar 2006 01:59:43 GMT

I do get different results from you, :)
but not in the way that I expected. :(

I would have expected test_dir to have been installed with privilege to achieve your results.

Was it installed? what privs?

If you answer you own questions in this forum, can you award yourself points?

Phil

Re: Wrong image name identified in IMGNAME error message

John Gillings — Tue, 07 Mar 2006 16:03:06 GMT

Richard,

>Oh really? Which ones? (Specifically)

See the code in your MACRO defining the service:

cmpb (ap),#narg
bgeq endmacro
movzwl #ss$_insfarg,r0
ret

This checks the argument count, but doesn't check that AP points anywhere first. A null argument list will result in an ACCVIO. In kernel mode that takes out the whole system. Even if the argument COUNT is valid, there's no attempt to make sure the entire (apparent) argument list is accessible. The AP could point to the last longword in mapped memory. Referencing 4(AP) or beyond could ACCVIO. You're already in kernel or exec mode at this time, so NOTHING the user gives you can be trusted.

>Do you stop looking at threads once
>the little rabbit has been assigned?

ITRC is entirely voluntary. It's pretty much at the bottom of my priorities. I will contribute when I have time, and believe it's well spent. I don't come here to "spar" or score points (figurative or literal). If I get the impression my opinion or advice is not wanted, or will be ignored, I don't waste anyone's time by posting it.

In this case my opinion is there is no need to be doing any of this in kernel or exec mode. I recommend you step back, consider what you're really trying to achieve and look at safer means to achieve it.

Re: Wrong image name identified in IMGNAME error message

Richard J Maher — Wed, 08 Mar 2006 10:30:26 GMT

Hi,

Below is the dispatcher snippet and attached is the six-year old discussion from COV.

Cheers Richard.

00C0 14820 ; If there are more than 6arguments, they must be copied from the

SYSTEM_SERVICE_DISPATCHER Change Mode System Service Disp 19-NOV-2004 08:30:51 MACRO-64 V1.2-108-367CC Page 23
X-52 Change Mode to EXEC Dispatcher 20-JUL-2004 21:14:13 [SYS_2.SRC]SYSTEM_SERVICE_DISPATCHER.M64;1

00C0 14821 ; caller's to the inner mode stack. We neither validate the argument
00C0 14822 ; count nor probe the accessibility of the data pointed to by the
00C0 14823 ; arguments. However, we have to make certain we can access the
00C0 14824 ; arguments themselves.
00C0 14825 ;
*Optimized* 14826 AND R25, #255,R22 ; isolate number of arguments
*Optimized* 14827 OR R16, R31, R2 ; Save prvmod
*Optimized* 14828 SUBQ R22, #6, R22 ; get number of arguments > 6
*Optimized* 14829 BLE R22, 30$ ; if LEQ, 6 or fewer
00D0 14830
*Optimized* 14831 OR R17, R31, R6 ; Save additional argument registers
*Optimized* 14832 OR R18, R31, R1
00D8 14833 ;
00D8 14834 ; Set up to probe the caller's excess parameters. These are
00D8 14835 ; on top of caller's stack, whose address has been saved in R28.
00D8 14836 ;
*Optimized* 14837 OR R16, R31,R18 ; copy caller's CURMOD for PROBE
*Optimized* 14838 OR R28, R31,R16 ; PROBE wants address in R16
*Optimized* 14839 S8SUBQ R22, #1, R17 ; point to last datum
00E4 14840 ;
00E4 14841 ; Probe caller's stack to insure we can read the arguments themselves
00E4 14842 ; (not what they point to).
00E4 14843 ; Because the maximum number of arguments is 255 we will not span more
00E4 14844 ; than two Alpha pages.
00E4 14845 ;
*Optimized* 14846 PROBER ; can we read the argument list?
*Optimized* 14847 BLBC R0,KERNEL_ACCVIO ; no, fail service
00EC 14848 ; (NOTE: caller R26 still intact)
*Optimized* 14849 SUBL SP, R17, SP ; make room for arguments
*Optimized* 14850 BIC SP, #15, SP ; force OCTAWORD alignment
*Optimized* 14851 OR SP, R31, R18 ; copy pointer to inner stack
00F8 14852
00F8 14853 ;
00F8 14854 ; Determine if sign extension checking should be performed for the stack-based
00F8 14855 ; arguments.
00F8 14856 ;
00F8 14857 20$:
*Optimized* 14858 AND R5,#SSFLAG_K_64_BIT_ARGS, R28
*Optimized* 14859 BNE R28, 27$
0100 14860
0100 14861 ;
0100 14862 ; R18 -> inner stack
0100 14863 ; R16 -> caller stack
0100 14864 ; R22 = number of excess parameters to be copied
0100 14865 ; Copy doing sign extension check.
0100 14866 ;
0100 14867 25$:
*Optimized* 14868 LDQ R28, (R16) ; get caller's datum
0104 14869 IS_32_BITS R28, R0 ; check if arg is sign extended
*Optimized* 14870 STQ R28, (R18) ; store in inner stack
*Optimized* 14871 LDA R16, 8(R16) ; autoincrement
*Optimized* 14872 LDA R18, 8(R18)
*Optimized* 14873 SUBL R22, #1, R22 ; count it
*Optimized* 14874 BGT R22, 25$ ; loop if not done
*Optimized* 14875 BR R31, 29$ ; branch around non-sign extended check copy
*Optimized* 14875 ing
0128 14876

SYSTEM_SERVICE_DISPATCHER Change Mode System Service Disp 19-NOV-2004 08:30:51 MACRO-64 V1.2-108-367CC Page 24
X-52 Change Mode to EXEC Dispatcher 20-JUL-2004 21:14:13 [SYS_2.SRC]SYSTEM_SERVICE_DISPATCHER.M64;1

0128 14877 ;
0128 14878 ; Copy stack arguments without sign-extension checking.
0128 14879 ;
0128 14880 27$:
*Optimized* 14881 LDQ R28, (R16) ; get caller's datum
*Optimized* 14882 STQ R28, (R18) ; store in inner stack
*Optimized* 14883 LDA R16, 8(R16) ; autoincrement
*Optimized* 14884 LDA R18, 8(R18)
*Optimized* 14885 SUBL R22, #1, R22 ; count it
*Optimized* 14886 BGT R22, 27$ ; loop if not done
0140 14887
0140 14888 29$:
*Optimized* 14889 OR R6, R31, R17 ; Restore registers saved across PROBE
*Optimized* 14890 OR R1, R31, R18

Re: Wrong image name identified in IMGNAME error message

John Gillings — Wed, 08 Mar 2006 15:53:26 GMT

Richard,

Are you actually looking for help and advice, or are you just here to insult people?

Consider:

CLRL R0
CALLG (R0),your-routine

upon entry to your routine, AP will be zero. Therefore the instruction:

CMPB (AP),#anything

will ACCVIO.

Try it on a VAX, look it up in the architecture manual (section 8.4 in my 1977 first edition). That's how the CALL instruction is defined.

Now, as it *happens*, in some cases the Alpha MACRO-32 compiler may generate code for the CALL in such a way as to result in an ACCVIO *before* actually calling the target routine. That may protect you from this particular exploit, but depending on coincidences is entirely the wrong attitude when coding in inner modes.

The first rule of inner mode, is to do your best to AVOID it. The second is to not trust anything sent to you. That includes the AP and everything it points to.

Again, I suggest that you look at what you're trying to achieve and use the available user mode mechanisms.

Re: Wrong image name identified in IMGNAME error message

Hein van den Heuvel — Sun, 12 Mar 2006 13:44:44 GMT

Richard, I respect your techincal insights and probing questions and sense of humor. But replies are no longer constructive, sarcastic, cynical or funny but crossed in to the ugly world of personal attacks. Please don't.

Regards,
Hein van den Heuvel.

Re: Wrong image name identified in IMGNAME error message

Phil.Howell — Sun, 12 Mar 2006 20:11:06 GMT

ok back to the original questions...

Q1: Without the use of enhanced privileges and with the Main Executable Image not having being INSTALLed: - Can a call from an inner-mode UWSS out to any other shareable image (/PROTECTED or otherwise) be spoofed and redirected to another shareable image?

No - until proved otherwise.
(what do have against installing your executable image with privilege?)

My testing to-date indicates that the image activator insists on all shareable images being INSTALLed. Is this supported and architected behaviour?

Yes - but only if the executable is privileged, or any shared image referenced by the executable image is protected, or if the executable image is installed as /execute_only
Shared images that do not have any security implications do not have to be installed.

From Install utility reference:
" any routine called by the privileged image must also be trusted. For this reason, any shareable images activated for use by a privileged image must be installed. Only trusted logical names (names defined in executive and kernel mode) can be used in locating shareable images to be used by a privileged image."

Q2: When a LIB$ routine is called from an EXEC Mode UWSS, why does the image activator consider Non-Trusted, Supervisor-Mode Logical Names when activating LIBRTL? Furthermore, why does the image activator then appear to ignore non-trusted logical names when activating other shareable images? Is there something peculiar about LIBRTL?

When I tried your code, it worked when I wasn't expecting it to, so I'll pass on this one while I re-check what I did.

One question
$install/list shows installed image details
what determines if an image is listed as
"Shared" or "SharAddr"

Phil

Re: Wrong image name identified in IMGNAME error message

Guy Peleg — Sat, 18 Mar 2006 13:23:57 GMT

As one of the forum's moderators I have
deleted some answers I considered inappropriate.

John Gillings is one of the best VMS people
on planet earth.

Guy Peleg
OpenVMS Engineering