My professor made this claim... 
Author Message
 My professor made this claim...

Quote:



> > > Wow, that is truly twisted.
> > > I wonder why they didn't just put in a code like 01 for TXT and 02 for RLD
> > > though.  It seems like it would not only save space in the file but make
> > > the loader code simpler as well.  And it would be more, well, logical.

> True, but this way the card types were "readable" by the human eye. Besides
> REP cards were frequently made manually with the IBM29 or IBM129
> card punches (remember those anybody?) and that justified plain text
> wherever possible. Also see my next comment on card physical strength.

> > > Also, the use of blanks (40h) is a nuisance.  Why couldn't they have put 00
> > > in the gaps so we could read the addresses as words (which is supposedly
> > > faster)?

> No speed difference in those days, and using blanks instead of lots of
> 12-0-1-8-9 punches made the cards stronger. Card crashes were not at
> all uncommon, and caused much delays and trouble, especially with
> binary card decks.

> >  And 404040h in the END card is supposed to be "blank" but what
> > > would happen if your program really was that big and that really was the
> > > starting address?

> That is a really good question. Luckily this never became a problem with the
> machine sizes in use at the time. Load addresses in the ranges above
> 100000h (or x'100000' as we usually wrote) hardly ever occurred.

> > First of all, I think that the technique outlined by extracting the second
> > character is pretty good. There are other CARDS that need to be considered
> > however; like the REP and SYM.

> > Second, notice I capitalized CARDS. That's because that's how all of this
> > started its life. The X'02' punch in column 1 was the 21-11-0-7-8-9 combo.

> No, it was a plain 12-2-9

> > I *THINK* - Gotta go back to the original green card for this! (Actually,
> > the punches were present in subsequent GCs, but I forget where it stopped)

> Oh, they are still present in my Yellow card (S/370) from November 1976
> and in the EBCDIC chart in one of the appendixes in my PoP - also on
> S/370 XA - from January 1987.

> > Wow, NULL must be a youngster...

> Quite likely since "his professor made this claim". After all I realize I worked
> on these matters back in the 60s and 70s - that is 30 years ago!
> Was NULL even born by then?

> regards Sven

Physical strength of the card as a reason for blanks....hmmm, I hadn't thought of
that.  That might explain the first 16 bytes (or should I say columns) having so
many blanks, but what of the last 64?  They could be anything, blank or not.

I realize that the whole concept of "cards" that permeates mainframe programming
comes from the punched cards used aeons ago.  Fixed length records, the continuation

mark in column 72, the blanks, the breaks in the EBCDIC alphabet, the packed decimal

formats, etc., all seem to from this.  Does anyone else get the impression that the
mainframe was built as a peripheral to the card reader, not the other way around?

Youngster?  Yeah I guess.



Wed, 25 Apr 2001 03:00:00 GMT  
 My professor made this claim...
Binary cards were used quite a bit on IBM 2nd generation mainframes, but
very rarely on 3rd generation mainframes.

Partly it was a character set issue.  On 2nd generation systems, the byte
was 6 bits, and you could get 2 bytes in one column.  On 3rd generation
systems, a byte contains 8-bits, so you can get only 1 1/2 bytes into
one column binary.  In addition, you had to correctly detect the card
was binary before it was read, and that represented a problem, which
was mostly avoided by not using it on 3rd generation systems.

Also, back in 2nd generation days, cards, well cared for, were probably
more reliable than tape, and possibly cheaper, as well.  This became less
true as the 60s progressed into the 70s.  In addition, cards did not suffer
from a multiplicity of formats, like tape drives in the second
generation era.

I, personally, never had any particular trouble with physical strength
issues with binary cards, unless they were deliberately "laced", which
even for program images was rare.  Non-binary cards, of course, never
punched more than 6 rows (out of 12).

Large mainframes, like the 709x machines, for example, could not be
considered periperhals of the unit record devices.  The main control
input was card images on tape built by a small system, typically a
1401, and print output was sent to tape and later printed on a 1401.

A very good argument can be made for the small mainframes.  It was no
accident --

1401 (computer system)
1402 (card reader-punch)
1403 (printer)

I always felt the EBCDIC coding sequence was rather arbitrary.  IBM had
the good sense, unlike the ASCII folks, to actually use 8 bits, and
not 7 bits, which still affects us today.  But the ASCII folks were
very paper tape oriented, I think, which I think is where the 7 bit
ideas came from.

On the other hand, the IBM standard object deck format seemed rather
dumb to me, too.  Even in 1967 or so when I started using it.

Well, this is a topic that deserves more discussion, but I literally
have to run.

-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Wed, 25 Apr 2001 03:00:00 GMT  
 My professor made this claim...
If you have access to a VM system, LINK to one of the HCPxxxxx mini-disks
and do a LISTFILE for 3CARD LOADER *

The sequence of the IPL was such that card 1 only contained 24 bytes.
A PSW and two CCWS. The two CCWs are READ commands to fetch the two
subsequent cards in the 3card loader scheme. The first CCW had command
and data chaining (although I've seen it without the data chain) turned
on. The second CCW had no flags except SLI - suppress incorrect length.
(The "silly" bit).

When channel/device end was presented from the ipl'ed unit, the PSW was
fetched and instruction execution commenced. The processor was taken
out of the load state and placed into the run state.

Quote:

> Does anyone still have the "3 card loader" that was used to IPL a text
> deck from the card reader?  I remember dis-assembling it some time
> around 1968.  As I recall, the first card only had an initial PSW and a
> couple CCWs, so the whole program was pretty small.  I can't remember if
> it did relocation or not, but possibly this is what the professor is
> thinking of.

> Bill Fenlason



Wed, 25 Apr 2001 03:00:00 GMT  
 My professor made this claim...
Hey!  I just looked on our VM system, and noted that '3CARD LOADER S' is
actually five (5) cards long!

...however, it's probably still only 3, measured in constant-1970 cards :-)
--

      IBM Research, Yorktown Heights



Fri, 27 Apr 2001 03:00:00 GMT  
 My professor made this claim...
That particular version [probably] has XA support in it as well as 370.
If you disassemble the thing, you'll find that it's actually pretty
clever in how it goes about doing its thing...


Quote:

> Hey!  I just looked on our VM system, and noted that '3CARD LOADER S' is
> actually five (5) cards long!

> ...however, it's probably still only 3, measured in constant-1970 cards :-)
> --

>       IBM Research, Yorktown Heights



Fri, 27 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:

> I always felt the EBCDIC coding sequence was rather arbitrary.

It may indeed have been arbitrary, but only in the sense that it was the
product of one mind, a design by a committee of one person, Gene Amdahl.

Fred Brooks, Jr. related that there was much discussion re the
assignment
of "graphics" [characters] to byte values - particularly the order of
the
special characters, but that the general overall design (which placed
the
special characters before the lower case alphabetic characters before
the
upper case alphabetic characters before the numeric characters) which
was
adopted by the System/360 Architecture Committee was the proposal made
by
Gene Amdahl.  One of the primary considerations was what the natural
sort
order should be, so lexicographers and librarians were consulted. In
that
respect, EBCDIC is the only "correct" coding sequence for so-called
Latin
character set graphics.  

The extra bit made available over what was then ASCII made it possible
to
assign the graphics in a symmetrical manner. Assigning the upper case
and
numeric graphics to the X'C0'-X'FF' quadrant makes it possible to test
in
one instruction if a valid, assigned byte value is standard
alphanumeric,
for example. A string that consists of valid, assigned, printable
graphic
charaters only can have the lower case characters folded to upper case
by
ORing them with (a string of) blanks; special characters remain
unchanged
by that process. You can't do that quickly with ASCII. Of course, this
is
now not all that important in practice - especially if the TR
instruction
can be used. Many originally empty EBCDIC code points have been filled
in
now with important, frequently-used graphics, but the design made room
to
do that available.

Of course, in hindsight, a DBCS should have been used, but that would
have
been judged as wasteful as using four digits to encode the year portion
of
a date ...

--
=========1=========2=========3=========4=========5=========6=========7==

~~~~~~~ ~~ ~~~~~    [remove the ".spam"]    ~~~~~~~~~~~~~~~~~~~     ~~~~
The two most common elements in the universe are Hydrogen and stupidity.
Unfortunately, the observed level of Hydrogen appears to be diminishing.
=========1=========2=========3=========4=========5=========6=========7==



Fri, 27 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:


> > I always felt the EBCDIC coding sequence was rather arbitrary.

> It may indeed have been arbitrary, but only in the sense that it was the
> product of one mind, a design by a committee of one person, Gene Amdahl.

I don't think that Gene had anything to do with the implementation of
the EBCDIC coding sequence. Can't be sure, but while I worked for him
for two years he talked about a lot of things in the past but never
that.

Where did Herman Hollerith (sp?) come in to play on this?



Sat, 28 Apr 2001 03:00:00 GMT  
 My professor made this claim...


: > I always felt the EBCDIC coding sequence was rather arbitrary.

: ... In
: that
: respect, EBCDIC is the only "correct" coding sequence for so-called
: Latin
: character set graphics.  

: Assigning the upper case
: and
: numeric graphics to the X'C0'-X'FF' quadrant makes it possible to test
: in
: one instruction if a valid, assigned byte value is standard
: alphanumeric,
: for example. A string that consists of valid, assigned, printable
: graphic
: charaters only can have the lower case characters folded to upper case
: by
: ORing them with (a string of) blanks; special characters remain
: unchanged
: by that process.

This is only true if your character set is restricted to old original
codepage 001 (USA, WP).  All modern "Latin character set" code pages
(e.g., CP037 USA/Canada CECP) contain *numerous* alphabetics that are
converted to upper case by ORing with x'20'.  For example, the lower case
alphabetics x'42'-x'49' when converted to upper case are x'62'-x'69'.
--
| Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
| Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

| 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |        
| Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Sat, 28 Apr 2001 03:00:00 GMT  
 My professor made this claim...
on VM/CMS check out  3CARD LOADER S2  

amazingly enough.. it's 5 cards!

----------


Quote:
>Does anyone still have the "3 card loader" that was used to IPL a text
>deck from the card reader?  I remember dis-assembling it some time
>around 1968.  As I recall, the first card only had an initial PSW and a
>couple CCWs, so the whole program was pretty small.  I can't remember if
>it did relocation or not, but possibly this is what the professor is
>thinking of.  

>Bill Fenlason



Sat, 28 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:

> Where did Herman Hollerith (sp?) come in to play on this?

He did not come into play anywhere on "this" -- the assignment of code
points to graphics ("characters") in the EBCDIC coding scheme.  EBCDIC
was an 8-bit alternative to the ASCII coding scheme that was originally
invented for and introduced with the IBM System/360 ca. 1965.  By that
time Mr. Hollerith was long gone from this life. Here is what my online
encyclopedia has to say about the gentleman:

: Hollerith, Herman, 1860-1929, American inventor; b. Buffalo, N.Y.
: He developed a system that used cards with punched holes to encode
: data, as well as machines to punch and tabulate the cards. In 1896
: he founded the Tabulating Machine Company, predecessor of the
: International Business Machines Company (IBM).

--
=========1=========2=========3=========4=========5=========6=========7==

~~~~~~~ ~~ ~~~~~    [remove the ".spam"]    ~~~~~~~~~~~~~~~~~~~     ~~~~
The two most common elements in the universe are Hydrogen and stupidity.
Unfortunately, the observed level of Hydrogen appears to be diminishing.
=========1=========2=========3=========4=========5=========6=========7==



Sat, 28 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:
> This is only true if your character set is restricted to old original
> codepage 001 (USA, WP).

Of course, which is what I was talking about: the EBCDIC character set
-- as originally conceived. After all, the point I was addressing was  
a statement made by Steve Myers that he felt that "the EBCDIC coding
sequence was rather arbitrary." My point was merely to show that, when
originally conceived, it was anything BUT "arbitrary." The symmetry in
the EBCDIC coding scheme, and the corresponding symmetry in the S/360
instruction set, were so anything but arbitrary that they occupied an
entire lecture for several years in Fred Brooks' Software Engineering
Laboratory course. Brooks, of course, made no secret of the inventor
of each of these: Gene Amdahl.

--
=========1=========2=========3=========4=========5=========6=========7==

~~~~~~~ ~~ ~~~~~    [remove the ".spam"]    ~~~~~~~~~~~~~~~~~~~     ~~~~
The two most common elements in the universe are Hydrogen and stupidity.
Unfortunately, the observed level of Hydrogen appears to be diminishing.
=========1=========2=========3=========4=========5=========6=========7==



Sat, 28 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:


> > Where did Herman Hollerith (sp?) come in to play on this?

> He did not come into play anywhere on "this"

Not so; the assignement of code points in EBCDIC is derived from the
assignements of punches to characters on the 80-column ("Holerith")
card, e.g., A-I are C1-C9 in EBCDIC because they are punched as 12-1
through 12-9.

--

Shmuel (Seymour J.) Metz
Reply to host nsf (dot) gov, user smetz



Sun, 29 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:
> A-I are C1-C9 in EBCDIC because they are punched as 12-1 through 12-9.

A-I on an IBM punched card (usually punched by an 026 keypunch machine)
were 12-1 thru 12-9 long before EBCDIC was conceived. It is natural for
the alphabetic characters to fall into sequence in the "card code" just
as it is natural for them to fall into sequence in ASCII, EBCDIC, etc.
Given that the punched card codes for the vast majority of the numbers
and letters and special characters were already determined when EBCDIC
(and the System/360) was being designed, it was natural for them to be
given similar (symmetrical) code points. That was exactly the point I
was making, but did not state explicitly in the message to which you
replied (I did state it more explicitly in another message). Hollerith
thus had something to do with EBCDIC, just as the designers of the IBM
7094 had something to do with the System/360. But, I interpreted the
question to which I was responding more literally ... in the sense that
the designers of the IBM 7094 did not have anything to do, directly,
with the S/360 (of course they did, indirectly). But, Mr. Hollerith was
not around when the S/360 or EBCDIC was hatched, which was the question
that I was trying to answer, originally (a question which I interpreted
quite literally, apparently to the dismay of at least a couple of folks
here).  Apparently, the original questioner and, now I see, potentially
you were quite aware of who Mr. Hollerith was; in every other instance
of that question arising, the persons asking the question were not, in
fact, aware of his relationship to the 80-column card. I suppose by the
same logic, we have Mr. Hollerith to "blame" for terminals and PCs (in
their usual text mode, at least) having 80 columns. Of course, I under-
stand the connection, but when I am asked today why a "DOS prompt" is
80 characters by 24 (or 25) lines, it has never occurred to me to say
that Mr. Hollerith is responsible. The 2260-2, the 3270, and the IBM PC
could just as well have had 100 or 128 (or, better yet, 132+) positions
per displayed line; however, 80 was judged adequate and consistent with
the precedent. Had the precedent not been adhered to, we'd be having a
very different discussion.  I attribute the decision to adhere to a
precedent to the person who made the decision to do so, not to the
person who conceived the original idea that became the precedent: just
a different way of thinking about the world when it's time to answer a
question about who did what when. Thus, by my world view, Mr. Hollerith
didn't have anything to do with EBCDIC code point assignments -- after
all, several alternatives were discussed, and any one could have been
chosen, but the one we have is the one that *was* chosen (and not by
Mr. Hollerith).  If you feel that I have slighted Mr. Hollerith's real
contribution, then I most sincerely apologize.

--
=========1=========2=========3=========4=========5=========6=========7==
The two most common elements in the universe are Hydrogen and stupidity.
                                                        - Harlan Ellison
Unfortunately, the observed level of Hydrogen appears to be diminishing.

=========1=========2=========3=========4=========5=========6=========7==



Sun, 29 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:
> A-I are C1-C9 in EBCDIC because they are punched as 12-1 through 12-9.

i WOULD LIKE TO ADD THAT
Robert Rayhawk



Sat, 12 May 2001 03:00:00 GMT  
 My professor made this claim...

Quote:
> A-I are C1-C9 in EBCDIC because they are punched as 12-1 through 12-9.

I would like to add a minor point, which is probably clear to most readers, but
for folks like me it takes a little study to see the point.

The derrivation of the EBCDIC encodings from Hollerith card encodings, explains
not only the assignments of values, but it explains the gaps in the alphabetic
sequence.

The Hollerith cards are primitive, if we consider hexadecimal orthogonality as
the indicator of modernism.  The 80-column Hollerith code table reflects the
physical reality of the adding machines that the tabulating machinery was
intended to replace.

The very best example I ever saw of this phenomena was a ceramic vase from
ancient Geeece that was formed in a shape and surfase that mimicked the older
bronze vases with dummy fittings (almost like nuts and bolts) around the top
rim. Maybe people trusted this more, or were comforted by the familiarity.

The Hollerith codes for the numerics are exact analogs to the key selections of
an old adding machine that had columns and rows of numbers
The analog is exact.  

The alphabetics are an extension of this symetric table. On the quasi decimal
cards (not on the binary machines), the C-9 is followed by D-1. On an adding
machine with columns of numbers it is not necessary to punch zero (not even
intermediate zero); because the function of zero as a place holder is not
needed in hardware where the place is fixed spatially. And although D9 would
seem to follow E1, it is worth noting that Z being at the bottom reflects a
table that was built from the bottom of the row/column matrix of quasi-decimal
values. It is as though it was a big adding machine style typewriter. The
'lower keys' would be easier to get to, so stack an incomplete column from the
bottom (comparable to a 'pop- up' menu as opposed to a 'pull-down' menu).

The Hollerith cards and machinery were used to compile a U.S. census that was
running very late managed by only traditional methods. The method used replaced
adding machines that are just about depicted in the code set.

Although ASCI breaks free of the syncopated encoding partly, it is not free of
artifacts from the past.  The numerics start at x'31', not at x'30', and are
followed by special character filler, so that the alphabetics start in the next
column. And the cipher-A is not x'40' but is x'41'. The alphas could have as
easily been placed at x'40', and still been able to exploit logical operations
to transform to/from lower/upper case.

To a very small extent, and in a really faint way, the placement of cipher-A at
x'41' in _ASCII_ still echoes the non-entry of zero on fixed column arithmetic
machinery of the 19-th century.

Best Wishes,

Robert Rayhawk



Sat, 12 May 2001 03:00:00 GMT  
 
 [ 33 post ]  Go to page: [1] [2] [3]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software