| Re: Versioning file systems [message #386402] |
Tue, 27 August 2019 08:33  |
|
|
Originally posted by: Bob Eager
On Tue, 27 Aug 2019 09:15:03 +0000, Huge wrote:
> IIRC, Files-11 on DEC operating systems (and I'm mainly thinking of
> RSX11/M here) supported version numbers for files. Again, IIRC,
> you could have a file called;
>
> TEST.DAT;1
>
> And if you edited that, you ended up with
>
> TEST.DAT;1 TEST.DAT;2
>
> And so on.
>
> I found this extremely useful, to the extent that I've kinda implemented
> it with a lot of the day to day utilities I use in Linux.
>
> But ... why did it never catch on? One obvious disadvantage is that
> disks fill up really quickly if you keep every version of every file you
> ever change. I've never seen another file system that implements it
> (although I know nada about mainframes. Are Generation Data Groups on
> IBM the same kind of thing?)
I agree. Very useful. A load of people hated it because you ended using
all of your disk quota (this was on the ill fated VME/K, though). THere
was also (typical ICL) no easy means of saying 'delete all but the N most
recent versions', although we ended up writing kludgy utilities for that.
When I set up our VMS cluster, I put a default version limit of 3 on the
file system. So if you created a fourth version, it deleted the oldest
one. People liked that, it worked well, and you could override it if you
wanted to.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Versioning file systems [message #386406 is a reply to message #386402] |
Tue, 27 August 2019 09:59  |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Bob Eager <news0073@eager.cx> wrote:
> On Tue, 27 Aug 2019 09:15:03 +0000, Huge wrote:
>
>> IIRC, Files-11 on DEC operating systems (and I'm mainly thinking of
>> RSX11/M here) supported version numbers for files. Again, IIRC,
>> you could have a file called;
>>
>> TEST.DAT;1
>>
>> And if you edited that, you ended up with
>>
>> TEST.DAT;1 TEST.DAT;2
>>
>> And so on.
>>
>> I found this extremely useful, to the extent that I've kinda implemented
>> it with a lot of the day to day utilities I use in Linux.
>>
>> But ... why did it never catch on? One obvious disadvantage is that
>> disks fill up really quickly if you keep every version of every file you
>> ever change. I've never seen another file system that implements it
>> (although I know nada about mainframes. Are Generation Data Groups on
>> IBM the same kind of thing?)
>
> I agree. Very useful. A load of people hated it because you ended using
> all of your disk quota (this was on the ill fated VME/K, though). THere
> was also (typical ICL) no easy means of saying 'delete all but the N most
> recent versions', although we ended up writing kludgy utilities for that.
>
> When I set up our VMS cluster, I put a default version limit of 3 on the
> file system. So if you created a fourth version, it deleted the oldest
> one. People liked that, it worked well, and you could override it if you
> wanted to.
>
SET FILE/VERSIONS= maybe?
--
Pete
|
|
|
|
| Re: Versioning file systems [message #386413 is a reply to message #386406] |
Tue, 27 August 2019 11:06 |
|
|
Originally posted by: Bob Eager
On Tue, 27 Aug 2019 06:59:52 -0700, Peter Flass wrote:
> Bob Eager <news0073@eager.cx> wrote:
>> On Tue, 27 Aug 2019 09:15:03 +0000, Huge wrote:
>>
>>> IIRC, Files-11 on DEC operating systems (and I'm mainly thinking of
>>> RSX11/M here) supported version numbers for files. Again, IIRC,
>>> you could have a file called;
>>>
>>> TEST.DAT;1
>>>
>>> And if you edited that, you ended up with
>>>
>>> TEST.DAT;1 TEST.DAT;2
>>>
>>> And so on.
>>>
>>> I found this extremely useful, to the extent that I've kinda
>>> implemented it with a lot of the day to day utilities I use in Linux.
>>>
>>> But ... why did it never catch on? One obvious disadvantage is that
>>> disks fill up really quickly if you keep every version of every file
>>> you ever change. I've never seen another file system that implements
>>> it (although I know nada about mainframes. Are Generation Data Groups
>>> on IBM the same kind of thing?)
>>
>> I agree. Very useful. A load of people hated it because you ended using
>> all of your disk quota (this was on the ill fated VME/K, though). THere
>> was also (typical ICL) no easy means of saying 'delete all but the N
>> most recent versions', although we ended up writing kludgy utilities
>> for that.
>>
>> When I set up our VMS cluster, I put a default version limit of 3 on
>> the file system. So if you created a fourth version, it deleted the
>> oldest one. People liked that, it worked well, and you could override
>> it if you wanted to.
>>
>>
> SET FILE/VERSIONS= maybe?
Indeed. I did that on the root user directiories, and it propagated .
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Versioning file systems [message #386431 is a reply to message #386402] |
Tue, 27 August 2019 14:30 |
|
|
Originally posted by: Andy Walker
On 27/08/2019 13:33, Bob Eager wrote:
[Versioning file systems:]
> When I set up our VMS cluster, I put a default version limit of 3 on the
> file system. So if you created a fourth version, it deleted the oldest
> one. People liked that, it worked well, [...].
Not universally. That was how our computing centre implemented
it on our mainframe [ICL 1906A running George 3, 1972]. The problem was
that quite frequently something went wrong and [eg] the machine crashed,
so somehow an empty file got stored over the original. User comes to
edit the file; shock, horror, my useful file has disappeared! Closes
the edit, goes to the help desk, "My file has disappeared!" Help-droid
goes to terminal, "So, what did you do?" "I tried to edit my file, like
this, and it was empty." Sadly, this is now the third empty version of
the file [initial wrong file and two edits], and so the useful version
is automatically erased. If you were very lucky, an old version might
exist on some dump tape somewhere, and the operators would, with much
grumbling, manage to restore it for the user.
The computing centre used to issue regular bulletins, and the
above scenario was common enough that they wrote an article entitled
"What The User Should Have Done", explaining how any sensible person
should have known not to close the edit, and certainly not to show
the staff what they had done. It seems never to have occurred to them
that the computer was perfectly capable of detecting empty files and
could have rescued this situation in several obvious ways without the
need for all the palaver.
From then on, as users, we became used to saying to each other
"What the user should have done ..." every time a misfeature of the
operating system or the centre's version of it caused problems. It
is still a catch-phrase among our old-timers. Geo3 in general was
fine, and there were parts of it that we missed when we got hold of
Unix. But in general, it was just sooo much better to be masters of
our own fate, and independent of the centre.
--
Andy Walker,
Nottingham.
|
|
|
|
| Re: Versioning file systems [message #386437 is a reply to message #386413] |
Tue, 27 August 2019 14:43 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Bob Eager <news0073@eager.cx> wrote:
> On Tue, 27 Aug 2019 06:59:52 -0700, Peter Flass wrote:
>
>> Bob Eager <news0073@eager.cx> wrote:
>>> On Tue, 27 Aug 2019 09:15:03 +0000, Huge wrote:
>>>
>>>> IIRC, Files-11 on DEC operating systems (and I'm mainly thinking of
>>>> RSX11/M here) supported version numbers for files. Again, IIRC,
>>>> you could have a file called;
>>>>
>>>> TEST.DAT;1
>>>>
>>>> And if you edited that, you ended up with
>>>>
>>>> TEST.DAT;1 TEST.DAT;2
>>>>
>>>> And so on.
>>>>
>>>> I found this extremely useful, to the extent that I've kinda
>>>> implemented it with a lot of the day to day utilities I use in Linux.
>>>>
>>>> But ... why did it never catch on? One obvious disadvantage is that
>>>> disks fill up really quickly if you keep every version of every file
>>>> you ever change. I've never seen another file system that implements
>>>> it (although I know nada about mainframes. Are Generation Data Groups
>>>> on IBM the same kind of thing?)
>>>
>>> I agree. Very useful. A load of people hated it because you ended using
>>> all of your disk quota (this was on the ill fated VME/K, though). THere
>>> was also (typical ICL) no easy means of saying 'delete all but the N
>>> most recent versions', although we ended up writing kludgy utilities
>>> for that.
>>>
>>> When I set up our VMS cluster, I put a default version limit of 3 on
>>> the file system. So if you created a fourth version, it deleted the
>>> oldest one. People liked that, it worked well, and you could override
>>> it if you wanted to.
>>>
>>>
>> SET FILE/VERSIONS= maybe?
>
> Indeed. I did that on the root user directiories, and it propagated .
>
Amazing the bits I remember. I last used VMS maybe 25 years ago, but some
of the commands apparently stuck.
--
Pete
|
|
|
|
| Re: Versioning file systems [message #386447 is a reply to message #386431] |
Tue, 27 August 2019 16:30 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Andy Walker <anw@cuboid.co.uk> wrote:
> On 27/08/2019 13:33, Bob Eager wrote:
> [Versioning file systems:]
>> When I set up our VMS cluster, I put a default version limit of 3 on the
>> file system. So if you created a fourth version, it deleted the oldest
>> one. People liked that, it worked well, [...].
>
> Not universally. That was how our computing centre implemented
> it on our mainframe [ICL 1906A running George 3, 1972]. The problem was
> that quite frequently something went wrong and [eg] the machine crashed,
> so somehow an empty file got stored over the original. User comes to
> edit the file; shock, horror, my useful file has disappeared! Closes
> the edit, goes to the help desk, "My file has disappeared!" Help-droid
> goes to terminal, "So, what did you do?" "I tried to edit my file, like
> this, and it was empty." Sadly, this is now the third empty version of
> the file [initial wrong file and two edits], and so the useful version
> is automatically erased. If you were very lucky, an old version might
> exist on some dump tape somewhere, and the operators would, with much
> grumbling, manage to restore it for the user.
Shouldn’t have to depend on luck. Everything should be backed up nightly
and multiple backup versions retained. Fortunately, as a sysprog I didn’t
have to ask anyone, but I can recall times I had to go back three
generations of backup to recover a file.
--
Pete
|
|
|
|
| Re: Versioning file systems [message #386490 is a reply to message #386447] |
Wed, 28 August 2019 12:30 |
|
|
Originally posted by: Andy Walker
On 27/08/2019 21:30, Peter Flass wrote:
>> [...] Sadly, this is now the third empty version of
>> the file [initial wrong file and two edits], and so the useful version
>> is automatically erased. If you were very lucky, an old version might
>> exist on some dump tape somewhere, and the operators would, with much
>> grumbling, manage to restore it for the user.
> Shouldn’t have to depend on luck. Everything should be backed up nightly
> and multiple backup versions retained.
(a) That doesn't help with "today"'s work, which may well have
amounted to hours sitting at a terminal [in those days, access to which
was like gold dust -- you were expected to sit there typing or else
those in the queue would be muttering behind your back].
(b) A full nightly dump would have been much too expensive,
given the ratio of "old" files to "new". There was an incremental
dump every night, and I expect there was some cycle of full dumps of
parts of the file system [eg, Science Faculty dumped every Wednesday,
Engineering every Thursday, external users every Friday, ...]. They
had rooms full of mag tapes, and some stored off-site. AFAIR, if you
wanted a non-current file, the operators had to trudge off and get
it, anything from ten minutes to several hours.
> Fortunately, as a sysprog I didn’t
> have to ask anyone, but I can recall times I had to go back three
> generations of backup to recover a file.
Even quite recently, I've had occasions when a file was
somehow corrupted, and I've had to go back to the version that I
copied into a compressed tar file several computers ago. Luckily,
every new computer I've had since the 1980s has had enough more
disc space than its predecessor that it's been possible to keep a
complete copy of all my old files!
--
Andy Walker,
Nottingham.
|
|
|
|
| Re: Versioning file systems [message #386494 is a reply to message #386490] |
Wed, 28 August 2019 13:52 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Andy Walker <anw@cuboid.co.uk> wrote:
> On 27/08/2019 21:30, Peter Flass wrote:
>>> [...] Sadly, this is now the third empty version of
>>> the file [initial wrong file and two edits], and so the useful version
>>> is automatically erased. If you were very lucky, an old version might
>>> exist on some dump tape somewhere, and the operators would, with much
>>> grumbling, manage to restore it for the user.
>> Shouldn’t have to depend on luck. Everything should be backed up nightly
>> and multiple backup versions retained.
>
> (a) That doesn't help with "today"'s work, which may well have
> amounted to hours sitting at a terminal [in those days, access to which
> was like gold dust -- you were expected to sit there typing or else
> those in the queue would be muttering behind your back].
If I know I’m going to do extensive work on a program I make a copy before
I start, or tar the whole directory. As we’ve discussed, most editors let
you back out your changes one-by-one.
>
> (b) A full nightly dump would have been much too expensive,
> given the ratio of "old" files to "new". There was an incremental
> dump every night, and I expect there was some cycle of full dumps of
> parts of the file system [eg, Science Faculty dumped every Wednesday,
> Engineering every Thursday, external users every Friday, ...]. They
> had rooms full of mag tapes, and some stored off-site. AFAIR, if you
> wanted a non-current file, the operators had to trudge off and get
> it, anything from ten minutes to several hours.
These days have it’s much quicker - snapshot to another set of DASD,
assuming you have enough. Before that HSM made incremental backups easy.
Specify how many backup copies you want to retain and it happens
automatically.
>
>> Fortunately, as a sysprog I didn’t
>> have to ask anyone, but I can recall times I had to go back three
>> generations of backup to recover a file.
>
> Even quite recently, I've had occasions when a file was
> somehow corrupted, and I've had to go back to the version that I
> copied into a compressed tar file several computers ago. Luckily,
> every new computer I've had since the 1980s has had enough more
> disc space than its predecessor that it's been possible to keep a
> complete copy of all my old files!
>
--
Pete
|
|
|
|
| Re: Versioning file systems [message #386497 is a reply to message #386494] |
Wed, 28 August 2019 14:19 |
|
|
Originally posted by: Andy Walker
On 28/08/2019 18:52, Peter Flass wrote:
> Andy Walker <anw@cuboid.co.uk> wrote:
>> On 27/08/2019 21:30, Peter Flass wrote:
>>>> [...] Sadly, this is now the third empty version of
>>>> the file [initial wrong file and two edits], and so the useful version
>>>> is automatically erased. If you were very lucky, an old version might
>>>> exist on some dump tape somewhere, and the operators would, with much
>>>> grumbling, manage to restore it for the user.
>>> Shouldn’t have to depend on luck. Everything should be backed up nightly
>>> and multiple backup versions retained.
>> (a) That doesn't help with "today"'s work, which may well have
>> amounted to hours sitting at a terminal [in those days, access to which
>> was like gold dust -- you were expected to sit there typing or else
>> those in the queue would be muttering behind your back].
> If I know I’m going to do extensive work on a program I make a copy before
> I start, or tar the whole directory. As we’ve discussed, most editors let
> you back out your changes one-by-one.
That's back to "What the user should have done ..." territory.
This was a university with several thousand users, the vast majority
of whom knew absolutely nothing beyond a few canned recipes for how
to do some simple things. They were told that the system kept old
versions; as in the scenario discussed, that didn't always work.
Keeping copies doesn't help with new programs, and saving regularly
doesn't solve the "three empty files and your work has gone" case
being discussed. There is also the problem of saving multiple copies
clagging up your [very limited] space allocation -- in an era when
entire departments might be allowed a megabyte or so in total.
As for editors, the whole concept of file systems and editors
was relatively new in those days. In 1972, we could scarcely conceive
that an automated system could allocate space on tape [no discs!] as
well as a human. As for editors, those too were quite new. I never
used one before 1972; if you wanted to change your program, you
punched some new cards or spliced in some new paper tape. Small
changes were often made by hand punch. I never saw an editor that
allowed you to back out changes until I wrote my own. Even after
1972, I kept almost all my own programs on paper tape, until we
got Unix and had direct access to [physically large but logically
small!] discs.
--
Andy Walker,
Nottingham.
|
|
|
|
| Re: Versioning file systems [message #386501 is a reply to message #386497] |
Wed, 28 August 2019 18:02 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Andy Walker <anw@cuboid.co.uk> wrote:
> [snip]
> As for editors, the whole concept of file systems and editors
> was relatively new in those days. In 1972, we could scarcely conceive
> that an automated system could allocate space on tape [no discs!] as
> well as a human. As for editors, those too were quite new. I never
> used one before 1972; if you wanted to change your program, you
> punched some new cards or spliced in some new paper tape. Small
> changes were often made by hand punch. I never saw an editor that
> allowed you to back out changes until I wrote my own. Even after
> 1972, I kept almost all my own programs on paper tape, until we
> got Unix and had direct access to [physically large but logically
> small!] discs.
>
Cards are their own backup. Unless they become separated and blow out a car
window it’s usually possible to reconstruct the deck. I suppose you could
blow them up. It’s almost impossible to incinerate a deck of cards. Even a
card jam on a 2501 that shoots cards all over the room is recoverable. The
problems all started when we moved away from cards.
--
Pete
|
|
|
|
| Re: Versioning file systems [message #386503 is a reply to message #386501] |
Wed, 28 August 2019 18:56 |
|
|
Originally posted by: Bob Eager
On Wed, 28 Aug 2019 15:02:14 -0700, Peter Flass wrote:
> Andy Walker <anw@cuboid.co.uk> wrote:
>> [snip]
>> As for editors, the whole concept of file systems and editors
>> was relatively new in those days. In 1972, we could scarcely conceive
>> that an automated system could allocate space on tape [no discs!] as
>> well as a human. As for editors, those too were quite new. I never
>> used one before 1972; if you wanted to change your program, you
>> punched some new cards or spliced in some new paper tape. Small
>> changes were often made by hand punch. I never saw an editor that
>> allowed you to back out changes until I wrote my own. Even after 1972,
>> I kept almost all my own programs on paper tape, until we got Unix and
>> had direct access to [physically large but logically small!] discs.
>>
>>
> Cards are their own backup. Unless they become separated and blow out a
> car window it’s usually possible to reconstruct the deck. I suppose you
> could blow them up. It’s almost impossible to incinerate a deck of
> cards. Even a card jam on a 2501 that shoots cards all over the room is
> recoverable. The problems all started when we moved away from cards.
Paper tape was better. The worst you had to do was wind it up. It kept
all the records in order, unlike a dropped deck of cards!
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Versioning file systems [message #386509 is a reply to message #386501] |
Wed, 28 August 2019 23:24 |
|
|
Originally posted by: J. Clarke
On Wed, 28 Aug 2019 15:02:14 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> Andy Walker <anw@cuboid.co.uk> wrote:
>> [snip]
>> As for editors, the whole concept of file systems and editors
>> was relatively new in those days. In 1972, we could scarcely conceive
>> that an automated system could allocate space on tape [no discs!] as
>> well as a human. As for editors, those too were quite new. I never
>> used one before 1972; if you wanted to change your program, you
>> punched some new cards or spliced in some new paper tape. Small
>> changes were often made by hand punch. I never saw an editor that
>> allowed you to back out changes until I wrote my own. Even after
>> 1972, I kept almost all my own programs on paper tape, until we
>> got Unix and had direct access to [physically large but logically
>> small!] discs.
>>
>
> Cards are their own backup. Unless they become separated and blow out a car
> window its usually possible to reconstruct the deck. I suppose you could
> blow them up. Its almost impossible to incinerate a deck of cards. Even a
> card jam on a 2501 that shoots cards all over the room is recoverable. The
> problems all started when we moved away from cards.
While true in a sense, I never will forget the time that one of our
engineers managed to drop NASTRAN down the stairwell . . .
|
|
|
|
| Re: Versioning file systems [message #386521 is a reply to message #386503] |
Thu, 29 August 2019 06:42 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 28 Aug 2019 22:56:31 GMT
Bob Eager <news0073@eager.cx> wrote:
> Paper tape was better. The worst you had to do was wind it up. It kept
Yes, of course when the winder and the computer's punch are on
opposite sides of the room there is the little problem of some plonker
treading on the tape as you wind it - we all got good at using the splicer
at that place.
> all the records in order, unlike a dropped deck of cards!
Now that takes me back, one of my CS A level assignments was a
comparative essay on the merits of cards and paper tape. The main downside
of tape is that it is a PITA to edit.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Versioning file systems [message #386678 is a reply to message #386503] |
Wed, 04 September 2019 13:56 |
|
|
Originally posted by: googlegroups jmfbahciv
On Wednesday, August 28, 2019 at 6:56:33 PM UTC-4, Bob Eager wrote:
> On Wed, 28 Aug 2019 15:02:14 -0700, Peter Flass wrote:
>
>> Andy Walker <anw@cuboid.co.uk> wrote:
>>> [snip]
>>> As for editors, the whole concept of file systems and editors
>>> was relatively new in those days. In 1972, we could scarcely conceive
>>> that an automated system could allocate space on tape [no discs!] as
>>> well as a human. As for editors, those too were quite new. I never
>>> used one before 1972; if you wanted to change your program, you
>>> punched some new cards or spliced in some new paper tape. Small
>>> changes were often made by hand punch. I never saw an editor that
>>> allowed you to back out changes until I wrote my own. Even after 1972,
>>> I kept almost all my own programs on paper tape, until we got Unix and
>>> had direct access to [physically large but logically small!] discs.
>>>
>>>
>> Cards are their own backup. Unless they become separated and blow out a
>> car window it’s usually possible to reconstruct the deck. I suppose you
>> could blow them up. It’s almost impossible to incinerate a deck of
>> cards. Even a card jam on a 2501 that shoots cards all over the room is
>> recoverable. The problems all started when we moved away from cards.
>
> Paper tape was better. The worst you had to do was wind it up. It kept
> all the records in order, unlike a dropped deck of cards!
I HATED handling paper tape, especially the oiled stuff. I enjoyed
handling cards. However, the best storage devices are still
DECtapes. ;-)
/BAH
|
|
|
|
| Re: Versioning file systems [message #386679 is a reply to message #386521] |
Wed, 04 September 2019 14:03 |
|
|
Originally posted by: googlegroups jmfbahciv
On Thursday, August 29, 2019 at 7:00:04 AM UTC-4, Ahem A Rivet's Shot wrote:
> On 28 Aug 2019 22:56:31 GMT
> Bob Eager <news0073@eager.cx> wrote:
>
>> Paper tape was better. The worst you had to do was wind it up. It kept
>
> Yes, of course when the winder and the computer's punch are on
> opposite sides of the room there is the little problem of some plonker
> treading on the tape as you wind it - we all got good at using the splicer
> at that place.
We had a forklift run over a very long oiled tape. The guy was lucky
he didn't get murdered by the woman who had just finished punching
it.
>
>> all the records in order, unlike a dropped deck of cards!
>
> Now that takes me back, one of my CS A level assignments was a
> comparative essay on the merits of cards and paper tape. The main downside
> of tape is that it is a PITA to edit.
It wasn't difficult to reassemble a deck of cards. Remember using
a marker to color a slanted line from the left corner of the first
card to the right corner of the last card?
|
|
|
|
| Re: Versioning file systems [message #386681 is a reply to message #386679] |
Wed, 04 September 2019 15:22 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 4 Sep 2019 11:03:03 -0700 (PDT)
googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
> It wasn't difficult to reassemble a deck of cards.
That depends on the fate of the deck, muddy puddles are not good
for punched cards, especially if they are to be read by a 1442.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Versioning file systems [message #386687 is a reply to message #386679] |
Wed, 04 September 2019 16:30 |
Richard Thiebaud
Messages: 222
Registered: May 2013
Karma: 0
|
Senior Member |
|
|
On 9/4/19 2:03 PM, googlegroups jmfbahciv wrote:
> On Thursday, August 29, 2019 at 7:00:04 AM UTC-4, Ahem A Rivet's Shot wrote:
>> On 28 Aug 2019 22:56:31 GMT
>> Bob Eager <news0073@eager.cx> wrote:
>>
>>> Paper tape was better. The worst you had to do was wind it up. It kept
>>
>> Yes, of course when the winder and the computer's punch are on
>> opposite sides of the room there is the little problem of some plonker
>> treading on the tape as you wind it - we all got good at using the splicer
>> at that place.
>
>
> We had a forklift run over a very long oiled tape. The guy was lucky
> he didn't get murdered by the woman who had just finished punching
> it.
>
>
>>
>>> all the records in order, unlike a dropped deck of cards!
>>
>> Now that takes me back, one of my CS A level assignments was a
>> comparative essay on the merits of cards and paper tape. The main downside
>> of tape is that it is a PITA to edit.
>
>
> It wasn't difficult to reassemble a deck of cards. Remember using
> a marker to color a slanted line from the left corner of the first
> card to the right corner of the last card?
>
Or putting sequence numbers in columns 73-80.
|
|
|
|
| Re: Versioning file systems [message #386691 is a reply to message #386679] |
Wed, 04 September 2019 21:45 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
> On Thursday, August 29, 2019 at 7:00:04 AM UTC-4, Ahem A Rivet's Shot wrote:
>> On 28 Aug 2019 22:56:31 GMT
>> Bob Eager <news0073@eager.cx> wrote:
>>
>>> Paper tape was better. The worst you had to do was wind it up. It kept
>>
>> Yes, of course when the winder and the computer's punch are on
>> opposite sides of the room there is the little problem of some plonker
>> treading on the tape as you wind it - we all got good at using the splicer
>> at that place.
>
>
> We had a forklift run over a very long oiled tape. The guy was lucky
> he didn't get murdered by the woman who had just finished punching
> it.
>
>
>>
>>> all the records in order, unlike a dropped deck of cards!
>>
>> Now that takes me back, one of my CS A level assignments was a
>> comparative essay on the merits of cards and paper tape. The main downside
>> of tape is that it is a PITA to edit.
>
>
> It wasn't difficult to reassemble a deck of cards. Remember using
> a marker to color a slanted line from the left corner of the first
> card to the right corner of the last card?
>
>
Or just use sequence numbers. I’s pretty easy to run the deck thru a
sorter.
--
Pete
|
|
|
|
| Re: Versioning file systems [message #386692 is a reply to message #386681] |
Wed, 04 September 2019 21:47 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Wed, 4 Sep 2019 11:03:03 -0700 (PDT)
> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>
>> It wasn't difficult to reassemble a deck of cards.
>
> That depends on the fate of the deck, muddy puddles are not good
> for punched cards, especially if they are to be read by a 1442.
>
I recall having to dup a few cards on an 029, which was more tolerant of
this sort of stuff than a card reader.
--
Pete
|
|
|
|
| Re: Versioning file systems [message #386714 is a reply to message #386691] |
Thu, 05 September 2019 17:49 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-09-05, Peter Flass <peter_flass@yahoo.com> wrote:
> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>
>> It wasn't difficult to reassemble a deck of cards. Remember using
>> a marker to color a slanted line from the left corner of the first
>> card to the right corner of the last card?
>
> Or just use sequence numbers. I’s pretty easy to run the deck thru a
> sorter.
I never was big on sequence numbers, especially for source code.
Moving a block of code elsewhere in the deck means that you'd
have to re-punch (and interpret) the deck.
Data decks were less of an issue; they usually contained a key field
(e.g. customer ID and/or stock number) on which you sorted it anyway.
As for dropped decks, the key (as in anything else) was not to panic.
Often the cards would spread themselves across the floor in such a
way that if you were careful you could gather them up pretty much
in sequence (perhaps in several groups).
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: Versioning file systems [message #386793 is a reply to message #386687] |
Sun, 08 September 2019 11:17 |
|
|
Originally posted by: Thomas Koenig
Richard Thiebaud <thiebauddick2@aol.com> schrieb:
> On 9/4/19 2:03 PM, googlegroups jmfbahciv wrote:
>> It wasn't difficult to reassemble a deck of cards. Remember using
>> a marker to color a slanted line from the left corner of the first
>> card to the right corner of the last card?
> Or putting sequence numbers in columns 73-80.
Excellent, especially if your editor still does so by default,
wihle not displaying them. I got caught by that once when writing
TeX on an MVS system with the ISPF editor with an FB80 PDS...
|
|
|
|
| Re: Versioning file systems [message #387036 is a reply to message #386714] |
Sat, 14 September 2019 12:53 |
|
|
Originally posted by: googlegroups jmfbahciv
On Thursday, September 5, 2019 at 5:50:13 PM UTC-4, Charlie Gibbs wrote:
> On 2019-09-05, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>
>>> It wasn't difficult to reassemble a deck of cards. Remember using
>>> a marker to color a slanted line from the left corner of the first
>>> card to the right corner of the last card?
>>
>> Or just use sequence numbers. I’s pretty easy to run the deck thru a
>> sorter.
>
> I never was big on sequence numbers, especially for source code.
> Moving a block of code elsewhere in the deck means that you'd
> have to re-punch (and interpret) the deck.
>
> Data decks were less of an issue; they usually contained a key field
> (e.g. customer ID and/or stock number) on which you sorted it anyway.
>
> As for dropped decks, the key (as in anything else) was not to panic.
> Often the cards would spread themselves across the floor in such a
> way that if you were careful you could gather them up pretty much
> in sequence (perhaps in several groups).
Yup. If you're in development sequence numbers aren't useful.
Think the messes with BASIC, etc. There is a special way
PDP-10 software denoted sequence numbers in ASCII files but
we always stripped them out with the first edit.
W.r.t. cards, inserting even one card could mess up the program
when the program was thousands of cards long.
/BAh
|
|
|
|
| Re: Versioning file systems [message #387051 is a reply to message #387036] |
Sun, 15 September 2019 02:51 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-09-14, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
> On Thursday, September 5, 2019 at 5:50:13 PM UTC-4, Charlie Gibbs wrote:
>
>> On 2019-09-05, Peter Flass <peter_flass@yahoo.com> wrote:
>>
>>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>
>>>> It wasn't difficult to reassemble a deck of cards. Remember using
>>>> a marker to color a slanted line from the left corner of the first
>>>> card to the right corner of the last card?
>>>
>>> Or just use sequence numbers. I’s pretty easy to run the deck thru a
>>> sorter.
>>
>> I never was big on sequence numbers, especially for source code.
>> Moving a block of code elsewhere in the deck means that you'd
>> have to re-punch (and interpret) the deck.
>>
>> Data decks were less of an issue; they usually contained a key field
>> (e.g. customer ID and/or stock number) on which you sorted it anyway.
>>
>> As for dropped decks, the key (as in anything else) was not to panic.
>> Often the cards would spread themselves across the floor in such a
>> way that if you were careful you could gather them up pretty much
>> in sequence (perhaps in several groups).
>
> Yup. If you're in development sequence numbers aren't useful.
> Think the messes with BASIC, etc. There is a special way
> PDP-10 software denoted sequence numbers in ASCII files but
> we always stripped them out with the first edit.
>
> W.r.t. cards, inserting even one card could mess up the program
> when the program was thousands of cards long.
That's why, if you used sequence numbers, you'd typically create
them in intervals of 10, or even 100. This made insertions easy.
However, my previous comment about moving blocks of code still stands.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: Versioning file systems [message #387151 is a reply to message #387051] |
Fri, 20 September 2019 13:49 |
|
|
Originally posted by: googlegroups jmfbahciv
On Sunday, September 15, 2019 at 2:51:35 AM UTC-4, Charlie Gibbs wrote:
> On 2019-09-14, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>
>> On Thursday, September 5, 2019 at 5:50:13 PM UTC-4, Charlie Gibbs wrote:
>>
>>> On 2019-09-05, Peter Flass <peter_flass@yahoo.com> wrote:
>>>
>>>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>>
>>>> > It wasn't difficult to reassemble a deck of cards. Remember using
>>>> > a marker to color a slanted line from the left corner of the first
>>>> > card to the right corner of the last card?
>>>>
>>>> Or just use sequence numbers. I’s pretty easy to run the deck thru a
>>>> sorter.
>>>
>>> I never was big on sequence numbers, especially for source code.
>>> Moving a block of code elsewhere in the deck means that you'd
>>> have to re-punch (and interpret) the deck.
>>>
>>> Data decks were less of an issue; they usually contained a key field
>>> (e.g. customer ID and/or stock number) on which you sorted it anyway.
>>>
>>> As for dropped decks, the key (as in anything else) was not to panic.
>>> Often the cards would spread themselves across the floor in such a
>>> way that if you were careful you could gather them up pretty much
>>> in sequence (perhaps in several groups).
>>
>> Yup. If you're in development sequence numbers aren't useful.
>> Think the messes with BASIC, etc. There is a special way
>> PDP-10 software denoted sequence numbers in ASCII files but
>> we always stripped them out with the first edit.
>>
>> W.r.t. cards, inserting even one card could mess up the program
>> when the program was thousands of cards long.
>
> That's why, if you used sequence numbers, you'd typically create
> them in intervals of 10, or even 100. This made insertions easy.
> However, my previous comment about moving blocks of code still stands.
The only way to insert a chunk of code would be a subroutine. In
new development, it's simply easier (especially on the keypunch
operator) to not key in those numbers. When the card deck code
has been declared to be stable, then the keypunchers can number the
cards.
Remember the #1 rule of being kind to your keypunchers? ;-))))
/BAH
|
|
|
|
| Re: Versioning file systems [message #387152 is a reply to message #387151] |
Fri, 20 September 2019 14:07 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
> On Sunday, September 15, 2019 at 2:51:35 AM UTC-4, Charlie Gibbs wrote:
>> On 2019-09-14, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>
>>> On Thursday, September 5, 2019 at 5:50:13 PM UTC-4, Charlie Gibbs wrote:
>>>
>>>> On 2019-09-05, Peter Flass <peter_flass@yahoo.com> wrote:
>>>>
>>>> > googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> >
>>>> >> It wasn't difficult to reassemble a deck of cards. Remember using
>>>> >> a marker to color a slanted line from the left corner of the first
>>>> >> card to the right corner of the last card?
>>>> >
>>>> > Or just use sequence numbers. I’s pretty easy to run the deck thru a
>>>> > sorter.
>>>>
>>>> I never was big on sequence numbers, especially for source code.
>>>> Moving a block of code elsewhere in the deck means that you'd
>>>> have to re-punch (and interpret) the deck.
>>>>
>>>> Data decks were less of an issue; they usually contained a key field
>>>> (e.g. customer ID and/or stock number) on which you sorted it anyway.
>>>>
>>>> As for dropped decks, the key (as in anything else) was not to panic.
>>>> Often the cards would spread themselves across the floor in such a
>>>> way that if you were careful you could gather them up pretty much
>>>> in sequence (perhaps in several groups).
>>>
>>> Yup. If you're in development sequence numbers aren't useful.
>>> Think the messes with BASIC, etc. There is a special way
>>> PDP-10 software denoted sequence numbers in ASCII files but
>>> we always stripped them out with the first edit.
>>>
>>> W.r.t. cards, inserting even one card could mess up the program
>>> when the program was thousands of cards long.
>>
>> That's why, if you used sequence numbers, you'd typically create
>> them in intervals of 10, or even 100. This made insertions easy.
>> However, my previous comment about moving blocks of code still stands.
>
>
> The only way to insert a chunk of code would be a subroutine. In
> new development, it's simply easier (especially on the keypunch
> operator) to not key in those numbers. When the card deck code
> has been declared to be stable, then the keypunchers can number the
> cards.
>
> Remember the #1 rule of being kind to your keypunchers? ;-))))
>
> /BAH
>
>
Back when I was doing COBOL I’d number by 100s, with sections separated by
large blocks of code. If you’re going to insert more than a couple of
hundred cards in one place (renumber one existing card if >100) then you
might as well throw up our hands until it’s more stable. When we were done
we’d punch out a new deck all renumbered.
--
Pete
|
|
|
|
| Re: Versioning file systems [message #387521 is a reply to message #387152] |
Thu, 03 October 2019 15:01 |
|
|
Originally posted by: googlegroups jmfbahciv
On Friday, September 20, 2019 at 2:07:31 PM UTC-4, Peter Flass wrote:
> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>> On Sunday, September 15, 2019 at 2:51:35 AM UTC-4, Charlie Gibbs wrote:
>>> On 2019-09-14, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>
>>>> On Thursday, September 5, 2019 at 5:50:13 PM UTC-4, Charlie Gibbs wrote:
>>>>
>>>> > On 2019-09-05, Peter Flass <peter_flass@yahoo.com> wrote:
>>>> >
>>>> >> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> >>
>>>> >>> It wasn't difficult to reassemble a deck of cards. Remember using
>>>> >>> a marker to color a slanted line from the left corner of the first
>>>> >>> card to the right corner of the last card?
>>>> >>
>>>> >> Or just use sequence numbers. I’s pretty easy to run the deck thru a
>>>> >> sorter.
>>>> >
>>>> > I never was big on sequence numbers, especially for source code.
>>>> > Moving a block of code elsewhere in the deck means that you'd
>>>> > have to re-punch (and interpret) the deck.
>>>> >
>>>> > Data decks were less of an issue; they usually contained a key field
>>>> > (e.g. customer ID and/or stock number) on which you sorted it anyway..
>>>> >
>>>> > As for dropped decks, the key (as in anything else) was not to panic..
>>>> > Often the cards would spread themselves across the floor in such a
>>>> > way that if you were careful you could gather them up pretty much
>>>> > in sequence (perhaps in several groups).
>>>>
>>>> Yup. If you're in development sequence numbers aren't useful.
>>>> Think the messes with BASIC, etc. There is a special way
>>>> PDP-10 software denoted sequence numbers in ASCII files but
>>>> we always stripped them out with the first edit.
>>>>
>>>> W.r.t. cards, inserting even one card could mess up the program
>>>> when the program was thousands of cards long.
>>>
>>> That's why, if you used sequence numbers, you'd typically create
>>> them in intervals of 10, or even 100. This made insertions easy.
>>> However, my previous comment about moving blocks of code still stands.
>>
>>
>> The only way to insert a chunk of code would be a subroutine. In
>> new development, it's simply easier (especially on the keypunch
>> operator) to not key in those numbers. When the card deck code
>> has been declared to be stable, then the keypunchers can number the
>> cards.
>>
>> Remember the #1 rule of being kind to your keypunchers? ;-))))
>>
>> /BAH
>>
>>
>
> Back when I was doing COBOL I’d number by 100s, with sections separated by
> large blocks of code. If you’re going to insert more than a couple of
> hundred cards in one place (renumber one existing card if >100) then you
> might as well throw up our hands until it’s more stable. When we were done
> we’d punch out a new deck all renumbered.
And, how did you punch that deck? If you wrote a program,
then you had to use the interpreter to print the code on the
card. Reading characters printed by an interpreter made
people want to repunch cards using a keypunch.
/BAH
|
|
|
|
| Re: Versioning file systems [message #387525 is a reply to message #387521] |
Thu, 03 October 2019 16:13 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-10-03, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
> On Friday, September 20, 2019 at 2:07:31 PM UTC-4, Peter Flass wrote:
>
>> Back when I was doing COBOL I’d number by 100s, with sections separated
>> by large blocks of code. If you’re going to insert more than a couple of
>> hundred cards in one place (renumber one existing card if >100) then you
>> might as well throw up our hands until it’s more stable. When we were
>> done we’d punch out a new deck all renumbered.
>
> And, how did you punch that deck? If you wrote a program,
> then you had to use the interpreter to print the code on the
> card. Reading characters printed by an interpreter made
> people want to repunch cards using a keypunch.
You're referring, no doubt, to interpreters like the IBM 557, which
could only print 60 characters of text across the top of the card.
Their print quality was lovely, but the fact that the characters
didn't line up with the card columns could drive you nuts.
A later option on the IBM 029 keypunch added a read station at the
punch station, giving it the ability to interpret cards, showing
all 80 characters aligned with the columns in the 029's typical
dot-matrix style. But it was noisy and slow, and was an extra-price
option that few shops sprang for.
A later keypunch, the Univac 1710, had a miniature drum printer which
printed 80 characters lined up with the columns. It could also function
as an interpreter: not quite as fast as the IBM 557, but much faster
than the modified 029. The 1710 came out while the IBM 129 was still
in development. A friend who worked as an IBM CE told me that IBM
responded by rushing the 129 out the door, and in his opinion as
the guy who had to fix them, the result was half-baked. Univac sold
a lot of keypunches, and not just to shops with a Univac computer.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: Versioning file systems [message #387526 is a reply to message #387521] |
Thu, 03 October 2019 17:37 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
googlegroups jmfbahciv <jmfbah102162@gmail.com> writes:
> On Friday, September 20, 2019 at 2:07:31 PM UTC-4, Peter Flass wrote:
>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>> On Sunday, September 15, 2019 at 2:51:35 AM UTC-4, Charlie Gibbs wrote:
>>>> On 2019-09-14, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> =20
>>>> > On Thursday, September 5, 2019 at 5:50:13 PM UTC-4, Charlie Gibbs wro=
> te:
>>>> >=20
>>>> >> On 2019-09-05, Peter Flass <peter_flass@yahoo.com> wrote:
>>>> >>=20
>>>> >>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> >>>=20
>>>> >>>> It wasn't difficult to reassemble a deck of cards. Remember using
>>>> >>>> a marker to color a slanted line from the left corner of the first
>>>> >>>> card to the right corner of the last card?
>>>> >>>=20
>>>> >>> Or just use sequence numbers. I=E2=80=99s pretty easy to run the de=
> ck thru a
>>>> >>> sorter.
>>>> >>=20
>>>> >> I never was big on sequence numbers, especially for source code.
>>>> >> Moving a block of code elsewhere in the deck means that you'd
>>>> >> have to re-punch (and interpret) the deck.
>>>> >>=20
>>>> >> Data decks were less of an issue; they usually contained a key field
>>>> >> (e.g. customer ID and/or stock number) on which you sorted it anyway=
> .
>>>> >>=20
>>>> >> As for dropped decks, the key (as in anything else) was not to panic=
> .
>>>> >> Often the cards would spread themselves across the floor in such a
>>>> >> way that if you were careful you could gather them up pretty much
>>>> >> in sequence (perhaps in several groups).
>>>> >=20
>>>> > Yup. If you're in development sequence numbers aren't useful.
>>>> > Think the messes with BASIC, etc. There is a special way
>>>> > PDP-10 software denoted sequence numbers in ASCII files but
>>>> > we always stripped them out with the first edit.
>>>> >=20
>>>> > W.r.t. cards, inserting even one card could mess up the program
>>>> > when the program was thousands of cards long. =20
>>>> =20
>>>> That's why, if you used sequence numbers, you'd typically create
>>>> them in intervals of 10, or even 100. This made insertions easy.
>>>> However, my previous comment about moving blocks of code still stands.
>>> =20
>>> =20
>>> The only way to insert a chunk of code would be a subroutine. In=20
>>> new development, it's simply easier (especially on the keypunch
>>> operator) to not key in those numbers. When the card deck code
>>> has been declared to be stable, then the keypunchers can number the
>>> cards.
>>> =20
>>> Remember the #1 rule of being kind to your keypunchers? ;-))))
>>> =20
>>> /BAH
>>> =20
>>> =20
>> =20
>> Back when I was doing COBOL I=E2=80=99d number by 100s, with sections sep=
> arated by
>> large blocks of code. If you=E2=80=99re going to insert more than a coupl=
> e of
>> hundred cards in one place (renumber one existing card if >100) then you
>> might as well throw up our hands until it=E2=80=99s more stable. When we =
> were done
>> we=E2=80=99d punch out a new deck all renumbered.
>
> And, how did you punch that deck?
The resequence program reads in the original deck using the
card reader. It updates the sequence number field and sends
the card images to the card punch.
Good resequence programs could also apply patch files along the
way.
> If you wrote a program,
> then you had to use the interpreter to print the code on the
> card. Reading characters printed by an interpreter made
> people want to repunch cards using a keypunch.
We'd just read the deck and send the images directly to the printer. Much easer than
farting around trying to read the text on the card.
On the Burrough systems:
PFM CRDPRN
was sufficient.
|
|
|
|
| Re: Versioning file systems [message #387530 is a reply to message #387521] |
Thu, 03 October 2019 19:54 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
> On Friday, September 20, 2019 at 2:07:31 PM UTC-4, Peter Flass wrote:
>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>> On Sunday, September 15, 2019 at 2:51:35 AM UTC-4, Charlie Gibbs wrote:
>>>> On 2019-09-14, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>>
>>>> > On Thursday, September 5, 2019 at 5:50:13 PM UTC-4, Charlie Gibbs wrote:
>>>> >
>>>> >> On 2019-09-05, Peter Flass <peter_flass@yahoo.com> wrote:
>>>> >>
>>>> >>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> >>>
>>>> >>>> It wasn't difficult to reassemble a deck of cards. Remember using
>>>> >>>> a marker to color a slanted line from the left corner of the first
>>>> >>>> card to the right corner of the last card?
>>>> >>>
>>>> >>> Or just use sequence numbers. I’s pretty easy to run the deck thru a
>>>> >>> sorter.
>>>> >>
>>>> >> I never was big on sequence numbers, especially for source code.
>>>> >> Moving a block of code elsewhere in the deck means that you'd
>>>> >> have to re-punch (and interpret) the deck.
>>>> >>
>>>> >> Data decks were less of an issue; they usually contained a key field
>>>> >> (e.g. customer ID and/or stock number) on which you sorted it anyway.
>>>> >>
>>>> >> As for dropped decks, the key (as in anything else) was not to panic.
>>>> >> Often the cards would spread themselves across the floor in such a
>>>> >> way that if you were careful you could gather them up pretty much
>>>> >> in sequence (perhaps in several groups).
>>>> >
>>>> > Yup. If you're in development sequence numbers aren't useful.
>>>> > Think the messes with BASIC, etc. There is a special way
>>>> > PDP-10 software denoted sequence numbers in ASCII files but
>>>> > we always stripped them out with the first edit.
>>>> >
>>>> > W.r.t. cards, inserting even one card could mess up the program
>>>> > when the program was thousands of cards long.
>>>>
>>>> That's why, if you used sequence numbers, you'd typically create
>>>> them in intervals of 10, or even 100. This made insertions easy.
>>>> However, my previous comment about moving blocks of code still stands.
>>>
>>>
>>> The only way to insert a chunk of code would be a subroutine. In
>>> new development, it's simply easier (especially on the keypunch
>>> operator) to not key in those numbers. When the card deck code
>>> has been declared to be stable, then the keypunchers can number the
>>> cards.
>>>
>>> Remember the #1 rule of being kind to your keypunchers? ;-))))
>>>
>>> /BAH
>>>
>>>
>>
>> Back when I was doing COBOL I’d number by 100s, with sections separated by
>> large blocks of code. If you’re going to insert more than a couple of
>> hundred cards in one place (renumber one existing card if >100) then you
>> might as well throw up our hands until it’s more stable. When we were done
>> we’d punch out a new deck all renumbered.
>
> And, how did you punch that deck? If you wrote a program,
> then you had to use the interpreter to print the code on the
> card. Reading characters printed by an interpreter made
> people want to repunch cards using a keypunch.
The 129 keypunch could interpret. At one site we interpreted them on a
360/20 MFCM that could print 80 columns. I agree interpreters were a royal
pain.
--
Pete
|
|
|
|
| Re: Versioning file systems [message #387580 is a reply to message #387530] |
Sat, 05 October 2019 15:41 |
|
|
Originally posted by: googlegroups jmfbahciv
On Thursday, October 3, 2019 at 7:54:49 PM UTC-4, Peter Flass wrote:
> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>> On Friday, September 20, 2019 at 2:07:31 PM UTC-4, Peter Flass wrote:
>>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> On Sunday, September 15, 2019 at 2:51:35 AM UTC-4, Charlie Gibbs wrote:
>>>> > On 2019-09-14, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> >
>>>> >> On Thursday, September 5, 2019 at 5:50:13 PM UTC-4, Charlie Gibbs wrote:
>>>> >>
>>>> >>> On 2019-09-05, Peter Flass <peter_flass@yahoo.com> wrote:
>>>> >>>
>>>> >>>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> >>>>
>>>> >>>>> It wasn't difficult to reassemble a deck of cards. Remember using
>>>> >>>>> a marker to color a slanted line from the left corner of the first
>>>> >>>>> card to the right corner of the last card?
>>>> >>>>
>>>> >>>> Or just use sequence numbers. I’s pretty easy to run the deck thru a
>>>> >>>> sorter.
>>>> >>>
>>>> >>> I never was big on sequence numbers, especially for source code.
>>>> >>> Moving a block of code elsewhere in the deck means that you'd
>>>> >>> have to re-punch (and interpret) the deck.
>>>> >>>
>>>> >>> Data decks were less of an issue; they usually contained a key field
>>>> >>> (e.g. customer ID and/or stock number) on which you sorted it anyway.
>>>> >>>
>>>> >>> As for dropped decks, the key (as in anything else) was not to panic.
>>>> >>> Often the cards would spread themselves across the floor in such a
>>>> >>> way that if you were careful you could gather them up pretty much
>>>> >>> in sequence (perhaps in several groups).
>>>> >>
>>>> >> Yup. If you're in development sequence numbers aren't useful.
>>>> >> Think the messes with BASIC, etc. There is a special way
>>>> >> PDP-10 software denoted sequence numbers in ASCII files but
>>>> >> we always stripped them out with the first edit.
>>>> >>
>>>> >> W.r.t. cards, inserting even one card could mess up the program
>>>> >> when the program was thousands of cards long.
>>>> >
>>>> > That's why, if you used sequence numbers, you'd typically create
>>>> > them in intervals of 10, or even 100. This made insertions easy.
>>>> > However, my previous comment about moving blocks of code still stands.
>>>>
>>>>
>>>> The only way to insert a chunk of code would be a subroutine. In
>>>> new development, it's simply easier (especially on the keypunch
>>>> operator) to not key in those numbers. When the card deck code
>>>> has been declared to be stable, then the keypunchers can number the
>>>> cards.
>>>>
>>>> Remember the #1 rule of being kind to your keypunchers? ;-))))
>>>>
>>>> /BAH
>>>>
>>>>
>>>
>>> Back when I was doing COBOL I’d number by 100s, with sections separated by
>>> large blocks of code. If you’re going to insert more than a couple of
>>> hundred cards in one place (renumber one existing card if >100) then you
>>> might as well throw up our hands until it’s more stable. When we were done
>>> we’d punch out a new deck all renumbered.
>>
>> And, how did you punch that deck? If you wrote a program,
>> then you had to use the interpreter to print the code on the
>> card. Reading characters printed by an interpreter made
>> people want to repunch cards using a keypunch.
>
> The 129 keypunch could interpret. At one site we interpreted them on a
> 360/20 MFCM that could print 80 columns. I agree interpreters were a royal
> pain.
And they were so damned slow. I don't think I've ever met
a 129. How did they work mechanically? Oh, there must have been
a section which read the holes and then sent them on to print on the
card? Or did it punch/print another card. I did that if the
deck was small (for various flavors of "small") by programming
a drum card to dup a card on program one and releasing a card
on program 2. Then I would shuffle the deck I wanted to dup
with blank cards and then just hit the prog1 and prog2 buttons.
Reading in a huge deck and then punching a new one with new numbers
wasn't allowed in my shop. Too much waste of cards :-).
/BAH
|
|
|
|
| Re: Versioning file systems [message #387583 is a reply to message #387580] |
Sat, 05 October 2019 17:03 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
> On Thursday, October 3, 2019 at 7:54:49 PM UTC-4, Peter Flass wrote:
>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>> On Friday, September 20, 2019 at 2:07:31 PM UTC-4, Peter Flass wrote:
>>>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> > On Sunday, September 15, 2019 at 2:51:35 AM UTC-4, Charlie Gibbs wrote:
>>>> >> On 2019-09-14, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> >>
>>>> >>> On Thursday, September 5, 2019 at 5:50:13 PM UTC-4, Charlie Gibbs wrote:
>>>> >>>
>>>> >>>> On 2019-09-05, Peter Flass <peter_flass@yahoo.com> wrote:
>>>> >>>>
>>>> >>>>> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>> >>>>>
>>>> >>>>>> It wasn't difficult to reassemble a deck of cards. Remember using
>>>> >>>>>> a marker to color a slanted line from the left corner of the first
>>>> >>>>>> card to the right corner of the last card?
>>>> >>>>>
>>>> >>>>> Or just use sequence numbers. I’s pretty easy to run the deck thru a
>>>> >>>>> sorter.
>>>> >>>>
>>>> >>>> I never was big on sequence numbers, especially for source code.
>>>> >>>> Moving a block of code elsewhere in the deck means that you'd
>>>> >>>> have to re-punch (and interpret) the deck.
>>>> >>>>
>>>> >>>> Data decks were less of an issue; they usually contained a key field
>>>> >>>> (e.g. customer ID and/or stock number) on which you sorted it anyway.
>>>> >>>>
>>>> >>>> As for dropped decks, the key (as in anything else) was not to panic.
>>>> >>>> Often the cards would spread themselves across the floor in such a
>>>> >>>> way that if you were careful you could gather them up pretty much
>>>> >>>> in sequence (perhaps in several groups).
>>>> >>>
>>>> >>> Yup. If you're in development sequence numbers aren't useful.
>>>> >>> Think the messes with BASIC, etc. There is a special way
>>>> >>> PDP-10 software denoted sequence numbers in ASCII files but
>>>> >>> we always stripped them out with the first edit.
>>>> >>>
>>>> >>> W.r.t. cards, inserting even one card could mess up the program
>>>> >>> when the program was thousands of cards long.
>>>> >>
>>>> >> That's why, if you used sequence numbers, you'd typically create
>>>> >> them in intervals of 10, or even 100. This made insertions easy.
>>>> >> However, my previous comment about moving blocks of code still stands.
>>>> >
>>>> >
>>>> > The only way to insert a chunk of code would be a subroutine. In
>>>> > new development, it's simply easier (especially on the keypunch
>>>> > operator) to not key in those numbers. When the card deck code
>>>> > has been declared to be stable, then the keypunchers can number the
>>>> > cards.
>>>> >
>>>> > Remember the #1 rule of being kind to your keypunchers? ;-))))
>>>> >
>>>> > /BAH
>>>> >
>>>> >
>>>>
>>>> Back when I was doing COBOL I’d number by 100s, with sections separated by
>>>> large blocks of code. If you’re going to insert more than a couple of
>>>> hundred cards in one place (renumber one existing card if >100) then you
>>>> might as well throw up our hands until it’s more stable. When we were done
>>>> we’d punch out a new deck all renumbered.
>>>
>>> And, how did you punch that deck? If you wrote a program,
>>> then you had to use the interpreter to print the code on the
>>> card. Reading characters printed by an interpreter made
>>> people want to repunch cards using a keypunch.
>>
>> The 129 keypunch could interpret. At one site we interpreted them on a
>> 360/20 MFCM that could print 80 columns. I agree interpreters were a royal
>> pain.
>
> And they were so damned slow. I don't think I've ever met
> a 129. How did they work mechanically? Oh, there must have been
> a section which read the holes and then sent them on to print on the
> card? Or did it punch/print another card. I did that if the
> deck was small (for various flavors of "small") by programming
> a drum card to dup a card on program one and releasing a card
> on program 2. Then I would shuffle the deck I wanted to dup
> with blank cards and then just hit the prog1 and prog2 buttons.
>
> Reading in a huge deck and then punching a new one with new numbers
> wasn't allowed in my shop. Too much waste of cards :-).
>
You know, I can’t really recall now...
--
Pete
|
|
|
|
| Re: Versioning file systems [message #387591 is a reply to message #387580] |
Sat, 05 October 2019 18:29 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-10-05, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
> On Thursday, October 3, 2019 at 7:54:49 PM UTC-4, Peter Flass wrote:
>
>> The 129 keypunch could interpret. At one site we interpreted them on
>> a 360/20 MFCM that could print 80 columns. I agree interpreters were
>> a royal pain.
>
> And they were so damned slow. I don't think I've ever met
> a 129. How did they work mechanically? Oh, there must have been
> a section which read the holes and then sent them on to print on
> the card?
Yup. Mechanically the 129 looked a lot like a 029; it just had
more electronics.
> Or did it punch/print another card. I did that if the
> deck was small (for various flavors of "small") by programming
> a drum card to dup a card on program one and releasing a card
> on program 2. Then I would shuffle the deck I wanted to dup
> with blank cards and then just hit the prog1 and prog2 buttons.
You gotta do what you gotta do...
> Reading in a huge deck and then punching a new one with new numbers
> wasn't allowed in my shop. Too much waste of cards :-).
I once wrote a program that I'd feed cards from the scrap bin;
it would select the blanks into a separate stacker. Given the
amount of waste, I was able to reclaim enough blank cards that
nobody dared complain about my usage.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: Versioning file systems [message #387592 is a reply to message #387591] |
Sat, 05 October 2019 18:45 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2019-10-05, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>
>> On Thursday, October 3, 2019 at 7:54:49 PM UTC-4, Peter Flass wrote:
>>
>>> The 129 keypunch could interpret. At one site we interpreted them on
>>> a 360/20 MFCM that could print 80 columns. I agree interpreters were
>>> a royal pain.
>>
>> And they were so damned slow. I don't think I've ever met
>> a 129. How did they work mechanically? Oh, there must have been
>> a section which read the holes and then sent them on to print on
>> the card?
>
> Yup. Mechanically the 129 looked a lot like a 029; it just had
> more electronics.
>
>> Or did it punch/print another card. I did that if the
>> deck was small (for various flavors of "small") by programming
>> a drum card to dup a card on program one and releasing a card
>> on program 2. Then I would shuffle the deck I wanted to dup
>> with blank cards and then just hit the prog1 and prog2 buttons.
>
> You gotta do what you gotta do...
>
>> Reading in a huge deck and then punching a new one with new numbers
>> wasn't allowed in my shop. Too much waste of cards :-).
>
> I once wrote a program that I'd feed cards from the scrap bin;
> it would select the blanks into a separate stacker. Given the
> amount of waste, I was able to reclaim enough blank cards that
> nobody dared complain about my usage.
>
Never thought of that one %-)
--
Pete
|
|
|
|
| Re: Versioning file systems [message #387596 is a reply to message #387592] |
Sat, 05 October 2019 19:12 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> On 2019-10-05, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>
>>> On Thursday, October 3, 2019 at 7:54:49 PM UTC-4, Peter Flass wrote:
>>>
>>>> The 129 keypunch could interpret. At one site we interpreted them on
>>>> a 360/20 MFCM that could print 80 columns. I agree interpreters were
>>>> a royal pain.
>>>
>>> And they were so damned slow. I don't think I've ever met
>>> a 129. How did they work mechanically? Oh, there must have been
>>> a section which read the holes and then sent them on to print on
>>> the card?
>>
>> Yup. Mechanically the 129 looked a lot like a 029; it just had
>> more electronics.
>>
>>> Or did it punch/print another card. I did that if the
>>> deck was small (for various flavors of "small") by programming
>>> a drum card to dup a card on program one and releasing a card
>>> on program 2. Then I would shuffle the deck I wanted to dup
>>> with blank cards and then just hit the prog1 and prog2 buttons.
>>
>> You gotta do what you gotta do...
>>
>>> Reading in a huge deck and then punching a new one with new numbers
>>> wasn't allowed in my shop. Too much waste of cards :-).
>>
>> I once wrote a program that I'd feed cards from the scrap bin;
>> it would select the blanks into a separate stacker. Given the
>> amount of waste, I was able to reclaim enough blank cards that
>> nobody dared complain about my usage.
>
> Never thought of that one %-)
Somehow reading cards from the scrap bin sounds like a bad idea.
I can't recall ever being in a shop that cared about card usage.
Renumbering a moved section of code should be easy enough,
put in a program card, dupe the source, type in new number, repeat
for all the cards in the moved code and possibly a couple
of surrounding cards to make room.
I have really dim memories of having a special keypunch program
card for this.
--
Dan Espen
|
|
|
|
| Re: Versioning file systems [message #387632 is a reply to message #387525] |
Mon, 07 October 2019 13:45 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Thursday, October 3, 2019 at 4:14:47 PM UTC-4, Charlie Gibbs wrote:
> On 2019-10-03, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>
>> On Friday, September 20, 2019 at 2:07:31 PM UTC-4, Peter Flass wrote:
>>
>>> Back when I was doing COBOL I’d number by 100s, with sections separated
>>> by large blocks of code. If you’re going to insert more than a couple of
>>> hundred cards in one place (renumber one existing card if >100) then you
>>> might as well throw up our hands until it’s more stable. When we were
>>> done we’d punch out a new deck all renumbered.
>>
>> And, how did you punch that deck? If you wrote a program,
>> then you had to use the interpreter to print the code on the
>> card. Reading characters printed by an interpreter made
>> people want to repunch cards using a keypunch.
>
> You're referring, no doubt, to interpreters like the IBM 557, which
> could only print 60 characters of text across the top of the card.
> Their print quality was lovely, but the fact that the characters
> didn't line up with the card columns could drive you nuts.
>
> A later option on the IBM 029 keypunch added a read station at the
> punch station, giving it the ability to interpret cards, showing
> all 80 characters aligned with the columns in the 029's typical
> dot-matrix style. But it was noisy and slow, and was an extra-price
> option that few shops sprang for.
I think it was cheaper than an 557. We had one and used it a lot.
Nice to have the characters lined up. But as you said, it was
indeed slow and noisy.
(Note that all tab machines were slow and rather noisy.)
I remember once insurance company had their keypunchers packed
into this small room with cinderblock walls. Very noisy. I wonder
if the girls suffered from hearing loss after working their for
some years.
(Dentists tell me they have hearing loss from the machines
and high pitched compressors.)
> A later keypunch, the Univac 1710, had a miniature drum printer which
> printed 80 characters lined up with the columns. It could also function
> as an interpreter: not quite as fast as the IBM 557, but much faster
> than the modified 029. The 1710 came out while the IBM 129 was still
> in development. A friend who worked as an IBM CE told me that IBM
> responded by rushing the 129 out the door, and in his opinion as
> the guy who had to fix them, the result was half-baked. Univac sold
> a lot of keypunches, and not just to shops with a Univac computer.
We had 129s, which we got since they could double as a verifier
and thus were more economical. We liked them and they served us
well. They spoiled me since I could backspace and fix typos.
I used Burroughs and Univac stored-buffer keypunches. I didn't
like them as well.
|
|
|
|
| Re: Versioning file systems [message #387633 is a reply to message #387526] |
Mon, 07 October 2019 13:54 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Thursday, October 3, 2019 at 5:37:09 PM UTC-4, Scott Lurndal wrote:
> googlegroups jmfbahciv <jmfbah102162@gmail.com> writes:
>> If you wrote a program,
>> then you had to use the interpreter to print the code on the
>> card. Reading characters printed by an interpreter made
>> people want to repunch cards using a keypunch.
>
> We'd just read the deck and send the images directly to the printer. Much easer than
> farting around trying to read the text on the card.
many sites had an old tabulator left around to do '80-80 listings'
of decks of punched cards. In this way scarce computer time to
list a deck wasn't needed.
However, sometimes it was necessary to know what was on specific
cards in order to fix them, and interpretation was necessary.
As far as I know, in typical practice, the offside printing of the
interpreter was not an issue in production. Cards were not
edited based on the column content. Rather, the cards served as
an output document in themselves, such as a payment check or inventory
record, and the user just read the interpreted results, which could
be, and often was, anywhere on the card.
A separate IBM machine could print an index number on the edge
of the card, but I believe this was not the interpreter (should've
been-edge printing was a useful function.)
>
> On the Burrough systems:
>
> PFM CRDPRN
>
> was sufficient.
|
|
|
|
| Re: Versioning file systems [message #387634 is a reply to message #387596] |
Mon, 07 October 2019 13:57 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Saturday, October 5, 2019 at 7:12:44 PM UTC-4, Dan Espen wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>> On 2019-10-05, googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>>
>>>> On Thursday, October 3, 2019 at 7:54:49 PM UTC-4, Peter Flass wrote:
>>>>
>>>> > The 129 keypunch could interpret. At one site we interpreted them on
>>>> > a 360/20 MFCM that could print 80 columns. I agree interpreters were
>>>> > a royal pain.
>>>>
>>>> And they were so damned slow. I don't think I've ever met
>>>> a 129. How did they work mechanically? Oh, there must have been
>>>> a section which read the holes and then sent them on to print on
>>>> the card?
>>>
>>> Yup. Mechanically the 129 looked a lot like a 029; it just had
>>> more electronics.
>>>
>>>> Or did it punch/print another card. I did that if the
>>>> deck was small (for various flavors of "small") by programming
>>>> a drum card to dup a card on program one and releasing a card
>>>> on program 2. Then I would shuffle the deck I wanted to dup
>>>> with blank cards and then just hit the prog1 and prog2 buttons.
>>>
>>> You gotta do what you gotta do...
>>>
>>>> Reading in a huge deck and then punching a new one with new numbers
>>>> wasn't allowed in my shop. Too much waste of cards :-).
>>>
>>> I once wrote a program that I'd feed cards from the scrap bin;
>>> it would select the blanks into a separate stacker. Given the
>>> amount of waste, I was able to reclaim enough blank cards that
>>> nobody dared complain about my usage.
>>
>> Never thought of that one %-)
>
> Somehow reading cards from the scrap bin sounds like a bad idea.
>
> I can't recall ever being in a shop that cared about card usage.
I once asked about printing on the backside to save paper. They
said absolutely not--too much risk of confusion. They pointed
out the machines were very expensive and the cost of paper
and cards miniscule in comparison.
Many years later we went to double sided printing since the
printers could handle it. Sometimes it was a good idea--besides
saving paper, it made for less bulk and logical for things like
directories. But sometimes it was a bad idea.
|
|
|
|
| Re: Versioning file systems [message #387635 is a reply to message #387633] |
Mon, 07 October 2019 13:57 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com writes:
> On Thursday, October 3, 2019 at 5:37:09 PM UTC-4, Scott Lurndal wrote:
>> googlegroups jmfbahciv <jmfbah102162@gmail.com> writes:
>
>>> If you wrote a program,
>>> then you had to use the interpreter to print the code on the
>>> card. Reading characters printed by an interpreter made
>>> people want to repunch cards using a keypunch.
>>
>> We'd just read the deck and send the images directly to the printer. Much easer than
>> farting around trying to read the text on the card.
>
> many sites had an old tabulator left around to do '80-80 listings'
> of decks of punched cards. In this way scarce computer time to
> list a deck wasn't needed.
>
> However, sometimes it was necessary to know what was on specific
> cards in order to fix them, and interpretation was necessary.
Unless you had a hollerith chart handy... Slow, but effective.
|
|
|
|
| Re: Versioning file systems [message #387636 is a reply to message #387635] |
Mon, 07 October 2019 14:25 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Monday, October 7, 2019 at 1:57:38 PM UTC-4, Scott Lurndal wrote:
> hancock4@bbs.cpcn.com writes:
>> On Thursday, October 3, 2019 at 5:37:09 PM UTC-4, Scott Lurndal wrote:
>>> googlegroups jmfbahciv <jmfbah102162@gmail.com> writes:
>>
>>>> If you wrote a program,
>>>> then you had to use the interpreter to print the code on the
>>>> card. Reading characters printed by an interpreter made
>>>> people want to repunch cards using a keypunch.
>>>
>>> We'd just read the deck and send the images directly to the printer. Much easer than
>>> farting around trying to read the text on the card.
>>
>> many sites had an old tabulator left around to do '80-80 listings'
>> of decks of punched cards. In this way scarce computer time to
>> list a deck wasn't needed.
>>
>> However, sometimes it was necessary to know what was on specific
>> cards in order to fix them, and interpretation was necessary.
>
> Unless you had a hollerith chart handy... Slow, but effective.
In the old days, some sites expected their programmers and
operators to know Hollerith code (basically only letters).
Note that some frugal sites didn't bother with a printer
on their keypunch machines, which was an extra cost option.
Of course, punch outs from the computer or other machines
weren't printed.
Likewise, some telegraph operators had to know Baudot
to handle the paper tapes, despite printing on them in
some cases. They had chadless tape to handle overprint.
|
|
|
|
| Re: Versioning file systems [message #387641 is a reply to message #387634] |
Mon, 07 October 2019 17:00 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-10-07, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
> I once asked about printing on the backside to save paper. They
> said absolutely not--too much risk of confusion. They pointed
> out the machines were very expensive and the cost of paper
> and cards miniscule in comparison.
I used the back side of old listings as scratch paper.
> Many years later we went to double sided printing since the
> printers could handle it. Sometimes it was a good idea--besides
> saving paper, it made for less bulk and logical for things like
> directories. But sometimes it was a bad idea.
One shop I worked in used 8 1/2 x 14 paper, rather than the more
common 11x17 paper. It was much easier to handle; I talked a
couple of other shops into converting. The 11x17 paper covered
your desk pretty thoroughly, and was almost impossible to read
while riding on a bus.
If you printed at 8 lines per inch, you could get as much on
an 8 1/2-inch deep page as on an 11-inch page at 6 lines per
inch. Two lines more, actually (68 vs. 66 if you don't count
top and bottom margins). The closer spacing wasn't too much
of a problem if you used paper with pastel bars printed on it
(a.k.a. "pyjama paper").
Another advantage of the smaller paper is that it fit into
standard legal-size file folders and cabinets, rather than
requiring expensive specialized gear from Wright Line or whoever.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
Members
Search
Help
Register
Login
Home
