topic Re: Strange occurance when mixing "set proc/unit=byte" and pipe in Operating System - OpenVMS

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

Ken Robinson — Thu, 25 Sep 2008 03:18:41 GMT

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

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

Steven Schweda — Thu, 25 Sep 2008 03:45:55 GMT

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.

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

Willem Grooters — Thu, 25 Sep 2008 05:28:45 GMT

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

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

Robert Gezelter — Thu, 25 Sep 2008 06:54:06 GMT

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

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

Willem Grooters — Thu, 25 Sep 2008 09:56:05 GMT

@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?

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

Steven Schweda — Thu, 25 Sep 2008 12:33:17 GMT

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

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

Steven Schweda — Thu, 25 Sep 2008 12:36:17 GMT

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.

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

Jan van den Ende — Thu, 25 Sep 2008 13:04:15 GMT

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

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

Ken Robinson — Thu, 25 Sep 2008 13:14:49 GMT

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

Ken

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

Hoff — Thu, 25 Sep 2008 13:31:16 GMT

$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

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

John Gillings — Sun, 28 Sep 2008 22:09:28 GMT

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