<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Bob's comments agree with mine.</p>
<p>What may be confusing people is that that reading a data file may
be different from a print file.</p>
<p>This depends on the OS. In the case of VMS, it depends on the
file attributes, which tell RMS whether the file has embedded
carriage control character, FORTRAN carriage control characters,
"Print" (PRN = prefix/suffix implied") carriage control,
CRLF-delimited, lines, or LF-delimited lines, or is an ASCII
stream. In the case of TOPS-10/20, a .DAT file type implies
FORTRAN, everything else is explicit carriage control; by
convention crlf, crff, crvt.</p>
<p>The default (or file attribute-declared) interpretation can be
overridden with OPEN arguments; this was new in F75 or so, though
DEC supported it as an extension earlier.<br>
</p>
<p>Any data file that you have has probably been through some form
of conversion. And depending on any file system attributes, may
have been converted correctly or not. And even if correctly
converted, may have an incorrect implicit conversion where it is
now. Older programs probably don't specify OPEN arguments and
rely on the defaults.</p>
<p>So, depending on what platform you are on now, you may have to
set attributes or force a conversion.</p>
<p>Note that on VMS (and other platforms), a TYPE (or cat) command
may invoke implicit conversions different from what the FORTRAN
RTL invokes.</p>
<p>I may have missed it, but you'll get more help if you provide the
OS that you're running on, the file attributes (for DCL, dir/full
and/or dump/header), and a hex dump of the first block or two of
the file.</p>
<p>I know it's odd, but the 'simple' act of writing a record to a
file can be surprisingly complicated and non-portable.</p>
On 02-Feb-18 14:59, Lars Brinkhoff wrote:<br>
<blockquote type="cite" cite="mid:7wvaff6u3n.fsf@junk.nocrew.org">
<blockquote type="cite">
<pre wrap="">I see that the data file from which the strings are read do prefix all
strings with a space character. So it looks like the intent is that
FORMAT(20A5) should do the right thing. Maybe the root cause is in
the code reading the data file.
</pre>
</blockquote>
<pre wrap="">
For example the data file contains lines like this:
42 YOU ARE IN A MAZE OF TWISTY LITTLE PASSAGES, ALL ALIKE.
Right after the number is a TAB character, and then there's a space
character, and then the text. "42\t YOU..."
1004 READ(1,1005)JKIND,(LLINE(I,J),J=3,22)
1005 FORMAT(1G,20A5)
1G should read a number. I'm guessing the TAB is a separator here? In
that case, 20A5 ought to read the text including the first space
character.
_______________________________________________
Simh mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a>
<a class="moz-txt-link-freetext" href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a>
</pre>
</blockquote>
<br>
</body>
</html>