3 Apr
2009
3 Apr
'09
10:35 p.m.
After a very long wait and a lot of effort, my VAX is finally running
OpenVMS.
So, you know how boat builders break a bottle of Champaign on their new
creations? Well, my tradition is to get Colossal Caves running on all new
machines. The problem is that while I can find lots of downloads for
OpenVMS, none of them seem to work. Mostly it seems like FTP'ing the data
file corrupts it.
Any suggestion on how to get advent running on VMS?
3 Apr
3 Apr
11:40 p.m.
On Fri, Apr 3, 2009 at 6:35 PM, David Coolbear <david at thecoolbears.org> wrote:
After a very long wait and a lot of effort, my VAX is
finally running
OpenVMS.
Congratulations!
So, you know how boat builders break a bottle of
Champaign on their new
creations? Well, my tradition is to get Colossal Caves running on all new
machines. The problem is that while I can find lots of downloads for
OpenVMS, none of them seem to work. Mostly it seems like FTP'ing the data
file corrupts it.
With VMS, you need to worry about "RMS file attributes". Unlike UNIX,
files are not merely streams of bytes to VMS. We used to use a
program called BACKPACK.EXE that could encode RMS attributes into a
uuencoded-like textual stream that could be easily reconstituted.
We'd BACKPACK OLB files and such and have our customers use Kermit or
BLAST to get the data from us, then they'd turn the downloads back
into files and it all worked great. For non-VMS-to-VMS transfers, it
might not be so easy. EXEs are slightly easy to get because they use
512-byte fixed-sized records, so you could download a binary stream,
fix up the attributes, and VMS would recognize the file as an
executable. For the specific case of the data file for VMS, you'd
have to know what sort of file the executable is expecting and get the
data into that type of file.
So plain text files and executable binaries are easy to move onto a
VMS system. Odd binary formats (object libraries and other formatted
binary files) aren't easy to move on and off VMS. If the versions of
Adventure you've been playing with depend on odd files, then I can
understand why FTP wouldn't be able to move them around.
Any suggestion on how to get advent running on VMS?
Did you try this copy of the code? It appears to have the data file
in plain-text (atext.txt).
<http://simh.trailing-edge.com/games/adventure.zip>
(from <http://simh.trailing-edge.com/software.html>)
Back in the day, we used to move copies around on magtape, bypassing
all sorts of stream-of-bytes issues. Today, of course, most things
expect streams of bytes, so that's how most things are presented.
-ethan
4 Apr
4 Apr
3:47 p.m.
I used that version (with the atext.txt file) for our VAX-11/780-5 and it worked fine via
FTP. -- Ian
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of
Ethan Dicks [ethan.dicks at gmail.com]
Sent: Friday, April 03, 2009 4:40 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: The VAX is running
On Fri, Apr 3, 2009 at 6:35 PM, David Coolbear <david at thecoolbears.org> wrote:
After a very long wait and a lot of effort, my VAX is
finally running
OpenVMS.
Congratulations!
So, you know how boat builders break a bottle of
Champaign on their new
creations? Well, my tradition is to get Colossal Caves running on all new
machines. The problem is that while I can find lots of downloads for
OpenVMS, none of them seem to work. Mostly it seems like FTP'ing the data
file corrupts it.
With VMS, you need to worry about "RMS file attributes". Unlike UNIX,
files are not merely streams of bytes to VMS. We used to use a
program called BACKPACK.EXE that could encode RMS attributes into a
uuencoded-like textual stream that could be easily reconstituted.
We'd BACKPACK OLB files and such and have our customers use Kermit or
BLAST to get the data from us, then they'd turn the downloads back
into files and it all worked great. For non-VMS-to-VMS transfers, it
might not be so easy. EXEs are slightly easy to get because they use
512-byte fixed-sized records, so you could download a binary stream,
fix up the attributes, and VMS would recognize the file as an
executable. For the specific case of the data file for VMS, you'd
have to know what sort of file the executable is expecting and get the
data into that type of file.
So plain text files and executable binaries are easy to move onto a
VMS system. Odd binary formats (object libraries and other formatted
binary files) aren't easy to move on and off VMS. If the versions of
Adventure you've been playing with depend on odd files, then I can
understand why FTP wouldn't be able to move them around.
Any suggestion on how to get advent running on VMS?
Did you try this copy of the code? It appears to have the data file
in plain-text (atext.txt).
<http://simh.trailing-edge.com/games/adventure.zip>
(from <http://simh.trailing-edge.com/software.html>)
Back in the day, we used to move copies around on magtape, bypassing
all sorts of stream-of-bytes issues. Today, of course, most things
expect streams of bytes, so that's how most things are presented.
-ethan
5:53 p.m.
In article <f4eb766f0904031640g7c90507eo92411f16365021e1 at mail.gmail.com>,
Ethan Dicks <ethan.dicks at gmail.com> writes:
Back in the day, we used to move copies around on
magtape, bypassing
all sorts of stream-of-bytes issues. Today, of course, most things
expect streams of bytes, so that's how most things are presented.
How does magtape avoid the stream-of-bytes issue?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
5:58 p.m.
Magtape has blocks.
On Apr 4, 2009, at 12:53 PM, Richard wrote:
In article
<f4eb766f0904031640g7c90507eo92411f16365021e1 at mail.gmail.com>,
Ethan Dicks <ethan.dicks at gmail.com> writes:
Back in the day, we used to move copies around on
magtape, bypassing
all sorts of stream-of-bytes issues. Today, of course, most things
expect streams of bytes, so that's how most things are presented.
How does magtape avoid the stream-of-bytes issue?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
6:19 p.m.
On Sat, Apr 4, 2009 at 1:58 PM, Daniel Seagraves
<dseagrav at lunar-tokyo.net> wrote:
Magtape has blocks.
On Apr 4, 2009, at 12:53 PM, Richard wrote:
> In article <f4eb766f0904031640g7c90507eo92411f16365021e1 at mail.gmail.com>,
> ? ?Ethan Dicks <ethan.dicks at gmail.com> ?writes:
>
>> Back in the day, we used to move copies around on magtape, bypassing
>> all sorts of stream-of-bytes issues. ?Today, of course, most things
>> expect streams of bytes, so that's how most things are presented.
>
> How does magtape avoid the stream-of-bytes issue?
Right... one block, one RMS record.
On UNIX systems, tape blocks tend to be all one size. Somewhat less so on VMS.
-ethan
6:29 p.m.
In article <2877e57dba24bc750739ccec428ded28 at lunar-tokyo.net>,
Daniel Seagraves <dseagrav at lunar-tokyo.net> writes:
What exactly is a block?
Is it defined as a sequence of bits or as a sequence of bytes?
If its just a sequence of bytes that define a block, I'm not sure I
understand how blocks avoid the stream-of-bytes issue.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
In article
<f4eb766f0904031640g7c90507eo92411f16365021e1 at mail.gmail.com>,
Ethan Dicks <ethan.dicks at gmail.com> writes:
> Back in the day, we used to move copies around on magtape, bypassing
> all sorts of stream-of-bytes issues. Today, of course, most things
> expect streams of bytes, so that's how most things are presented.
On Apr 4, 2009, at 12:53 PM, Richard wrote:
How does magtape avoid the stream-of-bytes issue?
Magtape has blocks. 
6:35 p.m.
>> Back
in the day, we used to move copies around on magtape,
bypassing
>> all sorts of stream-of-bytes issues.
Today, of course, most
things
>
expect streams of bytes, so that's how most things are presented.
On Apr 4, 2009, at 12:53 PM, Richard wrote:
How does magtape avoid the stream-of-bytes issue?
Magtape has blocks.
6:49 p.m.
In article <D8CEBB6AE9D43848BD2220619A43F326297685 at M31.equallogic.com>,
"Paul Koning" <Paul_Koning at Dell.com> writes:
I think the more important point is that tapes also
have file
attributes, similar to what RMS has. So when you need valid attributes
-- as you do on VMS -- then transferring the file via ANSI labeled tapes
will do that, while transferring via FTP will not.
It sounds like you're saying that metadata about the file is lost
because FTP just transmits the file contents and not the metadata.
(Similar to the data and resource forks on a Macintosh file?)
The solution seems to be to capture the file in a way that captures
the metadata as well, like StuffIt for Mac files.
Is that it?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
7:35 p.m.
On Sat, Apr 4, 2009 at 2:49 PM, Richard <legalize at xmission.com> wrote:
It sounds like you're saying that metadata about
the file is lost
because FTP just transmits the file contents and not the metadata.
Pretty much.
(Similar to the data and resource forks on a Macintosh
file?)
Not that formal. With tapes, the out-of-band data wasn't part of the
data stream from your application, but your application could make
requests of the driver to write EOF and EOT "markers" and by the size
of the blocks you sent to the driver, created the aforementioned
metadata.
The solution seems to be to capture the file in a way
that captures
the metadata as well, like StuffIt for Mac files.
Is that it?
That's what "tape container files" are, in essence... imagine a
stream-of-bytes file, with a record size, then the "payload" then a
record size, with the ability to insert end-of-tape "markers" in the
file for whatever application is going to re-parse the file.
Such things exist now, but were not so common 20 years ago. We had
real tapes and we moved real tapes around - FTP and such became
popular on non-UNIX platforms later (well... there's FTP for TOPS-20,
but I didn't have any direct experience with that back in the day, so
I can't speak to what happened in that world).
-ethan
11:36 p.m.
New subject: FTP xfer modes, was Re: The VAX is running
Ethan Dicks wrote:
Such things exist now, but were not so common 20 years ago. We had
real tapes and we moved real tapes around - FTP and such became
popular on non-UNIX platforms later
It was about 20 years ago that I was working with CMU-TEK and TGV's
MultiNet TCP/IP packages on VMS. ISTR that there was a mode available in
the FTP client for one or both of these that I could use with other
hosts where records were used (VMS, TOPS, etc) so that I could transfer
files with the record structure intact. Much like switching between
ASCII and BINARY mode, but I can't recall what the command was. (TENEX?
STRUCT?)
Of course I have been out in the sun without a hat today, so this could
be an indication of delirium or the CIA's orbital mind-control lasers,
whichever you're more inclined towards. ;^)
--S.
5 Apr
5 Apr
3:08 a.m.
New subject: FTP xfer modes, was Re: The VAX is running
It was about 20 years ago that I was working with
CMU-TEK and TGV's
MultiNet TCP/IP packages on VMS. ISTR that there was a mode
available in the FTP client for one or both of these that I could use
with other hosts where records were used (VMS, TOPS, etc) so that I
could transfer files with the record structure intact.
FTP has a lot of facilities that nobody ever uses in today's
pointy-clicky "everything's a stream of bytes" world (which the people
who designed those into FTP would, like as not, justifiably correct to
"...stream of octets").
You might want to actually go read the spec (RFC 959, IIRC) if you care
about this stuff.
Of course, this is not to say that there wasn't some private extension
in use in the setup you saw.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
3:48 a.m.
New subject: FTP xfer modes, was Re: The VAX is running
On 4 Apr 2009 at 16:36, Steven M Jones wrote:
It was about 20 years ago that I was working with
CMU-TEK and TGV's
MultiNet TCP/IP packages on VMS. ISTR that there was a mode available
in the FTP client for one or both of these that I could use with other
hosts where records were used (VMS, TOPS, etc) so that I could
transfer files with the record structure intact. Much like switching
between ASCII and BINARY mode, but I can't recall what the command
was. (TENEX? STRUCT?)
Inter mainframe incompatibilities were part of FTP from very early
days,
RFC 571 (1973( brought up the TENEX problem and RFC 683 (1975)
proposed a solution. How simple the matter of codes has become is
evidenced by the listing of the various datatypes in RFC 114 (about
30 of them).
Cheers,
Chuck
8 Apr
8 Apr
4:48 a.m.
On 05/04/2009, at 4:49 AM, Richard wrote:
The solution seems to be to capture the file in a way that captures
the metadata as well, like StuffIt for Mac files.
The easiest approach is to put the file(s) to be transferred into a
BACKUP save set. Transfer the save set via ftp (or any other method -
kermit anyone?). Sure the BACKUP save set has lost it's attributes
during the transfer, but it's trivial to fix. Even more so with V8.4
which has a /repair switch to BACKUP for just this purpose.
Huw Davies | e-mail: Huw.Davies at kerberos.davies.net.au
Melbourne | "If soccer was meant to be played in the
Australia | air, the sky would be painted green"
4 Apr
4 Apr
6:36 p.m.
A block is a sequence of tape frames. Those can be 7 or 8 bits wide
depending on your hardware. Blocks have length, and can vary in length
from block to block. You can have a small descriptor
block between long
data blocks on the tape, where the small block describes what
the next
large block contains, and so on. You can tell if a block is a
descriptor by its length, or looking for a magic number at the start of
the block, or whatever.
Tapes also have file-marks.
On Apr 4, 2009, at 1:29 PM, Richard wrote:
In article <2877e57dba24bc750739ccec428ded28 at lunar-tokyo.net>,
Daniel Seagraves <dseagrav at lunar-tokyo.net> writes:
What exactly is a block?
Is it defined as a sequence of bits or as a sequence of bytes?
If its just a sequence of bytes that define a block, I'm not sure I
understand how blocks avoid the stream-of-bytes issue.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
In
article
<f4eb766f0904031640g7c90507eo92411f16365021e1 at mail.gmail.com>,
Ethan Dicks <ethan.dicks at gmail.com> writes:
> Back in the day, we used to move copies around on magtape, bypassing
> all sorts of stream-of-bytes issues. Today, of course, most things
> expect streams of bytes, so that's how most things are presented.
On Apr 4, 2009, at 12:53 PM, Richard wrote:
How does magtape avoid the stream-of-bytes issue?
Magtape has blocks.
6:45 p.m.
In article <ec771527c0a0c99d33c9adc43d6bb32d at lunar-tokyo.net>,
Daniel Seagraves <dseagrav at lunar-tokyo.net> writes:
A block is a sequence of tape frames. Those can be 7
or 8 bits wide
depending on your hardware. Blocks have length, and can vary in length
from block to block. You can have a small descriptor block between long
data blocks on the tape, where the small block describes what the next
large block contains, and so on. You can tell if a block is a
descriptor by its length, or looking for a magic number at the start of
the block, or whatever.
OK, this seems to indicate that there is a well defined mapping
between tape frames and bytes. Since a block is a sequence of tape
frames, that implies that blocks are well mapped to a sequence of
bytes. I guess I'm still missing something that magtape solves that a
stream of bytes doesn't solve.
My understanding is that the hardware tape interface just delivers a
sequence of tape frames without any additional interpretation and that
its the driver/OS/whatever that interprets the tape frames into some
larger structure.
Tapes also have file-marks.
How is that represented?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
5 Apr
5 Apr
2:38 p.m.
>> How does magtape avoid the stream-of-bytes
issue?
> Magtape has blocks.
What exactly is a block?
Is it defined as a sequence of bits or as a sequence
of bytes?
It depends on the tape technology. The most classical one in my
(admittedly limited) experience has blocks that are variable-sized
strings of bytes. That is, it would be accurate for these purposes to
model the tape as a stream of symbols from a 258-symbol alphabet: 256
bytes plus "block boundary" and "tape mark", where block boundaries
delimit blocks and tape marks delimit files. I'm not sure this model
is totally accurate - for example, I'm not sure a zero-length block is
possible - and it's definitely not a close match to the implementation.
But it's probably close enough to get the flavour.
More recent technologies are a bit different. Some (all?) QIC tapes,
for example, are not streams of variable-sized blocks but streams of
512-octet blocks.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
5744
days inactive
5749
days old
16 comments
10 participants
participants (10)
-
cclist＠sydex.com -
classiccmp＠crash.com -
david＠thecoolbears.org -
dseagrav＠lunar-tokyo.net -
ethan.dicks＠gmail.com -
huw.davies＠mail.vsm.com.au -
IanK＠vulcan.com -
legalize＠xmission.com -
mouse＠Rodents-Montreal.ORG -
Paul_Koning＠Dell.com