On the origin of the /text section/ for code

[Johann 'Myrkraverk' Oskarsson]

Dear a.f.computers,

I am curious to know where the term "text section" comes from
in object files. I have traced these terms to the Multics lite-
rature, though I think I misplaced the reference that gave a hint
to what it might be.

The "text section" is for read only data, and code, and I thought
maybe that the term /read only/ had been a Multics pun to create
a "text section."

The exact reference I am thinking of is now misplaced. I thought
it was in the Multics Programmer's Manual, but I don't find it at
first glance, and it doesn't seem to be [in a very superficial
search] in the Multics System Programmer's Manual, which is really
the design document, and comes in about 900+ pdf files or so. [*]

I was pretty sure it was not a passage in Organick's book, but as
I've also been reading that, it's a possibility.

So, does the pun /read only/ --> /text/ make sense in anything
older than Multics? Wasn't that the first system with strictly
read only passages in memory?

Am I completely off base in this terminology search?

[*] Or so I understand; I'm not a multician.

[Dan Espen]

Post by Johann 'Myrkraverk' Oskarsson
Dear a.f.computers,
I am curious to know where the term "text section" comes from
in object files. I have traced these terms to the Multics lite-
rature, though I think I misplaced the reference that gave a hint
to what it might be.
The "text section" is for read only data, and code, and I thought
maybe that the term /read only/ had been a Multics pun to create
a "text section."
The exact reference I am thinking of is now misplaced. I thought
it was in the Multics Programmer's Manual, but I don't find it at
first glance, and it doesn't seem to be [in a very superficial
search] in the Multics System Programmer's Manual, which is really
the design document, and comes in about 900+ pdf files or so. [*]
I was pretty sure it was not a passage in Organick's book, but as
I've also been reading that, it's a possibility.
So, does the pun /read only/ --> /text/ make sense in anything
older than Multics? Wasn't that the first system with strictly
read only passages in memory?
Am I completely off base in this terminology search?
[*] Or so I understand; I'm not a multician.

Back in 1964, IBM had TXT records in it's object decks:

https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types

[Douglas Miller]

Post by Dan Espen
...
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types
--
Dan Espen

Fascinating. I had first heard it on Unix, but no one there could say where that came from. I wonder if it goes back even further.

Perhaps the logic behind the term was that it represented the "text" - i.e. usable (runable) part - of the object file, with the rest being meta-data/headers. Or else "TXT" stands for something other than "text" and it just got morphed into ".text" on Unix. I do wonder if there is anyone left that truly knows where the term originated.

[Johann 'Myrkraverk' Oskarsson]

Post by Douglas Miller

Post by Dan Espen
...
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types
--
Dan Espen

Fascinating. I had first heard it on Unix, but no one there could say where that came from. I wonder if it goes back even further.
Perhaps the logic behind the term was that it represented the "text" - i.e. usable (runable) part - of the object file, with the rest being meta-data/headers. Or else "TXT" stands for something other than "text" and it just got morphed into ".text" on Unix. I do wonder if there is anyone left that truly knows where the term originated.

It is early enough to sort of predate Multics, but by then the effort
was already underway.

https://www.multicians.org/chrono.html

Post by Douglas Miller
Object Segment Format
All Multics translators produce a standard object segment that
contains object code, linkage data, and other information that
may be required at execution time. The overall format of an
object segment is shown below.
+----------------------+
| | text
| |
+----------------------+ definitions
| |
+----------------------+ linkage
| static |
+----------------------+
| |
+----------------------+
| | symbol
| |
+----------------------+ object map

So it was /not/ a Unix invention, and it comes to us straight from
Multics.

That Multics was working with an even older tradition from IBM does not
surprise me. But that doesn't mean it /came from/ IBM. Here is the
term "binary text" in a GE 635 document, pertaining to the output of the
assembler.

Post by Douglas Miller
The GE-625/635 Macro Assembler is being provided to give the
professional programmers some of the conveniences of a compiler and
the flexibility of an Assembler. The ability to design desired MACROs
in order to provide convenient shorthand notations plus the use of all
GE-625/635 machine instructions as well as a complete set of pseudo-
operations provides the programmer with a very powerful and flexible
tool. The output options enable him to obtain binary text in
relocatable as well as absolute formats. ^^^^^^^^^^^

|
http://ed-thelen.org/comp-hist/GE-635.html |
^
So it looks like a term from the 60s, if not 50s, but I'm still unsure
/why/.

[Douglas Miller]

Yes, definitely pre-dates Unix.

One "interesting" thing about the older (50's and 60's) "character-based" computers is that each "byte" was 6-bits and typically all (64) possible values were printable. So, a binary blob of executable code could actually be printed, and I've seen documentation implying that people did actually create machine code images by "typing in the text characters" and could directly read the machine code out of records/printouts. I don't know if this could have anything to do with the term, but back then the difference between printable/readable text and machine code was thin-to-non-existent.

[Douglas Miller]

On second thought, it might be even simpler than that. On these variable-word-length computers the 6-bit "byte" was called a character. What else would you call a bunch of characters (executable part of an object file) but "text"?

Post by Douglas Miller
Yes, definitely pre-dates Unix.
One "interesting" thing about the older (50's and 60's) "character-based" computers is that each "byte" was 6-bits and typically all (64) possible values were printable. So, a binary blob of executable code could actually be printed, and I've seen documentation implying that people did actually create machine code images by "typing in the text characters" and could directly read the machine code out of records/printouts. I don't know if this could have anything to do with the term, but back then the difference between printable/readable text and machine code was thin-to-non-existent.

[Douglas Miller]

I also suspect that usage of the term would pre-date it's appearance in documentation. Or at least that's a likely possibility.

[Johann 'Myrkraverk' Oskarsson]

Post by Douglas Miller
I also suspect that usage of the term would pre-date it's appearance in documentation. Or at least that's a likely possibility.

Yes. We have real world experiences of words being used for hundreds of
years, before they're written down for the first time.

Some, particularly naughty words, still don't appear in print. I have
an example from the Netherlands, but it's /not fit for printing/.

[Douglas Miller]

Speaking of words, these old machines used "word marks" to identify the start (or end) of an instruction. So, you've got characters and words already, seems like an easy hop to "text".

Post by Douglas Miller
I also suspect that usage of the term would pre-date it's appearance in documentation. Or at least that's a likely possibility.

Yes. We have real world experiences of words being used for hundreds of
years, before they're written down for the first time.
Some, particularly naughty words, still don't appear in print. I have
an example from the Netherlands, but it's /not fit for printing/.
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/

[Johann 'Myrkraverk' Oskarsson]

Post by Douglas Miller
On second thought, it might be even simpler than that. On these variable-word-length computers the 6-bit "byte" was called a character. What else would you call a bunch of characters (executable part of an object file) but "text"?

I was reasently reading the /abstracting away the machine/ book, about
the history of Fortran. The term does not appear in that book, but the
story refers to people reading the /object code/ IIRC, and reverse
engineering the compiler, so to speak; from the distribution punch
cards. Then rearranging the I/O on tapes, to make the compiler faster.

[Or that's how I remember the story, the real book may have
differences.]

Post by Douglas Miller

Post by Douglas Miller
Yes, definitely pre-dates Unix.
One "interesting" thing about the older (50's and 60's) "character-based" computers is that each "byte" was 6-bits and typically all (64) possible values were printable. So, a binary blob of executable code could actually be printed, and I've seen documentation implying that people did actually create machine code images by "typing in the text characters" and could directly read the machine code out of records/printouts. I don't know if this could have anything to do with the term, but back then the difference between printable/readable text and machine code was thin-to-non-existent.

Possibly they just read the hollerith codes on the punch cards. Though
I guess text printouts would be easier to deal with; but I have no
experience with real world punch cards, nor such printouts.

[Peter Flass]

Post by Johann 'Myrkraverk' Oskarsson

Post by Douglas Miller
On second thought, it might be even simpler than that. On these
variable-word-length computers the 6-bit "byte" was called a character.
What else would you call a bunch of characters (executable part of an
object file) but "text"?

I was reasently reading the /abstracting away the machine/ book, about
the history of Fortran. The term does not appear in that book, but the
story refers to people reading the /object code/ IIRC, and reverse
engineering the compiler, so to speak; from the distribution punch
cards. Then rearranging the I/O on tapes, to make the compiler faster.

Have the book, and yes. I can’t remember the title just now, but I could
find it if anyone’s interested.

Post by Johann 'Myrkraverk' Oskarsson
[Or that's how I remember the story, the real book may have
differences.]

Post by Douglas Miller

Post by Douglas Miller
Yes, definitely pre-dates Unix.
One "interesting" thing about the older (50's and 60's)
"character-based" computers is that each "byte" was 6-bits and
typically all (64) possible values were printable. So, a binary blob of
executable code could actually be printed, and I've seen documentation
implying that people did actually create machine code images by "typing
in the text characters" and could directly read the machine code out of
records/printouts. I don't know if this could have anything to do with
the term, but back then the difference between printable/readable text
and machine code was thin-to-non-existent.

Possibly they just read the hollerith codes on the punch cards. Though
I guess text printouts would be easier to deal with; but I have no
experience with real world punch cards, nor such printouts.

[John Levine]

Post by Johann 'Myrkraverk' Oskarsson
I was reasently reading the /abstracting away the machine/ book, about
the history of Fortran.

Have the book, and yes. I can’t remember the title just now, but I could
find it if anyone’s interested.

Abstracting Away the Machine: the History of the Fortran Programming Language

Mark Jones Lorenzo, 2019, ISBN 978-1082395949

It's pretty good.

[Rich Alderson]

Post by Johann 'Myrkraverk' Oskarsson
Possibly they just read the hollerith codes on the punch cards. Though
I guess text printouts would be easier to deal with; but I have no
experience with real world punch cards, nor such printouts.

Binary punch code are *not* Hollerith encoded!

A binary card consisted of two 6 bit fields per column (12 locations) times
72 columns. Thus, you could have multiple "numeric" punches in a single
column, forbidden in Hollerith encoding.

[Douglas Miller]

Post by Rich Alderson

Possibly they just read the hollerith codes on the punch cards. Though
I guess text printouts would be easier to deal with; but I have no
experience with real world punch cards, nor such printouts.

Binary punch code are *not* Hollerith encoded!
A binary card consisted of two 6 bit fields per column (12 locations) times
72 columns. Thus, you could have multiple "numeric" punches in a single
column, forbidden in Hollerith encoding.
--
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

There were a lot of different "binary" card formats used by various systems. Just today I was reading about one of the earlier IBM 700 systems, where it (if I understood it correctly) formatted some *rows* on the punch card as binary data, sort of like turning the data 90 degrees from "normal". This would make sense if you think of the card reader as starting with row 9 and reading all columns of the row in parallel. so, the format allowed for special punches in row 9, read first, that directed how those columns were interpreted on other rows (8, 7, ... 0, 11, 12).

Some systems/formats just converted hollerith codes to internal character binary format and placed them in memory. The Honeywell 200/2000 machines could do either this character-binary format or the 6+6-per-column binary format you mention. I'm sure there were others used as well. Most of the stranger ones were dropped early on, it would seem.

[Anne & Lynn Wheeler]

Post by Douglas Miller
There were a lot of different "binary" card formats used by various
systems. Just today I was reading about one of the earlier IBM 700
systems, where it (if I understood it correctly) formatted some *rows*
on the punch card as binary data, sort of like turning the data 90
degrees from "normal". This would make sense if you think of the card
reader as starting with row 9 and reading all columns of the row in
parallel. so, the format allowed for special punches in row 9, read
first, that directed how those columns were interpreted on other rows
(8, 7, ... 0, 11, 12).

I mentioned upthread implementing 1401 MPIO on 360/30 ... univ had
709/1401 with 709 tape->tape and 1401 doing unit record front end (tapes
manually move between tape drives on the different systems). the univ
had been sold 360/67 (for tss/360) to replace 709/1401 with 360/30
temporary interim replacing just 1401 pending 360/67 (tss/360 never came
to production fruition, so ran as 360/65 with os/360).

Reading cards to tape, I had to recognize binary (two 6bit bytes/column)
and BCD (simple character encode per column) ... read default BCD
and if error, reread as binary (80 cols. mapped to 160bytes)
... BCD&binary written to 7track tape (6bits + parity).

similarly on output, had to recognize whether images (read from tape)
were punched BCD or binary.

Note: inside IBM, a 360 "green card" was implemented in CMS IOS3270
(full screen 3270 terminal). I've since done a quick and dirty
converstion to HTML
http://www.garlic.com/~lynn/gcard.html
card/reader punch I/O for 3504/3505/3525 (same as 2540)
http://www.garlic.com/~lynn/gcard.html#23
2540
https://en.wikipedia.org/wiki/IBM_2540

other trivia: Univ. had sense marked cards for class registration
.... large number of tables around the perimeter of the gym for class
signups ... cards would fill maybe 30-40 trays total. they were then fed
through mark sense & printed/punched. I wrote part of the program for
registration ... cards were fed into 2540 card reader for the middle
stacker. These were all" manila" cards ... the punch side of the 2540
had colored edge cards ... if there was something wrong with a
registration card, a blank color edge card would be punched to the
middle stacker (behind card with problem). It was then going through all
the trays looking for the color edge cards for problem registration that
needed fixing.

more trivia: account of how 360 originally was suppose to be an ASCII
machine ... but ASCII unit record gear was late ... so (temporarily)
went as EBCDIC (but never recovered) ... gone 404, but lives on at
wayback machine
https://web.archive.org/web/20180513184025/http://www.bobbemer.com/P-BIT.HTM

[Peter Flass]

Post by Anne & Lynn Wheeler
Note: inside IBM, a 360 "green card" was implemented in CMS IOS3270
(full screen 3270 terminal). I've since done a quick and dirty
converstion to HTML
http://www.garlic.com/~lynn/gcard.html
card/reader punch I/O for 3504/3505/3525 (same as 2540)
http://www.garlic.com/~lynn/gcard.html#23
2540
https://en.wikipedia.org/wiki/IBM_2540

Thanks, but I’ve got a real one in my desk drawer:-)

Post by Anne & Lynn Wheeler
other trivia: Univ. had sense marked cards for class registration
.... large number of tables around the perimeter of the gym for class
signups ... cards would fill maybe 30-40 trays total. they were then fed
through mark sense & printed/punched. I wrote part of the program for
registration ... cards were fed into 2540 card reader for the middle
stacker. These were all" manila" cards ... the punch side of the 2540
had colored edge cards ... if there was something wrong with a
registration card, a blank color edge card would be punched to the
middle stacker (behind card with problem). It was then going through all
the trays looking for the color edge cards for problem registration that
needed fixing.

We did something similar with punched cards. Every student got an id card
and then went around the gym to pick up a card for a section of the courses
they wanted. Little deck assembled with section cards behind the header,
all packed into a tray and read in to generate the schedule.

[Peter Flass]

Post by Douglas Miller

Post by Rich Alderson

Possibly they just read the hollerith codes on the punch cards. Though
I guess text printouts would be easier to deal with; but I have no
experience with real world punch cards, nor such printouts.

Binary punch code are *not* Hollerith encoded!
A binary card consisted of two 6 bit fields per column (12 locations) times
72 columns. Thus, you could have multiple "numeric" punches in a single
column, forbidden in Hollerith encoding.
--
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

There were a lot of different "binary" card formats used by various
systems. Just today I was reading about one of the earlier IBM 700
systems, where it (if I understood it correctly) formatted some *rows* on
the punch card as binary data, sort of like turning the data 90 degrees
from "normal". This would make sense if you think of the card reader as
starting with row 9 and reading all columns of the row in parallel. so,
the format allowed for special punches in row 9, read first, that
directed how those columns were interpreted on other rows (8, 7, ... 0, 11, 12).
Some systems/formats just converted hollerith codes to internal character
binary format and placed them in memory. The Honeywell 200/2000 machines
could do either this character-binary format or the 6+6-per-column binary
format you mention. I'm sure there were others used as well. Most of the
stranger ones were dropped early on, it would seem.

IBM 1130 had a weird binary format for program loading. Card rows 12-2
were stored in bits 0-4 of a word. Bits 5-7 were set to 0, row 3 went into
bits 8 and 9, and rows 4-9 into bits 10-15.

[Scott Lurndal]

Post by Rich Alderson

Post by Johann 'Myrkraverk' Oskarsson
Possibly they just read the hollerith codes on the punch cards. Though
I guess text printouts would be easier to deal with; but I have no
experience with real world punch cards, nor such printouts.

Binary punch code are *not* Hollerith encoded!
A binary card consisted of two 6 bit fields per column (12 locations) times
72 columns. Thus, you could have multiple "numeric" punches in a single
column, forbidden in Hollerith encoding.

On Burroughs systems, a binary card encoded two columns (24 'bits') as
three bytes, with the middle byte split across the two columns.

[Peter Flass]

Post by Douglas Miller
Yes, definitely pre-dates Unix.
One "interesting" thing about the older (50's and 60's) "character-based"
computers is that each "byte" was 6-bits and typically all (64) possible
values were printable. So, a binary blob of executable code could
actually be printed, and I've seen documentation implying that people did
actually create machine code images by "typing in the text characters"
and could directly read the machine code out of records/printouts. I
don't know if this could have anything to do with the term, but back then
the difference between printable/readable text and machine code was thin-to-non-existent.

Heck, I’ve created executables by multi-punching on a keypunch.

[Charles Richmond]

Post by Douglas Miller
Yes, definitely pre-dates Unix.
One "interesting" thing about the older (50's and 60's) "character-based" computers is that each "byte" was 6-bits and typically all (64) possible values were printable. So, a binary blob of executable code could actually be printed, and I've seen documentation implying that people did actually create machine code images by "typing in the text characters" and could directly read the machine code out of records/printouts. I don't know if this could have anything to do with the term, but back then the difference between printable/readable text and machine code was thin-to-non-existent.

the EDSAC computer at Cambridge first ran in May of 1949. The
instruction codes of the EDSAC were all printable characters in the
character set used. This allowed a trace program co-resident with the
code of your program... to intercept the instruction code and send it to
the printer.

I have *not* heard or read that the term "text" was used for the
executable code.... but maybe...

[Douglas Miller]

Right, We may never be sure how or when the term was first used. The term "text" for a block of executable code makes as little sense for an IBM 360 as it does for a Linux system. I trust IBM engineers must have had a good reason for choosing that term, as it is not very meaningful on the surface of it. IBM continues to prefer the term "IPL" to bootstrap to this day, which is actually a more logical term - Initial Program Load. I would find it strange for IBM to choose the term test (TXT) unless it was already established.

To me, I can see some logic to the term in the context of a block of characters organized into "words" of executable code. Not a compelling origin, but I haven't heard a better one yet.

Post by Charles Richmond

...

I have *not* heard or read that the term "text" was used for the
executable code.... but maybe...
--
Charles Richmond

[Dan Espen]

Post by Douglas Miller
Right, We may never be sure how or when the term was first used. The
term "text" for a block of executable code makes as little sense for
an IBM 360 as it does for a Linux system. I trust IBM engineers must
have had a good reason for choosing that term, as it is not very
meaningful on the surface of it. IBM continues to prefer the term
"IPL" to bootstrap to this day, which is actually a more logical term
- Initial Program Load. I would find it strange for IBM to choose the
term test (TXT) unless it was already established.

Sure they had a reason.

Object decks had RLD, ESD, END, and cards with the actual code in them.
What else would you call that stuff other than TXT?
The RLD and ESD cards had data that allowed the loader to adjust any
ADCONS to the actual load address. The END card signaled the end and
where to branch into the module after it's loaded and adjusted.

REP cards are another story.

[Douglas Miller]

A lot of things would have made more sense than TXT. OBJ, EXE, etc. I'm not seeing a reason that a group of IBM engineers would have chosen TXT without a compelling reason.

Post by Dan Espen
...
What else would you call that stuff other than TXT?

...

--
Dan Espen

[Anne & Lynn Wheeler]

Post by Douglas Miller
A lot of things would have made more sense than TXT. OBJ, EXE,
etc. I'm not seeing a reason that a group of IBM engineers would have
chosen TXT without a compelling reason.

the os/360 ("02"/12-2-9) "TXT" cards were just data for the loader, most
of the others were loader control. ESD cards were names, 1) entry,
indicating start &/or other points into the program ... or 2) external,
indicating symbolic location in some other program. I guess could have
used 3letter "DAT" ... if text hadn't already been in use for loader
"data".

There were OS/360 2,3,7 card loaders that could handle a single TXT deck
(ESD/END). In some assembler source programs they had "PUNCH" cards at
the front that would prefix the assembler output with a 2 or 3 card
loader (making it self loading program).

In the OS/360 BPS loader (maybe 60-70 cards prefixed with a 3?card
loader) supported multiple program loading. it had a table with 255
slots for ESD entry points. For an external ESD, it would search the
loader table with the same name to get the associated address.

At one time, I had a card tray of assembler output and started to exceed
the 255 entry for the BPS loader ... & had various hacks to keep adding
stuff overloading a single symbolic entry (to keep within BPS 255 slot
table).

[Douglas Miller]

I still haven't heard an explanation for "TXT" on the IBM 360. This sort of thing would have gone through internal reviews, so there must have been a reason. It may be lost to history, but there should be some logic behind it, like:

A) IBM already used the term internally
B) Customers already used it
C) It was widely accepted throughout the industry
or
D) "TXT" because... [some explanation or acronym we haven't heard yet]

The main point is that "text" doesn't seem to make sense in the context of a block (or records) of executable code. If "TXT" was an acronym, I could imagine it being colloquialized to "text" and then propagated to Multics, Unix, etc. But, what does "TXT" mean then?

[Dan Espen]

Post by Dan Espen
...
What else would you call that stuff other than TXT?

...

Last time I fix your top posting.

A lot of things would have made more sense than TXT. OBJ, EXE,
etc. I'm not seeing a reason that a group of IBM engineers would have
chosen TXT without a compelling reason.

Nope.

The data in a text segment is not an EXE, the EXE is the whole thing
together.

Similar for OBJ.


Really, top post and talk to yourself. I'm too old for this foolishness.

[Douglas Miller]

Likewise.

Post by Dan Espen
...
Last time I fix your top posting.
...
Really, top post and talk to yourself. I'm too old for this foolishness.
--
Dan Espen

Likewise.

[Peter Flass]

Post by Dan Espen

Post by Dan Espen
...
What else would you call that stuff other than TXT?

...

Last time I fix your top posting.

A lot of things would have made more sense than TXT. OBJ, EXE,
etc. I'm not seeing a reason that a group of IBM engineers would have
chosen TXT without a compelling reason.

Nope.
The data in a text segment is not an EXE, the EXE is the whole thing
together.
Similar for OBJ.
Really, top post and talk to yourself. I'm too old for this foolishness.

I’m not sure anyone clued him in. I was thinking of saying something, but
figured lots of other people probably would.

[Dan Espen]

Post by Douglas Miller

Post by Dan Espen
...
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types
-- Dan Espen

Fascinating. I had first heard it on Unix, but no one there could say
where that came from. I wonder if it goes back even further.

Not likely.

Before S/360, object decks were executable in themselves. The first few
cards bootstrapped the logic to read the rest of the object deck.
There's no way that little bit of logic would differentiate text and
other record types in the object deck.

The 2 types of object decks I'm familiar with were from IBM 1401 and IBM
1440. Both types had logic to read a card into a memory location and
set work marks in that memory to mark the instructions and constants.

I don't know what other manufacturers were up to at the time but I don't
recall any discussion of relocating loaders in that time period.

[Douglas Miller]

Not sure what you're objecting to. The term "text" (TXT) for executable code is seen in the '360 documentation. The common usage for that term likely predates the '360.

Post by Dan Espen
...

Post by Douglas Miller
Fascinating. I had first heard it on Unix, but no one there could say
where that came from. I wonder if it goes back even further.

Not likely.
Before S/360, object decks were executable in themselves. >...
--
Dan Espen

[Dan Espen]

Post by Douglas Miller

Post by Dan Espen
...

Post by Douglas Miller
Fascinating. I had first heard it on Unix, but no one there could
say where that came from. I wonder if it goes back even further.

Not likely.
Before S/360, object decks were executable in themselves. >...

Not sure what you're objecting to. The term "text" (TXT) for
executable code is seen in the '360 documentation. The common usage
for that term likely predates the '360.

As I said, first time I encountered the term text was in S/360 object
decks.

As for the term going back farther, I can't see how. As I said,
object decks for earlier machines were a bootstrap loader followed
by object code. There was no reason to use the term text to describe
that stuff.

[Johann 'Myrkraverk' Oskarsson]

Post by Dan Espen

Post by Douglas Miller

Post by Dan Espen
...

Post by Douglas Miller
Fascinating. I had first heard it on Unix, but no one there could
say where that came from. I wonder if it goes back even further.

Not likely.
Before S/360, object decks were executable in themselves. >...

Not sure what you're objecting to. The term "text" (TXT) for
executable code is seen in the '360 documentation. The common usage
for that term likely predates the '360.

As I said, first time I encountered the term text was in S/360 object
decks.
As for the term going back farther, I can't see how. As I said,
object decks for earlier machines were a bootstrap loader followed
by object code. There was no reason to use the term text to describe
that stuff.

So, if I get the timeline right, OS/360, announced in 1964, had TXT
records in its object deck format; and nothing earlier seems to use
the term.

I am assuming your use of S/360 is system/360 or something like it,
effectively or exactly the same as OS/360 from IBM.

Then that term became "text" in Multics, by virtue of the same people
working on it? That's the /only/ scenario that makes sense to me,
since the timeline is a bit too tight otherwise, looking at the Multics
timeline I linked elsewhere in this discussion.

And from there it spread into Unix, and the rest of the world. [*]

But why did IBM choose TXT records? Do we have anything like the
/Multics System Programmer's Manual/ or design documents from the
time of OS/360, to look at? [I have not seen anything like it,
at first glance.]

[*] The term is used in both DOS and Amiga manuals, if I'm not mis-
taken, so it's not as Unix-centric as people may believe.

[Dan Espen]

Post by Johann 'Myrkraverk' Oskarsson

Post by Dan Espen

Post by Douglas Miller

Post by Dan Espen
...

Post by Douglas Miller
Fascinating. I had first heard it on Unix, but no one there could
say where that came from. I wonder if it goes back even further.

Not likely.
Before S/360, object decks were executable in themselves. >...

Not sure what you're objecting to. The term "text" (TXT) for
executable code is seen in the '360 documentation. The common usage
for that term likely predates the '360.

As I said, first time I encountered the term text was in S/360 object
decks.
As for the term going back farther, I can't see how. As I said,
object decks for earlier machines were a bootstrap loader followed
by object code. There was no reason to use the term text to describe
that stuff.

So, if I get the timeline right, OS/360, announced in 1964, had TXT
records in its object deck format; and nothing earlier seems to use
the term.
I am assuming your use of S/360 is system/360 or something like it,
effectively or exactly the same as OS/360 from IBM.

IBM developed multiple operating systems for S/360, OS/360 is only 1
of them. The object format was common to DOS/360, OS/360, and I'm
pretty sure BOS/360.

Post by Johann 'Myrkraverk' Oskarsson
Then that term became "text" in Multics, by virtue of the same people
working on it? That's the /only/ scenario that makes sense to me,
since the timeline is a bit too tight otherwise, looking at the Multics
timeline I linked elsewhere in this discussion.
And from there it spread into Unix, and the rest of the world. [*]
But why did IBM choose TXT records? Do we have anything like the
/Multics System Programmer's Manual/ or design documents from the
time of OS/360, to look at? [I have not seen anything like it,
at first glance.]
[*] The term is used in both DOS and Amiga manuals, if I'm not mis-
taken, so it's not as Unix-centric as people may believe.

Try to think of another term for the data that makes up the instructions
and data in an executable.

My guess is that 8 out of 10 designers use the term text.

[John Levine]

Post by Dan Espen
IBM developed multiple operating systems for S/360, OS/360 is only 1
of them. The object format was common to DOS/360, OS/360, and I'm
pretty sure BOS/360.

Yes, and the semi-compatible 360/20, too. We always called them text
cards. The DOS assembler manual called them text cards, which contain
"Up to 56 bytes of text--data or instructions to be loaded"

Post by Dan Espen

Post by Johann 'Myrkraverk' Oskarsson
But why did IBM choose TXT records?

As someone else noted, the 7044 system which predated the 360 also
called the contents of the object deck text, so we know it dates at
least back to the early 1960s, probably farther.

[Johann 'Myrkraverk' Oskarsson]

Post by John Levine

Post by Dan Espen
IBM developed multiple operating systems for S/360, OS/360 is only 1
of them. The object format was common to DOS/360, OS/360, and I'm
pretty sure BOS/360.

Yes, and the semi-compatible 360/20, too. We always called them text
cards. The DOS assembler manual called them text cards, which contain
"Up to 56 bytes of text--data or instructions to be loaded"

I see, thanks.

Post by John Levine

Post by Dan Espen

Post by Johann 'Myrkraverk' Oskarsson
But why did IBM choose TXT records?

As someone else noted, the 7044 system which predated the 360 also
called the contents of the object deck text, so we know it dates at
least back to the early 1960s, probably farther.

Yes. The GE 635 assembler docs I listed refer to "binary text" and date
to July, 1964, though the revision we see online is from 1966 [*]. I
doubt such a term would have been changed to reflect something
originating in IBM in the intervening years. But stranger things have
happened.

We are almost certainly looking at a very old tradition, though exactly
when or how it originated, and why is murky. With the SHARE assembler
docs for the 704 /not/ using the term, we have an upper bound in print,
but the oral tradition can still date from the 50s, or even 40s; or
older if it dates from punch card machines that predate computers.

The question I have now, is: is there something to read, from the 50s,
that might use the term?

[*] Or so it claims. The dates can be wrong too.

[John Levine]

Post by Johann 'Myrkraverk' Oskarsson

Post by John Levine
As someone else noted, the 7044 system which predated the 360 also
called the contents of the object deck text, so we know it dates at
least back to the early 1960s, probably farther.

Yes. The GE 635 assembler docs I listed refer to "binary text" and date
to July, 1964, ...

The 635 was obviously intended to be a better 709x. It's 36 bits, word
addressed, single accumulator and multiple index registers. So I think
it is reasonable to assume the people who built the 635's software were
familiar with 704x/709x software.

I don't know how to trace the term farther back. It might be interesting
to look at Burroughs and Univac documentation from the late 50s or early
60s and see what terms they used, since they were the main non-IBM computers.
I looked at some Univac assembler manuals at bitsavers which don't contain
the word "text".

I also programmed a PDP-8 in the 1960s, with software on paper tape, but I
don't recall any particular term we used for the contents of a binary tape.

[Scott Lurndal]

Post by John Levine

Post by Johann 'Myrkraverk' Oskarsson

Post by John Levine
As someone else noted, the 7044 system which predated the 360 also
called the contents of the object deck text, so we know it dates at
least back to the early 1960s, probably farther.

Yes. The GE 635 assembler docs I listed refer to "binary text" and date
to July, 1964, ...

The 635 was obviously intended to be a better 709x. It's 36 bits, word
addressed, single accumulator and multiple index registers. So I think
it is reasonable to assume the people who built the 635's software were
familiar with 704x/709x software.
I don't know how to trace the term farther back. It might be interesting
to look at Burroughs and Univac documentation from the late 50s or early

I have the electrodata datatron manuals in storage. I'll see if I can't
dig them out and check. I also have some B200 and B300 documentation
around somewhere.

[Johann 'Myrkraverk' Oskarsson]

Post by Scott Lurndal

Post by John Levine

Post by Johann 'Myrkraverk' Oskarsson

Post by John Levine
As someone else noted, the 7044 system which predated the 360 also
called the contents of the object deck text, so we know it dates at
least back to the early 1960s, probably farther.

Yes. The GE 635 assembler docs I listed refer to "binary text" and date
to July, 1964, ...

The 635 was obviously intended to be a better 709x. It's 36 bits, word
addressed, single accumulator and multiple index registers. So I think
it is reasonable to assume the people who built the 635's software were
familiar with 704x/709x software.
I don't know how to trace the term farther back. It might be interesting
to look at Burroughs and Univac documentation from the late 50s or early

I have the electrodata datatron manuals in storage. I'll see if I can't
dig them out and check. I also have some B200 and B300 documentation
around somewhere.

I plan to scrounge around in bitsavers, computer history museum, and
archive.org soon-ish. Though I don't know how much stuff the chm has
online.

Obviously, I can only read what I have, which is pretty much limited to
the above. The only physical relevant anything would be my 1965
McCracken, but I haven't seen it discuss anything of the sort; plus it's
too recent.

[Scott Lurndal]

Post by Johann 'Myrkraverk' Oskarsson

Post by Scott Lurndal

Post by John Levine

Post by Johann 'Myrkraverk' Oskarsson

Post by John Levine
As someone else noted, the 7044 system which predated the 360 also
called the contents of the object deck text, so we know it dates at
least back to the early 1960s, probably farther.

Yes. The GE 635 assembler docs I listed refer to "binary text" and date
to July, 1964, ...

The 635 was obviously intended to be a better 709x. It's 36 bits, word
addressed, single accumulator and multiple index registers. So I think
it is reasonable to assume the people who built the 635's software were
familiar with 704x/709x software.
I don't know how to trace the term farther back. It might be interesting
to look at Burroughs and Univac documentation from the late 50s or early

I have the electrodata datatron manuals in storage. I'll see if I can't
dig them out and check. I also have some B200 and B300 documentation
around somewhere.

I plan to scrounge around in bitsavers, computer history museum, and
archive.org soon-ish. Though I don't know how much stuff the chm has
online.
Obviously, I can only read what I have, which is pretty much limited to
the above. The only physical relevant anything would be my 1965
McCracken, but I haven't seen it discuss anything of the sort; plus it's
too recent.

Well, I did take Dr. Atanasoff to dinner once back in 1982, but I didn't
ask him about the origin of the use of the term 'text' for executable
binary code :-)

[Don Poitras]

Post by Scott Lurndal
Well, I did take Dr. Atanasoff to dinner once back in 1982, but I didn't
ask him about the origin of the use of the term 'text' for executable
binary code :-)

I think you all are getting hung up on this use of "text" as if it's
mutually exclusive with "binary". Think of it as synonymous with
"body". When describing a book, it has a table of contents, an index,
illustrations and the body. Or "body of text". And just so, a program
can be described by the various parts where the meta information is
normally located apart from the main body (text) of the program.

If you look for synonyms of "body of text", you'll find (among other
things):

Body Matter
Main Content

[Johann 'Myrkraverk' Oskarsson]

Post by Don Poitras

Post by Scott Lurndal
Well, I did take Dr. Atanasoff to dinner once back in 1982, but I didn't
ask him about the origin of the use of the term 'text' for executable
binary code :-)

I think you all are getting hung up on this use of "text" as if it's
mutually exclusive with "binary". Think of it as synonymous with
"body". When describing a book, it has a table of contents, an index,
illustrations and the body. Or "body of text". And just so, a program
can be described by the various parts where the meta information is
normally located apart from the main body (text) of the program.

Obviously, it's not exclusive of anything. I just like to know how
things originated /when I can know/. Some things really are lost to
time, like how to properly build a pyramid.

Post by Don Poitras
If you look for synonyms of "body of text", you'll find (among other
Body Matter
Main Content

Sure, that's one possibility, but I still like /evidence/ if there's
any to be had.

[Kerr-Mudd, John]

On Mon, 7 Feb 2022 20:48:17 +0000

Post by Johann 'Myrkraverk' Oskarsson

Post by Don Poitras

Post by Scott Lurndal
Well, I did take Dr. Atanasoff to dinner once back in 1982, but I didn't
ask him about the origin of the use of the term 'text' for executable
binary code :-)

I think you all are getting hung up on this use of "text" as if it's
mutually exclusive with "binary". Think of it as synonymous with
"body". When describing a book, it has a table of contents, an index,
illustrations and the body. Or "body of text". And just so, a program
can be described by the various parts where the meta information is
normally located apart from the main body (text) of the program.

Obviously, it's not exclusive of anything. I just like to know how
things originated /when I can know/. Some things really are lost to
time, like how to properly build a pyramid.

That's easy; first build a ramp, turn the corner a few times and you're up before you know it.

Post by Johann 'Myrkraverk' Oskarsson

Post by Don Poitras
If you look for synonyms of "body of text", you'll find (among other
Body Matter
Main Content

Sure, that's one possibility, but I still like /evidence/ if there's
any to be had.

Seems you've had quite a few plausible suggestions.

[Rich Alderson]

Post by John Levine

Post by Johann 'Myrkraverk' Oskarsson
Yes. The GE 635 assembler docs I listed refer to "binary text" and date
to July, 1964, ...

The 635 was obviously intended to be a better 709x. It's 36 bits, word
addressed, single accumulator and multiple index registers. So I think
it is reasonable to assume the people who built the 635's software were
familiar with 704x/709x software.

The 635 was intended to be a better GE-235.

36 bits was a popular word size in late 1950s computers from several
manufacturers; others used 48 bit words.

[John Levine]

Post by Rich Alderson

Post by John Levine
The 635 was obviously intended to be a better 709x. It's 36 bits, word
addressed, single accumulator and multiple index registers.

The 635 was intended to be a better GE-235.

As a hardware implementation, maybe, for a programmer, they had nothing in common.
The 235 had 20 bit words and no index registers.

Post by Rich Alderson
36 bits was a popular word size in late 1950s computers from several
manufacturers; others used 48 bit words.

I suppose the Univac 1103 was 36 bits but it had no index registers either.

The 704 and its successors were phenomenally successful and it's not surprising
they had a lot of influence on later machines like the 635 and the PDP-6.

[Vir Campestris]

Post by Rich Alderson
36 bits was a popular word size in late 1950s computers from several
manufacturers; others used 48 bit words.

The DECSystem10 was 36 bit, and I was using a _new_ one at the end of
the 1970s. At the same time the ICL 1900 series was 24 bit words (of 4
6-bit chars)

On cards - I'm sure I recall using punch codes like 10-3-8 for asterisk,
so multiple numeric holes were used.

Andy

[Bob Eager]

Post by Vir Campestris

Post by Rich Alderson
36 bits was a popular word size in late 1950s computers from several
manufacturers; others used 48 bit words.

The DECSystem10 was 36 bit, and I was using a _new_ one at the end of
the 1970s. At the same time the ICL 1900 series was 24 bit words (of 4
6-bit chars)

And indeed so was the Elliott 4100 series, 24 bit, 4 * 6 bit characters.
My first real computing experience (BASIC, then assembler, FORTRAN and
ALGOL) was on a 4130.

Post by Vir Campestris
On cards - I'm sure I recall using punch codes like 10-3-8 for asterisk,
so multiple numeric holes were used.

Yes, I learned some of those when using a hand punch for correcting
mispunched job cards on the ICL 1900 at the University of Sussex (summer
job).

[Charlie Gibbs]

Post by Vir Campestris

Post by Rich Alderson
36 bits was a popular word size in late 1950s computers from several
manufacturers; others used 48 bit words.

The DECSystem10 was 36 bit, and I was using a _new_ one at the end of
the 1970s. At the same time the ICL 1900 series was 24 bit words (of 4
6-bit chars)
On cards - I'm sure I recall using punch codes like 10-3-8 for asterisk,
so multiple numeric holes were used.

Rows 8 and 9 were kind of special, as was row 0. The only invalid
combinations on many machines were multiple punches in rows 1 through 7.

[Rich Alderson]

Post by Charlie Gibbs

Post by Vir Campestris
On cards - I'm sure I recall using punch codes like 10-3-8 for asterisk,
so multiple numeric holes were used.

Rows 8 and 9 were kind of special, as was row 0. The only invalid
combinations on many machines were multiple punches in rows 1 through 7.

You said it before I could.

The use of rows 12, 11, 0, 8, and 9 with a single punch in one of rows 1-7 *is*
"Hollerith encoding", rather than "binary".

[Peter Flass]

Post by Johann 'Myrkraverk' Oskarsson

Post by Dan Espen

Post by Douglas Miller

Post by Dan Espen
...

Post by Douglas Miller
Fascinating. I had first heard it on Unix, but no one there could
say where that came from. I wonder if it goes back even further.

Not likely.
Before S/360, object decks were executable in themselves. >...

Not sure what you're objecting to. The term "text" (TXT) for
executable code is seen in the '360 documentation. The common usage
for that term likely predates the '360.

As I said, first time I encountered the term text was in S/360 object
decks.
As for the term going back farther, I can't see how. As I said,
object decks for earlier machines were a bootstrap loader followed
by object code. There was no reason to use the term text to describe
that stuff.

So, if I get the timeline right, OS/360, announced in 1964, had TXT
records in its object deck format; and nothing earlier seems to use
the term.
I am assuming your use of S/360 is system/360 or something like it,
effectively or exactly the same as OS/360 from IBM.
Then that term became "text" in Multics, by virtue of the same people
working on it? That's the /only/ scenario that makes sense to me,
since the timeline is a bit too tight otherwise, looking at the Multics
timeline I linked elsewhere in this discussion.
And from there it spread into Unix, and the rest of the world. [*]
But why did IBM choose TXT records? Do we have anything like the
/Multics System Programmer's Manual/ or design documents from the
time of OS/360, to look at? [I have not seen anything like it,
at first glance.]
[*] The term is used in both DOS and Amiga manuals, if I'm not mis-
taken, so it's not as Unix-centric as people may believe.

A lot of computer history predated System/360.

[Dennis Boone]

Post by Dan Espen
As I said, first time I encountered the term text was in S/360 object
decks.

The 1964 revision of the 7090 IBJOB manual talks about binary program
text. See http://bitsavers.org/pdf/ibm/7090/C28-6275-2_7090_IBJOB.pdf
around PDF page 47.

De

[Peter Flass]

Post by Dan Espen

Post by Douglas Miller

Post by Dan Espen
...

Post by Douglas Miller
Fascinating. I had first heard it on Unix, but no one there could
say where that came from. I wonder if it goes back even further.

Not likely.
Before S/360, object decks were executable in themselves. >...

Not sure what you're objecting to. The term "text" (TXT) for
executable code is seen in the '360 documentation. The common usage
for that term likely predates the '360.

As I said, first time I encountered the term text was in S/360 object
decks.
As for the term going back farther, I can't see how. As I said,
object decks for earlier machines were a bootstrap loader followed
by object code. There was no reason to use the term text to describe
that stuff.

Bootstrap loading was phased out when the first supervisory programs were
developed. The function of the resident supervisor is to load and execute a
stream of programs, so this much predates System/360 - I believe someone
wrote a primitive supervisor for the IAS in the 50s.

This, of course, has no bearing on the usage of “text” for executable code.
Some of the pioneers are still around, although probably not here, to ask
for their memories.

[Dan Espen]

Post by Peter Flass

Post by Dan Espen

Post by Douglas Miller

Post by Dan Espen
...

Post by Douglas Miller
Fascinating. I had first heard it on Unix, but no one there could
say where that came from. I wonder if it goes back even further.

Not likely.
Before S/360, object decks were executable in themselves. >...

Not sure what you're objecting to. The term "text" (TXT) for
executable code is seen in the '360 documentation. The common usage
for that term likely predates the '360.

As I said, first time I encountered the term text was in S/360 object
decks.
As for the term going back farther, I can't see how. As I said,
object decks for earlier machines were a bootstrap loader followed
by object code. There was no reason to use the term text to describe
that stuff.

Bootstrap loading was phased out when the first supervisory programs were
developed. The function of the resident supervisor is to load and execute a
stream of programs, so this much predates System/360 - I believe someone
wrote a primitive supervisor for the IAS in the 50s.
This, of course, has no bearing on the usage of “text” for executable code.
Some of the pioneers are still around, although probably not here, to ask
for their memories.

I vaguely remember something on 14xx disk systems that would load
programs. I saw that and started writing all my 1401 code to treat a
comma in column 1 of card input as end of file. If the program saw the
comma it would do normal end of job processing then set a word mark in
column 1 and branch there.

I marked every job that allowed stacking as such. As I remember I never
could get the operators to take advantage of it.

[Douglas Miller]

So, to the original question, it sounds like a possible scenario is:

By the time of the UNIVAC 1103 and IBM 700 series, in the early 1950's, the term was either unknown or not considered formal enough to make it's way into documentation and design. By the end of the 1950's, it seems to have gained enough acceptance to start appearing in documentation and even design (e.g. IBM 360 "TXT" records). So the answer to "why" would likely be in how the computer industry evolved during the 1950's, or possibly 1940's if the term was widely, but informally, used before.

[Charles Richmond]

On 2/7/2022 7:59 AM, Peter Flass wrote:
[ snip... ] [ snip... ] \ [ snip... ]

Post by Peter Flass
Bootstrap loading was phased out when the first supervisory programs were
developed. The function of the resident supervisor is to load and execute a
stream of programs, so this much predates System/360 - I believe someone
wrote a primitive supervisor for the IAS in the 50s.
This, of course, has no bearing on the usage of “text” for executable code.
Some of the pioneers are still around, although probably not here, to ask
for their memories.

The EDSAC had a bootstrap loader they called "initial orders". This
loader did convert decimal operands to binary as well as do some
elementary address relocation. Most of the EDSAC code was position
independent.

See the video of a talk given to a group of DEC employees in the 1970's
... the talk given by Maurice Wilkes:

[Vir Campestris]

Post by Charles Richmond
See the video of a talk given to a group of DEC employees in the 1970's
http://youtu.be/MZGZfsr1KfY

That's a few hours I'm going to lose.

I like you guys. Interesting stuff, and you make me feel young. Which is
increasingly unusual...

Andy

[Douglas Miller]

Looking over documentation on the IBM 700 series from the early 1950's, I'm reminded of just how primitive those systems were. You basically manually assembled, relocated, and organized your code. There was no "object file" in the sense of something with headers, meta-data, special record types. So there was no need to name something that didn't need to be separated.

By the mid-1950's there was relocatable object code, libraries, and the need for all sorts of meta-data and special records to organize all that. At that point there was the need to give a name to that "instructions and data" portion of the object file or module.

It does seem that the term appeared multiple places at about the same time, so that could suggest it came from some other source (such as being driven by common usage). Slight differences in dates of appearances may not indicate an order, as these documents represent fairly large development efforts over several years. It may have been committed to documentation/product much earlier than the release date of the hardware/software or the copyright on the document.

The idea that the term relates back to formal printed matter, such as the format of a letter, seems to be the best one so far (only one?). It still seems like a somewhat odd association to me - a letter to a program - but not entirely out of place. All it would take is some programmers/engineers to have a background or affinity in the printed word. It would be nice to find someone that actually was part of those decisions, or part of the community where the term sprung up, but that's seeming less and less likely.

[John Levine]

Post by Douglas Miller
Looking over documentation on the IBM 700 series from the early 1950's, I'm reminded of just how primitive those systems were. You basically manually assembled,
relocated, and organized your code. There was no "object file" in the sense of something with headers, meta-data, special record types. So there was no need to name
something that didn't need to be separated.
By the mid-1950's there was relocatable object code, libraries, and the need for all sorts of meta-data and special records to organize all that. At that point
there was the need to give a name to that "instructions and data" portion of the object file or module.

In 1947 John Mauchly, one of the creators of the ENIAC and UNIVAC,
wrote about relocating loaders. I believe that loaders even predate
assemblers.

But I don't recall that he used the term "text".

[Charlie Gibbs]

Post by Peter Flass
Bootstrap loading was phased out when the first supervisory programs were
developed. The function of the resident supervisor is to load and execute a
stream of programs, so this much predates System/360 - I believe someone
wrote a primitive supervisor for the IAS in the 50s.

Still, you have to bootstrap the supervisor... :-)

[Anne & Lynn Wheeler]

Post by Charlie Gibbs
Still, you have to bootstrap the supervisor... :-)

... as mentioned upthread both the Multics group (5th flr) and the IBM
science center (4th flr) and come over from the MIT CTSS/7094.

the initial CP67 I got at the univ. had all the assembler source on
OS/360 ... assembler output txt decks were punched and arranged in card
tray prefixed by BPS loader. The cards were IPL'ed, when everything was
loaded into memory, the LDT card had execution transfer to "CPINIT".

CPINIT would write initial IPL text to disk, and then a copy
of memory to disk. IPL'ing the disk would bring in CPINIT but
at an entry that reversed the write to read.

360 IPL read 24bytes into location 0, assumed to be PSW and two I/O CCWs
... and continues the I/O with transfer to first CCW. When I/O finishes,
it loads the "PSW".

Shortly later, the CP group had moved all the source to CMS ... and
assembler output was CMS txt files. Could have a CMS exec that "punched"
to a virtual punch which was transfered to a virtual reader (instead of
the real punch) and the virtual reader IPL'ed and written to disk (which
could either be a disk for a test system, or the production system disk
to update the production system for the next real IPL).

An 80x80 image of the card files (BPS loader followed by all the txt
files) could also be written to tape. I got in habit of keeping
"production system" tapes where the first file was IPL'ed (to restore
that system) ... followed by all the CMS source and other files that
went into making that specific production system.

I was able to discover ... that on transfer from the BPS loader,
that it passed the address of the ESD table and number of entries
in registers ... and did some fiddling that copied the table
to the end of the CP67 kernel ... including it in the image
written to disk.

I mentioned running into the BPS loader 255 ESD external limit and all
sorts of hacks to work around it. Later, at the science center I found
dusty file cabinet that had the source for the BPS loader ... and was
able to update the BPS loader to handle more ESD entries.

Morph from CP67->VM370 was similar ... except all module names had
"DMK" prefix and CPINIT became DMKCPI.

Inside IBM an IOS3270 version of the "green card" was done, I've done
a quick&dirty converstion to HTML ... this is "fixed storage"
http://www.garlic.com/~lynn/gcard.html#4
0: 8 byte IPL PSW
8: 8 byte IPL CCW1
16: 8 byte IPL CCW2

card note: CCW1 would normally read 80-byte image to fixed address,
could be instructions or more CCWs (10) or instructions or combination
of instructions and CCWs. If more CCWs then CCW2 could be a "tic"
command that continued the I/O channel program with the additionsl
CCWs.

[John Levine]

Post by Dan Espen
Before S/360, object decks were executable in themselves. The first few
cards bootstrapped the logic to read the rest of the object deck.
There's no way that little bit of logic would differentiate text and
other record types in the object deck.

The 360/20 had a one card bootstrap loader that could read IBM assembler
object decks. It was just clever enough to recognize the X in TXT cards,
the N in the END card, and ignore anything else like ESD and RLD.

[Charlie Gibbs]

Post by John Levine

Post by Dan Espen
Before S/360, object decks were executable in themselves. The first few
cards bootstrapped the logic to read the rest of the object deck.
There's no way that little bit of logic would differentiate text and
other record types in the object deck.

The 360/20 had a one card bootstrap loader that could read IBM assembler
object decks. It was just clever enough to recognize the X in TXT cards,
the N in the END card, and ignore anything else like ESD and RLD.

Sweet. The best I managed on the Univac 9300 was a one-card loader that
would read from 1 to 16 subsequent cards starting at a given location in
memory - but each of those cards was 80 bytes of... err... text.

The 9300's object card layout matched the 360's in only two places:
the 0x02 (12-2-9 punch) in column 1, and the program name and sequence
number in columns 73-80. Column 2 contained one of the following types:

A - program name and base address
H - entry point definition
J - basically a copy of the A card, designed to sort in such a way
that multiple object decks could be sorted together so a link
could be done in one pass. I never saw this done, though.
K - external reference
Q - text (yes, Univac documentation called it "text" too)
Y - end

There were no separate RLD cards - 3-byte RLD entries were placed
in the corresponding Q card, so relocation could be applied to
each text card without waiting until the whole deck was loaded.
Text went from left to right, RLDs went from right to left until
the card was full.

Also, columns 3 through 71 were not in EBCDIC, but in Univac's
"compressed code", which was a much more regular encoding than
EBCDIC. A byte was encoded as follows:

xxxx xxxx
|||| |||`-- row 12
|||| ||`--- row 11
|||| |`---- row 0
|||| `----- row 8
|```------- row 1: 011
| row 2: 101
| row 3: 001
| row 4: 010
| row 5: 100
| row 6: 111
| row 7: 110
`---------- row 9

This saved hardware, but you needed translation tables to go
to and from EBCDIC.

And yes, we had REP cards too. When it was really hard for us
programmers to get machine time, we'd just patch an object deck
until it fell apart under the weight of several dozen REP cards.

[Thomas Koenig]

Post by Dan Espen
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types

I looked through the documentation of the SHARE assembler for the 704,
and it didn't have it.

[Johann 'Myrkraverk' Oskarsson]

Post by Thomas Koenig

Post by Dan Espen
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types

I looked through the documentation of the SHARE assembler for the 704,
and it didn't have it.

What year does that date from? IIRC, SHARE assembler was from the
mid 50s, and as Douglas Miller alludes to, the term may have been
used well before appearing in print.

It gives us an upper bound on the term in print, but even if SHARE
members were using it informally, would it appear in their printed
documentation, or notes?

[Anne & Lynn Wheeler]

Post by Dan Espen
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types

2001 a.f.c. posts about 360 "TXT" decks and types of cards, ICS, TXT,
REP, RLD, END, LDT ... from 60s CP67/CMS manuals
http://www.garlic.com/~lynn/2001.html#14

TXT card format specific, started with similar question (why called
"TEXT")
http://www.garlic.com/~lynn/2001.html#60

the wikipedia entry, additionally mentions SYM & XSD (but not ICS &
LDT), "SYM" cards were for OS/360 "TESTRAN" ... kind of symbolic
debugger.
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types

note some of the MIT CTSS/7094 people went to the 5th flr, Project MAC
to do MULTICS, others went to the IBM Science Center on the 4th flr and
did CP40/CMS (morphs into CP67/CMS when 360/67 becomes available,
precursor to VM370), internal network, lots of performance tools (&
precursor to capacity planning), invented GML in 1969 (precursor to SGML
& HTML, CTSS RUNOFF had been redone for CMS as SCRIPT, and then GML
processing was added to SCRIPT), etc.

[Johann 'Myrkraverk' Oskarsson]

Post by Anne & Lynn Wheeler

Post by Dan Espen
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types

2001 a.f.c. posts about 360 "TXT" decks and types of cards, ICS, TXT,
REP, RLD, END, LDT ... from 60s CP67/CMS manuals
http://www.garlic.com/~lynn/2001.html#14
TXT card format specific, started with similar question (why called
"TEXT")
http://www.garlic.com/~lynn/2001.html#60

That describes what and the when, so to speak. But not /why/ nor
what it means. Or meant back then. Or did I just not see it, in
your references?

Post by Anne & Lynn Wheeler
the wikipedia entry, additionally mentions SYM & XSD (but not ICS &
LDT), "SYM" cards were for OS/360 "TESTRAN" ... kind of symbolic
debugger.
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types
note some of the MIT CTSS/7094 people went to the 5th flr, Project MAC
to do MULTICS, others went to the IBM Science Center on the 4th flr and
did CP40/CMS (morphs into CP67/CMS when 360/67 becomes available,
precursor to VM370), internal network, lots of performance tools (&
precursor to capacity planning), invented GML in 1969 (precursor to SGML
& HTML, CTSS RUNOFF had been redone for CMS as SCRIPT, and then GML
processing was added to SCRIPT), etc.

The Open Watcom project still has documentation typeset in Watcom, or
Waterloo, GML format. I am unsure if that has any relationship with
this 1969 GML.

The source code for the document processor has been lost, and is being
recreated.

[Anne & Lynn Wheeler]

Post by Johann 'Myrkraverk' Oskarsson
The Open Watcom project still has documentation typeset in Watcom, or
Waterloo, GML format. I am unsure if that has any relationship with
this 1969 GML.
The source code for the document processor has been lost, and is being
recreated.

CTSS runoff
https://en.wikipedia.org/wiki/TYPSET_and_RUNOFF
SCRIPT history
https://en.wikipedia.org/wiki/SCRIPT_(markup)
In 1968 "IBM contracted Stuart Madnick of MIT to write a simple document
preparation ..."[10][1] to run on CP/67.[11] He modeled it on MIT's CTSS
RUNOFF.[12][13] In 1974, William Dwyer at Yale University ported the
CP-67 version of Script to the Time Sharing Option (TSO) of OS/360 under
the name NSCRIPT.[14] The University of Waterloo rewrote and extended
NSCRIPT as Waterloo SCRIPT,[15] also in 1974, making it available for
free to CMS and TSO users for several releases before eventually
charging for new releases.

GML&SGML history
https://en.wikipedia.org/wiki/IBM_Generalized_Markup_Language
https://en.wikipedia.org/wiki/Standard_Generalized_Markup_Language
SGML descended from IBM's Generalized Markup Language (GML), which
Charles Goldfarb, Edward Mosher, and Raymond Lorie developed in the
1960s. Goldfarb, editor of the international standard, coined the "GML"
term using their surname initials.[5] Goldfarb also wrote the definitive
work on SGML syntax in "The SGML Handbook".[6] The syntax of SGML is
closer to the COCOA format.[clarification needed] As a document markup
language, SGML was originally designed to enable the sharing of
machine-readable large-project documents in government, law, and
industry. Many such documents must remain readable for several
decades'a long time in the information technology field. SGML
also was extensively applied by the military, and the aerospace,
technical reference, and industrial publishing industries. The advent of
the XML profile has made SGML suitable for widespread application for
small-scale, general-purpose use.

Above doesn't mention in late 70s, an IBM SE (in LA) implemented SCRIPT
(newscript) for TRS-80.

GML->HTML
http://infomesh.net/html/history/early/
references Waterloo SCRIPT GML User's Guide ... URL gone 404, but
Waterloo script (6jun1990)
https://csg.uwaterloo.ca/sdtp/watscr.html
Waterloo SCRIPT is a rewritten and extended version of a processor
called NSCRIPT that had been converted to OS and TSO from CP-67/CMS
SCRIPT. The original NSCRIPT package is available from the SHARE Program
Library. Waterloo obtained NSCRIPT in late 1974 as a viable alternative
to extending ATS to meet local requirements. The local acceptance of
Waterloo SCRIPT has continued to provide the motivation for additional
on-going development.

[Peter Flass]

Post by Johann 'Myrkraverk' Oskarsson

Post by Anne & Lynn Wheeler

Post by Dan Espen
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types

2001 a.f.c. posts about 360 "TXT" decks and types of cards, ICS, TXT,
REP, RLD, END, LDT ... from 60s CP67/CMS manuals
http://www.garlic.com/~lynn/2001.html#14
TXT card format specific, started with similar question (why called
"TEXT")
http://www.garlic.com/~lynn/2001.html#60

That describes what and the when, so to speak. But not /why/ nor
what it means. Or meant back then. Or did I just not see it, in
your references?

Post by Anne & Lynn Wheeler
the wikipedia entry, additionally mentions SYM & XSD (but not ICS &
LDT), "SYM" cards were for OS/360 "TESTRAN" ... kind of symbolic
debugger.
https://en.wikipedia.org/wiki/OS/360_Object_File_Format#Record_Types
note some of the MIT CTSS/7094 people went to the 5th flr, Project MAC
to do MULTICS, others went to the IBM Science Center on the 4th flr and
did CP40/CMS (morphs into CP67/CMS when 360/67 becomes available,
precursor to VM370), internal network, lots of performance tools (&
precursor to capacity planning), invented GML in 1969 (precursor to SGML
& HTML, CTSS RUNOFF had been redone for CMS as SCRIPT, and then GML
processing was added to SCRIPT), etc.

The Open Watcom project still has documentation typeset in Watcom, or
Waterloo, GML format. I am unsure if that has any relationship with
this 1969 GML.

Waterloo Script was similar to IBM script, although I’m not sure they were
completely compatible. IBM GML was the precursor of HTML, so presumably
Waterloo GML was related.

Post by Johann 'Myrkraverk' Oskarsson
The source code for the document processor has been lost, and is being
recreated.

Great!

[Peter Flass]

Post by Johann 'Myrkraverk' Oskarsson
Dear a.f.computers,
I am curious to know where the term "text section" comes from
in object files. I have traced these terms to the Multics lite-
rature, though I think I misplaced the reference that gave a hint
to what it might be.
The "text section" is for read only data, and code, and I thought
maybe that the term /read only/ had been a Multics pun to create
a "text section."
The exact reference I am thinking of is now misplaced. I thought
it was in the Multics Programmer's Manual, but I don't find it at
first glance, and it doesn't seem to be [in a very superficial
search] in the Multics System Programmer's Manual, which is really
the design document, and comes in about 900+ pdf files or so. [*]
I was pretty sure it was not a passage in Organick's book, but as
I've also been reading that, it's a possibility.
So, does the pun /read only/ --> /text/ make sense in anything
older than Multics? Wasn't that the first system with strictly
read only passages in memory?
Am I completely off base in this terminology search?
[*] Or so I understand; I'm not a multician.

“Text” as a description of object code much predates Multics. For example,
here is a relatively late (1965) manual for the IBM 7040 that uses “text”.

http://www.bitsavers.org/pdf/ibm/7040/C28-6339-4_OSsysPgmrGuide.pdf

The developers of Multics would have been familiar with this usage.

The “read-only” part came later, since early systems didn’t really, and in
some cases couldn’t, support read-only storage.

[Johann 'Myrkraverk' Oskarsson]

Post by Peter Flass
“Text” as a description of object code much predates Multics. For example,
here is a relatively late (1965) manual for the IBM 7040 that uses “text”.
http://www.bitsavers.org/pdf/ibm/7040/C28-6339-4_OSsysPgmrGuide.pdf
The developers of Multics would have been familiar with this usage.
The “read-only” part came later, since early systems didn’t really, and in
some cases couldn’t, support read-only storage.
Relocatable Binary Program Text
1. File text
2. Data and procedure text
File text always appears first, if it exists. Data and
procedure text follows file text and always starts on a
new card. Either or both of these parts of the relocat-
able binary program text may be omitted. Words 1
and 2 are control and check sum words, as previously
noted. [...]

So "text" here means that it was literal text, on the punch
cards? Or is there some other meaning to the term?

[Douglas Miller]

My guess would be that it was a term adopted by customers, and it eventually made it's way back to vendors which then incorporated it into documentation, and even formats (like the "TXT" record type).

Post by Johann 'Myrkraverk' Oskarsson
So "text" here means that it was literal text, on the punch
cards? Or is there some other meaning to the term?
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/