Bob's comments agree with mine.

What may be confusing people is that that reading a data file may be
different from a print file.

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.

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.

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.

So, depending on what platform you are on now, you may have to set
attributes or force a conversion.

Note that on VMS (and other platforms), a TYPE (or cat) command may
invoke implicit conversions different from what the FORTRAN RTL invokes.

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.

I know it's odd, but the 'simple' act of writing a record to a file can
be surprisingly complicated and non-portable.

On 02-Feb-18 14:59, Lars Brinkhoff wrote:
>> 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.
> For example the data file contains lines like this:
> 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Simh mailing list

Reply via email to