4KB size limit for DCL commands doesn't work

[Petr Spisek]

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

I have a problem with line size limit after using command:
READ/PROMPT = "Continue? Y/N: " SYS$COMAND CONT

After this command the same DCL session change line limit from 4095 to 256 bytes.
Does anybody know why?

I've running VMS V7.3-2.

Petr

[Petr Spisek]

Corrrection:
READ/PROMPT = "Continue? Y/N: " SYS$COMMAND CONT
... of course.

[Volker Halle]

Petr,

could you provide an example to illustrate what you are doing and what kind of problem/symptom/error message you see ?

Volker.

[Petr Spisek]

See attachment.

[Martin Vorlaender]

I can't reproduce it here (see atachment).

cu,
Martin

[Karl Rohwedder]

I tried to reproduce it using V7.3-2 and V8.2 and was not able to do so.

Do you have plain V7.3-2 or are any patches installed?

regards Kalle

[Bojan Nemec]

Petr,

I can reproduce the error.
After the read command the limit becames 512 bytes. I tested this on an "real" terminal (OPA0 and TTA0) and on a DECterm (FTA) and also on an DECnet (RTA) remote terminal.
The strange thing is that on the DECnet remote terminal I cant reproduce the error.

After the RMS-W-TNS error you receive another error if you tray to recall the long line (or with RECALL or simply with up arrow). The error is:
%SYSTEM-F-BADPARAM, bad parameter value

My system has no last paches installed!

Bojan

[Volker Halle]

Petr,

I can also reproduce it on V7.3-2 and E8.2. The problems is NOT the symbol length (SHOW SYMBOL b), but the interactive command line input, which fails with

%RMS-W-TNS, terminator not seen

after 512. bytes.

I know someone, who's probably interested in this ;-)

Volker.

[Petr Spisek]

Hi, thanks for interest.
I've 3 months old patches (attachment). It looks as some problem with user buffer. I can reproduce this from common VTA100 terminals (decterm, aterm, PowerTerm).

[Petr Spisek]

Bojan,
BADPARAM it's inference of incomplete command.

Volker,
... and when will be fix? :-)

To all:
I always use TELNET sessions to connect my terminal. Not DECNET.

[Volker Halle]

Petr,

your reproducer uses the READ/PROMPT ... command interactively - probably nothing which would be used in reality, so this problem may seem to have minimal (near zero) impact.

But what's making this problem (just) a little bit more interesting, is that - if you use this command in a DCL procedure executed interactively - it will permanently change the DCL command line size for your process (to 512 bytes). You have to logout and login again to obtain the extended command line size.

But who is using interactive commands with more than 512 bytes anyway ;-)

Volker.

[Jan van den Ende]

Volker wrote:


But who is using interactive commands with more than 512 bytes anyway ;-)


for one thing, more and more often longer filenames and directory paths are being (generated and) used. Also, commands are slowly growing the amounts of (combinable) qualifiers and parameters.
As a result, commands DO tend to grow.

The one that has bothered us for over a decade, and now finally seemed resolved, is manipulating the result of F$GETJPI(xx,"RIGHTSLIST"). We had to trick around it in complex ways. Of course :-) that has not yet been trimmed back, and now it seems that I have to be very glad for that laziness!!

Like a former collegue used to say:
"Laziness is a virtue"

Thanks for the warning Petr. Iwill remain lazy some longer.

Proost.

Have one on me.

Jan

[Volker Halle]

Jan,

this specific problem only happens when you INTERACTIVELY type in a DCL command line, which is longer than 512 characters. The error is %RMS-W-TNS, terminator not seen.

It doesn't affect DCL command procedures operating with long filenames, symbols etc.

So again: do you normally type in DCL commands more than 512 bytes long ?

and then recognize that you mistyped the first character ;-(

Volker.

[Guy Peleg]

Petr,

This looks like a bug in DCL.
DCL is setting RAB$W_USZ to 4096, I suspect
that after we process the READ/PROMPT
command, USZ is being overwritten or
reset to a default value.

Please escalate the problem to your local
support center. This will have to be investigated officially.

Regards,

Guy Peleg
Current father of DCL

[Hein van den Heuvel]

To investigate yourself, you can probably use ANAL/SYSTEM ... SHOW PROC/RMS=(RAB,PIO)

The ISI should be 'funny' like 8081x
The USZ would be the interesting field.

fwiw,
Hein

[Volker Halle]

Hein,

funny, the USZ remains the same:

USZ: 1000 4096.

it seems to be the BDB size, which is changing:

SIZE: 00001000 NUMB: 00001000

SIZE: 00000200 NUMB: 00000200

and - among some others :

BKPBITSEXT: 00000000

changes to

BKPBITSEXT: 00000020 UR_DEFAULT_BUFSZ


How to find out what's changed:

SDA> SET PROC/IND=
SDA> SET OUT/NOINDEX x1.x
SDA> SHOW PROC/RMS=(PIO,ALL)

Issue the READ/PROMPT command in the test-process

SDA> SET OUT/NOINDEX x2.x
SDA> SHOW PROC/RMS=(PIO,ALL)
SDA> EXIT

$ DIFF/IGNO=HEADER x1.x x2.x

Volker.

[Petr Spisek]

Volker, sometimes I use READ/PROMPT in command procedures and from this my process permanently changes line-size. Workaround Logout/Login â ¦ What does it mean? Is it a Windows or the VMS? :-) Iâ m just only pointing to the potential problem.

Hein,
USZ wasnâ t changed (check this attachment)

So, Iâ ll try to escalate th

[Volker Halle]

Petr,

something in the READ/PROMPT command PERMANENTLY changes some attribute in the process (probably in P1 space), that's why only Logout/Login is a workaround, as it will create a new process address space. It's clearly an OpenVMS problem.

How did you discover this ? Do you REALLY type in interactive DCL commands longer than 512. bytes ???

Volker.

[Petr Spisek]

:-) no, as it happens.
I was troubleshooted a problem in a DCL script ... I couldn't write the long line to a file, but problem was in the limit between quotation marks "" to 256. Solution is: add to commas WRITE WF "long string","next long strig",...