different output when running from command line and from "inside" descrip.mms file

[Jansen_8]

Can someone explain to me why the output from exactly the same executable (compiled from C++ sources) gives a complete different lay-out when runned from the command line and when invoked by MMS from its descrip.mms file (see example below)
The one from the command line I prefer.

Jouk


example:

$ run cppunittestmain.exe
Running
OK (0)

$ mms
run cppunittestmain.exe
R
u
n
n
i
n
g


O
K

(
0
)

[Hoff · Accepted solution]

That's typical of specific character-I/O operations in the C and C++ code, and can arise from down-revision software and particularly with some old problems within the C I/O redirection; that pattern was a fairly common misbehavior of C I/O some years ago, as well. There was an old bug with record handling with stdout an eon or two ago.

Check the versions of and patch levels of VMS, C++ and DECset MMS here.

Check the C++ code; what output calls are in use here.

And look for whatever I/O redirection is being contributed by MMS.

Also try mmk or gmake as a potential workaround.

Unfortunately, VMS has never gotten its I/O redirection working anywhere near as elegantly as is the norm on Unix.

[Jansen_8]

Thanks Hoff,

Both C++ and MMS are the latest versions for OpenVMS8.4 Alpha

C++ : HP C++ V7.3-009
MMS : V3.9-0

MMK gives the same results as MMS.

[Steven Schweda]

> [...] (compiled from [invisible] C++
> sources) [...]

> [...] MMS from its [invisible] descrip.mms
> file [...]

With my weak psychic powers, it's hard to be
sure of exactly what your secret code is
doing, but my guess would be that you have
something like:

fwrite( cp, 1, n, file)

instead of:

fwrite( cp, n, 1, file)

somewhere. The details of how many records
fwrite() creates when/why are all explained
somewhere in the C RTL documentation. VMS is
not UNIX.

If you want an answer which involves more
than pure guesswork, then you might consider
providing a complete (small) test case
instead of only a vague description.

I've seen this sort of behavior when program
output is directed to a log file instead of
to a terminal, as from a batch job. I can't
admit that MMS made any difference, but then
we non-psychics have no real idea of how you
got the results which you claim to have seen,
so it's hard to be really confident of
anything here.

[Jansen_8]

Steven,

The code is not so secret. I just tried to port the CPPUNIT package of which this program is a "test" program. (details on what I did are on my web page http://nchrem.tnw.tudelft.nl/openvms/software2.html
(next week I'll post an improved version there)

However there are no fwrites involved, but it looks like something like:

CPPUNIT_NS::stdCOut() << "Running " << testPath;

[Hoff]

Smells of bug. Probably in the language library, though a rule-out of mistakes within the application C++ code is in order.

[RBrown_1]

Just out of interest, what does it do if you

$ spawn cppunittestmain.exe

?

[Craig A Berry]

The most likely explanation has to do with differences in the record format and/or carriage return characteristics of the output device in each case. When running from the command line, C++ and its supporting run-time have more control over how SYS$OUTPUT gets opened. When running under MMS, MMS (or possibly DCL) has control.

Under MMS the child process running the C++ program is probably communicating to the parent through a mailbox, and a mailbox is a record-oriented device. It may be that the parent process running MMS has inherited DCL characteristics for SYS$OUTPUT. Either or both of these things could explain the behavior you're seeing.

In any case, the goal would be to make the C++ program see a stream-oriented output, perhaps by giving it the ability to create its own output file. Then you're MMS snippet would look something like:

mcr sys$disk:[]cppunittestsmain --output myfile.tmp
type myfile.tmp
delete/nolog myfile.tmp;

[Jansen_8]

spawning the run command gives exactly the same problem.

[Jansen_8]

assigning sys$output to a file gives a file with one character per line when invoked by MMS
and when runned from the command line.