parse_style

[stephen atwell]

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]

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

ALP $ show logi sys$sylogin
"SYS$SYLOGIN" = "SYS$MANAGER:SYLOGIN" (LNM$SYSTEM_TABLE)

[stephen atwell]

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]

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.

[Hoff]

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.

Use LOGIN.COM or SYLOGIN.COM here.

[stephen atwell]

Thanks all! I will suggest they keep it that way.

[John Gillings]

stephen,

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:

$ IF F$GETSYI("VERSION").GTS."V7"
$ THEN
$ restore_parse_style="SET PROCESS/PARSE_STYLE="+F$GETJPI("","PARSE_STYLE_PERM")
$ SET PROCESS/PARSE_STYLE=EXTENDED
$ ENDIF

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,

call SYS$SET_PROCESS_PROPERTIESW(0,0,0,PPROP$C_PARSE_STYLE_TEMP,PARSE_STYLE$C_EXTENDED,0)

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).

[stephen atwell]

Excellent .. thanks again!

[Steven Schweda]

> 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]

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!