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

record too large for user's buffer

 
Highlighted
shiva27
Frequent Advisor

record too large for user's buffer

Appreciate ur help in advance.
while executing procedure getting error-
$@test.com;
%RMS-W-RTB, 16383 byte record too large for user's buffer

OS:OVMS V7.3-2
i think we can resovle this issue by,
$set file/attributes=(mrs=0,lrl=1000) test.com;

Ques:how can i calculate mrs=?,lrl=? values.

Is there any other way to fix this issue.
7 REPLIES 7
Steven Schweda
Honored Contributor

Re: record too large for user's buffer

> i think we can resovle this issue by,
> $set file/attributes=(mrs=0,lrl=1000) test.com;

Possible, but I doubt it. What's in
test.com? I'd guess that the error is
triggered by some command in the procedure,
not by DCL trying to read the procedure file
itself.

SET VERIFY
@ test.com
shiva27
Frequent Advisor

Re: record too large for user's buffer

$set verify
$ty test.com;
%TYPE-F-WRITEERR, error writing SYS$OUTPUT:.;
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, process quota exceeded

$@test.com;
%RMS-W-RTB, 16383 byte record too large for user's buffer

I had uploded this file (provided by vendor) for monitoring setup.

I tried to upload in ascii and binary.
Steven Schweda
Honored Contributor

Re: record too large for user's buffer

> $ty test.com;
> %TYPE-F-WRITEERR, [...]

Ok, you win. The procedure file itself is
bad.

> I had uploded this file (provided by
> vendor) [...]

I think we'd call that downloading. This
would have been good to know at the
beginning.

How, exactly, did you do it?

> I tried to upload in ascii and binary.

So that's FTP then?

DIRE /FULL test.com

If you did it the wrong way first, then the
second version of the file could have
inherited the bad attributes from the first
version. I'd try ASCII into a clean
directory or a different name. Then, look at
the file with an editor to see if you can
read it that way. If you get desperate,
DUMP /BYTE, and look at the actual data, too.
_Then_ when you know what you have, you can
think about SET FILE /ATTR = RFM: xxx.
Playing with MRS and/or LRL is almost
certainly a bad idea.
shiva27
Frequent Advisor

Re: record too large for user's buffer

Okay. I will try to download the file in another directory and if the same error then will ask the vendor to verify the file at source.
Hein van den Heuvel
Honored Contributor

Re: record too large for user's buffer

Or, you $DUMP/BLOC=COUN=1 test.com and carefully study the result. Compare what you see with $DIR/FULL test.com;.
You may be able to 'fix' the file with a $SET FILE /ATTR=RFM=STMLF or some such.

Hein.

Steven Schweda
Honored Contributor

Re: record too large for user's buffer

> [...] $SET FILE /ATTR=RFM=STMLF or some such.

For an example of "some such", text file
attachments in this forum normally have CR+LF
line endings, and a typical Web browser will
save them as Stream_LF, leaving the CR's all
visible. SET FILE /ATTR = RFM: STM can fix
that.
Hoff
Honored Contributor

Re: record too large for user's buffer

So this is a case of DCL bits provided by a vendor that breaks, and you're here in ITRC asking questions? An approach more proximate and that would seem most expedient would be to ask the vendor that provided the DCL bits how to transfer the bits over to the host.

OpenVMS files that touch Windows boxes are often corrupted by that stop-over, which is why various vendors provide these as zip archives. zip (with the zip "-V" switch specified, including the quotes around it) prevents intervening hosts from stripping the file attributes; from producing these sorts of corruptions.

Here, use cut-and-paste if you have that set up. If you received this DCL as a mail attachment or such, save the file as a .txt and not a .com, and re-transfer it as an ASCII text file. Or you can ask the vendor to resend the file as a zip archive (with "-V") as that prevents corruptions.

DCL command procedure can be corrupted with a stop-over in Windows for a second reason, as the browsers and tools on Windows all tend to assume a .COM file is an executable and not a sequential text file. Which is another reason to use zip (with "-V") option to protect the files. More than a few firewalls strip messages with .COM files, too.

The other option is to download the DCL bits directly to and via the OpenVMS box and its networking capabilities, as the tools and browsers on OpenVMS assume a .COM file is a sequential text file.

Yes, I'm very deliberately repeating the recommendation around the use of a zip archive (with "-V") as that prevents corruptions. Vendors that don't do that should be called up and verbally flogged as they're allowing you and other users of their products and tools to join the legions of those that have encountered corrupted file transfers.

Your vendor left you hanging here, either in terms of skipping the use of zip (with "-V") or with the lack of directions on how to use these bits of DCL from the file source (mail, ftp server, otherwise) over onto the OpenVMS host.