Q about set mess text initial-letter upcasing

$!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx $ search myfile.log; "mytext"/exact %SEARCH-I-NOMATCHES, no strings matched $ set message /noiden /nofac /nosev $ search myfile.log; "mytext"/exact No strings matched $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx In this example the word "no" in the case where all parts of set message are enabled, is lower case, but when only /TEXT is enabled, the "N" in "No" is upcased. Is this a conceit of F$FAO for readability at the expense of easy parsing?

norm.raphael@metso.com wrote: > $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > $ search myfile.log; "mytext"/exact > %SEARCH-I-NOMATCHES, no strings matched > $ set message /noiden /nofac /nosev > $ search myfile.log; "mytext"/exact > No strings matched > $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > In this example the word "no" in the case > where all parts of set message are enabled, > is lower case, but when only /TEXT is > enabled, the "N" in "No" is upcased. > > Is this a conceit of F$FAO for readability > at the expense of easy parsing? > It is SYS$GETMSG that upcases the leading character if the ident, facility, and severity are turned off. Been that way since day 1. Why are you parsing the output instead of checking $STATUS? -- John Reagan HP Pascal/{A|I}MACRO for OpenVMS Project Leader Hewlett-Packard Company

John Reagan wrote: > > It is SYS$GETMSG that upcases the leading character if the ident, > facility, and severity are turned off. Been that way since day 1. My mistake. SYS$PUTMSG does the upcasing, not SYS$GETMSG. -- John Reagan HP Pascal/{A|I}MACRO for OpenVMS Project Leader Hewlett-Packard Company

In article <OFCC4F53D0.464F697A-ON85257162.006BC420-85257162.006C323E@metso.com>, norm.raphael@metso.com writes: |> $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |> $ search myfile.log; "mytext"/exact |> %SEARCH-I-NOMATCHES, no strings matched |> $ set message /noiden /nofac /nosev |> $ search myfile.log; "mytext"/exact |> No strings matched |> $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |> |> In this example the word "no" in the case |> where all parts of set message are enabled, |> is lower case, but when only /TEXT is |> enabled, the "N" in "No" is upcased. This is a longstanding behaviour of the message processing. |> Is this a conceit of F$FAO for readability |> at the expense of easy parsing? Parsing? Parsing messages can be an indication of a problem within the application, or within the application design. (Parsing is generally a last resort, and not generally a supported approach -- changes due to internationalization or due to application display changes or upgrades can obviously derail applications that parse output text, of course.) If you are searching a log file for potential problems, however, then the usual target for the search is: "-E-","-W-","-F-" This functions correctly in many (but not all) application cases. -- On a semi-unrelated note, the GNM tool on the Freeware might be of interest, as this allows you to have messages, SDL and its derivative condition (include or definition) files, and error message and recovery documentation (DOCUMENT SDML files) from one source file.

norm.raphael@metso.com wrote: > > $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > $ search myfile.log; "mytext"/exact > %SEARCH-I-NOMATCHES, no strings matched > $ set message /noiden /nofac /nosev > $ search myfile.log; "mytext"/exact > No strings matched > $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > In this example the word "no" in the case > where all parts of set message are enabled, > is lower case, but when only /TEXT is > enabled, the "N" in "No" is upcased. > > Is this a conceit of F$FAO for readability > at the expense of easy parsing? Why would that pose a parsing problem? -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/

norm.raphael@metso.com wrote on 2-5-2006 21:41... > $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > $ search myfile.log; "mytext"/exact > %SEARCH-I-NOMATCHES, no strings matched > $ set message /noiden /nofac /nosev > $ search myfile.log; "mytext"/exact > No strings matched > $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx and if you're really into finding the error string, looking for "o strings matched" (without the first letter) will even be correct when the message text is changed to "Zero strings matched". :-; /Wilm

In article <OFCC4F53D0.464F697A-ON85257162.006BC420-85257162.006C323E@metso.com>, norm.raphael@metso.com writes: > $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > $ search myfile.log; "mytext"/exact > %SEARCH-I-NOMATCHES, no strings matched > $ set message /noiden /nofac /nosev > $ search myfile.log; "mytext"/exact > No strings matched > $!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > In this example the word "no" in the case > where all parts of set message are enabled, > is lower case, but when only /TEXT is > enabled, the "N" in "No" is upcased. > > Is this a conceit of F$FAO for readability > at the expense of easy parsing? It shows that the programmers were actually thinking when implementing this facility!