OpenVMS file format for lines longer than 32767

[Clark Powell]

We are running a GE Centricity Business 4.3 function (uses Cache database from Intersystems) in batch mode with the following DCL line:
$ @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.

[Richard Brodie_1]

My choice would be to PIPE it through a filter program e.g.

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.

[Craig A Berry]

You might be able to do this by coercing your output into stream format, though DCL doesn't make that easy. Something like this might work:

$ 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...

[Clark Powell]

I think that PIPE will not pass the output on until it sees a LF or CR.

[Hein van den Heuvel]

Are those 'naked' dots, or embedded in an escape sequence?

>> 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

[John Gillings]

Clark,

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.

[John McL]

Do you need to catch that data stream in transit in order to post your dots?

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.

[Clark Powell]

New developments:

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

[Craig A Berry]

I'm not sure how "can't get past the buffer of anything DCL" applies if DCL is not doing the writes. By default, DCL opens all files, including process-permanent files like SYS$OUTPUT, in a record-oriented format. But the example I gave shows how to get around that. This revised version of my example writes 65,535 dots to the file without blowing up:

$ 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).

[Hein van den Heuvel]

>> 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).

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.