Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Strange occurance when mixing "set proc/unit=byte" and pipe

 
Ken Robinson
Valued Contributor

Strange occurance when mixing "set proc/unit=byte" and pipe

I noticed a very strange (reproducible) bug today on both V7.3-2 and v8.3-1h1

Do the following:

$ set proc/unit=byte
$ sho dev d/mou ! this is fine -- the free space shows as bytes
$ pipe sho dev d/mou ! this is also fine
$ pipe sho dev d/mou | type sys$pipe ! what happened? the free space shows as blocks
$ pipe sho dev d/mou/un=by | type sys$pipe ! ok again, but I shouldn't have do that

This also happens when you pipe the output of the directory/size command to another process.

Ken
10 REPLIES 10
Steven Schweda
Honored Contributor

Re: Strange occurance when mixing "set proc/unit=byte" and pipe

SPAWN, and the subprocess also has forgotten:

alp $ show proc /unit
[...]
Units: Bytes

alp $ spawn
%DCL-S-SPAWNED, process SMS_44309 spawned
%DCL-S-ATTACHED, terminal now attached to process SMS_44309

alp $ show proc /unit
[...]
Units: Blocks

Knowing nothing, I'd guess that these
phenomena are related.
Willem Grooters
Honored Contributor

Re: Strange occurance when mixing "set proc/unit=byte" and pipe


$ SET POCESS => sets attributes for THIS process.

$ SPAWN creates a new process - with the default setting: Blocks.

$ PIPE can be thought of creating a new process by, or similar to SPAWN, execute the FIRST command in that context, and, in the current process, process the output of the subprocess.
In your example. the created process would execute SHO DEV D/MOU, and pass the units in blocks (being the default setting) to the main process, wheer it will show in blocks. If you specify /UN=BY, the created process will do the math, and you'll see the units in bytes.

To be sure: $ SET PROCESS/UNIT-BLOCKS
and re-execute the second command. You'll get the info - in BYTES.

(not tested, but deducted)
Willem Grooters
OpenVMS Developer & System Manager
Robert Gezelter
Honored Contributor

Re: Strange occurance when mixing "set proc/unit=byte" and pipe

Ken,

I agree with Steve and Willem.

This is one of those debates about what the proper things to propagate when SPAWN is invoked. There is an argument for a greater set of process parameters to be "cloned" when a SPAWN is done, i.e., there is a strong argument that a whole set of settable parameters should be cloned, or at least the default should be that they are cloned. Among these parameters are RMS parameters, and various process settings. Insofar as I recall, only the DEFAULT string, symbols, and process logical names are cloned.

I suspect that you are not the first to notice this inconsistency.

Perhaps a "feature" request to Engineering for SET PROCESS/SPAWN_MODE=CLONE|RAW or SET PROCESS/SPAWN=([NO]LOGICAL_NAME,[NO]RMS,[NO]SYMBOL, [NO]SETTINGS])?

- Bob Gezelter, http://www.rlgsc.com
Willem Grooters
Honored Contributor

Re: Strange occurance when mixing "set proc/unit=byte" and pipe

@rob:

I agree. Even more, I would like to see both implemented: first for a quick, basic setting (RAW = inherit nothing, CLOSE=inherit all) and the second for a specific one; RAW or CLONE taking precedence.

Does the advocay still exist, or an alternative site?
Willem Grooters
OpenVMS Developer & System Manager
Steven Schweda
Honored Contributor

Re: Strange occurance when mixing "set proc/unit=byte" and pipe

> This is one of those debates about what the
> proper things to propagate when SPAWN is
> invoked. [...]

Yup. Try it with something similar, like
"Parse Style" or "Case Lookup". Around here,
those two get inherited. "Units" getting
lost looks to me like a bug. (Of course,
"Image Dump" gets lost, too, but that's more
reasonable, I'd say.)
Steven Schweda
Honored Contributor

Re: Strange occurance when mixing "set proc/unit=byte" and pipe

And, in any case, if SPAWN got more options
to deal with these choices, then PIPE would
need similar changes to deal with the
original complaint.
Jan van den Ende
Honored Contributor

Re: Strange occurance when mixing "set proc/unit=byte" and pipe

All,

advocacy does not exist anymore, but if anyone gets a formal request trough, point thm to this thread also. In which case I can be counted as another vote in favor.

Re Stevens last remark: I think that calls for another process setting to define which properties to inherit by PIPE and SPAWN (and similar others? Which?). Of course, any qualifier specified with a specific command should take precedence over the process setting.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Ken Robinson
Valued Contributor

Re: Strange occurance when mixing "set proc/unit=byte" and pipe

Thanks for everyone chipping in as to why I was seeing the "problem".

Ken
Hoff
Honored Contributor

Re: Strange occurance when mixing "set proc/unit=byte" and pipe

$loop:
$ candidate = f$device(,1,,)
$ if candidate .eqs. "" then exit
$ if f$getdvi(candidate,"MNT")
$ then
$ freeblocks = f$getdvi(candidate,"FREEBLOCKS")
$ write sys$output "Device ''candidate' has ''freeblocks' blocks free"
$ endif
$ goto loop
John Gillings
Honored Contributor

Re: Strange occurance when mixing "set proc/unit=byte" and pipe

Ken,

A bit more detail on the reasons behind the observed behaviour...

$ PIPE command

with no pipe separator executes in the context of the current process, hence the settings for the current process are used.

[why would you use this? it can be useful for I/O redirection, (add "> file") or I/O supression (add ">nl: 2>nl:")]

Using a pipe separator "|" causes the pipe segments to be executed in subprocesses.

The simplest way to get what I assume you want is to add a SET PROCESS command to the relevant pipe segment.

$ PIPE (SET PROCESS/UNIT=BYTE ; SHOW DEVICE D/MOUNT) | TYPE SYS$PIPE

A crucible of informative mistakes