6 Apr
2009
6 Apr
'09
5:20 p.m.
> Source files should not be giving you a
'record problem' (since they're
> text) - but there is another potential issue. I downloaded some BASIC
> source files on a PC, zipped them up and transferred them over to a VAX.
> I picked one to compile (this is BASIC we're talking about), and it
> failed with an error per line. I opened up the file in TPU and
> discovered that there was a 'spurious' CR at the end of each line. I
> removed those and everything compiled and linked. Take a look at the
> line-level translation that may be happening. -- Ian
New-line is not really standardized.
Although the machines may all claim to be using ASCII,
newline may be represented by
CR LF,
CR,
LF,
or LF CR (rarest)
The reasons are enough for a thread of its own.
This is almost exactly what I was seeing. I was able to resolve the problem
by NOT transferring the source files with FTP's binary image mode turned on.
I was then able to compile the source and I'm now in a maze of twisty
passages all alike.
6 Apr
6 Apr
9:46 p.m.
On Mon, Apr 6, 2009 at 1:20 PM, David Coolbear <david at thecoolbears.org> wrote:
Ah... there you go... text files must be transmitted between
architectures and platforms in text mode to allow the tool to Do The
Right Thing(tm). Both ftp servers and clients can communicate in an
RFC-described manner, but each end is ultimately responsible for
knowing what a text file is on their own systems and translating as
required.
VMS itself doesn't represent files internally (i.e., on the
filesystem) as streams of bytes with CR or LF or a combination at the
end of a line. An RMS text file is a series of variable length
records that are converted to things like null terminated strings,
etc., by, IIRC, a combination of RMS and the run-time-library for your
application's language (VAXCRTL.EXE, etc.)
This is conceptually quite different from how DOS and UNIX and
AmigaDOS, etc., etc., do things.
> Source
files should not be giving you a 'record problem' (since they're
> text) - but there is another potential issue.
> ... discovered that there was a 'spurious' CR at the end of each line. ?I
> removed those and everything compiled and linked. ?Take a look at the
> line-level translation that may be happening. ?-- Ian
This is almost exactly what I was seeing. I was able to resolve the problem
by NOT transferring the source files with FTP's binary image mode turned on. I was then able to compile the source and I'm now
in a maze of twisty
passages all alike.
Excellent. Congrats!
-ethan
7 Apr
7 Apr
1:12 a.m.
VMS itself doesn't represent files internally
(i.e., on the
filesystem) as streams of bytes with CR or LF or a combination at the
end of a line. An RMS text file is a series of variable length
records that are converted to things like null terminated strings,
etc., by, IIRC, a combination of RMS and the run-time-library for your
application's language (VAXCRTL.EXE, etc.)
That's one of the RMS formats: sequential variable length records. RMS
also has fixed length record files (card decks, sort of, with selectable
card width). And it does support "stream" files, with your choice of
CRLF, LF, or CR newline.
Then it has more exotic stuff like indexed files (key/data pairs). All
this was done much earlier in OS/360, perhaps first though I don't know
that for a fact. The 360s were also odd ducks in that they had hardware
support for variable length blocks and key/value files right in the disk
drives. This complexity still exists, in "mainframe" storage area
networking devices.
paul
5745
days inactive
5746
days old
2 comments
3 participants
participants (3)
-
david＠thecoolbears.org -
ethan.dicks＠gmail.com -
Paul_Koning＠Dell.com