- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: OpenVMS file format for lines longer than 3276...
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
тАО11-09-2010 01:07 PM
тАО11-09-2010 01:07 PM
OpenVMS file format for lines longer than 32767
$ @filename.com/output=filename.log
The function in question was designed to run interactively and it prints dots to let the user know that work is being done, (but we run this program in batch.) This worked fine for Cache 5.0.21 and back because Intersystems had inserted a LF/CR after 16K characters. Now under Cache 2008, Intersystems has removed the CR/LF and the problem is that OpenVMS has a line length limit of 32767 characters so the execution blows up after that number.
My question is, is there an OpenVMS file format that would insert a lf/cr after so many characters.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-09-2010 03:09 PM
тАО11-09-2010 03:09 PM
Re: OpenVMS file format for lines longer than 32767
pipe @filenam.com | perl -p -e "s/(\.)+/./" > filename.log
That one-liner will reduce running dots to 1. You could write a pager in Perl or another language if you prefer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-09-2010 03:21 PM
тАО11-09-2010 03:21 PM
Re: OpenVMS file format for lines longer than 32767
$ type stream_output.com
$ create/fdl=sys$input: myoutput.log
RECORD
CARRIAGE_CONTROL carriage_return
FORMAT stream_lf
$ open/share/append outfile myoutput.log
$ define/user sys$output outfile
$ define/user sys$error outfile
$ write sys$output "Something to output..."
$ close outfile
$ exit
$ @stream_output
$ type myoutput.log
Something to output...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-09-2010 03:48 PM
тАО11-09-2010 03:48 PM
Re: OpenVMS file format for lines longer than 32767
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-09-2010 03:49 PM
тАО11-09-2010 03:49 PM
Re: OpenVMS file format for lines longer than 32767
>> My question is, is there an OpenVMS file format that would insert a lf/cr after so many characters.
VMS does not insert CR/LF. Program do. Sometimes.
IMHO it is a Cache bug. They should recognize the output not being send to a terminal. Someone paid good money for for the software, let the vendor fix it or come up with a workaround.
If DECC is happened to be used for the output, which I do not know, then you could try define
DECC$DEFAULT_UDF_RECORD. But then how are you going to read it?
Hmmm, I suppose that as per Craig reply the output will go to a process permanent file anyway. Try what he said with /out=outfile
btw... on 8.3 you can use $CREATE/FDL="form stream_lf". That's all that's needed.
Redirect to the NL: device?
Redirect to a mailbox?
Nah that is unlikely to work.
If you do that check: DECC$MAILBOX_CTX_STM
I suppose you could create a Pseudo Terminal device (PDT) and run the output there, swallowing series of dots. That is most likely to be the best solution outside Cache support.
Good luck,
Hein
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-09-2010 04:06 PM
тАО11-09-2010 04:06 PM
Re: OpenVMS file format for lines longer than 32767
It depends on how the writer is sending the output. What's inside "filename.com" generating the dots?
Using PIPE might work, but it might also hit the PIPE length limit instead, which is typically much less than the RMS limit (I think it's DEFMBXMXMSG).
I'd be reporting this as a bug to Intersystems if it means you can't run their code in batch mode.
Short term, if the code is assuming a terminal type interface, you might be able to cook up something using a pseudo terminal to catch the output and chop it up anyway you like.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-10-2010 01:50 PM
тАО11-10-2010 01:50 PM
Re: OpenVMS file format for lines longer than 32767
I'm wondering if letting it go to a file and running your "dot producing" utility - maybe even a DCL that uses F$FILE_ATTRIBUTE to get EOF and FFB - is a possibility.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-10-2010 02:25 PM
тАО11-10-2010 02:25 PM
Re: OpenVMS file format for lines longer than 32767
I have been told that all DCL solutions won't work unless one uses a lower level language like MACRO. Without a LF/CR the cut off the record, the line won't get past the buffer of anything DCL.
Intersystems says that they took the LF/CR out of the stream because having it there was a "bug." They certainly are not OpenVMS centric.
Now that our GE team has realized that they have a vested interest in fixing this problem, they have found that other GE Cache applications have had this problem fixed by only printing 80 characters followed by a LF. So we will not have to resort to programming heroics to fix this problem.
That closes the thread for me unless you all can't put it down. If so, please continue.
Here is the Cache line causing the problem
W "." for 1 to infinity until processing is done with no LF or CR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-10-2010 08:37 PM
тАО11-10-2010 08:37 PM
Re: OpenVMS file format for lines longer than 32767
$ type stream_output.com
$ create/fdl=sys$input: myoutput.log
RECORD
CARRIAGE_CONTROL carriage_return
FORMAT stream_lf
$ open/share/append outfile myoutput.log
$ define/user sys$output outfile
$ define/user sys$error outfile
$ perl -e "for (1..65_535) { syswrite STDOUT, '.' }"
$ close outfile
$ exit
You happen to get 65,535 lines, each with a single dot on it because this Perl invocation uses an unbuffered write. Just replace that perl command with "@filename.com" and see what happens. If Cache is using stdio, you'll probably get records that are BUFSIZ - 1 in length, which is 8192 on VAX, 32,768 otherwise. But my impression is you don't care if the lines get wrapped a bit too often, just that the job doesn't blow up.
Hein, I don't think DECC$MAILBOX_CTX_STM helps on writes, only reads, but I might misremember (I know IO$M_STREAM at the $QIO level is only for reads).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-10-2010 08:53 PM
тАО11-10-2010 08:53 PM
Re: OpenVMS file format for lines longer than 32767
Agreed. I put it out there because I ran into that logical looking up the other one.
I probably should know this stuff better, but I don't run into trouble into this space often enough to recall details.
Furthermore I find these problem are often just fighting symptoms, not core problem. Like here.
That code "W "." for 1 to infinity until processing is done with no LF or CR" is just sloppy. Looks like it is just a timer based, poorly executed, misleading display with little or no real information being conveyed. I could be wrong though. Maybe each . represent a quantity of real work being done and not just a faked heartbeat.
fwiw,
Hein.