- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- record too large for user's buffer
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2009 10:59 PM
тАО01-22-2009 10:59 PM
record too large for user's buffer
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2009 11:50 PM
тАО01-22-2009 11:50 PM
Re: record too large for user's buffer
> $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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 12:21 AM
тАО01-23-2009 12:21 AM
Re: record too large for user's buffer
$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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 12:37 AM
тАО01-23-2009 12:37 AM
Re: record too large for user's buffer
> %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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 02:47 AM
тАО01-23-2009 02:47 AM
Re: record too large for user's buffer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 04:11 AM
тАО01-23-2009 04:11 AM
Re: record too large for user's buffer
You may be able to 'fix' the file with a $SET FILE /ATTR=RFM=STMLF or some such.
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 06:41 AM
тАО01-23-2009 06:41 AM
Re: record too large for user's buffer
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 09:08 AM
тАО01-23-2009 09:08 AM
Re: record too large for user's buffer
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.