Re: LIB$SET_SYMBOL ... 4096, why not 8192?

On 10/20/07 21:10, Mark Daniel wrote:
Ron Johnson wrote:
On 10/20/07 18:30, Mark Daniel wrote:
[snip]

http://h71000.www7.hp.com/doc/732FINAL/aa-rv8xa-te/00/00/20-con.html

then becomes a little misleading and requires interpretation by a
scribe. After your commentary I would now interpret it more carefully,
perhaps as

The CLI now supports a DCL symbol capacity of 8192.
Various other VMS components have been modified to accomodate the CLI.

rather than all those components now having a capacity of 8192. You can
understand why lay-people need to have scholars (like yourself) to make
things clear for them when the original text can be so misleading.

Forward referencing your program link (thanks) it is obvious you are a
High Priest indeed, and as all such keep a little back for yourself

LEN = 8192-64 ; symbol equivalence size less CLI SYM block overhead

This lends weight to the suspicion that 8192 is not symbol capacity as
it can never be fully realised. Why then document it as 8192 I wonder
[rhetorically]?

I am guessing that the CLI manipulates symbols and their values using
its own code in a similar vein to yours, avoiding any LIB$ constraints.

Thought I'd demonstrate this to myself.

[snip]

8158
8159
%DCL-W-BUFOVF, command buffer overflow - shorten expression or
command line

Quits with a margin of 33 (8192 - 8159). I'm never sure whether this is
an artifact of how I'm constructing the command-line, of the intepreter,
or of underlying symbol capacity limits (WASD uses a similar symbol
concatenation algorithm to build CGI variable values larger than the
platform's command-line length limit).

Thanks for your input.

[And just to have another gratuitous shot - I wonder how I'd manage to
format this response via that 1990s interface at ITRC?]


One bit of code which hasn't yet (as of v8.2) been "adjusted" yet is
DCL READ, which still can't process any records over ~255 bytes.

This DCL snippet

$ record1 = f$fao("!250*$")
$ record2 = ""
$ open /write file sys$scratch:test.txt
$ on warning then goto end_write_loop
$ write sys$output "-----WRITE-----"
$ write_loop:
$ record2 = record2 + record1
$ write sys$output f$length(record2)
$ write /symbol file record2
$ goto write_loop
$ end_write_loop:
$ close file
$ open /read file sys$scratch:test.txt
$ on warning then goto end_read_loop
$ write sys$output "------READ-----"
$ read_loop:
$ read /end_of_file=end_read_loop file record3
$ write sys$output f$length(record3)
$ goto read_loop
$ end_read_loop:
$ close file
$ write sys$output "------END------"
$ delete sys$scratch:test.txt;*

seems to work well enough (Alpha V8.3)

-----WRITE-----
250
500
750
...
7500
7750
8000
%DCL-W-BUFOVF, command buffer overflow - shorten expression or
command line
------READ-----
250
500
750
...
7500
7750
8000
------END------

I was ambiguous.

Even though reading works, (at least in Alpha v8.2) DCL throws a
%DCL-W-TKNOVF when trying to write the symbol. This URL shows what
I mean:

http://members.cox.net/ron.l.johnson/VMS_READ_ERROR.TXT

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
.

Loading