%NONAME-I-NOMSG

[Art Wiens]

Why?

$ pipe show dev/files sys$sysdevice: | search sys$pipe sysuaf
TCPware_FTP 20200226 [VMS$COMMON.SYSEXE]SYSUAF.DAT;1
QUEUE_MANAGER 20200213 [VMS$COMMON.SYSEXE]SYSUAF.DAT;1
$ show sym $status
$STATUS == "%X10000001"
$ write sys$output f$message($status)
%SYSTEM-S-NORMAL, normal successful completion


$ pipe show dev/files sys$sysdevice: | search sys$pipe nothere
%SEARCH-I-NOMATCHES, no strings matched
$ show sym $status
$STATUS == "%X18D78053"
$ write sys$output f$message($status)
%NONAME-I-NOMSG, Message number 18D78053

I would expect it to return %SEARCH-I-NOMATCHES.

Only certain facilities work with f$message?

VMS v8.3

Cheers,
Art

[Hoff · Accepted solution]

By default, only a select few system messages work by default. Everything else doesn't.

This has been a long-standing behavior of OpenVMS, and one that probably should have been remediated by now.

One approach toward avoiding this is:

---
$ help/message/status=%x18D78053


NOMATCHES, no strings matched

Facility: SEARCH, SEARCH Command

Explanation: The search operation opened and searched one or more files,
but the files did not contain the search strings. This message
is informational.

User Action: None.
---


As for other sources of information and tools and discussions on this topic...

Search for NOMSG here:

http://h71000.www7.hp.com/doc/73final/6300/6300pro_008.html

Search for NOMSG here:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1054903

Search for NOMSG here:

http://www.phrack.com/issues.html?issue=35&id=7

And see the DCL tool available here:

http://h71000.www7.hp.com/wizard/wiz_5171.html

[Hein van den Heuvel]

$ set message sys$message:cliutlmsg


Hein

[John Gillings]

Art,

I've logged a case with HP against the way PIPE handles condition codes from some utilities. It may be related to what you're seeing. Try this:

$ SEARCH NOFILE.DAT NOTTHERE

now

$ SEARCH NOFILE.DAT NOTTHERE >nl: 2>nl:

Send me mail if you want the gory details (my name with @ in the middle and dot com on the end).

For testing results of SEARCH, I use $SEVERITY rather than $STATUS. 1 means found, 3 means not found. Anything else is an error.

Speculating on "why" - I'd guess that the developer of SEARCH decided to use the generic SS$_NORMAL for success, but didn't want "NOMATCH" to be an error or warning. Since there was no existing "standard" condition code, they had to define one. Rather than using system wide scope, it's been defined in a local message library (as Hein has pointed out CLIUTLMSG). There are various procedures around for searching SYS$MESSAGE for condition codes. I've attached my version.

[P Muralidhar Kini]

Hi Art,

Yes. Even a simple search command that does not find a string in a given
set of files will see this behavior.

$sea *.* "NOTHERE"
%SEARCH-I-NOMATCHES, no strings matched
$ show sym $status
$STATUS == "%X08D78053"
$ write sys$output f$message($status)
%NONAME-I-NOMSG, Message number 08D78053
$

The success messages is using the message from the system scope
i.e. "SYSTEM-S-NORMAL". whereas the failure message is using the
message from the cliutlmsg scope i.e. "SEARCH-I-NOMATCHES".
This is what is causing f$message to not print the failure message properly.

The same behavior is there on latest versions of VMS also.

>> For testing results of SEARCH, I use $SEVERITY rather than $STATUS.
>> 1 means found, 3 means not found. Anything else is an error.
Thats intresting. I usually use the $STATUS for checking the status.
In case you want to know whether its success or not and are not intrested
in the specific error message, then this would be more suited i guess.

Regards,
Murali

[Shriniketan Bhagwat]

Hi,

>> Only certain facilities work with f$message?

Yes, even I have seen this behavior with f$message. It does not work with all facilities.

For example:

$ backup *.txt txt.bck/save/log
%BACKUP-S-COPIED, copied SYS$SYSDEVICE:[BACKUP]ONE.TXT;1
$ show sym $status
$STATUS == "%X10000001"
$ write sys$output f$message($status)
%SYSTEM-S-NORMAL, normal successful completion
$
-----------------
$ backup *.exe exe.bck/save/log
%BACKUP-W-NOFILES, no files selected from SYS$SYSDEVICE:[000000.BACKUP]*.EXE;*
$ show sym $status
$STATUS == "%X10A38400"
$ write sys$output f$message($status)
%BACKUP-W-NOMSG, Message number 10A38400
$


Regards,
Ketan

[John Gillings]

Murali,

>Thats intresting. I usually use the
>$STATUS for checking the status.

The trouble with $STATUS is it includes bit fields which don't affect the meaning of the condition, and you don't know if they'll be set or not. In particular STS$M_INHIB. In this posting you can see two values of $STATUS for the condition "SEARCH-I-NOMATCHES": %X18D78053 and %X08D78053. The difference is STS$M_INHIB.

If you perform an equality test against one of those values, you won't always detect the condition correctly. You could mask out STS$M_INHIB, but it's easier to use $SEVERITY - the low 3 bits of $STATUS.

[P Muralidhar Kini]

>> If you perform an equality test against one of those values, you won't
>> always detect the condition correctly. You could mask out STS$M_INHIB,
>> but it's easier to use $SEVERITY - the low 3 bits of $STATUS.

Nice point John.

I found the following meaning for different bits of $SEVERITY

Value Symbol
0 STS$K_WARNING
1 STS$K_SUCCESS
2 STS$K_ERROR
3 STS$K_INFO
4 STS$K_SEVERE

In case the SEARCH command finds a entry then $SEVERITY would be
1 (i.e.STS$K_SUCCESS) and in case SEARCH command does not find any
thing then it would throw a informational message "SEARCH-I-NOMATCHES"
and hence the $SEVERITY would be 3 (i.e. STS$K_INFO).

Hence as you had mentioned, the command procedure can check $SEVERITY
for values 1 or 3 to decide whether SEARCH command found a match or not.

Thanks John.
I would be changing my command procedures to use $SEVERITY along with
the SEARCH command because its easier indeed.

Regards,
Murali

[H.Becker]

f$message() can only show messages from the process permanent message files. An image is free to have an own message section, which is mapped by the image activator, at the appropriate time. That section is unmapped, at image rundown time.

Obviously search uses such a section for printing the %SEARCH-I-NOMATCHES message and it returns or exits with such an own status.

As Hein said, you can add the according message file to the process message files with set message. You can add/replace only one additional file.

Whether a VMS supplied utility should exit with a facility depended status value or a system value is the question. And that seems to be addressed by the SPR/PTR/QUIX/whatever-the-current-report-name-is.

[Ian Miller.]

and for future readers.

If programming see
LIB$MATCH_COND and the fine manual

http://h71000.www7.hp.com/doc/82final/5841/5841pro_028.html#index_x_770