Showing results for 
Search instead for 
Did you mean: 




I have a customer using an application that uses directories with special characters. This requires they do a set/proc/parse_style=extended. They currently set that in user login scripts, but would like to set it as the system process default. I can't find anywhere to do that. Any help would be appreciated.
Steven Schweda
Honored Contributor

Re: parse_style

I keep mine in my user's SYS$LOGIN:LOGIN.COM,
but there's always the big one:

ALP $ show logi sys$sylogin

Re: parse_style

Thanks. They are looking for somewhere to permanently set it such as sysgen or authorize rather than in the login. Don't ask me why :-)
Jess Goodman
Esteemed Contributor

Re: parse_style

The only other way I can think of would be to use a LOGINOUT callout. This requires creating a shared image that would execute your code when LOGINOUT runs.

In this case the code would call the $SET_PROCESS_PROPERTIESW system service with the PPROP$C_PARSE_STYLE_PERM flag (for interactive processes).

I could whip up an example for you if you wish, but it would be far easier to use s system wide login command procedure, as Steven suggested. If they are worried that users may not execute it (CTRL-Y or /NOCOMMAND), you could set all the accounts RESTRICTED with AUTHORIZE.
I have one, but it's personal.
Honored Contributor

Re: parse_style

I'd be cautious around setting this stuff system-wide regardless, and if such a system parameter control mechanism even existed. (AFAIK, it doesn't; DCL_CTLFLAGS is arguably the closest here, and that doesn't document this mechanism.) There is too much risk of breaking some software somewhere that didn't expect the parsing default to change.


Re: parse_style

Thanks all! I will suggest they keep it that way.
John Gillings
Honored Contributor

Re: parse_style


I'd strongly recommend that this NOT be made a system default, rather that the application which depends on it explicitly enables parse style (and restores the previous setting on exit). I wouldn't even put it in LOGIN, rather, it should be embedded in command procedure and images of the application.

Application dependencies should be made explicit and encapsulated inside the application itself, otherwise you can end up with conflicts between different applications, and mysterious failures when (not IF) invisible global settings are lost.

Relying on a SYSGEN setting is a recipe for errors and confusion down the track. I've seen this type of situation many times with site specific PQL settings being forgotten when moving software to a new system.

In DCL, the modular and version independent way to deal with parse style or token settings is:


then just prior to exit:

$ 'restore_parse_style'

(note quotes so it's a NOOP if the symbol is undefined)

Inside an image it's even easier,


Since the setting is temporary it is automatically reverted at image exit.

(note to MACRO32 programmers, the system service macro $SET_PROCESS_PROPERTIESW_S has typos that make it unusable - reported to HP).
A crucible of informative mistakes

Re: parse_style

Excellent .. thanks again!
Steven Schweda
Honored Contributor

Re: parse_style

> Inside an image it's even easier, [...]

But you need to get it done before the
command line has been parsed, so you may need
to use a mechanism like LIB$INITIALIZE for
that. (Good luck on a C++ program.)

> I wouldn't even put it in LOGIN, [...]

I took that chance some years ago, and the
biggest problems I've had are rogue
(HP-supplied) command procedures which set it
back to TRADITIONAL while I'm not looking,
and temporary confusion when I go back to a
VAX where TRADITIONAL is all there is, and I
need to remember to quote things again. It's
a personal/organizational choice, but I've
grown very fond of this in my LOGIN.COM:

$ if (f$getsyi( "HW_MODEL") .ge. 1024)
$ then
$ set process /parse_style = extended
$ endif

I never worked up the courage (or had a need)
to do it to SYLOGIN.COM, but I have a
personal pseudo-LOGIN.COM which I use when
I'm SYSTEM, and there's one in there, too, so
unless someone messes with it, I do all my
personal and SYSTEM work with EXTENDED.

If your (unspecified) application is accessed
through command procedures, then they could
either check the setting or set it.
Willem Grooters
Honored Contributor

Re: parse_style

A word of warning.
Parse_style also effects the way command-line attributes are passed to programs when the LIB$GET_FOREIGN system service is used.
When TRADITIONAL (normally default), the information will be converted to uppercase, where EXTENDED will leave the data unchanged:

Assume prg code:
stats=LIB$GET_FOREIGN (sym)
IF sym = "A" THEN

When run:

$ prg :== $prg.exe
$ prg a

the effect of the condition depends on setting of PARSE_STYLE:
TRADITIONAL: since the parameter ("a") will be converted and passed as "A", the condition will return TRUE.
EXTENDED: since the parameter will be passed as-is, so as "a", the condition will return FALSE.

It's not that uncommon in older programs!

Willem Grooters
OpenVMS Developer & System Manager
John Gillings
Honored Contributor

Re: parse_style

>so you may need to use a mechanism like

Doesn't work :-(

I guess the processing of the foreign command is done by DCL before the LIB$INITIALIZE routine has any effect.
A crucible of informative mistakes
Steven Schweda
Honored Contributor

Re: parse_style

> Doesn't work :-(

LIB$INITIALIZE is good enough to get
"DECC$ARGV_PARSE_STYLE" set, which is good
enough to preserve case in argv[], _if_
parse_style = extended. I never tried to
force extended parse_style in a program.