DOS history question
Adam Fairbrother
history of the 8.3 file name convention in DOS. I was reading through
some old messages in google groups, and found a partial answer, but it
isn't something that I understand all that well. Something about a CP/M
OS refrenced when making DOS as well as something to do with the PDP10(6
bit chars), and RAD50(Octal packing).
Now don't get me wrong, I do have a bit of an understanding
about... bits as well as Octal, and that part makes scence to me, other
then the part of what the hell a "PDP10" and a "RAD50". Although I
still havn't fully looked into their history yet.
When i started looking into the CP/M I found a link to this
website. http://members.fortunecity.com/pcmuseum/kildall.htm, and the
name Gary Kildall, the apprerant programer of CP/M. The web page states
that he took the 8.3 naming convention from the DEC PDP-10 VMS OS.
After searching around a bit more I found a newsgroup post that states
that "Either Gary had a time machine and traveled to an alternate
universe to do the copying, or the page is wrong :-). I'll agree fully
that there was a significant influence from the DES OS's, but you cannot
tie it to any one because he did not copy any one of them in detail." --
Tim Shoppa (sho...@trailing-edge.com). The same post states that he
choose 8.3 just because.
Now, I hope this isn't asking to much, but is all that information
pretty much accurate? did he really just choose it on a whim or is there
a real reason that he chose the 8.3. Also any information that you can
point me to or provide on the "PDP10" and "RAD50" would greatly be
appreciated.
Thanks in advance
--Adam Fairbrother
jmfb...@aol.com
Adam Fairbrother <quickn...@hotmail.com> wrote:
> Hello, I was just wondering if anyone in here would know the
>history of the 8.3 file name convention in DOS. I was reading through
>some old messages in google groups, and found a partial answer, but it
>isn't something that I understand all that well. Something about a CP/M
>OS refrenced when making DOS as well as something to do with the PDP10(6
>bit chars), and RAD50(Octal packing).
This was on all of DEC's architectures.
>
> Now don't get me wrong, I do have a bit of an understanding
>about... bits as well as Octal, and that part makes scence to me, other
>then the part of what the hell a "PDP10"
PDP-10 was a CPU architecture.
> ..and a "RAD50".
RAD50 was simply a "formatting" scheme and was used by the
assemblers when they output *.REL files to save memory, disk
space, etc. Now I bet you'll have to ask what a *.REL file is.
> .. Although I
>still havn't fully looked into their history yet.
>
> When i started looking into the CP/M I found a link to this
>website. http://members.fortunecity.com/pcmuseum/kildall.htm, and the
>name Gary Kildall, the apprerant programer of CP/M. The web page states
>that he took the 8.3 naming convention from the DEC PDP-10 VMS OS.
Hit that man with a hundred wet noodles; he apparently doesn't know
his OS from a hole in the ground.
>After searching around a bit more I found a newsgroup post that states
>that "Either Gary had a time machine and traveled to an alternate
>universe to do the copying, or the page is wrong :-). I'll agree fully
>that there was a significant influence from the DES OS's, but you cannot
>tie it to any one because he did not copy any one of them in detail." --
>Tim Shoppa (sho...@trailing-edge.com). The same post states that he
>choose 8.3 just because.
>
> Now, I hope this isn't asking to much, but is all that information
>pretty much accurate? did he really just choose it on a whim or is there
>a real reason that he chose the 8.3. Also any information that you can
>point me to or provide on the "PDP10" and "RAD50" would greatly be
>appreciated.
alt.sys.pdp10
/BAH
Subtract a hundred and four for e-mail.
Hans Vlems
"Adam Fairbrother" <quickn...@hotmail.com> schreef in bericht
news:Xns9289171BE9...@24.67.253.211...
history. What remains are legends, deteriorating memories and downright
nonsense. An example of the latter is "DEC PDP-10 VMS OS". Sounds impressive
but it combines a computer architecture (the PDP-10, and it came in several
implementations in hardware) and an operating system (VMS). VMS runs on
several platforms, the PDP-10 was not part of that set. Both the PDP10 and
VMS are products of Digital Equipment Corp.
To return to the 8.3 question, (AFAIK) VMS had 9.3 in the beginning and it
was later modified to 39.39.
RAD50 is more a coding (compression) technique. It translates values into a
radix-50 system and the neat thing is that you can put 3 radix-50 symbols in
a single byte.
8.3 filenames were used by DEC operating systems. OS8, RT-11 and RSX spring
to mind. IIRC OS8 (runs on the PDP-8 platform) dates from the mid 70's.
DG's RDOS also had 8.3 filenames and in unix the concept doesn't even exist.
Unix allows a dot in a filename but it has no meaning for the OS itself.
Hans
jmfb...@aol.com
Was it 9? I don't seem to be able to remember what 11M could do.
> ...and it
>was later modified to 39.39.
After TOPS-20.
>RAD50 is more a coding (compression) technique.
>It translates values into a
>radix-50 system and the neat thing is that you can put
>3 radix-50 symbols in a single byte.
You should probably define byte here.
>8.3 filenames were used by DEC operating systems.
>OS8, RT-11 and RSX spring to mind.
I don't remember them being 8.3. On the other hand, all
the work I did for -11 and -8 groups was prepared on a
PDP-10, so that might explain why I never saw 8 characters.
> ..IIRC OS8 (runs on the PDP-8 platform)
Yup.
> ... dates from the mid 70's.
Nope. Earlier. I don't have dates, though. One of the guys who
worked on 0S8 was doing it around when I started working at DEC
and that was 1971.
>DG's RDOS also had 8.3 filenames and in unix the
>concept doesn't even exist.
>Unix allows a dot in a filename but it has no meaning for the OS itself.
That's another breakage in standard usage, IMO. The extension
had a definite mean, had standards established, and was a
remarkably useful way to organize and manage files.
Douglas H. Quebbeman
> >DG's RDOS also had 8.3 filenames and in unix the concept doesn't even exist.
> >Unix allows a dot in a filename but it has no meaning for the OS itself.
>
> That's another breakage in standard usage, IMO. The extension
> had a definite mean, had standards established, and was a
> remarkably useful way to organize and manage files.
Actually, while it may not mean anything to the Unix *kernel*,
the file extension does tend to mean things to compilers and
the like.
The MacOS through HFS (hierarchical file system) allows one
or more dots in a filename, but uses a separate mechanism
to determine type of a file, as well as the application
resposible for files of a given type. These are additional
fields in the directory. And, while I have no idea whether
you can refer to these fields in the underlying Unix shell
found in OS X, in the GUI shell, you can issue a search for
files of a specified type and creator.
-dq
Joe Morris
>Hit that man with a hundred wet noodles; he apparently doesn't know
>his OS from a hole in the ground.
I don't know if you thought that one up or got it from somewhere else;
i've not seen it before. ROFLM(OS)O!
Consider it stolen by me for use elsewhere. Thanks!
Joe Morris
Tim Shoppa
> When i started looking into the CP/M I found a link to this
> website. http://members.fortunecity.com/pcmuseum/kildall.htm, and the
> name Gary Kildall, the apprerant programer of CP/M. The web page states
> that he took the 8.3 naming convention from the DEC PDP-10 VMS OS.
1) VMS didn't exist until 1978. CP/M had existed several years by then.
2) First versions of VMS used 9.3, just like RSX-11 and its filesystem
ODS-1.
3) VMS doesn't run on a PDP-10.
Tim.
Anne & Lynn Wheeler
> 1) VMS didn't exist until 1978. CP/M had existed several years by then.
>
> 2) First versions of VMS used 9.3, just like RSX-11 and its filesystem
> ODS-1.
>
> 3) VMS doesn't run on a PDP-10.
there was some statement about the head of pok contributing heavily to
VMS ... this was not related to
http://www.garlic.com/~lynn/2001m.html#15 departmental server
in the mid-70s a number of the smaller, outlying operations were being
consolidated.
in '76, vm/370 development in burlington mall was being closed and the
group consolidated in endicott. at some point the head of POK realized
that MVS/XA development was dependent on the VMTOOL (a internal only
version of VM for providing XA virtual machines in support of
operating system development) and the people got told that instead of
moving to Endicott as part of product development they had to move to
POK to support the internal VMTOOL (and another round of VM product
being killed). Some number refused to moved to POK and instead left
IBM to go to work for DEC on VMS.
--
Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/
Roland Hutchinson
> The MacOS through HFS (hierarchical file system) allows one
> or more dots in a filename, but uses a separate mechanism
> to determine type of a file, as well as the application
> resposible for files of a given type.
The "application responsible" (called the "creator") is specified for each
file individually in the Mac filesystems. (Yet another mechanism -- at the
OS level, not the filesytem level -- is responsible for finding the default
application for a given file type if the file's own creator is not
available). One creator can create and open many different file types (as
on other systems), but also files of a single type can have any of several
different creators (this file HERE is a MS-Word text file, but that one
THERE is a BBedit text file -- and by default they will open in their
respective applications).
Of course "creator" is something of a misnomer, given that there have been
utilities available from almost Day One of the Macintosh Finder that let
the user edit the creator field so that files created with one program can
be reassigned to be open by default with another.
I think that the MacOS way of doing this is a big win, if for no other
reason than that it eliminates the "turf wars" among applications that have
come to plague Windows users.
I note with interest that on my Linux box, KDE has a means of specifying
the "application responsible" for a file on a per-file basis, but it is
rather kludgy and broken, and consequently I rarely have used it. (It
squirrels the information away in a hidden file in the directory, and it
forgets about it if you move the file to another directory, at least as of
version 2.2.2. IMHO one of the things that the KDE designers failed to
grasp at the outset is that, in a modern desktop GUI environment, creating
directories and moving files should be "lightweight" tasks requiring no
more than a single touch-typeable keystroke or mouse gesture to accomplish.
The whole thing seems to be set up on the rather old-fashioned premise that
once a file is created in a given directory it's going to stay put for a
long time. Guess what? -- computers may like to work like that [and I
don't for a minute begrudge my machine its expectation that the contents of
/usr/bin will not be moving around arbirarily during my workday] -- but
PEOPLE don't; at least this person doesn't! Shuffling things around
between different folders -- on the computer desktop or on my physical
desktop -- is necessary for me to get things done -- or to at least make me
FEEL like I'm getting something done.)
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to my_sp...@mac.com is heavily filtered to remove
spam. If your message looks like spam I may not see it.
Roland Hutchinson
> <jmfb...@aol.com> wrote in message news:alvf6l$evp$3...@bob.news.rcn.net...
>> >DG's RDOS also had 8.3 filenames and in unix the concept doesn't even
>> >exist. Unix allows a dot in a filename but it has no meaning for the OS
>> >itself.
>>
>> That's another breakage in standard usage, IMO. The extension
>> had a definite mean, had standards established, and was a
>> remarkably useful way to organize and manage files.
>
> Actually, while it may not mean anything to the Unix *kernel*,
> the file extension does tend to mean things to compilers and
> the like.
True enough, but the true notion of "file type" in Unix -- to the extent
that there is one -- depends on smoke and mirrors^W^W^Wmagic numbers in
combination with arcane guesswork. (See "man file".)
Tim Shoppa
> 8.3 filenames were used by DEC operating systems. OS8, RT-11 and RSX spring
> to mind.
OS/8 is 6.2
RT-11 is 6.3
RSX-11 is 9.3
Don't get me wrong; the DEC OS conventions weighed heavily in CP/M's
design. But it was not, by any means, a verbatim "clone" of any one of them.
Tim.
jrla...@shell.golden.net
>RAD50 is more a coding (compression) technique. It translates values into a
>radix-50 system and the neat thing is that you can put 3 radix-50 symbols in
>a single byte.
I think you mean 'in a single word', i.e. 16 bits. Three RAD50 characters
won't pack into an 8-bit byte.
The 50 in RAD50 is actually octal which means you had the values from 0 to
47 (octal) or 0 to 39 (decimal). From the "RT-11 Mini-Reference Manual"
(March 1983), space = 0, 'A' = 1, 'B' = 2, ..., 'Z' = 32, '$' = 33, '.' =
34, 35 is unused, '0' = 36, '1' = 37, ..., '9' = 47
Given three characters, c1, c2 and c3, you'd encode them into RAD50 by
converting them to their numeric values then doing the calculation:
(c1*40 + c2)*40 + c3
So "AAA" would be 003151 (in octal).
--
john R. Latala
jrla...@golden.net
Steve O'Hara-Smith
Roland Hutchinson <my_sp...@mac.com> wrote:
RH> True enough, but the true notion of "file type" in Unix -- to the
RH> extent
Unix file types - hmm lessee - directory, device, pipe, socket,
symlink, regular file - the last may be executable and if so may be
in one of the supported binary formats. More than that and it's the
business of applications and nothing to do with the OS. This aspect
of unix I like.
--
C:>WIN | Directable Mirrors
The computer obeys and wins. |A Better Way To Focus The Sun
You lose and Bill collects. | licenses available - see:
| http://www.sohara.org/
Charles Richmond
you want... On the Mac, file names can contain most characters,
except the colon (:). MacOS uses the colon as a directory
separator in path names.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
jmfb...@aol.com
"Douglas H. Quebbeman" <dqueb...@ixnayamspayacm.org> wrote:
><jmfb...@aol.com> wrote in message news:alvf6l$evp$3...@bob.news.rcn.net...
>> >DG's RDOS also had 8.3 filenames and in unix the concept doesn't even
exist.
>> >Unix allows a dot in a filename but it has no meaning for the OS
itself.
>>
>> That's another breakage in standard usage, IMO. The extension
>> had a definite mean, had standards established, and was a
>> remarkably useful way to organize and manage files.
>
>Actually, while it may not mean anything to the Unix *kernel*,
>the file extension does tend to mean things to compilers and
>the like.
TOPS-10 knew about a few so that people didn't have to type
everything out. If I said R FOO, the latest assumption would
be to LOOKUP FOO.EXE. On the other hand, it did not insist
that all executables be that extension. If you really, really
thought you needed to RUN FOO.FOR, it would obey, LOOKUP the
file FOO.FOR, and allow the user job to execute it. It was
a wonderful first stab for a new processor test. Processors
should be able to handle crap without going completely berserk.
jmfb...@aol.com
Roland Hutchinson <my_sp...@mac.com> wrote:
>Douglas H. Quebbeman wrote:
>
>> <jmfb...@aol.com> wrote in message
news:alvf6l$evp$3...@bob.news.rcn.net...
>>> >DG's RDOS also had 8.3 filenames and in unix the concept doesn't even
>>> >exist. Unix allows a dot in a filename but it has no meaning for the
OS
>>> >itself.
>>>
>>> That's another breakage in standard usage, IMO. The extension
>>> had a definite mean, had standards established, and was a
>>> remarkably useful way to organize and manage files.
>>
>> Actually, while it may not mean anything to the Unix *kernel*,
>> the file extension does tend to mean things to compilers and
>> the like.
>
>True enough, but the true notion of "file type" in Unix -- to the extent
>that there is one -- depends on smoke and mirrors^W^W^Wmagic numbers in
>combination with arcane guesswork. (See "man file".)
>
a computer, you know.
jmfb...@aol.com
jcmo...@mitre.org (Joe Morris) wrote:
>jmfb...@aol.com writes:
>
>>Hit that man with a hundred wet noodles; he apparently doesn't know
>>his OS from a hole in the ground.
>
>I don't know if you thought that one up or got it from somewhere else;
>i've not seen it before. ROFLM(OS)O!
I was wondering if anybody would get it. :-)
I have no idea if it's mine or somebody else's. I did think that
I had just "thought it up" but who knows?
>
>Consider it stolen by me for use elsewhere. Thanks!
You're very welcome. Now all I have to do is hex that damned
web page. PDP-10 VMS indeed!
Brian {Hamilton Kelly}
> In article <Xns9289171BE9...@24.67.253.211>,
> Adam Fairbrother <quickn...@hotmail.com> wrote:
> > ..and a "RAD50".
>
> RAD50 was simply a "formatting" scheme and was used by the
> assemblers when they output *.REL files to save memory, disk
> space, etc. Now I bet you'll have to ask what a *.REL file is.
I'd hardly call it a "formatting scheme", unless you also view Base64 and
uuencoding as "formatting schemes".
No one seems to have told Adam much about what RAD50 does, so I'll make
an attempt (old DEC hands feel free to shoot me down): essentially,
it's a mechanism for compressing data (conventionally, the set of
character codes that are used for filenames, symbols in assembler code,
etc) into fewer bits than would be consumed in ASCII (or any of the 6- or
7-bit character set codes utilized by some DEC computer architectures).
There were a total of 40 different characters that could be represented;
these included the digits 0--9, the upper-case letters A--Z, the period,
the dollar, the underscore, and (IIRC) the hyphen (or was it the space?).
Each character was given its "RAD50 code" in the range 0--39. If Adam
tries the arithmetic, he'll find that three such codes can fit into a 16-
bit word (39*40^2+39*40+39 = 63999 < 65536). The name RAD50 was used,
despite the fact that the arithmetic was being performed in radix-40,
because 40 decimal is 50 octal; and in those days we ALL of us used to
"think" in octal, hexadecimal not yet having been invented :-)
I know that operating systems such as RSX-11M and RT-11 on the 16-bit DEC
architectures used to take advantage of RAD50 to pack the six letters of
an assembler or compiler identifier (aka "symbol") into two 16-bit words.
I also remember being gob-smacked by the elegance of the code for
performing this packing operation (since we had the advantage in those
days of the source assembler code of RSX-11M being delivered with the
computer, and hence could *read* programs and appreciate them); IIRC, the
operations of packing three characters into a word, or unpacking them,
was performed in about 20 bytes of machine-code.
However, I don't see that RAD50 would have any bearing upon an 8+3
filenaming system; even with the 36-bit DEC architectures, it takes more
than one word to be able to encode 8 characters into RAD50. Indeed, I
suspect that the 9+3 schemes of the PDP-11 operating systems, and the
early VMS on the 32-bit machines, arose from packing 9+3 characters into
four 16-bit (or two 32-bit) words. So where Larry got the idea of only
EIGHT characters before the dot eludes me (unless something in CP/M stole
the ninth character for some other purpose).
--
Brian {Hamilton Kelly} b...@dsl.co.uk
"We have gone from a world of concentrated knowledge and wisdom to one of
distributed ignorance. And we know and understand less while being incr-
easingly capable." Prof. Peter Cochrane, formerly of BT Labs
Brian {Hamilton Kelly}
hvl...@iae.nl "Hans Vlems" writes:
> RAD50 is more a coding (compression) technique. It translates values into a
> radix-50 system and the neat thing is that you can put 3 radix-50 symbols in
> a single byte.
Errm, that's radix FORTY <TeX>$40_10 = 50_8$</TeX>; and one can put three
radix-40 symbols into a *double* byte.
> 8.3 filenames were used by DEC operating systems. OS8, RT-11 and RSX spring
> to mind.
RT-11 and RSX (and, later, VMS) used NINE+three filenames. (VMS from
V4.0 onwards used 39+39.)
> IIRC OS8 (runs on the PDP-8 platform) dates from the mid 70's.
Mid-1960s, more like; I first remember playing with a PDP-8 down in the
cellar of Imperial College in the summer of 1966.
> DG's RDOS also had 8.3 filenames and in unix the concept doesn't even exist.
Didn't the DG Nova range (the only ones with which I've had a passing
acquaintance) also use a 9+3 scheme, not 8+3?
I do remember that RADOS on the Elliott 905 series used a 6+3 scheme,
using radix-64 characters with three in each of its 18-bit words.
Brian {Hamilton Kelly}
> The MacOS through HFS (hierarchical file system) allows one
> or more dots in a filename, but uses a separate mechanism
> to determine type of a file, as well as the application
> resposible for files of a given type. These are additional
> fields in the directory. And, while I have no idea whether
> you can refer to these fields in the underlying Unix shell
> found in OS X, in the GUI shell, you can issue a search for
> files of a specified type and creator.
OS/2 does (essentially) the same thing, but in an even more elegant
fashion, since the entire WPS (workplace shell) is object oriented, and
some of the properties of an object can associate it with one (or more)
relevant applications. It can even manage this with simple file systems
such as FAT-16, although it does it much more efficiently with HPFS or
JFS, since with those the EAs (extended attributes) don't need to be
placed in a special hidden file globally, but are within the individual
file itself (rather like HFS's "resource fork").
jmfb...@aol.com
I swear I've typed this in before but i sure can't find it.
This is the blurb DEC put in the 10's System Reference Card.
[Begin excerpt]
RADIX 50 REPRESENTATION
Radix 50 representation condenses 6-character symbols into
32 bits. The symbol characters are subscripted in the
following manner:
S_6S_5S_4S_3S_2S_1
Determine the octal code (O_n) for each character and use
the following formula to generate the 50_8 representation.
(((((O_6 * 50) + O_5) * 50 +O_4) * 50 + O_3) * 50 + O_2) * 50 + O_1
OCTAL CODES
_______________________________________________________
| Second Octal Digit |
| |
| 0 1 2 3 4 5 6 7 |
| __________________________________|
| 0 |null | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
| |---------------------------------|
| First 1 |7 | 8 | 9 | A | B | C | D | E |
| Octal |---------------------------------|
| Digit 2 |F | G | H | I | J | K | L | M |
| |---------------------------------|
| 3 |N | O | P | Q | R | S | T | U |
| |---------------------------------|
| 4 |V | W | X | Y | Z | . | $ | % |
|_____________________________________________________|
[End excerpt]
Ric Werme
> Hello, I was just wondering if anyone in here would know the
>history of the 8.3 file name convention in DOS. I was reading through
>some old messages in google groups, and found a partial answer, but it
>isn't something that I understand all that well. Something about a CP/M
>OS refrenced when making DOS as well as something to do with the PDP10(6
>bit chars), and RAD50(Octal packing).
When I first saw CP/M, I was struck by how much it looked like
TOPS-10, but heard later (I don't recall the quality of the source)
that it was patterned after RT-11, which was patterned after TOPS-10.
That seemed to make a lot more sense as both were aimed at small
systems. CP/M V1 even used ". " as the command prompt ala RT-11 and
TOPS-10.
As for the 8.3, look at the format of a CP/M directory entry. 16
bytes so they fill a disk block, not RAD50, 8 bytes for name, 3 for
extension, and I forget the rest, but it includes pointers to the
data. Your job as "punishment" for referring to VMS on the -10. Big
files linked to additional directory blocks to refer to the disk
clusters that made up the file.
... I'll agree fully
>that there was a significant influence from the DEC OS's, but you cannot
>tie it to any one because he did not copy any one of them in detail." --
>Tim Shoppa (sho...@trailing-edge.com). The same post states that he
>choose 8.3 just because.
Just because it fit well into the architecture at hand. Reverse engineering
the decision to use 8.3 is pointless unless you compare architectures,
design goals and costs along with looking at the OS family tree.
Of course, the trivial solution, "just ask Gary" is no longer available.
-Ric Werme
--
There are 10 kinds of people in the world:
Those who understand binary, and those who don't.
Ric Werme http://ewerme.home.attbi.com/ | ewe...@xxxxx.com
see also http://dcyf.home.attbi.com/ | Change xxxxx to attbi
Tim Shoppa
> When I first saw CP/M, I was struck by how much it looked like
> TOPS-10, but heard later (I don't recall the quality of the source)
> that it was patterned after RT-11, which was patterned after TOPS-10.
The RT-11 Historical Overview states:
The year 1971 was an exciting time...A popular operating system
for the PDP-8, called OS/8, was the design model for the new PDP-11
operating system, tentatively called OS-11...
...in the fall of 1972...the groundwork was laid to make OS-11
compatible with OS/8 and TOPS-10...
OS-11 was renamed first to RTPS-11 (Real-Time Programming System),
then to RT-11 (Real Time). Version 1 of RT-11 was completed in the
fall of 1973.
In my opinion, RT-11 V1 was more like OS/8 than TOPS-10. But the
supplied interchange utilities generally worked harder to allow
interchange with TOPS-10 systems; I believe the first build was
a cross-compile done from TOPS-10 but I do not have all those sources.
(OS/8 was also probably developed under TOPS-10).
Both OS/8 and TOPS-10 can be traced back to various PDP-6 monitors,
which can be traced back to PDP-1 monitors. IIRC PIP grew on the PDP-6.
That gives a family tree like:
/---> OS/8 -->-
PDP-1 ---> PDP-6 ---> TOPS-10 -/ \
monitor monitor \ \
\----------------+--> RT-11
And I would include both OS/8 and RT-11 in the CP/M ancestry, with no
special attention given to either as there were other obvious influences.
The most obvious of which was the Intel IOBYTE :-)
Tim.
Ric Werme
>Ric Werme <ewerme@attbi@nospam.com> wrote in message news:<E71h9.486704$UU1.77703@sccrnsc03>...
>> When I first saw CP/M, I was struck by how much it looked like
>> TOPS-10, but heard later (I don't recall the quality of the source)
>> that it was patterned after RT-11, which was patterned after TOPS-10.
>The RT-11 Historical Overview states:
Nore believeable stuff than some on this thread.
>In my opinion, RT-11 V1 was more like OS/8 than TOPS-10.
I should've included people in the list of things to keep in mind when
doing computer anthropology.
>(OS/8 was also probably developed under TOPS-10).
I didn't join DEC until 1974, after all that came into existance, but
hung around with some of the OS/8 and RT-11 principals. We still get
together at a monthly dinner, but under the guise of Alliant Computer
alumni.
Both -8 and -11 people used TOPS-10, so while I won't argue that the
direct link is TOPS-10 to OS/8 to RT11, the dotted links were pretty
substantial. I left the -8 out to keeping the focus a little tighter.
Also, I've never writtena PDP-8 program. (Gasp!) But I am sort
of familiar with its 8 instructions and some of the tricks with OPR.
>That gives a family tree like:
> /---> OS/8 -->-
> PDP-1 ---> PDP-6 ---> TOPS-10 -/ \
> monitor monitor \ \
> \----------------+--> RT-11
Yep. A little topiary there. :-)
>And I would include both OS/8 and RT-11 in the CP/M ancestry, with no
>special attention given to either as there were other obvious influences.
>The most obvious of which was the Intel IOBYTE :-)
-Ric
Hank Oredson
AFAIR I first ran across it just before CP/M appeared.
Another branch from RT-11?
--
... Hank
Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net
"Ric Werme" <ewerme@attbi@nospam.com> wrote in message
news:E71h9.486704$UU1.77703@sccrnsc03...
Brian Inglis
Shoppa) wrote:
>Ric Werme <ewerme@attbi@nospam.com> wrote in message news:<E71h9.486704$UU1.77703@sccrnsc03>...
>> When I first saw CP/M, I was struck by how much it looked like
>> TOPS-10, but heard later (I don't recall the quality of the source)
>> that it was patterned after RT-11, which was patterned after TOPS-10.
>And I would include both OS/8 and RT-11 in the CP/M ancestry, with no
>special attention given to either as there were other obvious influences.
>The most obvious of which was the Intel IOBYTE :-)
And also CP(/67?) and CMS from which batch submission, the
standard I/O devices: CON, RDR, PRT, PUN, drive letters, and
perhaps the virtual I/O interface (BDOS/BIOS) ideas may have
come.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
tos...@aol.com ab...@aol.com ab...@yahoo.com ab...@hotmail.com ab...@msn.com ab...@sprint.com ab...@earthlink.com ab...@cadvision.com ab...@ibsystems.com u...@ftc.gov
spam traps
Peter Ibbotson
> history of the 8.3 file name convention in DOS. I was reading through
> some old messages in google groups, and found a partial answer, but it
> isn't something that I understand all that well. Something about a CP/M
> OS refrenced when making DOS as well as something to do with the PDP10(6
> bit chars), and RAD50(Octal packing).
Hmm... We did this back in april most recently
See:
http://groups.google.com/groups?selm=3cb1a341.65680%40news.ocis.net
The summary is that no one knows for sure.
--
Work pet...@lakeview.co.uk.plugh.org | remove magic word .org to reply
Home pe...@ibbotson.co.uk.plugh.org | I own the domain but theres no MX
jmfb...@aol.com
It should also be noted that, in those days, developers were not
tied to just one system. They were assigned to develop an
OS as the project came up. So a guy who just implemented a whiz-bang
on the -10 would be assigned to the -8s current project. He
certainly wouldn't have started all over from scratch. The
guys also had a habit of liking certain tools, like TECO, DDT,
and PIP. In addition, a lot of the code was typed in by these
fingers when they were working in the group called Tape Preparation.
Most of our work was done on the -10 and then either dumped on
paper tape (for -8s) or FILEXed to a 11-formatted DECtape.
I think that the fact that one group did a lot of the grunt
work paved the way for a consistent style of naming conventions,
doc presentation conventions (oh, gawd, did we have the rules about
that), and stuff like that.
Also there weren't all that many machines available for programmers
to play with. All of you PC-affected people may make an erroneous
assumption that everybody had their own toy. Not true. Developers
would "steal" time from the machines Tape Prep had access to until
it was pointed out to them that they had a choice: use the machine
or get their data request fulfilled.
jmfb...@aol.com
Ric Werme <ewerme@attbi@nospam.com> wrote:
>sho...@trailing-edge.com (Tim Shoppa) writes:
>
>>Ric Werme <ewerme@attbi@nospam.com> wrote in message
news:<E71h9.486704$UU1.77703@sccrnsc03>...
>>> When I first saw CP/M, I was struck by how much it looked like
>>> TOPS-10, but heard later (I don't recall the quality of the source)
>>> that it was patterned after RT-11, which was patterned after TOPS-10.
>
>>The RT-11 Historical Overview states:
>
>Nore believeable stuff than some on this thread.
>
>>In my opinion, RT-11 V1 was more like OS/8 than TOPS-10.
>
>I should've included people in the list of things to keep in mind when
>doing computer anthropology.
>
>>(OS/8 was also probably developed under TOPS-10).
>
>I didn't join DEC until 1974, after all that came into existance, but
>hung around with some of the OS/8 and RT-11 principals. We still get
>together at a monthly dinner, but under the guise of Alliant Computer
>alumni.
>
>Both -8 and -11 people used TOPS-10,
No. Some of the -8 people WERE -10 people.
<snip>
Chris Hedley
> 2) First versions of VMS used 9.3, just like RSX-11 and its filesystem
> ODS-1.
Didn't VMS also originally use ODS-1, at least until the more familiar
ODS-2 arrived on the scene, or was ODS-2 there from the start?
> 3) VMS doesn't run on a PDP-10.
And I hope Barb hasn't seen that. :)
Chris.
--
"If the world was an orange it would be like much too small, y'know?" Neil, '84
Chris Hedley -- cbh(at)ieya(dot)co(dot)uk
http://cbh.paunix.org My stuff, including genealogy, other things, etc
jmfb...@aol.com
c...@ieya.co.REMOVE_THIS.uk (Chris Hedley) wrote:
>According to Tim Shoppa <tsh...@wmata.com>:
>> 2) First versions of VMS used 9.3, just like RSX-11 and its filesystem
>> ODS-1.
>
>Didn't VMS also originally use ODS-1, at least until the more familiar
>ODS-2 arrived on the scene, or was ODS-2 there from the start?
>
>> 3) VMS doesn't run on a PDP-10.
>
>And I hope Barb hasn't seen that. :)
<grin> I didn't get upset at all.
Tim Shoppa
> According to Tim Shoppa <tsh...@wmata.com>:
> > 2) First versions of VMS used 9.3, just like RSX-11 and its filesystem
> > ODS-1.
>
> Didn't VMS also originally use ODS-1, at least until the more familiar
> ODS-2 arrived on the scene, or was ODS-2 there from the start?
Yes, it was ODS-1. (Although there was some slight divergence between
ODS-1 in VMS and ODS-1 in RSX and ODS-1 in IAS.)
The old ODS-1 9.3 limits still show in some fundamental VMS filenames, even
though those limits have been irrelevant for decades. For example,
the install procedure is still VMSINSTAL.COM and accounting info is maintained
in ACCOUNTNG.DAT. I guess it's tough to change the names of such
fundamental resources when they're referenced in so many places in
hard and softcopy, and even etched into many system manager's spinal
cords :-)
(For most recent software, they've moved away from VMSINSTAL.COM and into
a PCSI-based installation method, but I think VMSINSTAL is still there.)
Tim.
Anne & Lynn Wheeler
> And also CP(/67?) and CMS from which batch submission, the
> standard I/O devices: CON, RDR, PRT, PUN, drive letters, and
> perhaps the virtual I/O interface (BDOS/BIOS) ideas may have
> come.
an old CMS "EXEC" from cp/67 (aka '60s). cms used blank deliminators with
8+8+2 (where the +2 could default) for file identifiers.
In cms, "wait" was an internal kernel routine that assumed it was
called by program with all hex zeros as deliminating the parameter
list. It was possible to call it from exec processor by careful
editing and inserting hex zeros. The following file had a name of
"waitload exec". The command line processor actually fed into the same
command resolution as internal kernel calls or other command calls
(aka in cms it was actually possible to create files with name of
internal kernel routines and have the alias executed in place of the
real kernel routine). This capability was somewhat inhibited in the
time-frame of CMS for VM/370 (aka early '70s) where a new "fast"
kernel call procedure was implemented (it was expensive to force every
routine linkage thru the same lookup interface as was used for commad
entry from a terminal). It was still possible to do the hack to access
internal routines from command line ... but internal code linkages
started using a fast lookup bypass.
waitload exec:
&CONTROL OFF
CP SP C CL Y
-READ DISK LOAD
&IF &RETCODE EQ 0 &SKIP 1
WAIT RDR1RDR1 .
Hans Vlems
Hans Vlems
<jmfb...@aol.com> schreef in bericht news:alvf6l$evp$3...@bob.news.rcn.net...
[snip]
> >VMS are products of Digital Equipment Corp.
> >To return to the 8.3 question, (AFAIK) VMS had 9.3 in
> >the beginning
>
> Was it 9? I don't seem to be able to remember what 11M could do.
Well actually that's what it was in 3.0. Now RSX-11M was also 9.3 so I
guessed that 9.3 must have been there from the beginning. With compatibility
in mind it really doesn't make sense to create problems with filenames,
right?
> > ...and it
> >was later modified to 39.39.
>
> After TOPS-20.
>
Yes
>
> >RAD50 is more a coding (compression) technique.
> >It translates values into a
> >radix-50 system and the neat thing is that you can put
> >3 radix-50 symbols in a single byte.
>
> You should probably define byte here.
??
> >8.3 filenames were used by DEC operating systems.
> >OS8, RT-11 and RSX spring to mind.
That was a mistake since RSX obviously used 9.3, and version numbers.
Perhaps the OS's that did not have version numbers also used 8.3 ?
> I don't remember them being 8.3. On the other hand, all
> the work I did for -11 and -8 groups was prepared on a
> PDP-10, so that might explain why I never saw 8 characters.
>
>
> > ..IIRC OS8 (runs on the PDP-8 platform)
>
> Yup.
>
> > ... dates from the mid 70's.
>
> Nope. Earlier. I don't have dates, though. One of the guys who
> worked on 0S8 was doing it around when I started working at DEC
> and that was 1971.
>
>
That's right, the -8 is somewhat older than my memory led me to believe....
> >DG's RDOS also had 8.3 filenames and in unix the
> >concept doesn't even exist.
> >Unix allows a dot in a filename but it has no meaning for the OS itself.
>
> That's another breakage in standard usage, IMO. The extension
> had a definite mean, had standards established, and was a
> remarkably useful way to organize and manage files.
>
The MCP (Burroughs large systems) did not use filetypes either; at least not
in their name. The filetype was part of the filespecification as maintained
by the IO subsystem. The file had an attribute that clearly identified its
use: ALGOL, ALGOLCODE etc.
Unix probably used a similar approach. The compilers do use a period, but
test.c, test.h,
test and test.cpp may all wiped out with a single rm -f * command...
Hans
Hans Vlems
<jrla...@shell.golden.net> schreef in bericht
news:am0kd8$sce$1...@shell.golden.net...
not even see it in a reply to Barb. Sorry.
Hans
Brian {Hamilton Kelly}
sho...@trailing-edge.com "Tim Shoppa" writes:
> (For most recent software, they've moved away from VMSINSTAL.COM and into
> a PCSI-based installation method, but I think VMSINSTAL is still there.)
Shame! I was absolutely gob-smacked when I first read through the code
of VMSINSTAL.COM, and realized that recursion was being done in an
interpreted scripting language. Soon afterwards, I acquired a copy[1] of
a book entitled something like "Writing REAL programs in DCL", by an
author with (IIRC) a Greek name.
Armed with this new-found knowledge, I implemented a LISTSERV-like suite
in DCL which handled mails in both RFC-822 *and* [Janet] Grey-Book Mail
formats. It parsed the various header fields using the entities defined
in the RFCs/CBS specifications, through recursive calls of the procedure.
Worked a treat, and handled serving many megabytes a day by e-mail from
the UK TeX Archive (when it was at Aston University).
[1] Sadly, I seem to have lost the book; even sadder, I no longer have
access to a VAX.
Chris Hedley
> Yes, it was ODS-1. (Although there was some slight divergence between
> ODS-1 in VMS and ODS-1 in RSX and ODS-1 in IAS.)
Coming from a mainly UNIX background, such divergence seems to be
the One True Way. :) And thanks for clearing up the "early VMS
filesystem" thing.
> The old ODS-1 9.3 limits still show in some fundamental VMS filenames, even
> though those limits have been irrelevant for decades. For example,
> the install procedure is still VMSINSTAL.COM
Ah, I'd always wondered about that one, pretty much every time I
ran it in fact. I'd previously assumed it was just one of those
random oddities like UNIX' e-less "creat" but now it makes sense!
Charles Richmond
>
> "Adam Fairbrother" <quickn...@hotmail.com> wrote in message
> news:Xns9289171BE9...@24.67.253.211...
> > Hello, I was just wondering if anyone in here would know the
> > history of the 8.3 file name convention in DOS. I was reading through
> > some old messages in google groups, and found a partial answer, but it
> > isn't something that I understand all that well. Something about a CP/M
> > OS refrenced when making DOS as well as something to do with the PDP10(6
> > bit chars), and RAD50(Octal packing).
>
> Hmm... We did this back in april most recently
>
> See:
> http://groups.google.com/groups?selm=3cb1a341.65680%40news.ocis.net
> The summary is that no one knows for sure.
>
the poster to "read the FAQ" (RTFM), but I do *not* think
that <a.f.c.> really has a FAQ as such...
Adam Fairbrother
news:3D8658B0...@ev1.net:
> Peter Ibbotson wrote:
>>
>> "Adam Fairbrother" <quickn...@hotmail.com> wrote in message
>> news:Xns9289171BE9...@24.67.253.211...
>> > Hello, I was just wondering if anyone in here would know the
>> > history of the 8.3 file name convention in DOS. I was reading
>> > through some old messages in google groups, and found a partial
>> > answer, but it isn't something that I understand all that well.
>> > Something about a CP/M OS refrenced when making DOS as well as
>> > something to do with the PDP10(6 bit chars), and RAD50(Octal
>> > packing).
>>
>> Hmm... We did this back in april most recently
>>
>> See:
>> http://groups.google.com/groups?selm=3cb1a341.65680%40news.ocis.net
>> The summary is that no one knows for sure.
>>
> Perhaps it is just a recurring troll... I guess we could ask
> the poster to "read the FAQ" (RTFM), but I do *not* think
> that <a.f.c.> really has a FAQ as such...
>
Well I'd like to think i'm not a troll, (especially since that was
my first post in this group), but I did go and take a look back at that
google groups link and Gene was/still is in the same course as myself,
just in an earlier intake. I wouldn't have posted the question had I
found that first, but the oly 8.3 related info that I had previously
found on Google groups was something from "sonya blade", again asking
the same question in comp.os.cpm and i just thought that the good people
in folkelore would have an answer, as the co.cpm people were rather
ambiguous with their replies. I'm sorry If I've offended anyone. And to
everyone that contribted a reply thank you very much.
-Adam
Charles Richmond
>
> Charles Richmond <rich...@ev1.net> wrote in
> news:3D8658B0...@ev1.net:
> >
> > Perhaps it is just a recurring troll... I guess we could ask
> > the poster to "read the FAQ" (RTFM), but I do *not* think
> > that <a.f.c.> really has a FAQ as such...
> >
>
> Well I'd like to think i'm not a troll, (especially since that was
> my first post in this group), but I did go and take a look back at that
> google groups link and Gene was/still is in the same course as myself,
> just in an earlier intake. I wouldn't have posted the question had I
> found that first, but the oly 8.3 related info that I had previously
> found on Google groups was something from "sonya blade", again asking
> the same question in comp.os.cpm and i just thought that the good people
> in folkelore would have an answer, as the co.cpm people were rather
> ambiguous with their replies. I'm sorry If I've offended anyone. And to
> everyone that contribted a reply thank you very much.
>
questions. I have read all the replies on the 8.3 file names, and
I still do *not* have a good answer for it. And in fact, it is
nice to see an "on-topic" post occasionally in <a.f.c.>... ;-)
Charles Richmond
>
> "Adam Fairbrother" <quickn...@hotmail.com> wrote in message
> news:Xns9289171BE9...@24.67.253.211...
> > Hello, I was just wondering if anyone in here would know the
> > history of the 8.3 file name convention in DOS. I was reading through
> > some old messages in google groups, and found a partial answer, but it
> > isn't something that I understand all that well. Something about a CP/M
> > OS refrenced when making DOS as well as something to do with the PDP10(6
> > bit chars), and RAD50(Octal packing).
>
> Hmm... We did this back in april most recently
>
> See:
> http://groups.google.com/groups?selm=3cb1a341.65680%40news.ocis.net
> The summary is that no one knows for sure.
>
the poster to "read the FAQ" (RTFM), but I do *not* think
that <a.f.c.> really has a FAQ as such...
--
Peter Ibbotson
>
> Well I'd like to think i'm not a troll, (especially since that was
> my first post in this group), but I did go and take a look back at that
> google groups link and Gene was/still is in the same course as myself,
> just in an earlier intake. I wouldn't have posted the question had I
> found that first, but the oly 8.3 related info that I had previously
> found on Google groups was something from "sonya blade", again asking
> the same question in comp.os.cpm and i just thought that the good people
> in folkelore would have an answer, as the co.cpm people were rather
> ambiguous with their replies. I'm sorry If I've offended anyone. And to
> everyone that contribted a reply thank you very much.
>
Sorry adam I wasn't accusing you of being a troll, however I was pointing
out that last time we did this wasn't all that long ago. (Funnily enough
googling for 8.3 doesn't give good answers)
You are asking in the right place. There is a FAQ for this group at
http://wilson.best.vwh.net/faq/ but its not been updated for ages.
jmfb...@aol.com
"Hans Vlems" <hvl...@iae.nl> wrote:
>
><jmfb...@aol.com> schreef in bericht
news:alvf6l$evp$3...@bob.news.rcn.net...
>[snip]
>> >VMS are products of Digital Equipment Corp.
>> >To return to the 8.3 question, (AFAIK) VMS had 9.3 in
>> >the beginning
>>
>> Was it 9? I don't seem to be able to remember what 11M could do.
>
>Well actually that's what it was in 3.0. Now RSX-11M was also 9.3 so I
>guessed that 9.3 must have been there from the beginning. With
compatibility
>in mind it really doesn't make sense to create problems with filenames,
>right?
>
>> > ...and it
>> >was later modified to 39.39.
>>
>> After TOPS-20.
>>
>Yes
>>
>> >RAD50 is more a coding (compression) technique.
>> >It translates values into a
>> >radix-50 system and the neat thing is that you can put
>> >3 radix-50 symbols in a single byte.
>>
>> You should probably define byte here.
>
>??
<grin> Byte sizes were left as an exercise for the programmer.
You really meant word. I think you caught the slip of the
bit.
>
>> >8.3 filenames were used by DEC operating systems.
>> >OS8, RT-11 and RSX spring to mind.
>
>That was a mistake since RSX obviously used 9.3, and version numbers.
>Perhaps the OS's that did not have version numbers also used 8.3 ?
This is a real sore point to me. Whatever idiot called those
file revision numbers "versions" should be shot. Version had
a definite definition within DEC and had to do with communicating
edit levels of software. We had strict rules about when and what
versions fields should be increased.
I don't remember 11M having revision capabilities until after
TENEX came around. Note that TENEX was in residience before
the PHBs decided it was TOPS-20.
<snip>
Brian {Hamilton Kelly}
hvl...@iae.nl "Hans Vlems" writes:
> <jmfb...@aol.com> schreef in bericht news:alvf6l$evp$3...@bob.news.rcn.net...
> >
> > You should probably define byte here.
>
> ??
What part of "define byte here" do you not understand? There is nothing
magical about a byte containing eight bits of data; I've known of
machines with 6, 7, 8 OR 9-bit bytes at different times over the past 40
years. Why do you suppose that all the Internet Standards (as
promulgated in RFCs) refer to "octets"? [Hint: it's not done to keep the
Frogs happy.]
And as has also been said elsewhere in this thread, by myself and others,
RAD50 squeezes three characters into SIXTEEN bits, not eight.
Hans Vlems
"Brian {Hamilton Kelly}" <b...@dsl.co.uk> schreef in bericht
news:103221...@dsl.co.uk...
> In article <am5fm7$2rntn$1...@ID-143435.news.dfncis.de>
> hvl...@iae.nl "Hans Vlems" writes:
>
> > <jmfb...@aol.com> schreef in bericht
news:alvf6l$evp$3...@bob.news.rcn.net...
> > >
> > > You should probably define byte here.
> >
> > ??
>
> What part of "define byte here" do you not understand? There is nothing
> magical about a byte containing eight bits of data; I've known of
> machines with 6, 7, 8 OR 9-bit bytes at different times over the past 40
> years. Why do you suppose that all the Internet Standards (as
> promulgated in RFCs) refer to "octets"? [Hint: it's not done to keep the
> Frogs happy.]
>
> And as has also been said elsewhere in this thread, by myself and others,
> RAD50 squeezes three characters into SIXTEEN bits, not eight.
>
immediately register.
Hans Vlems
> >> >It translates values into a
> >> >radix-50 system and the neat thing is that you can put
> >> >3 radix-50 symbols in a single byte.
> >>
> >> You should probably define byte here.
> >
> >??
>
> <grin> Byte sizes were left as an exercise for the programmer.
> You really meant word. I think you caught the slip of the
> bit.
It did, eventually....
As somebody else pointed out, the definition of the word byte depends on
machine context. On the PDP-11 a byte contained 8 bits, a word 16 bits. OTOH
a B6700 had 48 bit words.
> >
> >> >8.3 filenames were used by DEC operating systems.
> >> >OS8, RT-11 and RSX spring to mind.
> >
> >That was a mistake since RSX obviously used 9.3, and version numbers.
> >Perhaps the OS's that did not have version numbers also used 8.3 ?
>
> This is a real sore point to me. Whatever idiot called those
> file revision numbers "versions" should be shot. Version had
> a definite definition within DEC and had to do with communicating
> edit levels of software. We had strict rules about when and what
> versions fields should be increased.
IIRC the early VMS documentation actually used the term "file revision
numbers ".
Adam Fairbrother
based on what information all of you have supplied, i'd like to bounce a
therory around on this whole 8.3 thing, and see if you guys can tear it
up too shreds or if it actually holds. Even though i'm sure it's full
of holes mabey we'll be able to come up with a concrete answer, and you
won't have to go through all of this again the next time some one pokes
their head in here and just reference them to this thread on google.
My theroy is this:
In systems that used 6.3, which i'm assuming was the file naming
convention to pre-date 8.3, RAD50 was used to pack the name into 2 16-
bit words, but where in there dose it identify the diffrence between
filename and extention. unless i'm completely off my rockers, which i'm
starting to think I am (i'm not sure that i understand this whole rad50
thing... but), there must be something in memory that points to the
extention as being a seperate entity from the file name. I'm thinking
this because I don't belive that the peroid was used in the rad50
encoding, hence encoding only 9 characters 6+3 I'm probally wrong, but
thats what i'm going on. Using 8.3 if peroid was included in the
encoding that would make 12 characters to be encoded (somehow i got it
stuck in my mind that groupings of three are important). so if I'm
right (probally not) then that leaves 12 characters and no need to point
to the extention with a seperate word. Hence the same amount of memory
used, but with more description.
now like I said, I'm mostly likely completely off the wall with
this one and most likely deserve to be shot, but I got this crazy idea
while at work today and need to have it shot down (the prof won't do it
for about 4 months) before I can really continue with my life as a
"normal" person.
Thanks in advance
-Adam Fairbrother
Adam Fairbrother
what STIFF is? I belive that my teacher mentioned that it was important
Thanks in advance
-Adam
Bill Marcum
Adam Fairbrother <quickn...@hotmail.com> wrote:
> My theroy is this:
>
> In systems that used 6.3, which i'm assuming was the file naming
> convention to pre-date 8.3, RAD50 was used to pack the name into 2 16-
> bit words, but where in there dose it identify the diffrence between
> filename and extention. unless i'm completely off my rockers, which i'm
> starting to think I am (i'm not sure that i understand this whole rad50
> thing... but), there must be something in memory that points to the
> extention as being a seperate entity from the file name. I'm thinking
> this because I don't belive that the peroid was used in the rad50
> encoding, hence encoding only 9 characters 6+3 I'm probally wrong, but
> thats what i'm going on. Using 8.3 if peroid was included in the
> encoding that would make 12 characters to be encoded (somehow i got it
> stuck in my mind that groupings of three are important). so if I'm
> right (probally not) then that leaves 12 characters and no need to point
> to the extention with a seperate word. Hence the same amount of memory
> used, but with more description.
In the internal representation of a 6.3 or 8.3 filename, the period doesn't
have to be stored. The filename is stored as a fixed length string with
the extension in the last three positions, for example the name "FOO.BAR"
would be stored as "FOO BAR" .
jmfb...@aol.com
"Hans Vlems" <hvl...@iae.nl> wrote:
>> >> >RAD50 is more a coding (compression) technique.
>> >> >It translates values into a
>> >> >radix-50 system and the neat thing is that you can put
>> >> >3 radix-50 symbols in a single byte.
>> >>
>> >> You should probably define byte here.
>> >
>> >??
>>
>> <grin> Byte sizes were left as an exercise for the programmer.
>> You really meant word. I think you caught the slip of the
>> bit.
>
>It did, eventually....
>As somebody else pointed out, the definition of the word byte depends on
>machine context. On the PDP-11 a byte contained 8 bits, a word 16 bits.
Nope. A byte size was defined by the programmer (usually the largest
was the word size of the machine). On the PDP-10, I could define
bytes to be 1-36 bits just by setting up my byte pointer appropriately.
There were five instructions available:
1. use present pointer and load byte into AC (LDB)
2. use present pointer deposit byte from AC in memory (DPB)
3. increment byte pointer and load byte into AC (ILDB)
4. increment byte pointer and deposit byte in memory (IDPB)
5. increment byte pointer (IBP)
> ..OTOH
>a B6700 had 48 bit words.
>
>> >
>> >> >8.3 filenames were used by DEC operating systems.
>> >> >OS8, RT-11 and RSX spring to mind.
>> >
>> >That was a mistake since RSX obviously used 9.3, and version numbers.
>> >Perhaps the OS's that did not have version numbers also used 8.3 ?
>>
>> This is a real sore point to me. Whatever idiot called those
>> file revision numbers "versions" should be shot. Version had
>> a definite definition within DEC and had to do with communicating
>> edit levels of software. We had strict rules about when and what
>> versions fields should be increased.
>
>IIRC the early VMS documentation actually used the term "file revision
>numbers ".
Right. Somebody "fixed" that. I don't who.
jmfb...@aol.com
Adam Fairbrother <quickn...@hotmail.com> wrote:
<snip>
>My theroy is this:
>
> In systems that used 6.3, which i'm assuming was the file naming
>convention to pre-date 8.3, RAD50 was used to pack the name into 2 16-
>bit words,
<snip>
You're making the mistake that the one had anything to do with
the other. It didn't. RADIX50 was used to make symbol tables;
do not confuse symbols with filenames.
This is another case where people are confusing data and code
and their organization mechanisms.
Eric Sosman
>
> In article <Xns928D640D1...@24.67.253.211>,
> Adam Fairbrother <quickn...@hotmail.com> wrote:
> <snip>
>
> >My theroy is this:
> >
> > In systems that used 6.3, which i'm assuming was the file naming
> >convention to pre-date 8.3, RAD50 was used to pack the name into 2 16-
> >bit words,
>
> <snip>
>
> You're making the mistake that the one had anything to do with
> the other. It didn't. RADIX50 was used to make symbol tables;
> do not confuse symbols with filenames.
Symbols are not file names, granted. But file names and
pieces thereof *were* stored on disk in RAD50 encoding in at
least some DEC operating systems. PDP-11 DOS, for sure, and
I seem to recall this was also the case for RSX-11.
I used to speculate about whether RAD50 encoding of file
name components produced a net decrease or a net increase in
disk space usage. Sure, the encoding saved a few bytes per
file name. But at the same time, it required practically
every program to include encoding and/or decoding routines
amounting to perhaps a hundred bytes. Even on systems where
programs were able to share a single copy of the hundred
bytes, each program needed extra code to call those routines,
separate buffers for the internal and external representations,
and so on. Personally, I felt this use of RAD50 was probably
ill-advised -- but ill-advised or not, it was used thus.
Brian {Hamilton Kelly}
quickn...@hotmail.com "Adam Fairbrother" writes:
> Well thank you all for your support in this little bit of knowlage, and
> based on what information all of you have supplied, i'd like to bounce a
> therory around on this whole 8.3 thing, and see if you guys can tear it
> up too shreds or if it actually holds. Even though i'm sure it's full
> of holes mabey we'll be able to come up with a concrete answer, and you
> won't have to go through all of this again the next time some one pokes
> their head in here and just reference them to this thread on google.
>
> My theroy is this:
>
> In systems that used 6.3, which i'm assuming was the file naming
> convention to pre-date 8.3, RAD50 was used to pack the name into 2 16-
^
3
> bit words, but where in there dose it identify the diffrence between
> filename and extention. unless i'm completely off my rockers, which i'm
> starting to think I am (i'm not sure that i understand this whole rad50
> thing... but), there must be something in memory that points to the
> extention as being a seperate entity from the file name. I'm thinking
> this because I don't belive that the peroid was used in the rad50
> encoding, hence encoding only 9 characters 6+3 I'm probally wrong, but
Correct; using RAD50, the six letters in the "name" part could be
compressed into two 16-bit words, and the three in the "extension" into a
further 16-bit word. No need to use the period to delimit one from the
other /internally/; programs could use the three words as an entity to
reference the entire name, whilst those that needed to know the extension
could look at the single word at offset word+2.
Ditto for 9+3 names; these went happily into four 16-bit words (eight
8-bit bytes).
> thats what i'm going on. Using 8.3 if peroid was included in the
> encoding that would make 12 characters to be encoded (somehow i got it
> stuck in my mind that groupings of three are important). so if I'm
> right (probally not) then that leaves 12 characters and no need to point
> to the extention with a seperate word. Hence the same amount of memory
> used, but with more description.
Actually it uses more memory. The salient point is that by now it was
"cheaper" to use more memory (or disk space) than it was to perform the
conversions from/to RAD50. Permitting each character of a filename to be
represented internally as a single "byte" also allowed more "esoteric"
characters to be permitted within a filename. So an 8+3 filename,
including the period, could appear internally in a 12-byte structure.
(Actually, I think you'll find, if you look at a FAT-16 directory with a
disk utility, that the period is not actually encoded as a period, but
rather as a space (or perhaps it's a NUL \0 --- it's a long time since
I've done that, and I can't look now, because I only have HPFS and JFS
partitions on this system). All the same, the "filename" occupies twelve
bytes of a directory structure, and this makes more sense than having it
occupying 13, since that might lead to all sorts of problems when other
parts of the structure need to repesent 16- or 32-bit integers, and thus
need to be aligned appropriately.)
> now like I said, I'm mostly likely completely off the wall with
> this one and most likely deserve to be shot, but I got this crazy idea
> while at work today and need to have it shot down (the prof won't do it
> for about 4 months) before I can really continue with my life as a
> "normal" person.
I think you've probably found a reasonable explanation; eight character
"name", followed by a "filler byte" followed by a fixed three character
extension. All in a twelve byte field. The only question remaining to
be answered is WHY did Gary not just have a fixed nine character "name"
part and imply the "filler"?
Stan Barr
<b...@dsl.co.uk> wrote:
>
>(Actually, I think you'll find, if you look at a FAT-16 directory with a
>disk utility, that the period is not actually encoded as a period, but
>rather as a space (or perhaps it's a NUL \0 --- it's a long time since
>I've done that, and I can't look now, because I only have HPFS and JFS
>partitions on this system). All the same, the "filename" occupies twelve
>bytes of a directory structure,
ISTR from when I was writing file handling in Forth that a DOS filename
was stored as 8 ascii chars padded with spaces and the extension as 3
ascii chars (with the period _not_ stored), followed by 1 attribute byte.
Making a total of 12 bytes...
--
Cheers,
Stan Barr st...@dial.pipex.com
The future was never like this!
Goran Larsson
Brian {Hamilton Kelly} <b...@dsl.co.uk> wrote:
> I think you've probably found a reasonable explanation; eight character
> "name", followed by a "filler byte" followed by a fixed three character
> extension. All in a twelve byte field. The only question remaining to
> be answered is WHY did Gary not just have a fixed nine character "name"
> part and imply the "filler"?
This is not a description of the CP/M directory format. The CP/M 2.2
directory entry is 32 bytes and starts with this:
UN F1 F2 F3 F4 F5 F6 F7 F8 T1 T2 T3
where UN is a user number 0 to 15 (or 31) or 0xE5 if the file is
erased, Fn is the 8 character filename, and Tn is the three character
file type. The remaining bytes are used to keep track of the file data.
CP/M 2.2 disk format: < http://www.seasip.demon.co.uk/Cpm/format22.html >
CP/M 3.1 disk format: < http://www.seasip.demon.co.uk/Cpm/format31.html >
CP/M File Control Block: < http://www.seasip.demon.co.uk/Cpm/fcb.html >
--
Göran Larsson http://www.mitt-eget.com
Steve O'Hara-Smith
B> I think you've probably found a reasonable explanation; eight character
Unfortunately it is wrong - (and something *is* the way I
recall it).
B> "name", followed by a "filler byte" followed by a fixed three character
B> extension. All in a twelve byte field. The only question remaining to
Make that an 11 byte field - the following is taken from
http://www.seasip.demon.co.uk/Cpm/fcb.html.
CP/M File Control Block
The File Control Block is a 36-byte data structure (33 bytes in CP/M 1).
It is laid out as follows:
DR F1 F2 F3 F4 F5 F6 F7 F8 T1 T2 T3 EX S1 S2 RC .FILENAMETYP...
AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL ...............
CR R0 R1 R2 ....
The bytes in it have the following meanings:
FCB+00h DR - Drive. 0 for default, 1-16 for A-P. In DOSPLUS,
bit 7 can be set to indicate that the operation should work
with
subdirectories rather than files.
FCB+01h Fn - Filename, 7-bit ASCII. The top bits of the filename bytes
(usually referred to as F1' to F8') have the following
meanings:
F1'-F4' - User-defined attributes. Any program can use
them in any way it likes. The filename in the
disc directory has the corresponding bits set.
F5'-F8' - Interface attributes. They modify the
behaviour of various BDOS functions or
indicate error conditions. In the directory
these bits are always zero.
FCB+09h Tn - Filetype, 7-bit ASCII. T1' to T3' have the following
meanings:
T1' - Read-Only.
T2' - System (hidden). System files in user 0 can be
opened from other user areas.
T3' - Archive. Set if the file has not been changed
since it was last copied.
B> be answered is WHY did Gary not just have a fixed nine character "name"
B> part and imply the "filler"?
Because it was eight with an implied filler and even the spare bits
got used (the directory entry and FCB layouts match).
--
C:>WIN | Directable Mirrors
The computer obeys and wins. |A Better Way To Focus The Sun
You lose and Bill collects. | licenses available - see:
| http://www.sohara.org/
Brian {Hamilton Kelly}
> I used to speculate about whether RAD50 encoding of file
> name components produced a net decrease or a net increase in
> disk space usage. Sure, the encoding saved a few bytes per
> file name. But at the same time, it required practically
> every program to include encoding and/or decoding routines
> amounting to perhaps a hundred bytes. Even on systems where
> programs were able to share a single copy of the hundred
> bytes, each program needed extra code to call those routines,
> separate buffers for the internal and external representations,
> and so on. Personally, I felt this use of RAD50 was probably
> ill-advised -- but ill-advised or not, it was used thus.
No: as I've already remarked elsewhere in this thread, the routines for
packing and unpacking RAD50 were some of the most elegant and compact
machine-code I've ever had the privilege of reading (on RSX-11M at
least). Far from being "a hundred bytes", they were more like about
twenty apiece.
Anyone got access to RSX-11M source code, and able to post these
subroutines?
jmfb...@aol.com
Eric Sosman <Eric....@sun.com> wrote:
>jmfb...@aol.com wrote:
>>
>> In article <Xns928D640D1...@24.67.253.211>,
>> Adam Fairbrother <quickn...@hotmail.com> wrote:
>> <snip>
>>
>> >My theroy is this:
>> >
>> > In systems that used 6.3, which i'm assuming was the file naming
>> >convention to pre-date 8.3, RAD50 was used to pack the name into 2 16-
>> >bit words,
>>
>> <snip>
>>
>> You're making the mistake that the one had anything to do with
>> the other. It didn't. RADIX50 was used to make symbol tables;
>> do not confuse symbols with filenames.
>
> Symbols are not file names, granted. But file names and
>pieces thereof *were* stored on disk in RAD50 encoding in at
>least some DEC operating systems. PDP-11 DOS, for sure, and
>I seem to recall this was also the case for RSX-11.
>
> I used to speculate about whether RAD50 encoding of file
>name components produced a net decrease or a net increase in
>disk space usage.
Oh, I'd say a net increase. For some reason, PDP-11s were
just littered with itty bitty files. I never quite
understood why; perhaps, it was just the nature of the beast.
If a site wanted big files it bought a big machine.
> ..Sure, the encoding saved a few bytes per
>file name. But at the same time, it required practically
>every program to include encoding and/or decoding routines
>amounting to perhaps a hundred bytes.
Yup. And that is a pain in the patootie.
> .. Even on systems where
>programs were able to share a single copy of the hundred
>bytes, each program needed extra code to call those routines,
>separate buffers for the internal and external representations,
>and so on.
You have to realize that those -11 operating systems were not
designed for "timesharing". They were designed with single
usage in mind.
> .. Personally, I felt this use of RAD50 was probably
>ill-advised -- but ill-advised or not, it was used thus.
Never underestimate a bitty bytey programming style. In
the bad ol' days, it was useful but completely unmaintainable.
As hardware constraints eased up, maintenance became the
commodity causing the bitty code to get rewritten (or at least
symobolized).
Eric Sosman
>
> You have to realize that those -11 operating systems were not
> designed for "timesharing". They were designed with single
> usage in mind.
Most of my exposure was to a non-DEC O/S: it booted up as
PDP-11 DOS and then replaced the entire system image with
customized stuff. But it made an effort to keep the on-disk
structure at least partially DOS-compatible, so RAD50 was used
in a lot of places.
This system was something of a hot-rod. The PDP-11 itself
was heavily modified, with custom memory management and more
RAM than DEC would ever put on that model (ISTR the chip set
started out as an 11/34). There was a machine-to-machine
optically-isolated bus allowing a sort of clustering to permit
continued operation even if a CPU or disk should die. And a
typical two-machine cluster served 20-40 simultaneous users
doing text processing, typesetting, order entry, and workflow
management.
An oddity: While teaching myself PDP-11 assembler, I recall
finding three different single instructions that could be used to
return from an ordinary subroutine. Studying the instruction
timings for the PDP-11/(34?), I was surprised to learn that RET
was only the second-fastest; MOV (SP)+,PC was just a hair faster
(and JMP @(SP)+ was a good deal slower). I suggested to our hot-
rodders that changing the RETURN macro in our system-wide macro
file might be in order, but AFAIK nobody followed through.
Brian {Hamilton Kelly}
ste...@eircom.net "Steve O'Hara-Smith" writes:
> On Wed, 18 Sep 2002 18:43:55 +0000 (UTC)
> b...@dsl.co.uk (Brian {Hamilton Kelly}) wrote:
>
> B> I think you've probably found a reasonable explanation; eight character
>
> Unfortunately it is wrong - (and something *is* the way I
> recall it).
>
> B> "name", followed by a "filler byte" followed by a fixed three character
> B> extension. All in a twelve byte field. The only question remaining to
>
> Make that an 11 byte field - the following is taken from
> http://www.seasip.demon.co.uk/Cpm/fcb.html.
Thanks, Steve. Now, why has this all not come out on previous excursions
of the 8+3 thread?
> Because it was eight with an implied filler and even the spare bits
> got used (the directory entry and FCB layouts match).
That'll stop those Frogs and others wanting special NLS characters in
their files' names :-)
jmfb...@aol.com
Eric Sosman <Eric....@sun.com> wrote:
>jmfb...@aol.com wrote:
>>
>> You have to realize that those -11 operating systems were not
>> designed for "timesharing". They were designed with single
>> usage in mind.
>
> Most of my exposure was to a non-DEC O/S: it booted up as
>PDP-11 DOS and then replaced the entire system image with
>customized stuff.
<grin> Neat. I was always interested (and most of the time real
surprised) by what customers were doing with the gear.
> .. But it made an effort to keep the on-disk
>structure at least partially DOS-compatible, so RAD50 was used
>in a lot of places.
>
> This system was something of a hot-rod. The PDP-11 itself
>was heavily modified, with custom memory management and more
>RAM than DEC would ever put on that model (ISTR the chip set
>started out as an 11/34). There was a machine-to-machine
>optically-isolated bus allowing a sort of clustering to permit
>continued operation even if a CPU or disk should die. And a
>typical two-machine cluster served 20-40 simultaneous users
>doing text processing, typesetting, order entry, and workflow
>management.
Typesetting? That must have really sucked up the cycles.
What's workflow management?
>
> An oddity: While teaching myself PDP-11 assembler, I recall
>finding three different single instructions that could be used to
>return from an ordinary subroutine. Studying the instruction
>timings for the PDP-11/(34?), I was surprised to learn that RET
>was only the second-fastest; MOV (SP)+,PC was just a hair faster
>(and JMP @(SP)+ was a good deal slower). I suggested to our hot-
>rodders that changing the RETURN macro in our system-wide macro
>file might be in order, but AFAIK nobody followed through.
On the -10, there were also different ways to get from here
to there. Each one had an advantage; each one had its costs.
I'm pretty sure I can't give an accurate description of each.
jmfb...@aol.com
b...@dsl.co.uk (Brian {Hamilton Kelly}) wrote:
>In article <20020918214236....@eircom.net>
> ste...@eircom.net "Steve O'Hara-Smith" writes:
>
>> On Wed, 18 Sep 2002 18:43:55 +0000 (UTC)
>> b...@dsl.co.uk (Brian {Hamilton Kelly}) wrote:
>>
>> B> I think you've probably found a reasonable explanation; eight
character
>>
>> Unfortunately it is wrong - (and something *is* the way I
>> recall it).
>>
>> B> "name", followed by a "filler byte" followed by a fixed three
character
>> B> extension. All in a twelve byte field. The only question remaining
to
>>
>> Make that an 11 byte field - the following is taken from
>> http://www.seasip.demon.co.uk/Cpm/fcb.html.
>
>Thanks, Steve. Now, why has this all not come out on previous excursions
>of the 8+3 thread?
<GRIN> Because somebody read the fucking code rather than the
fucking manual.
Eric Sosman
>
> In article <3D89F072...@sun.com>,
> Eric Sosman <Eric....@sun.com> wrote:
> >
> > This system was something of a hot-rod. The PDP-11 itself
> >was heavily modified, with custom memory management and more
> >RAM than DEC would ever put on that model (ISTR the chip set
> >started out as an 11/34). There was a machine-to-machine
> >optically-isolated bus allowing a sort of clustering to permit
> >continued operation even if a CPU or disk should die. And a
> >typical two-machine cluster served 20-40 simultaneous users
> >doing text processing, typesetting, order entry, and workflow
> >management.
>
> Typesetting? That must have really sucked up the cycles.
Not really. The technology was different: we weren't generating
bit-maps from Bézier outlines and blasting them to raster engines.
Typesetters of the day were usually called "phototypesetters" because
they used (or simulated internally) photographic methods to copy
letterform images onto film. The glyph manufacturing happened off-
line in the typesetter; all we had to tell it was what glyph to
put where. This still involved a significant amount of computation,
but not of the kind you may have imagined.
> What's workflow management?
We sold the hot-rodded PDP-11s and our custom O/S and software
to newspapers and magazines for pre-press operations. By "workflow
management" I meant things like
- Grabbing raw copy from wire services, deciding whether or
not to use it in a story, routing it to a writer, routing
that to one or more editors, negotiating with the layout
people about how many column-inches to give it, routing
it to yet another editor for "make it fit" rewriting,
and eventually signing off on it and sending it to the
typesetters.
- Classified advertisements. I never realized before working
for that company just how many distinct steps there are
between "Herald-Fabricator classified ad department; how
may I help you?" and the appearance of "For Sale: IBM 709
computer, mint condition" in the printed newspaper. I
didn't work directly with our class-ad applications and
can't recount all the intricacies, but there were enough
of them to warrant building some special hooks directly
into the file system.
Fascinating system. Ahead of its time in some ways (clustering
for fault tolerance wasn't all that common in commercial products
of the mid-1970s), far behind in others (virtually everything was
writting in assembly language; C was just beginning to appear on
the fringes when I left the place in 1985). A victim of its own
success: with all that customization and with everything written in
assembly, we got far more bang out of a small PDP-11 than anyone had
a right to -- with the result that we didn't so much stick with the
-11 as get ourselves welded to it. Bigger and faster machines became
available but we couldn't take advantage of them -- we didn't even
manage to migrate to the VAX! -- but our competitors could. And did.
I think if we'd been less successful we might have done better at
keeping our options open.
Steve O'Hara-Smith
b...@dsl.co.uk (Brian {Hamilton Kelly}) wrote:
B> Thanks, Steve. Now, why has this all not come out on previous
B> excursions of the 8+3 thread?
We were looking for origins prior to CP/M or a clear indication
that it started there. This only came up now because the mention of a
filler byte triggered a neuron shouting "No" in my brain.
It doesn't help much to explain 8+3 in CP/M - for example if those
bit flags had been stuffed in their own byte it would have to be 7+3. I
lean to the GARYKILDALL theory :)
Rupert Pigott
news:3D8B3C15...@sun.com...
[SNIP]
> - Classified advertisements. I never realized before working
> for that company just how many distinct steps there are
> between "Herald-Fabricator classified ad department; how
> may I help you?" and the appearance of "For Sale: IBM 709
> computer, mint condition" in the printed newspaper. I
> didn't work directly with our class-ad applications and
> can't recount all the intricacies, but there were enough
> of them to warrant building some special hooks directly
> into the file system.
LOL, that one caught me out too !
> Fascinating system. Ahead of its time in some ways (clustering
Sounds fantastic, wish I'd come across one. Would you be
able to give me some google-able hints as to the vendor ?
I'm curious to se know if I might have tripped over a site
that used one. One site I went to had a museum of their
old type-setting gear, including some PDP-8 powered kit.
[SNIP]
> I think if we'd been less successful we might have done better at
> keeping our options open.
Ironic. :)
Cheers,
Rupert
Chris Hedley
> I lean to the GARYKILDALL theory :)
Wouldn't that suggest a 4.7 filename?
Chris.
--
"If the world was an orange it would be like much too small, y'know?" Neil, '84
Chris Hedley -- cbh(at)ieya(dot)co(dot)uk
http://cbh.paunix.org My stuff, including genealogy, other things, etc
Russell P. Holsclaw
> Correct; using RAD50, the six letters in the "name" part could be
> compressed into two 16-bit words, and the three in the "extension"
into a
> further 16-bit word. No need to use the period to delimit one from
the
> other /internally/; programs could use the three words as an entity
to
> reference the entire name, whilst those that needed to know the
extension
> could look at the single word at offset word+2.
I've gotta problem here. When you use the term Radix50, do you mean a
character set consisting of 50 character codes, compressed into 16
bits? If so, I must point out that such a thing wouldn't fit. A
40-code set, however, would fit nicely in 16 bits... that would
provide for 26 letters, 10 digits, a space, and 3 carefully-chosen
special characters. A Radix 50 set would require another bit to
encode it.
(40^3 = 64000 and 50^3 = 125000)
I note, however, that 50 in octal corresponds to 40 decimal. Is that
where the '50' comes from?
--
Russ
Chris Hedley
> I note, however, that 50 in octal corresponds to 40 decimal. Is that
> where the '50' comes from?
Yes. If IBM had done it, it would've been called RAD28. :)
Eric Sosman
>
> "Eric Sosman" <Eric....@sun.com> wrote in message
> news:3D8B3C15...@sun.com...
>
>
> Sounds fantastic, wish I'd come across one. Would you be
> able to give me some google-able hints as to the vendor ?
> I'm curious to se know if I might have tripped over a site
> that used one. One site I went to had a museum of their
> old type-setting gear, including some PDP-8 powered kit.
The company still exists, more or less; http://www.atex.com/
is their Web site. They've been sold and re-sold and merged and
re-merged several times, and it appears they've changed their
business focus more than a little. Not having seen the place
in seventeen years I can't be sure, but I rather imagine the
old hot-rodded PDP-11s that once were their bread and butter may
now be just a fading memory of indigestion.
Anne & Lynn Wheeler
> The company still exists, more or less; http://www.atex.com/
> is their Web site. They've been sold and re-sold and merged and
> re-merged several times, and it appears they've changed their
> business focus more than a little. Not having seen the place
> in seventeen years I can't be sure, but I rather imagine the
> old hot-rodded PDP-11s that once were their bread and butter may
> now be just a fading memory of indigestion.
one of the things that started my wife and i on ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
in the late '80s was platform for the applications for one of their
large customers. following newsgroup posting is totally unrelated
that my wife and i were doing in the late '80s.
From: al...@Atex.Kodak.COM (Alex Volanis)
Newsgroups: comp.newprod
Date: 1 Jul 92 19:27:54 GMT
NEW PRODUCT ANNOUNCEMENT: Ultra High Performace Fault Tolerant File
Server
Atex Inc., a Kodak subsidiary, a supplier of high availability
publishing systems has developed a Ultra high performance fault
tolerant NFS file server. The product allows NFS client processes to
continue computing, in the event of any single point of failure of the
server or its network enviroment, even if the failure occured
mid-transaction. This is accomplished without any modification to
client software.
The fault tolerant system is comprised of two 486 servers, one acting
as a primary server and the other as a secondary server. Each server
runs Unix V.3. A proprietary high speed interface connects the two
servers. The dual servers eliminate all single points of failure.
Continuous diagnostic monitoring of all system interfaces, including
the required un-interuptable powersupply, enables the secondary server
to detect when to take over client processes from a failed primary
server.
A change journal of all data blocks modified since the primary server
went down is used to quickly bring the primary back into data
synchronization when it is returned to service.
A modified UNIX file system copies all file system data updates from
the primary server to the secondary server. The dual data copies
obviate the need to commit file system data to disk. The use of a
large buffer cache allows the file server to operate out of memory
with little or no disk reads or writes. The result is large
improvement in UNIX file system and data base performance. The
secondary server can be used in a read only mode for further
performance gains.
Atex is looking for a strategic partner to market the FTFS product and
will port the product to the operating system and hardware of the
selected vendor.
For further product information contact:
Gordon Vinther
Atex Inc.
805 Middlesex Tpk.
Billerica Ma., 01821
U.S.A.
Tel: (508)670-3133
--
Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/
Anne & Lynn Wheeler
misc. other atex ...
Subject: "Can Atex Keep Its Proprietary Place in the Newsroom?"
Source: NY Times, 3/17/91, pg F4, John Markoff <120 LINES>
'A favorite is being superseded by desktop software'
o Atex Inc., Billerica MA
- once the world's premier maker of editorial and advertising systems
- now under pressure as new technology and nimble competitors challenge
o Bill Solimeno, Seybold Publishing Group (Media PA) analyst
"They don't have a competitive product today and they need one quickly"
o the news lately has been unrelentingly bad
- 3 multi-million deals have gone to their chief competitor, S11 from
Systems Integrators, Sacramento CA
. Toronto Star
. Washington Post
. Westchester Rockland Newspapers
- 2 weeks ago Atex announced the latest in their layoffs
. they are now down to 600 employees, from 1985's 1,400
- Time Magazine dropped their hardware service and support contract
. Time was Atex's premier magazine customer
- then Time announced plans at the Seybold seminar in Boston last month
. they're going to create a division and compete with Atex
. using Macintosh software technology from P.Ink (Germany)
o Atex was founded in 1973 by Charles and Richard Ying
- they developed their first system in an unheated loft in Lexington MA
after graduating from MIT
- Ray Toothaker, Advanced Technology Solutions pres. & former Atex exec
"They would be a classic business school study case.
The thing that's sad is they had the market and they let it go.
It was a revolutionary business when it started.
But Kodak slowed us down during a crucial period beginning in 1981.
They brought in two chemists who knew nothing about high technology"
- Kodak bought Atex from its founders for $77M
Atex announced a new president in January, and a new strategy
o they were developing a "big bang" product with IBM
- instead they will go to a modular approach
- they hope for more than a dozen products before yearend
o Brian Lacey, Atex president and former Monotype (UK) head
"This company has been in a deep freeze.
We have to come out and show the what what this technology can do"
o industry executives say Atex lost it's grip because:
- they were slow to modernize, and
- slow to recognize the power of the PC desktop publishing wave
. Atex's business was based on a minicomputer system from DEC
. minicomputer sales have largely sagged in the face of PC systems
o the same features that were exclusive to Atex are available on desktops
- plus features that newspaper publishers have been looking for
o Atex may be too late to save it's still-considerable customer base
- Paul Brainerd, Aldus (Seattle WA) president
"It's a fundamental change in the business model.
It's very difficult for a company to make this kind of transition
when everything is changing in the way you do business"
. he founded Aldus when he left Atex in 1984
o Lacey took over with a mandate from Kodak and IBM
- do whatever it takes to get back on track
o Atex will adopt to industry hardware and software standards: Lacey
- they'll also open their product line and work with other companies
- industry officials are adopting a wait and see:
. can Atex make progress while cutting headcount?
o Atex is going to finish new technology projects for newsroom pagination
- combining digitized photos and text on a computer screen and
sending the result directly to the printing press
- the New York Times announced a $22M plan in 1988
. Atex and IBM would develop a customized system
- there have been delays with the system, still...
. installation of the text editing will take place this year
. without the page layout feature
o Jonathon Seybold, Seybold Report publisher
"What you have is a company that has retreated into a corner.
It's partly ATex's fault and partly its customers fault"
- large newspapers had become too dependent on Atex
'the thought of changing systems is too painful to consider'
o Lacey believes Atex will stave off the desktop onslaught
"It's very easy for passion to be forgotten when you're part of a large
multinational company. We have to bring passion back to what we do"
Accompanied by a box, "Catching the '4th Wave'"
o a lot of the talk at the Seybold seminar in Boston was about Time & P.Ink
- selling sophisticated editorial production software to magazines & papers
o P.Ink Software Engineering is a modular collection of software programs
- they combine other commercial software...
. Quark's Xpress page-layout program
. a range of database managers, text editors, newswire viewers
o the programs run on Apple Macintoshes
- "IBMs RS/6000", Next's Nextstation and other Unix systems to be added
o P.Ink allows a reporter or editor to write in one window...
- while watching newswires in another...
- and simultaneously running other Mac programs
- it's the holy grail of publishing:
. combining editing, pagination, and coordinating with dozens of
other writers and editors
o Gerald Lelivre, Time director of development for pre-press systems
"I felt the software had potential, however they were a small German
company that had no immediate intention of moving into the US.
I couldn't afford to wait"
- P.Ink is installed at 10 sites in Germany
- at Leipziger Volkszeitung, P.Ink controls a system of 140 reporters
and editors using Macintosh Ilc's
Accompanied by a chart, "Atex's Stake Amoung Leading Newspapers"
Newspaper Circulation System
Wall Street Journal 1,835,713 Information Int'l
USA Today 1,325,507 Atex
Daily News 1,194,237 Atex
Los Angeles Times 1,107,823 Systems Integrators
New York Times 1,068,217 Atex, Harris
Washington Post 772,749 Systems Integrators
Chicago Tribune 720,155 Hazeltine
Newsday 700,174 Atex
Detroit News 690,422 Systems Integrators
Detroit Free Press 626,434 Atex
San Francisco Chronicle 560,640 Systems Integrators
Chicago Sun-Times 535,884 Atex
Boston Globe 516,031 Atex
New York Post 507,568 Harris
Philadelphia Inquirer 504,903 Atex
Brian Inglis
(Chris Hedley) wrote:
>According to Russell P. Holsclaw <ru...@holsclaw.nyet>:
>> I note, however, that 50 in octal corresponds to 40 decimal. Is that
>> where the '50' comes from?
>
>Yes. If IBM had done it, it would've been called RAD28. :)
IBM did use it and called it MOD40!
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
tos...@aol.com ab...@aol.com ab...@yahoo.com ab...@hotmail.com ab...@msn.com ab...@sprint.com ab...@earthlink.com ab...@cadvision.com ab...@ibsystems.com u...@ftc.gov
spam traps
Chris Hedley
> IBM did use it and called it MOD40!
No hex? Dreadful! But at least they didn't lower themselves
to using an octal designation, that would just be *too* DEC. :)
Brian {Hamilton Kelly}
ru...@holsclaw.nyet "Russell P. Holsclaw" writes:
> I've gotta problem here. When you use the term Radix50, do you mean a
> character set consisting of 50 character codes, compressed into 16
[snip]
> I note, however, that 50 in octal corresponds to 40 decimal. Is that
> where the '50' comes from?
As you would have seen mentioned in MANY other posts to this thread: when
answering one that's been running a week or two, it's usually a good idea
to read ALL the posts in the thread...
Russell P. Holsclaw
when
> answering one that's been running a week or two, it's usually a good
idea
> to read ALL the posts in the thread...
Well, I reviewed the rest of the posts and no-one else mentioned the
40/50 discrepancy.
OTOH, I've become aware that my ISP seems to miss a lot of ng
postings. I see people quoting posts that I never saw the originals
of. I complained to my ISP about this (Qwest.net) and they did nothing
except say that they "don't support the *content* of newsgroups". I
don't know what *that's* supposed to mean! I suppose that they would
say the same thing if I were missing emails ... They don't support the
"content"?
Many times I don't even ever see the posts I made myself. Anyway,
sorry if I offended you by not reading what I couldn't see.
--
Russ
Gene Wirchenko
>Peter Ibbotson wrote:
>>
>> "Adam Fairbrother" <quickn...@hotmail.com> wrote in message
>> news:Xns9289171BE9...@24.67.253.211...
>> > Hello, I was just wondering if anyone in here would know the
>> > history of the 8.3 file name convention in DOS. I was reading through
>> > some old messages in google groups, and found a partial answer, but it
>> > isn't something that I understand all that well. Something about a CP/M
>> > OS refrenced when making DOS as well as something to do with the PDP10(6
>> > bit chars), and RAD50(Octal packing).
>>
>> Hmm... We did this back in april most recently
January/February, and it was I who asked then.
>> See:
>> http://groups.google.com/groups?selm=3cb1a341.65680%40news.ocis.net
>> The summary is that no one knows for sure.
>>
>Perhaps it is just a recurring troll... I guess we could ask
>the poster to "read the FAQ" (RTFM), but I do *not* think
>that <a.f.c.> really has a FAQ as such...
No, it is not a troll. Both Adam and I are enrolled in the
Computer Systems: Operations and Management diploma program at The
University College of the Cariboo in Kamloops, British Columbia,
Canada. This question is from the instructor who usually teaches the
first-semester hardware course.
Apparently, only two students have ever gotten it, and he refuses
to give out the answer. Any chance I could persuade you folks to be
rotten, lousy, lowdown SOBs? I could threaten to publish the
instructor's contact information so that you might argue for being
spared from this question in the future. <G>
Of course, I have probably given enough information that, with a
bit of work, you could figure out who the instructor is. Please let
him live. He is actually quite a nice guy.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> No, it is not a troll. Both Adam and I are enrolled in the
> Computer Systems: Operations and Management diploma program at The
> University College of the Cariboo in Kamloops, British Columbia,
> Canada. This question is from the instructor who usually teaches the
> first-semester hardware course.
>
That sounds more like a breakfast cereal. Or maybe that would be
"Cariboo in Frootloops".
>
> Apparently, only two students have ever gotten it, and he refuses
> to give out the answer. Any chance I could persuade you folks to be
> rotten, lousy, lowdown SOBs? I could threaten to publish the
> instructor's contact information so that you might argue for being
> spared from this question in the future. <G>
>
answer to the question of where the 8+3 file file naming convention
came from.
>
> Of course, I have probably given enough information that, with a
> bit of work, you could figure out who the instructor is. Please let
> him live. He is actually quite a nice guy.
>
convention came from...is a cut above in my book.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Heinz W. Wiggeshoff
> Come on...there's *not* really a college called "Cariboo in Kamloops".
> That sounds more like a breakfast cereal. Or maybe that would be
> "Cariboo in Frootloops".
...
And you also don't believe there's a Moose Jaw High?
CBFalconer
> Gene Wirchenko wrote:
> >
> > [snip...] [snip...] [snip...]
> >
> > No, it is not a troll. Both Adam and I are enrolled in the
> > Computer Systems: Operations and Management diploma program at The
> > University College of the Cariboo in Kamloops, British Columbia,
> > Canada. This question is from the instructor who usually teaches
> > the first-semester hardware course.
> >
> Come on...there's *not* really a college called "Cariboo in Kamloops".
> That sounds more like a breakfast cereal. Or maybe that would be
> "Cariboo in Frootloops".
Boy oh boy - next thing somebody will claim to live in Moosejaw.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Lars Poulsen
>>Come on...there's *not* really a college called "Cariboo in Kamloops".
>>That sounds more like a breakfast cereal. Or maybe that would be
>>"Cariboo in Frootloops".
As always, Google is your friend:
http://osca.ouac.on.ca/cariboo.htm
http://www.cariboo.bc.ca/tt/electron/core.htm
--
/ Lars Poulsen +1-805-569-5277 http://www.beagle-ears.com/lars/
125 South Ontare Rd, Santa Barbara, CA 93105 USA la...@beagle-ears.com
Gene Wirchenko
>Gene Wirchenko wrote:
>>
>> [snip...] [snip...] [snip...]
>>
>> No, it is not a troll. Both Adam and I are enrolled in the
>> Computer Systems: Operations and Management diploma program at The
>> University College of the Cariboo in Kamloops, British Columbia,
>> Canada. This question is from the instructor who usually teaches the
>> first-semester hardware course.
>>
>Come on...there's *not* really a college called "Cariboo in Kamloops".
>That sounds more like a breakfast cereal. Or maybe that would be
>"Cariboo in Frootloops".
It is not a college. It is a university college. Yes, there is
such a thing. Does it sound like an unholy mix of college and
university? I suppose it could be called that.
Lars Poulsen got it right: http://www.cariboo.bc.ca/
>> Apparently, only two students have ever gotten it, and he refuses
>> to give out the answer. Any chance I could persuade you folks to be
>> rotten, lousy, lowdown SOBs? I could threaten to publish the
>> instructor's contact information so that you might argue for being
>> spared from this question in the future. <G>
>>
>IMHO the problem is that *no* one here seems to know the definitive
>answer to the question of where the 8+3 file file naming convention
>came from.
The students who found out must have been VERY lucky.
>> Of course, I have probably given enough information that, with a
>> bit of work, you could figure out who the instructor is. Please let
>> him live. He is actually quite a nice guy.
>>
>Any instructor that even *cares* where the 8+3 file naming
>convention came from...is a cut above in my book.
I take that as agreement that you will let him live. Oh, good!
Peter Ibbotson
news:3d94c80b...@news.ocis.net...
> Charles Richmond <rich...@ev1.net> wrote:
>
> >Peter Ibbotson wrote:
> >>
> >> "Adam Fairbrother" <quickn...@hotmail.com> wrote in message
> >> news:Xns9289171BE9...@24.67.253.211...
> >> > Hello, I was just wondering if anyone in here would know the
> >> > history of the 8.3 file name convention in DOS. I was reading
through
> >> > some old messages in google groups, and found a partial answer, but
it
> >> > isn't something that I understand all that well. Something about a
CP/M
> >> > OS refrenced when making DOS as well as something to do with the
PDP10(6
> >> > bit chars), and RAD50(Octal packing).
> >>
> >> Hmm... We did this back in april most recently
>
> January/February, and it was I who asked then.
Sorry gene, it was just when I googled for this I found your thread which
starts off with "A few months ago". Unfortunately for me the time frame for
this stuff is prior to my starting to work with computers so I have no
"real" answers.
I'd love to know what he thinks the "correct" answer is.
--
Work pet...@lakeview.co.uk.plugh.org | remove magic word .org to reply
Home pe...@ibbotson.co.uk.plugh.org | I own the domain but theres no MX
Mario Klebsch
news:Xns9289171BE9...@24.67.253.211...
> Hello, I was just wondering if anyone in here would know the history
> of the 8.3 file name convention in DOS. I was reading through some
> old messages in google groups, and found a partial answer, but it
> isn't something that I understand all that well. Something about a
> CP/M OS refrenced when making DOS as well
MS-DOS was strongly based on CP/M. CP/M was a standard OS on
8080/8085/Z80 baes systems osed around 1980-1985.
BW the source code of CP/M has been released to the public some years
ago.
73, Mario
--
Mario Klebsch ma...@klebsch.de
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518