Subject: On posting shepherd writeups in the datatracker

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Oct 2013 12:00:13 -0400

When certain things are posted in the datatracker, the tracker does
not wrap the lines, so long lines require a lot of left-right
scrolling in order to read them.  There's a problem ticket open that
asks for a fix for this, but we're not there yet.

Unfortunately, the shepherd writeups are subject to this problem, and
are also among the things that are most likely to have long lines.

So:
When you post the shepherd writeup into the datatracker, please first
re-flow the text to a reasonable width.

Thanks,
Barry

---

From: Warren Kumari <[email-masked]>
Date: Fri, 4 Oct 2013 13:12:01 -0400

Doh.

I *just* posted one a few hours ago, with really long lines...

Oh well..

W

Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

> On Oct 4, 2013, at 12:00 PM, Barry Leiba <[email-masked]> wrote:
>

---

From: Pete Resnick <[email-masked]>
Date: Fri, 4 Oct 2013 12:40:56 -0500

They are editable, are they not?

pr

On 10/4/13 12:12 PM, Warren Kumari wrote:
>> On Oct 4, 2013, at 12:00 PM, Barry Leiba<[email-masked]>  wrote:
>>

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 04 Oct 2013 20:08:35 +0200

> re-flow the text to a reasonable width.
Please define "reasonable width". Would 80 be ok?

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Oct 2013 18:25:26 +0000

> Please define "reasonable width". Would 80 be ok?

I recommend a right margin at 72 characters.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 4 Oct 2013 14:30:12 -0400

> I recommend a right margin at 72 characters.

No way, dude, you need to be able to use all 80 columns on those punch
cards for your COBOL code.

http://whatyearisit.info/img/what_year_is_it.jpg

</sarcasm>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 4 Oct 2013 14:36:08 -0400

Ah, but columns 73-80 are ignored. 

On Oct 4, 2013, at 2:30 PM, Richard Barnes <[email-masked]> wrote:

> No way, dude, you need to be able to use all 80 columns on those punch cards for your COBOL code.
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Oct 2013 12:17:29 -0700

Card sequence number.  Not ignored...

d/
--
Dave Crocker
bbiw.net

via mobile

---

From: Brian Rosen <[email-masked]>
Date: Fri, 4 Oct 2013 15:41:04 -0400

http://supportline.microfocus.com/documentation/books/sx20books/lrintr.htm

In fixed format, the COBOL source format divides each COBOL source record into 72 columns. These columns are used in the following way:

Columns 1 - 6	Sequence number
Column 7	Indicator area
Column 8 - 11	Area A
Columns 12 - 72	Area B
 A COBOL source record can extend up to 80 columns in length. The contents of columns 73 to 80 are ignored by the COBOL system.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Oct 2013 19:46:32 +0000

>  A COBOL source record can extend up to 80 columns in length. The contents of columns 73 to 80 are ignored by the COBOL system.

Excellent.  I'm glad we had this talk.   So do we have consensus, then, that in the future shepherd writeups shall be submitted on 80-column punch cards with optional sequence numbers in columns 73-80?

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 04 Oct 2013 15:11:34 -0500

> Excellent.  I'm glad we had this talk.   So do we have consensus, then, that in the future shepherd writeups shall be submitted on 80-column punch cards with optional sequence numbers in columns 73…

Well, I suppose that WOULD reduce the telechat reading list, at least 
for a while :p

Spencer

---

From: "Black, David" <[email-masked]>
Date: Fri, 4 Oct 2013 17:30:02 -0400

Absolutely - we have to support virtual card numbers just in case a stack of virtual cards happens to fall on the virtual floor :-).

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ted Lemon
> Sent: Friday, October 04, 2013 3:47 PM
> To: Brian Rosen
> Cc: [email-masked]; Barry Leiba
> >  A COBOL source record can extend up to 80 columns in length. The contents
> of columns 73 to 80 are ignored by the COBOL system.
> 
> Excellent.  I'm glad we had this talk.   So do we have consensus, then, that
> in the future shepherd writeups shall be submitted on 80-column punch cards
> with optional sequence numbers in columns 73-80?
>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 04 Oct 2013 21:09:18 -0400

It was Fortran that used 73-80 as sequence number.

On 04/10/2013 3:41 PM, Brian Rosen wrote:
> In fixed format, the COBOL source format divides each COBOL source
> record into 72 columns. These columns are used in the following way:
>
>
>   A COBOL source record can extend up to 80 columns in length. The
> contents of columns 73 to 80 are ignored by the COBOL system.
>
> On Oct 4, 2013, at 3:17 PM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
>
...

---

From: Dave Crocker <[email-masked]>
Date: Fri, 04 Oct 2013 18:28:52 -0700

> It was Fortran that used 73-80 as sequence number.

right.  my first training was Fortran II.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Yoav Nir <[email-masked]>
Date: Sat, 5 Oct 2013 06:54:07 +0000

> right.  my first training was Fortran II.

Luckily, us cool kids who learned PL/1 could be trusted to not let our card stack fall.

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 6 Oct 2013 06:52:37 +0000

Why COBOL ?

FORTRAN cards had columns 1-6 for line numbers, 7 as a continuation character, statements up to 72,
and then 73-80 ignored.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 04 October, 2013 22:41
To: Dave Crocker
Cc: [email-masked]; Barry Leiba
Subject: Re: On posting shepherd writeups in the datatracker

Columns 1 - 6

Sequence number

Column 7

Indicator area

Column 8 - 11

Area A

Columns 12 - 72

Area B

[http://supportline.microfocus.com/documentation/books/sx20books/dialm.gif] A COBOL source record can extend up to 80 columns in length. The contents of columns 73 to 80 are ignored by the COBOL system.
On Oct 4, 2013, at 3:17 PM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:

d/
--
Dave Crocker
bbiw.net<http://bbiw.net>

via mobile

-----Original Message-----
From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
To: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Barry Leiba <[email-masked]<mailto:[email-masked]>>
Sent: Fri, 04 Oct 2013 11:36 AM
Subject: Re: On posting shepherd writeups in the datatracker

On Oct 4, 2013, at 2:30 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Oct 4, 2013 at 2:25 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
On Oct 4, 2013, at 2:08 PM, Tomek Mrugalski <[email-masked]<mailto:[email-masked]>> wrote:

</sarcasm>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 06 Oct 2013 16:31:12 -0400

> Why COBOL ?

No reason. It wasn't unique to COBOL. As you say below, Fortran used the 
same convention. But it wasn't unique to them.

"Many early programming languages, including Fortran, Cobol and the 
various IBM assembler languages, used only the first 72 columns of a 
card — a tradition that traces back to the IBM 711 card reader used on 
the IBM 704/709/7090/7094 series (especially the IBM 704, the first 
mass-produced computer with floating point arithmetic hardware), which 
could only read 72 of the 80 columns in one pass. Columns 73-80 were 
ignored by the compilers and could be used for identification or a 
sequence number so that if the card deck was dropped it could be 
restored to its proper order using a card sorter. (An alternative, 
imperfect but commonly employed technique to maintain proper card order 
was to draw one or more diagonal stripes across the top edge of all the 
cards in a deck.)"

(http://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era)

> character, statements up to 72,

1-6 was for "statement numbers", not line numbers.
These were predecessors to labels. Most statements didn't have them, and 
they were not expected to be ordered in any way.

73-80 were ignored by the compiler for purposes of language parsing, but 
by convention *could* be used for sequence numbering the card deck, so 
that it could be sorted back into order after having been scrambled.

This made sense for punched cards, which were fixed width, abetted by 
card punches that made it easy to fill in the sequence numbers while 
keying in the cards.

It of course made no sense once programs moved from cards to files and 
text editors.

Basic introduced line numbers, and was conceptually scrambled by using 
them both for line sequencing and as statement labels.

	Thanks,
	Paul

> Y(J)S
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Brian Rosen
> *Sent:* 04 October, 2013 22:41
> *To:* Dave Crocker
> *Cc:* [email-masked]; Barry Leiba
> *Subject:* Re: On posting shepherd writeups in the datatracker
>
> bbiw.net <http://bbiw.net>
>
> via mobile
>
>
>
> From: Brian Rosen <[email-masked] <mailto:[email-masked]>>
> To: Richard Barnes <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, Barry Leiba <[email-masked]
> <mailto:[email-masked]>>
> On Oct 4, 2013, at 2:08 PM, Tomek Mrugalski <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 7 Oct 2013 14:30:02 -0400

Save columns 72-80 for the sequence number.

- Ralph, who can't find his 029 keypunch drum card

On Oct 4, 2013, at 2:08 PM, Tomek Mrugalski <[email-masked]> wrote:

> _______________________________________________
> BOFChairs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bofchairs

---

From: Ralph Droms <[email-masked]>
Date: Mon, 7 Oct 2013 14:32:21 -0400

True story - I once received an error message from an OS whose identity I will leave anonymous to the effect of "Virtual card punch overflow.  Operator intervention required."

- Ralph

---

From: Brian Rosen <[email-masked]>
Date: Mon, 7 Oct 2013 14:50:00 -0400

Ah, yes FORTRAN used 1-6 for statement numbers, and you only used a statement number when you need to reference it for a IF, GOTO or other program flow changes.  Sequence numbers were in 72-80 if you bothered (I never did).

But COBOL routinely numbered every line of code, and columns 1-6 were called (and used for) sequence numbers.

Now, to be sure, because of continuation and comment lines, I vaguely recall some programmers putting another sequence number in 72-80 so they could sort the deck if it was dropped.
The problem there was, again, fuzzy memory, but it printed those numbers, and made the printouts hard to follow.

Ralph, I'd have to dig through a box, but I "might" have an drum card for FORTRAN.   I'm sure I have a lot more keyboard time on an 026 than an 029.  As I recall, the drum cards were the same.

Brian

On Oct 6, 2013, at 4:31 PM, Paul Kyzivat <[email-masked]> wrote:

> No reason. It wasn't unique to COBOL. As you say below, Fortran used the same convention. But it wasn't unique to them.
> 
> "Many early programming languages, including Fortran, Cobol and the various IBM assembler languages, used only the first 72 columns of a card — a tradition that traces back to the IBM 711 card reader used on the IBM 704/709/7090/7094 series (especially the IBM 704, the first mass-produced computer with floating point arithmetic hardware), which could only read 72 of the 80 columns in one pass. Columns 73-80 were ignored by the compilers and could be used for identification or a sequence number so that if the card deck was dropped it could be restored to its proper order using a card sorter. (An alternative, imperfect but commonly employed technique to maintain proper card order was to draw one or more diagonal stripes across the top edge of all the cards in a deck.)"
> 
> These were predecessors to labels. Most statements didn't have them, and they were not expected to be ordered in any way.
> 
> 73-80 were ignored by the compiler for purposes of language parsing, but by convention *could* be used for sequence numbering the card deck, so that it could be sorted back into order after having been scrambled.
> 
> This made sense for punched cards, which were fixed width, abetted by card punches that made it easy to fill in the sequence numbers while keying in the cards.
> 
> It of course made no sense once programs moved from cards to files and text editors.
> 
> Basic introduced line numbers, and was conceptually scrambled by using them both for line sequencing and as statement labels.
> 
> 	Thanks,
> 	Paul
> 
>> Y(J)S
>>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Oct 2013 12:00:16 -0700

> Now, to be sure, because of continuation and comment lines, I vaguely recall some programmers putting another sequence number in 72-80 so they could sort the deck if it was dropped.

When I was 12 (1962) I spent some of the summer learning to program, 
from an unpublished book my brother Steve co-authored.  It explained 
about card sequence numbers in 72-80, as you describe.  So I did them.

I showed my brother my first punch deck (Fortran II, to print out 
squares, cubes, and their roots) and upon carefully inspect it, he noted 
and commented upon my diligent sequence numbers.

He then unceremoniously dropped the deck 5 feet to the floor.

When I got my breath back and stooped to retrieve the deck, he commented 
that very few cards ever actually get out of order...

d/

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Oct 2013 16:04:50 -0400

Ralph,

Along the lines of the jammed virtual card punch ...

In the early 70's I found an error message for the sort/merge app on a 
CDC 3300.
The message stated that an end-of-tape marker had been encountered 
during a merge pass.
It went on to note that since intermediate merge files were always on 
disk, this error
should not have occurred, and thus the sort/merge would be terminated 
abnormally :-).

Steve

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Oct 2013 22:07:42 +0000

On Oct 7, 2013, at 11:04 PM, Stephen Kent <[email-masked]>
 wrote:

> In the early 70's I found an error message for the sort/merge app on a CDC 3300.
> The message stated that an end-of-tape marker had been encountered during a merge pass.
> It went on to note that since intermediate merge files were always on disk, this error
> should not have occurred, and thus the sort/merge would be terminated abnormally :-).

In the mid-90s I was working as a mainframe system administrator/programmer. I had a VM user call me about a paper jam. VM is a virtualized environment, where every user gets a virtual mainframe complete with everything a mainframe needs: a virtual card reader, a virtual card punch, a virtual printer, a virtual console, and a virtual disk. A user can print to their virtual printer, and can issue a hypervisor command to move the virtual printout to another virtual machine that can move it to a physical printer. It turned out that it was the virtual printer that got the paper jam. Investigating further, his virtual printer was an IBM 1403 ([1]), and he was printing color graphics on it. So I thought, what if I replace his printer with a more expensive one? Like the 3800 ([2]). It did solve the paper jam. Luckily, virtual printers don't cost as much as real ones :-)

Yoav

[1] http://www.columbia.edu/cu/computinghistory/1403.html
[2] http://en.wikipedia.org/wiki/IBM_3800

---

From: Tom Taylor <[email-masked]>
Date: Tue, 08 Oct 2013 08:33:51 -0400

Reminds me of the fanciful additional instruction set for the IBM /360 
Model 67. A few of them, echoing the real instruction set:
  - Execute programmer
  - Branch on sleepy operator
  - Halt and catch fire
  - Beat drum

---

From: "Bradner, Scott" <[email-masked]>
Date: Tue, 8 Oct 2013 12:39:30 +0000

see http://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html

Scott 

On Oct 8, 2013, at 8:33 AM, Tom Taylor <[email-masked]> wrote:

> Reminds me of the fanciful additional instruction set for the IBM /360 Model 67. A few of them, echoing the real instruction set:
> - Execute programmer

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 08 Oct 2013 23:15:28 +0200

> Save columns 72-80 for the sequence number.
Shouldn't that be 73-80? Both COBOL and FORTRAN seem to ignore columns
73 and up. A character in column 72 should be ok.

Tomek

p.s.
I was secretly hoping that my question about reasonable width would
trigger some interesting comments. I got much more than I ever hoped for.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 8 Oct 2013 17:16:31 -0400

Just demonstrating the classic CS off-by-one error...

- Ralph