Info: F$GETSYI("MEMSIZE")

[Jan van den Ende]

To those interested:

To: Peleg, Guy (VMS Engineering)
Subject: block vs byte

Guy,

I just happened to stumble over the fact that F$GETSYI("MEMSIZE") does NOT honor SET PROCESS/UNIT=BYTE.

It is not terribly important to me, but it looks inconsistent, and I guess you will not want to leave it that way.

Just to let you know.


cu @ Bootcamp

Jan van den Ende

From: Peleg, Guy (VMS Engineering)
Subject: RE: block vs byte

Thanks....I'll fix it in V8.3

Guy


Just so you know..

Proost.

Have one on me.

Jan

[Gary Cantwell]

edited subject line to " F$GETSYI " at authors request,

cheers,


Gary

[Hein van den Heuvel]

I hope I am reading the message wrong.

IMHO getsyi memsize must always return the same number regardless of the set proc/unit settings.
The unit for memsize is PAGES, not KB or BYTE. You have to multiply by F$GETSYI("PAGE_SIZE") to get bytes.

But even if the unit had been bytes or kb, it should still not depend on the process setting. This is just an integer number. Leave it alone. It is NOT a DISPLAYed number.
SET PROC/UNIT is documented to influence displayed numbers alone. And SET PROC/UNIT is documented to operate on DISK SPACE, not everything that can be measured in bytes.
See below.

fwiw,
Hein.


/UNITS[=keyword]
Specifies whether the amount of disk space reported by certain utilities is to be displayed in blocks or bytes. Keyword options are: Keyword Explanation
BLOCKS Displays disk space in blocks.
BYTES Displays disk space in bytes.

Blocks is the default until /UNITS is set to BYTES. If you specify /UNITS with no keyword, disk space is reported in blocks.

Displays that are affected by changing the value of /UNITS include output from certain forms of the following commands: COPY, DELETE, DIRECTORY, PURGE, SHOW DEVICE, SHOW MEMORY, and SHOW QUOTA. Note that input to these commands can be specified only in blocks. The DIRECTORY, SHOW DEVICES, and SHOW MEMORY commands have a qualifier that lets you override the default SET PROCESS/UNITS setting for a single command.

[Robert Brooks_1]

Agreeing with Hein . . .

I think it would be a grave mistake to modify any of the programmatic interfaces to take that setting into account. It's one thing for a display to allow its output to be changed, but having $GETSYI/$GETDVI to return different values depending upon the environment could cause a lot of confusion.

While it may not be apparent, the DCL lexical functions F$GETXxxI are nothing more than wrappers around the traditional system services SYS$GETxxI; one would have to modify the core system service to effect this change, and I'd be quite against any change in $GETDVI.


-- Rob (current maintainer of $GETDVI)

[Jan van den Ende]

Hein,

after reading, I must agree you are formally right.
Then again, the usual parlance about memory is generally in Bytes, or powers of 1024 of bytes. So, in the spirit of SET PROC/UNIT=BYTE, I still think it desirable to extend its scope to this usage (and comparable? - I have not found, nor looked for others).

I know you are in an excellent position to discuss the pro's & con's of this with Guy, and you will inform us on the outcome.

Proost.

Have one on me.

jpe

[Jan van den Ende]

Robert,

those different view do not necessarily clash, do they?

Your own words: "F$GETSYI is just a wrapper around $GETSYI". I fully agree.

Then again, is the function of a wrapper not exactly to map the API's?
How many existing lexical functions are converting in- & output, re-formatting, performing checks and/or loops?

OF COURSE $GETSYI should NOT be changed for this! But a wrapper could format the output differently depending on whatever is steering it (?)

--- easy talking for me, from the side-line.
I trust you shall reach a wise decision.

Proost.

Have one on me.

Jan

[David B Sneddon]

Jan,

I have a number of DCL procedures that rely on the
combination of MEMSIZE and PAGE_SIZE values to return
some useful information. If this suddenly stopped
working as expected that would not be the "VMS way"...

Regards
Dave

[Uwe Zessin]

Agree with Hein, too.
To me, F$GETSYI is an API and its behaviour should not depend on the user interface.

[Guy Peleg]

Folks,

My mail was posted here with permission.

As one of the ITRC moderatos, I considered
deleting this entire thread but decided
not to.

We would NEVER do anything that will break
existing procedures. I will take a look at
the feasibility of this change but am not
promising to actually make this change.

Guy

[Jan van den Ende]

Guy,


As one of the ITRC moderatos, I considered
deleting this entire thread but decided
not to.


Thanks for _NOT_ doing that!

If nothing else comes from this, then at least we outside Engeneering have been given insight in the reasons WHY some things do not get done!
I, for one, am very glad that Hein & Robert chose to discuss the issues here.

As an aside: of course I am also one of all those that consider breaking old functionality VERY BAD. As an example, how about CSWS 2.0 vs 1.3. How many were hurt by no longer accepting non_stream files, and had to revert?
However, enhanced functionality where the old behavior is the default will usually be very pleasant to some.

I will be patient, and if introducing byte displays does not get implemented, I will understand why.

Proost.

Have one on me.

Jan

[Willem Grooters]

I strongly agree with engineering in this case. However, could it be considered to have an aditional optional facility to display memorysize in MB or GB units (F$GETSYI("MEMSIZE",,,"BYTES")? That would not break existing code - and faciliate the request

Willem

[Jan van den Ende]

Willem,

I previously wrote:


OF COURSE $GETSYI should NOT be changed for this! But a wrapper could format the output differently depending on whatever is steering it (?)


What you are suggesting is _A_ possible implementation of "steering it".

Proost.

Have one on me.

jpe

[Willem Grooters]

Sorry Jan, overlooked that.

[Antoniov.]

Sorry for late,
I was out of my office.
Thank to Guy: even he is very busy, he answer us about vms.
I believe the question is more global; some other functions could return value in bytes or better in Kb, for example:
f$getdvi("swapfile_page","kb")
f$getdvi("total_pages","kb")
f$getdvi("used_pages","kb")

For end users, byte or Kb or Mb are more readable than pages.

Antonio Vigliotti

[Guy Peleg · Accepted solution]

Another possibility instead of changing
the existing format of the lexical
functions (one could claim that F$GETDVI
should return information in bytes as well)
is to introduce a new lexical function
F$B2B (blocks to bytes) given number of
blocks it will translate it to bytes,
a possible usage then might be

$ WRITE SYS$OUTPUT F$B2B (F$GETSYI("MEMSIZE")

What do you think?

Guy

[Uwe Zessin]

There is a ')' missing ;-)

Seriously, what is that supposed to return for memory sizes > 4 GBytes? I haven't kept up to date with DCL, but can it now work with integers > 32 bits?

[David B Sneddon]

Guy,

Looks like a better approach...
would that not then be
$ write sys$output f$b2b(f$getsyi("PAGE_SIZE")*f$getsyi("MEMSIZE"))

Dave

PS. did you happen to notice a mention of another
possible lexical F$MATCH(candidate,pattern)?
As per STR$MATCH_WILD, I think it was on c.o.v.
in a thread about lexicals...

[David B Sneddon]

Oops... F$B2B would be BLOCKS to BYTES which would make
my last example wrong. There should be a /512 in there as well

Dave

[Guy Peleg]

My example was wrong...sorry, let me try
again....F$B2B (blocks to bytes) will
accept certain number of blocks and convert
it to bytes. MEMSIZE does not return
blocks so it will be up to the
user to perform the conversion to blocks.

It is true that the input
will be limited to 32 bits,however
we could probably teach the lexical function
to accept strings as input, this will allow
converting 64bit numbers.

I did not see the F$MATCH discussion,
in c.o.v, could you send me a pointer?

Guy

[Antoniov.]

Guy,
your idea is simple but very attractive. I think it is slight better a function like p2k (page to kilobyte).
With new function all old dcl procedure still works while new procedure can calculate every memory value in kilobyte (or bytes).
I vote for new function.

Antonio Vigliotti

[Jan van den Ende]

Back again.

Personally, I find the F$B2$ quite appealing.
And the conterexample in the case of mem_size is not really that heavy.
See Hein above in this stream: F$GETSYI("PAGE_SIZE") will do.

Guy,
on f$math in c.o.v., I also remember that. About 6 - 9 months ago.
And if my memory server ( but I AM getting old and gray ), then YOU were the prime contributor.
I'll try and find it again.

Proost.

Have one on me.

jpe

[Guy Peleg]

Jan,

Previous entry mentioned F$MATCH and
not F$MATH..

Guy

[Jan van den Ende]

Ouch.

Guess I need new glasses... :-(

Then again, maybe just reading too hastily.
I was under the impression that the issue of the last few entries was calculations, and I just jumped to conclusions.
I nasty habit, that has exposed me before....

Proost.

Have one on me.

jpe

[David B Sneddon]

Guy,

The "discussion" on c.o.v consisted of me asking the
above question in the thread related to the need for
SEARCH/QUIET.

http://groups-beta.google.com/group/comp.os.vms/browse_thread/thread/3b6bb7bf61fde328/c6fa267bfad9d6b2?q=%22f$match%22&rnum=1&hl=en#c6fa267bfad9d6b2

An example of what I was after can be found on the Freeware V5.0 CDs, DBS-LIBRARY package, f$match.*

Dave

[Travis Craig]

If F$B2B converts blocks to bytes, I'm wondering what we'll name one that converts bytes to blocks.

--Travis