| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410453 is a reply to message #410451] |
Sat, 07 August 2021 17:27   |
Harry Vaderchi
Messages: 719
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 7 Aug 2021 20:04:39 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
> undefined Hancock-4 <hancock4@bbs.cpcn.com> schrieb:
>
> [JCL]
>
>> There were convenience features, like stored procedures which were great for
>> compilations. Within a job, we could refer backwards to files created in an
>> earlier job step. We could direct the job to quit if an earlier step failed, or run
>> a special step.
>
> Ah yes, the fabled COND parameter, a wonder of interface design and user
> experience unrivalled since then.
>
Urgh indeed. I was quite taken aback to be told ICL had (George III?) a JCL that was just
simple If Else conditionals.
> I wrote JCL containing a hundred lines or so once, compiling a
> Fortran job on a 3090 to see if there were syntax errors, then
> sending it across to a Fujutsu vector computer which also ran MVS
> or a copy thereof, running the program and then getting back the
> output from there.
--
Bah, and indeed Humbug.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410455 is a reply to message #410449] |
Sat, 07 August 2021 21:13 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, August 8, 2021 at 5:38:58 AM UTC+10, undefined Hancock-4 wrote:
> On Friday, July 23, 2021 at 7:27:56 PM UTC-4, Peter Flass wrote:
>> undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
>>> On Tuesday, July 20, 2021 at 9:46:11 PM UTC-4, John Levine wrote:
>>>> According to undefined Hancock-4 <hanc...@bbs.cpcn.com>:
>>>> > (Given the experience of developing a massive online host and complex
>>>> > application software for SABRE, one wonders why they didn't learn
>>>> > from that when IBM developed OS for S/360 and got so bogged down.)
>>>> The projects were very different. SABRE was a single application realtime
>>>> transaction system. OS was a general purpose system that could run all sorts
>>>> of applicatons.
>>>
>>> I see your point, but I think there are still some common aspects. First,
>>> both were massive programming efforts, pushing the state of the art
>>> at the time, using new, large, powerful computers. Both programming
>>> groups were venturing into new areas (though SABRE had some influence
>>> from SAGE).
>>>
>>> Second, both the SABRE host and S/360-OS had to load in various
>>> modules on demand, execute them, and then release them. Both had
>>> to handle multiple modules running simultaneous, with protection
>>> and control against overlapping memory and I/O demands. All
>>> this is complex as well as new.
>>>
>>> Third, given the nature of both projects, all the programmers were
>>> somewhat inexperienced since it was cutting edge work. Further,
>>> given the size, I suspect some of the programmers were inexperienced
>>> altogether (there weren't that many programmers out there at the time..)
>>>
>>> I can't help but think programmers had to do some experimentation,
>>> which costs time. Some modules probably didn't work out very
>>> well in testing and had to be abandoned or rewritten, wasting
>>> calendar time.
>>>
>>> We know the S/360-OS programmers were under an enormous
>>> time pressure. But I suspect the SABRE people were as well.
>>>
>>>
>> SABRE was designed to do one thing very well. OS was expected to do
>> everything, and therefore wasn’t very good at anything. The Burroughs large
>> systems MCP could run rings around OS/360. It didn’t do everything OS did,
>> but did what had to be done.
> OS was developed to control resources of a large computer system. In the old
> days when memory, peripherals, and CPU speed were scarce yet workloads
> large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
> 800 bpi tape. So we could specify exactly the parameters of the file we were
> creating, including how many tracks it would take up. Not necessary today, but
> important back then. We had different kinds of files, such as library files (PDS).
>
> In looking over JCL, we see a million options. But they were necessary to handle
> many different I/O situations.
>
> For instance, we did things like store multiple independent files on a single reel
> of tape. We produced tapes of many different formats for export to other data
> centers, and likewise we would read such tapes. JCL handled all the options.
>
> We could specify a particular peripheral unit or let the system assign it to us.
> We could utilize spooling for printing, or print hot.
>
> Many times we output to a specialty device that needed special formatting..
>
> There were convenience features, like stored procedures which were great for
> compilations. Within a job, we could refer backwards to files created in an
> earlier job step. We could direct the job to quit if an earlier step failed, or run
> a special step. Output files could be automatically sequenced and old files
> rolled off (generation data group). The location and format of an input file
> could be stored in a catalog, or specified afresh.
>
> I remember a large university data center and the numerous requests to mount
> disk and tapes for specific jobs. The system had to track all that stuff.
>
> This is just scratching the surface.
>
> How did this compare to the JCL of other large scale computer systems?
..
It was overly complex. No need to specify block size and record length
on CDC's Cyber 70 series.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410489 is a reply to message #410449] |
Tue, 10 August 2021 13:57 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote:
> On Friday, July 23, 2021 at 7:27:56 PM UTC-4, Peter Flass wrote:
>> undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
>>> On Tuesday, July 20, 2021 at 9:46:11 PM UTC-4, John Levine wrote:
>>>> According to undefined Hancock-4 <hanc...@bbs.cpcn.com>:
>>>> > (Given the experience of developing a massive online host and complex
>>>> > application software for SABRE, one wonders why they didn't learn
>>>> > from that when IBM developed OS for S/360 and got so bogged down.)
>>>> The projects were very different. SABRE was a single application realtime
>>>> transaction system. OS was a general purpose system that could run all sorts
>>>> of applicatons.
>>>
>>> I see your point, but I think there are still some common aspects. First,
>>> both were massive programming efforts, pushing the state of the art
>>> at the time, using new, large, powerful computers. Both programming
>>> groups were venturing into new areas (though SABRE had some influence
>>> from SAGE).
>>>
>>> Second, both the SABRE host and S/360-OS had to load in various
>>> modules on demand, execute them, and then release them. Both had
>>> to handle multiple modules running simultaneous, with protection
>>> and control against overlapping memory and I/O demands. All
>>> this is complex as well as new.
>>>
>>> Third, given the nature of both projects, all the programmers were
>>> somewhat inexperienced since it was cutting edge work. Further,
>>> given the size, I suspect some of the programmers were inexperienced
>>> altogether (there weren't that many programmers out there at the time.)
>>>
>>> I can't help but think programmers had to do some experimentation,
>>> which costs time. Some modules probably didn't work out very
>>> well in testing and had to be abandoned or rewritten, wasting
>>> calendar time.
>>>
>>> We know the S/360-OS programmers were under an enormous
>>> time pressure. But I suspect the SABRE people were as well.
>>>
>>>
>> SABRE was designed to do one thing very well. OS was expected to do
>> everything, and therefore wasn’t very good at anything. The Burroughs large
>> systems MCP could run rings around OS/360. It didn’t do everything OS did,
>> but did what had to be done.
>
>
> OS was developed to control resources of a large computer system. In the old
> days when memory, peripherals, and CPU speed were scarce yet workloads
> large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
> 800 bpi tape. So we could specify exactly the parameters of the file we were
> creating, including how many tracks it would take up. Not necessary today, but
> important back then. We had different kinds of files, such as library files (PDS).
>
> In looking over JCL, we see a million options. But they were necessary to handle
> many different I/O situations.
>
> For instance, we did things like store multiple independent files on a single reel
> of tape. We produced tapes of many different formats for export to other data
> centers, and likewise we would read such tapes. JCL handled all the options.
>
> We could specify a particular peripheral unit or let the system assign it to us.
> We could utilize spooling for printing, or print hot.
>
> Many times we output to a specialty device that needed special formatting.
>
> There were convenience features, like stored procedures which were great for
> compilations. Within a job, we could refer backwards to files created in an
> earlier job step. We could direct the job to quit if an earlier step failed, or run
> a special step. Output files could be automatically sequenced and old files
> rolled off (generation data group). The location and format of an input file
> could be stored in a catalog, or specified afresh.
>
> I remember a large university data center and the numerous requests to mount
> disk and tapes for specific jobs. The system had to track all that stuff.
>
> This is just scratching the surface.
>
> How did this compare to the JCL of other large scale computer systems?
>
You could do 90% of the stuff with 20% of the complexity. Burroughs large
system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job
card and an execute card was about it. Things like DSNs were coded in the
program, although they could be overridden in exceptional cases. I don’t
think the systems supported a lot of exotic peripherals or options.
--
Pete
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410490 is a reply to message #410489] |
Tue, 10 August 2021 14:29 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2021-08-10, Peter Flass <peter_flass@yahoo.com> wrote:
> undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote:
>
>> In looking over JCL, we see a million options. But they were necessary
>> to handle many different I/O situations.
<snip>
>> How did this compare to the JCL of other large scale computer systems?
>
> You could do 90% of the stuff with 20% of the complexity. Burroughs large
> system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job
> card and an execute card was about it. Things like DSNs were coded in the
> program, although they could be overridden in exceptional cases. I don’t
> think the systems supported a lot of exotic peripherals or options.
A friend worked in a small Burroughs shop (1700). I think it wasn't
so much that not many peripherals were supported, but that the system
had a lot of device independence. You didn't need a special procedure
for each device, but just pointed your program at whatever device you
wanted to use and let the MCP sort it out. Also, there wasn't such a
plethora of file formats. I always hated the amount of work you had
to do to access a program module (source or binary) on a traditional
mainframe system. Mind you, given the overhead of each file (look
at the VTOC layout, for instance), storing each program module in
a separate file was simply not feasible in that environment.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410491 is a reply to message #410455] |
Tue, 10 August 2021 14:45 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Saturday, August 7, 2021 at 9:13:26 PM UTC-4, Robin Vowels wrote:
> On Sunday, August 8, 2021 at 5:38:58 AM UTC+10, undefined Hancock-4 wrote:
>> On Friday, July 23, 2021 at 7:27:56 PM UTC-4, Peter Flass wrote:
>>> undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
>>>> On Tuesday, July 20, 2021 at 9:46:11 PM UTC-4, John Levine wrote:
>>>> > According to undefined Hancock-4 <hanc...@bbs.cpcn.com>:
>>>> >> (Given the experience of developing a massive online host and complex
>>>> >> application software for SABRE, one wonders why they didn't learn
>>>> >> from that when IBM developed OS for S/360 and got so bogged down.)
>>>> > The projects were very different. SABRE was a single application realtime
>>>> > transaction system. OS was a general purpose system that could run all sorts
>>>> > of applicatons.
>>>>
>>>> I see your point, but I think there are still some common aspects. First,
>>>> both were massive programming efforts, pushing the state of the art
>>>> at the time, using new, large, powerful computers. Both programming
>>>> groups were venturing into new areas (though SABRE had some influence
>>>> from SAGE).
>>>>
>>>> Second, both the SABRE host and S/360-OS had to load in various
>>>> modules on demand, execute them, and then release them. Both had
>>>> to handle multiple modules running simultaneous, with protection
>>>> and control against overlapping memory and I/O demands. All
>>>> this is complex as well as new.
>>>>
>>>> Third, given the nature of both projects, all the programmers were
>>>> somewhat inexperienced since it was cutting edge work. Further,
>>>> given the size, I suspect some of the programmers were inexperienced
>>>> altogether (there weren't that many programmers out there at the time.)
>>>>
>>>> I can't help but think programmers had to do some experimentation,
>>>> which costs time. Some modules probably didn't work out very
>>>> well in testing and had to be abandoned or rewritten, wasting
>>>> calendar time.
>>>>
>>>> We know the S/360-OS programmers were under an enormous
>>>> time pressure. But I suspect the SABRE people were as well.
>>>>
>>>>
>>> SABRE was designed to do one thing very well. OS was expected to do
>>> everything, and therefore wasn’t very good at anything. The Burroughs large
>>> systems MCP could run rings around OS/360. It didn’t do everything OS did,
>>> but did what had to be done.
>> OS was developed to control resources of a large computer system. In the old
>> days when memory, peripherals, and CPU speed were scarce yet workloads
>> large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
>> 800 bpi tape. So we could specify exactly the parameters of the file we were
>> creating, including how many tracks it would take up. Not necessary today, but
>> important back then. We had different kinds of files, such as library files (PDS).
>>
>> In looking over JCL, we see a million options. But they were necessary to handle
>> many different I/O situations.
>>
>> For instance, we did things like store multiple independent files on a single reel
>> of tape. We produced tapes of many different formats for export to other data
>> centers, and likewise we would read such tapes. JCL handled all the options.
>>
>> We could specify a particular peripheral unit or let the system assign it to us.
>> We could utilize spooling for printing, or print hot.
>>
>> Many times we output to a specialty device that needed special formatting.
>>
>> There were convenience features, like stored procedures which were great for
>> compilations. Within a job, we could refer backwards to files created in an
>> earlier job step. We could direct the job to quit if an earlier step failed, or run
>> a special step. Output files could be automatically sequenced and old files
>> rolled off (generation data group). The location and format of an input file
>> could be stored in a catalog, or specified afresh.
>>
>> I remember a large university data center and the numerous requests to mount
>> disk and tapes for specific jobs. The system had to track all that stuff.
>>
>> This is just scratching the surface.
>>
>> How did this compare to the JCL of other large scale computer systems?
> .
> It was overly complex. No need to specify block size and record length
> on CDC's Cyber 70 series.
It appeared that the Cyber 70 was about ten years newer than S/360, so perhaps
disk blocking and usage was more efficient. But blocking is important, be it
handled automatically by software (as Z series does now) or by the programmer.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410492 is a reply to message #410451] |
Tue, 10 August 2021 14:49 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Saturday, August 7, 2021 at 4:04:40 PM UTC-4, Thomas Koenig wrote:
> undefined Hancock-4 <hanc...@bbs.cpcn.com> schrieb:
>
> [JCL]
>> There were convenience features, like stored procedures which were great for
>> compilations. Within a job, we could refer backwards to files created in an
>> earlier job step. We could direct the job to quit if an earlier step failed, or run
>> a special step.
> Ah yes, the fabled COND parameter, a wonder of interface design and user
> experience unrivalled since then.
Yes, the COND parameter was counter-intuitive. Saying COND=(0,NE) meant
to run the step, not ignore the step. Even the developer, Fred Brooks, said
it was a lousy design.
But it was a powerful tool to handle a multitude of trouble situations. A program
could set the condition code. There was an option to write a message to the
operator. In more recent years, one could issue an email from the job in case
of a problem, and various emails depending on the problem. Or, upon successful completion.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410493 is a reply to message #410489] |
Tue, 10 August 2021 14:54 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Tuesday, August 10, 2021 at 1:57:35 PM UTC-4, Peter Flass wrote:
> You could do 90% of the stuff with 20% of the complexity. Burroughs large
> system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job
> card and an execute card was about it. Things like DSNs were coded in the
> program, although they could be overridden in exceptional cases. I don’t
> think the systems supported a lot of exotic peripherals or options.
It wasn't every day, but periodically we had to write special JCL to handle
a special imported or exported file. We'd have to look up options in the JCL
manual, like bypassing standard label records, getting to multiple files on
a tape, or special formatting. For instance, almost all files were in standard
format, but every so often we'd use option U. All those commas for
positional parameters!
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410495 is a reply to message #410492] |
Tue, 10 August 2021 15:34 |
|
|
Originally posted by: J. Clarke
On Tue, 10 Aug 2021 11:49:07 -0700 (PDT), undefined Hancock-4
<hancock4@bbs.cpcn.com> wrote:
> On Saturday, August 7, 2021 at 4:04:40 PM UTC-4, Thomas Koenig wrote:
>> undefined Hancock-4 <hanc...@bbs.cpcn.com> schrieb:
>>
>> [JCL]
>>> There were convenience features, like stored procedures which were great for
>>> compilations. Within a job, we could refer backwards to files created in an
>>> earlier job step. We could direct the job to quit if an earlier step failed, or run
>>> a special step.
>> Ah yes, the fabled COND parameter, a wonder of interface design and user
>> experience unrivalled since then.
>
> Yes, the COND parameter was counter-intuitive. Saying COND=(0,NE) meant
> to run the step, not ignore the step. Even the developer, Fred Brooks, said
> it was a lousy design.
>
> But it was a powerful tool to handle a multitude of trouble situations. A program
> could set the condition code. There was an option to write a message to the
> operator. In more recent years, one could issue an email from the job in case
> of a problem, and various emails depending on the problem. Or, upon successful completion.
There's a particular job where one of these days I'm going to set it
up to send me an email, and on receipt of the email have Windows
retrieve and do stuff with the output.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410496 is a reply to message #410489] |
Tue, 10 August 2021 15:44 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote:
>> I remember a large university data center and the numerous requests to mount
>> disk and tapes for specific jobs. The system had to track all that stuff.
>>
>> This is just scratching the surface.
>>
>> How did this compare to the JCL of other large scale computer systems?
>>
>
> You could do 90% of the stuff with 20% of the complexity. Burroughs large
> system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job
> card and an execute card was about it. Things like DSNs were coded in the
> program, although they could be overridden in exceptional cases. I don’t
> think the systems supported a lot of exotic peripherals or options.
Actually, there were a fair number of peripherals supported, including
MICR reader/sorters, various types of tape drives, 100-byte and
180-byte sector media (disk vs. pack), tape listers (finance),
high-speed host interconnects, terminal controllers, etc et al.
The command language was simple. The filesystems (both disk and pack)
were extent-based and normally the MCP was responsible for allocation,
the application specified record size, block size, etc in the file
information block (FIB) in the application.
?EX PROGRAM; MEM + 300
?FILE INPUT = FRED CRD
?FILE OUTPUT = FREDOT PBK
?FILE ARCHIVE = FREDTP MTP
which would direct the internal file INPUT to a card deck
named 'FRED' (either from a real reader or a pseudo-card reader that reads disk files).
The output listing would go to printer backup (i.e. on disk); specify PRN instead and the
output would go to a printer named FREDOT automatically if the printer is ready (all printers
could be named).
If PROGRAM opened ARCHIVE, the MCP would look for a mounted tape named
FREDTP, and if not found, would suspend the program until the operator
mounted the tape and made the unit ready, or if the program opened the
tape OUTPUT, then the MCP would look for a mounted scratch tape, or suspend
the program until a scratch tape was ready on any drive (assigned by
the operator if necessary).
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410499 is a reply to message #410491] |
Wed, 11 August 2021 09:36 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, August 11, 2021 at 4:45:14 AM UTC+10, undefined Hancock-4 wrote:
> On Saturday, August 7, 2021 at 9:13:26 PM UTC-4, Robin Vowels wrote:
>> On Sunday, August 8, 2021 at 5:38:58 AM UTC+10, undefined Hancock-4 wrote:
>>> On Friday, July 23, 2021 at 7:27:56 PM UTC-4, Peter Flass wrote:
>>>> undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
>>>> > On Tuesday, July 20, 2021 at 9:46:11 PM UTC-4, John Levine wrote:
>>>> >> According to undefined Hancock-4 <hanc...@bbs.cpcn.com>:
>>>> >>> (Given the experience of developing a massive online host and complex
>>>> >>> application software for SABRE, one wonders why they didn't learn
>>>> >>> from that when IBM developed OS for S/360 and got so bogged down.)
>>>> >> The projects were very different. SABRE was a single application realtime
>>>> >> transaction system. OS was a general purpose system that could run all sorts
>>>> >> of applicatons.
>>>> >
>>>> > I see your point, but I think there are still some common aspects.. First,
>>>> > both were massive programming efforts, pushing the state of the art
>>>> > at the time, using new, large, powerful computers. Both programming
>>>> > groups were venturing into new areas (though SABRE had some influence
>>>> > from SAGE).
>>>> >
>>>> > Second, both the SABRE host and S/360-OS had to load in various
>>>> > modules on demand, execute them, and then release them. Both had
>>>> > to handle multiple modules running simultaneous, with protection
>>>> > and control against overlapping memory and I/O demands. All
>>>> > this is complex as well as new.
>>>> >
>>>> > Third, given the nature of both projects, all the programmers were
>>>> > somewhat inexperienced since it was cutting edge work. Further,
>>>> > given the size, I suspect some of the programmers were inexperienced
>>>> > altogether (there weren't that many programmers out there at the time.)
>>>> >
>>>> > I can't help but think programmers had to do some experimentation,
>>>> > which costs time. Some modules probably didn't work out very
>>>> > well in testing and had to be abandoned or rewritten, wasting
>>>> > calendar time.
>>>> >
>>>> > We know the S/360-OS programmers were under an enormous
>>>> > time pressure. But I suspect the SABRE people were as well.
>>>> >
>>>> >
>>>> SABRE was designed to do one thing very well. OS was expected to do
>>>> everything, and therefore wasn’t very good at anything. The Burroughs large
>>>> systems MCP could run rings around OS/360. It didn’t do everything OS did,
>>>> but did what had to be done.
>>> OS was developed to control resources of a large computer system. In the old
>>> days when memory, peripherals, and CPU speed were scarce yet workloads
>>> large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
>>> 800 bpi tape. So we could specify exactly the parameters of the file we were
>>> creating, including how many tracks it would take up. Not necessary today, but
>>> important back then. We had different kinds of files, such as library files (PDS).
>>>
>>> In looking over JCL, we see a million options. But they were necessary to handle
>>> many different I/O situations.
>>>
>>> For instance, we did things like store multiple independent files on a single reel
>>> of tape. We produced tapes of many different formats for export to other data
>>> centers, and likewise we would read such tapes. JCL handled all the options.
>>>
>>> We could specify a particular peripheral unit or let the system assign it to us.
>>> We could utilize spooling for printing, or print hot.
>>>
>>> Many times we output to a specialty device that needed special formatting.
>>>
>>> There were convenience features, like stored procedures which were great for
>>> compilations. Within a job, we could refer backwards to files created in an
>>> earlier job step. We could direct the job to quit if an earlier step failed, or run
>>> a special step. Output files could be automatically sequenced and old files
>>> rolled off (generation data group). The location and format of an input file
>>> could be stored in a catalog, or specified afresh.
>>>
>>> I remember a large university data center and the numerous requests to mount
>>> disk and tapes for specific jobs. The system had to track all that stuff.
>>>
>>> This is just scratching the surface.
>>>
>>> How did this compare to the JCL of other large scale computer systems?
>> .
>> It was overly complex. No need to specify block size and record length
>> on CDC's Cyber 70 series.
..
> It appeared that the Cyber 70 was about ten years newer than S/360, so perhaps
> disk blocking and usage was more efficient. But blocking is important, be it
> handled automatically by software (as Z series does now) or by the programmer.
..
The operating system Kronos on the Cyber 70 series was derived from
that on the earlier 6600 series, predating the S/360.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410500 is a reply to message #410499] |
Wed, 11 August 2021 11:00 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> wrote:
> On Wednesday, August 11, 2021 at 4:45:14 AM UTC+10, undefined Hancock-4 wrote:
>> On Saturday, August 7, 2021 at 9:13:26 PM UTC-4, Robin Vowels wrote:
>>> On Sunday, August 8, 2021 at 5:38:58 AM UTC+10, undefined Hancock-4 wrote:
>>>> On Friday, July 23, 2021 at 7:27:56 PM UTC-4, Peter Flass wrote:
>>>> > undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
>>>> >> On Tuesday, July 20, 2021 at 9:46:11 PM UTC-4, John Levine wrote:
>>>> >>> According to undefined Hancock-4 <hanc...@bbs.cpcn.com>:
>>>> >>>> (Given the experience of developing a massive online host and complex
>>>> >>>> application software for SABRE, one wonders why they didn't learn
>>>> >>>> from that when IBM developed OS for S/360 and got so bogged down.)
>>>> >>> The projects were very different. SABRE was a single application realtime
>>>> >>> transaction system. OS was a general purpose system that could run all sorts
>>>> >>> of applicatons.
>>>> >>
>>>> >> I see your point, but I think there are still some common aspects. First,
>>>> >> both were massive programming efforts, pushing the state of the art
>>>> >> at the time, using new, large, powerful computers. Both programming
>>>> >> groups were venturing into new areas (though SABRE had some influence
>>>> >> from SAGE).
>>>> >>
>>>> >> Second, both the SABRE host and S/360-OS had to load in various
>>>> >> modules on demand, execute them, and then release them. Both had
>>>> >> to handle multiple modules running simultaneous, with protection
>>>> >> and control against overlapping memory and I/O demands. All
>>>> >> this is complex as well as new.
>>>> >>
>>>> >> Third, given the nature of both projects, all the programmers were
>>>> >> somewhat inexperienced since it was cutting edge work. Further,
>>>> >> given the size, I suspect some of the programmers were inexperienced
>>>> >> altogether (there weren't that many programmers out there at the time.)
>>>> >>
>>>> >> I can't help but think programmers had to do some experimentation,
>>>> >> which costs time. Some modules probably didn't work out very
>>>> >> well in testing and had to be abandoned or rewritten, wasting
>>>> >> calendar time.
>>>> >>
>>>> >> We know the S/360-OS programmers were under an enormous
>>>> >> time pressure. But I suspect the SABRE people were as well.
>>>> >>
>>>> >>
>>>> > SABRE was designed to do one thing very well. OS was expected to do
>>>> > everything, and therefore wasn’t very good at anything. The Burroughs large
>>>> > systems MCP could run rings around OS/360. It didn’t do everything OS did,
>>>> > but did what had to be done.
>>>> OS was developed to control resources of a large computer system. In the old
>>>> days when memory, peripherals, and CPU speed were scarce yet workloads
>>>> large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
>>>> 800 bpi tape. So we could specify exactly the parameters of the file we were
>>>> creating, including how many tracks it would take up. Not necessary today, but
>>>> important back then. We had different kinds of files, such as library files (PDS).
>>>>
>>>> In looking over JCL, we see a million options. But they were necessary to handle
>>>> many different I/O situations.
>>>>
>>>> For instance, we did things like store multiple independent files on a single reel
>>>> of tape. We produced tapes of many different formats for export to other data
>>>> centers, and likewise we would read such tapes. JCL handled all the options.
>>>>
>>>> We could specify a particular peripheral unit or let the system assign it to us.
>>>> We could utilize spooling for printing, or print hot.
>>>>
>>>> Many times we output to a specialty device that needed special formatting.
>>>>
>>>> There were convenience features, like stored procedures which were great for
>>>> compilations. Within a job, we could refer backwards to files created in an
>>>> earlier job step. We could direct the job to quit if an earlier step failed, or run
>>>> a special step. Output files could be automatically sequenced and old files
>>>> rolled off (generation data group). The location and format of an input file
>>>> could be stored in a catalog, or specified afresh.
>>>>
>>>> I remember a large university data center and the numerous requests to mount
>>>> disk and tapes for specific jobs. The system had to track all that stuff.
>>>>
>>>> This is just scratching the surface.
>>>>
>>>> How did this compare to the JCL of other large scale computer systems?
>>> .
>>> It was overly complex. No need to specify block size and record length
>>> on CDC's Cyber 70 series.
> .
>> It appeared that the Cyber 70 was about ten years newer than S/360, so perhaps
>> disk blocking and usage was more efficient. But blocking is important, be it
>> handled automatically by software (as Z series does now) or by the programmer.
> .
> The operating system Kronos on the Cyber 70 series was derived from
> that on the earlier 6600 series, predating the S/360.
>
I never thought of CDC operating systems as particularly advanced, though.
It seems like they got the job done, but without a lot of frills. Sort of
like the hardware.
--
Pete
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410505 is a reply to message #410496] |
Fri, 13 August 2021 15:26 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Tuesday, August 10, 2021 at 3:44:16 PM UTC-4, Scott Lurndal wrote:
> Peter Flass <peter...@yahoo.com> writes:
>> You could do 90% of the stuff with 20% of the complexity. Burroughs large
>> system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job
>> card and an execute card was about it. Things like DSNs were coded in the
>> program, although they could be overridden in exceptional cases. I don’t
>> think the systems supported a lot of exotic peripherals or options.
> Actually, there were a fair number of peripherals supported, including
> MICR reader/sorters, various types of tape drives, 100-byte and
> 180-byte sector media (disk vs. pack), tape listers (finance),
> high-speed host interconnects, terminal controllers, etc et al.
Interestingly, one of the 'non standard' peripherals we attached was a Burroughs
microfiche printer. On 360-OS, it was very easy, just changed one parameter on the
JCL. OS had device independence, so program changes and recompilations were
not necessary to change devices. Major advantage.
However, on 360-DOS, it was necessary to recompile the program since the device
was specified in the program code.
As an aside, those microfiche printers were slick machines. Produced very high quality
cards. Automatically produced the appropriate visible index at the top or with minimal
setup. Saved a huge volume of paper, big savings in storage space and the visible index
was faster to locate data.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410506 is a reply to message #410505] |
Fri, 13 August 2021 15:49 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
undefined Hancock-4 <hancock4@bbs.cpcn.com> writes:
> Interestingly, one of the 'non standard' peripherals we attached was a Burroughs
> microfiche printer. On 360-OS, it was very easy, just changed one parameter on the
> JCL. OS had device independence, so program changes and recompilations were
> not necessary to change devices. Major advantage.
>
> However, on 360-DOS, it was necessary to recompile the program since the device
> was specified in the program code.
>
> As an aside, those microfiche printers were slick machines. Produced very high quality
> cards. Automatically produced the appropriate visible index at the top or with minimal
> setup. Saved a huge volume of paper, big savings in storage space and the visible index
> was faster to locate data.
home office 1977/1978, cdi miniterm, ibm tieline, and compact microfiche
viewer. plant site had microfiche printer and could get 24hr turn around
.... had couple hundred microfiche at home, source listings,
documentation, etc.
http://www.garlic.com/~lynn/miniterm.jpg
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410517 is a reply to message #410506] |
Mon, 16 August 2021 15:52 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Friday, August 13, 2021 at 3:49:41 PM UTC-4, ly...@garlic.com wrote:
>> As an aside, those microfiche printers were slick machines. Produced very high quality
>> cards. Automatically produced the appropriate visible index at the top or with minimal
>> setup. Saved a huge volume of paper, big savings in storage space and the visible index
>> was faster to locate data.
> home office 1977/1978, cdi miniterm, ibm tieline, and compact microfiche
> viewer. plant site had microfiche printer and could get 24hr turn around
> ... had couple hundred microfiche at home, source listings,
> documentation, etc.
Someone somehow hacked into the microfiche system and printed a bunch of pictures.
When my boss retired he gave me an envelope, "here, you might like this". It wasn't source code.
In the old days, people printed pictures from the line printer, which were very coarse. Some
had some shading to them by using different characters and overprinting. Can't imagine
anyone doing that today, let alone hanging them up in their cube.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410519 is a reply to message #410517] |
Mon, 16 August 2021 16:06 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
undefined Hancock-4 <hancock4@bbs.cpcn.com> writes:
> On Friday, August 13, 2021 at 3:49:41 PM UTC-4, ly...@garlic.com wrote:
>
>>> As an aside, those microfiche printers were slick machines. Produced very high quality
>>> cards. Automatically produced the appropriate visible index at the top or with minimal
>>> setup. Saved a huge volume of paper, big savings in storage space and the visible index
>>> was faster to locate data.
>> home office 1977/1978, cdi miniterm, ibm tieline, and compact microfiche
>> viewer. plant site had microfiche printer and could get 24hr turn around
>> ... had couple hundred microfiche at home, source listings,
>> documentation, etc.
>
> Someone somehow hacked into the microfiche system and printed a bunch of pictures.
> When my boss retired he gave me an envelope, "here, you might like this". It wasn't source code.
>
> In the old days, people printed pictures from the line printer, which were very coarse. Some
> had some shading to them by using different characters and overprinting. Can't imagine
> anyone doing that today, let alone hanging them up in their cube.
I've got one of those of myself (done with a 256-gray-scale capture system
in 1981).
I still have a copy of the 9track poster tape that was handed around in those
days - there's a poster of a 727 going over the golden gate bridge that required
taping several full-width listing side by each, and a really nice on
of the moon (the finished moon was about 2' in diameter when all the pieces
were taped together), and a handful of tame (by modern standards) topless
models.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410526 is a reply to message #410519] |
Mon, 16 August 2021 19:31 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2021-08-16, Scott Lurndal <scott@slp53.sl.home> wrote:
> undefined Hancock-4 <hancock4@bbs.cpcn.com> writes:
>
>> In the old days, people printed pictures from the line printer, which
>> were very coarse. Some had some shading to them by using different
>> characters and overprinting. Can't imagine anyone doing that today,
>> let alone hanging them up in their cube.
>
> I've got one of those of myself (done with a 256-gray-scale capture
> system in 1981).
>
> I still have a copy of the 9track poster tape that was handed around
> in those days - there's a poster of a 727 going over the golden gate
> bridge that required taping several full-width listing side by each,
> and a really nice on of the moon (the finished moon was about 2' in
> diameter when all the pieces were taped together), and a handful of
> tame (by modern standards) topless models.
I have one of those tapes myself. On mine the moon is about 5 feet
across. Another nice one was of Spock holding a model of the Enterprise.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410529 is a reply to message #410526] |
Tue, 17 August 2021 11:41 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> On 2021-08-16, Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> undefined Hancock-4 <hancock4@bbs.cpcn.com> writes:
>>
>>> In the old days, people printed pictures from the line printer, which
>>> were very coarse. Some had some shading to them by using different
>>> characters and overprinting. Can't imagine anyone doing that today,
>>> let alone hanging them up in their cube.
>>
>> I've got one of those of myself (done with a 256-gray-scale capture
>> system in 1981).
>>
>> I still have a copy of the 9track poster tape that was handed around
>> in those days - there's a poster of a 727 going over the golden gate
>> bridge that required taping several full-width listing side by each,
>> and a really nice on of the moon (the finished moon was about 2' in
>> diameter when all the pieces were taped together), and a handful of
>> tame (by modern standards) topless models.
>
> I have one of those tapes myself. On mine the moon is about 5 feet
> across. Another nice one was of Spock holding a model of the Enterprise.
Yeah, 5' sounds right. I haven't seen my copy of the poster in
decades, it may still be in a box in storage. The enterprise poster
is on that tape.
I did read the tape yesterday on the Burroughs Simulator (it is
an ANSI labeled EBCDIC tape); I should get the old dot matrix epson
132-column printer out of storage and (if I can find a parallel
port and new ribbon anywhere :-) see if I can't print a couple of the posters.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410548 is a reply to message #410529] |
Wed, 18 August 2021 12:38 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
scott@slp53.sl.home (Scott Lurndal) writes:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>
>> I have one of those tapes myself. On mine the moon is about 5 feet
>> across. Another nice one was of Spock holding a model of the Enterprise.
> I did read the tape yesterday on the Burroughs Simulator (it is
> an ANSI labeled EBCDIC tape); I should get the old dot matrix epson
> 132-column printer out of storage and (if I can find a parallel
> port and new ribbon anywhere :-) see if I can't print a couple of the posters.
>
$ (cd /work/4mmtapes/chm/; dd if=poster_890825_1600.tap conv=ascii | strings | grep -i hdr1)
HDR1SMALL.CAT POSTER00010001 77051 000000000000
HDR1LARGE.CAT POSTER00010002 77051 000000000000
HDR1SMALL.DOG POSTER00010003 77051 000000000000
HDR1LARGE.DOG POSTER00010004 77051 000000000000
HDR1SMALL.NUDE POSTER00010005 77051 000000000000
HDR1LARGE.NUDE POSTER00010006 77051 000000000000
HDR1PICASSO.SYLVETTE POSTER00010007 77051 000000000000
HDR1EINSTEIN POSTER00010008 77051 000000000000
HDR1MOUTN.CLIMBER POSTER00010009 77051 000000000000
HDR1MR.SPOCK POSTER00010010 77051 000000000000
HDR1ARMSTRNG.ON.MOON POSTER00010011 77051 000000000000
HDR1DEAN.AND.NIXON POSTER00010012 77051 000000000000
HDR1MOON POSTER00010013 77051 000000000000
HDR1BEETHOVN POSTER00010014 77051 000000000000
HDR1PLANE.B727 POSTER00010015 77051 000000000000
HDR1ISU.CY POSTER00010016 77054 000000000000
HDR1CLIPPER.SHIP POSTER00010017 77054 000000000000
HDR1MONA.LISA POSTER00010018 77054 000000000000
HDR1PIECE.OF.PI POSTER00010019 77054 000000000000
HDR1CAPN.ANDY POSTER00010020 77054 000000000000
HDR1DOG POSTER00010021 77054 000000000000
HDR1ECOLOGY POSTER00010022 77054 000000000000
HDR1PEACE.SYMBOL POSTER00010023 77054 000000000000
HDR1ALFRED POSTER00010024 77054 000000000000
HDR1EDITH POSTER00010025 77054 000000000000
HDR1RAQUEL.WELCH POSTER00010026 77054 000000000000
HDR1JFK POSTER00010027 77054 000000000000
HDR1JFK POSTER00010028 77054 000000000000
HDR1ROAD.RUNNER POSTER00010029 77054 000000000000
HDR1ROAD.RUNNER POSTER00010030 77054 000000000000
HDR1GOOD.GRIEF POSTER00010031 77054 000000000000
HDR1CHARLIE.BROWN POSTER00010032 77054 000000000000
HDR1LINUS POSTER00010033 77054 000000000000
HDR1LUCY POSTER00010034 77054 000000000000
HDR1SCHROEDR POSTER00010035 77054 000000000000
HDR1SNOOPY POSTER00010036 77054 000000000000
HDR1SNOOPY POSTER00010037 77054 000000000000
HDR1SNOOPY POSTER00010038 77054 000000000000
HDR1SNOOPY.ACE POSTER00010039 77054 000000000000
HDR1SNOOPY.CURSE POSTER00010040 77054 000000000000
HDR1SNOOPY.DISH POSTER00010041 77054 000000000000
HDR1SNOOPY.HANG POSTER00010042 77054 000000000000
HDR1SNOOPY.HANG.ON POSTER00010043 77054 000000000000
HDR1SNOOPY.HUG POSTER00010044 77054 000000000000
HDR1SNOOPY.PUNT POSTER00010045 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010046 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010047 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010048 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010049 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010050 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010051 77054 000000000000
HDR1NUDE POSTER00010052 77054 000000000000
HDR1NUDE POSTER00010053 77054 000000000000
HDR1NUDE POSTER00010054 77054 000000000000
HDR1NUDE.DOT POSTER00010055 77054 000000000000
HDR1NUDE.MIRROR POSTER00010056 77054 000000000000
HDR1NUDE.MISS.JUNE POSTER00010057 77054 000000000000
HDR1NUDE.RECLING POSTER00010058 77054 000000000000
HDR1NUDE.RECLING POSTER00010059 77054 000000000000
HDR1NUDE.STOOL POSTER00010060 77054 000000000000
HDR1NUDE.STOOL POSTER00010061 77054 000000000000
HDR1NUDE.STOOL POSTER00010062 77054 000000000000
HDR1NUDE.STOOL POSTER00010063 77054 000000000000
HDR1NUDE.STOOL POSTER00010064 77054 000000000000
HDR1NUDE.STOOL POSTER00010065 77054 000000000000
HDR1NUDE.STOOL POSTER00010066 77054 000000000000
HDR1LBJ POSTER00010067 77054 000000000000
HDR1XMAS.VIRGIN.MARY POSTER00010068 77054 000000000000
HDR1XMAS.WREATH POSTER00010069 77054 000000000000
HDR1XMAS.WREATH.MCHNYPOSTER00010070 77054 000000000000
HDR1XMAS.SANTA POSTER00010071 77055 000000000000
HDR1XMAS.SOLTICE POSTER00010072 77055 000000000000
HDR1XMAS.JOY POSTER00010073 77055 000000000000
HDR1XMAS.WISE.MEN POSTER00010074 77055 000000000000
HDR1XMAS.MERRY.XMAS POSTER00010075 77055 000000000000
HDR1XMAS.MERRY.XMAS POSTER00010076 77055 000000000000
HDR1XMAS.RAINDEER POSTER00010077 77055 000000000000
HDR1XMAS.RAINDEER POSTER00010078 77055 000000000000
HDR1XMAS.RAINDEER POSTER00010079 77060 000000000000
HDR1PLI.UNCOBOL POSTER00010080 77335 000000000000
HDR1SNOOPY.RUDE POSTER00010081 77343 000000000000
HDR1LINUS.PEACE POSTER00010082 77343 000000000000
HDR1SNOOPY.HOP POSTER00010083 77343 000000000000
HDR1STARSHIP POSTER00010084 80034 000000000000IBM OS/VS 370382 &
HDR1STARWARS POSTER00010085 81199 000000000000IBM OS/VS 370383 &
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410549 is a reply to message #410548] |
Wed, 18 August 2021 13:29 |
Harry Vaderchi
Messages: 719
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 18 Aug 2021 16:38:21 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>
>>>
>>> I have one of those tapes myself. On mine the moon is about 5 feet
>>> across. Another nice one was of Spock holding a model of the Enterprise.
>
>> I did read the tape yesterday on the Burroughs Simulator (it is
>> an ANSI labeled EBCDIC tape); I should get the old dot matrix epson
>> 132-column printer out of storage and (if I can find a parallel
>> port and new ribbon anywhere :-) see if I can't print a couple of the posters.
>>
> $ (cd /work/4mmtapes/chm/; dd if=poster_890825_1600.tap conv=ascii | strings | grep -i hdr1)
> HDR1SMALL.CAT POSTER00010001 77051 000000000000
> HDR1LARGE.CAT POSTER00010002 77051 000000000000
> HDR1SMALL.DOG POSTER00010003 77051 000000000000
> HDR1LARGE.DOG POSTER00010004 77051 000000000000
> HDR1SMALL.NUDE POSTER00010005 77051 000000000000
> HDR1LARGE.NUDE POSTER00010006 77051 000000000000
> HDR1PICASSO.SYLVETTE POSTER00010007 77051 000000000000
> HDR1EINSTEIN POSTER00010008 77051 000000000000
> HDR1MOUTN.CLIMBER POSTER00010009 77051 000000000000
> HDR1MR.SPOCK POSTER00010010 77051 000000000000
> HDR1ARMSTRNG.ON.MOON POSTER00010011 77051 000000000000
> HDR1DEAN.AND.NIXON POSTER00010012 77051 000000000000
> HDR1MOON POSTER00010013 77051 000000000000
> HDR1BEETHOVN POSTER00010014 77051 000000000000
> HDR1PLANE.B727 POSTER00010015 77051 000000000000
> HDR1ISU.CY POSTER00010016 77054 000000000000
> HDR1CLIPPER.SHIP POSTER00010017 77054 000000000000
> HDR1MONA.LISA POSTER00010018 77054 000000000000
> HDR1PIECE.OF.PI POSTER00010019 77054 000000000000
> HDR1CAPN.ANDY POSTER00010020 77054 000000000000
> HDR1DOG POSTER00010021 77054 000000000000
> HDR1ECOLOGY POSTER00010022 77054 000000000000
> HDR1PEACE.SYMBOL POSTER00010023 77054 000000000000
> HDR1ALFRED POSTER00010024 77054 000000000000
> HDR1EDITH POSTER00010025 77054 000000000000
> HDR1RAQUEL.WELCH POSTER00010026 77054 000000000000
> HDR1JFK POSTER00010027 77054 000000000000
> HDR1JFK POSTER00010028 77054 000000000000
> HDR1ROAD.RUNNER POSTER00010029 77054 000000000000
> HDR1ROAD.RUNNER POSTER00010030 77054 000000000000
> HDR1GOOD.GRIEF POSTER00010031 77054 000000000000
> HDR1CHARLIE.BROWN POSTER00010032 77054 000000000000
> HDR1LINUS POSTER00010033 77054 000000000000
> HDR1LUCY POSTER00010034 77054 000000000000
> HDR1SCHROEDR POSTER00010035 77054 000000000000
> HDR1SNOOPY POSTER00010036 77054 000000000000
> HDR1SNOOPY POSTER00010037 77054 000000000000
> HDR1SNOOPY POSTER00010038 77054 000000000000
> HDR1SNOOPY.ACE POSTER00010039 77054 000000000000
> HDR1SNOOPY.CURSE POSTER00010040 77054 000000000000
> HDR1SNOOPY.DISH POSTER00010041 77054 000000000000
> HDR1SNOOPY.HANG POSTER00010042 77054 000000000000
> HDR1SNOOPY.HANG.ON POSTER00010043 77054 000000000000
> HDR1SNOOPY.HUG POSTER00010044 77054 000000000000
> HDR1SNOOPY.PUNT POSTER00010045 77054 000000000000
> HDR1PLAYBOY.RABBIT POSTER00010046 77054 000000000000
> HDR1PLAYBOY.RABBIT POSTER00010047 77054 000000000000
> HDR1PLAYBOY.RABBIT POSTER00010048 77054 000000000000
> HDR1PLAYBOY.RABBIT POSTER00010049 77054 000000000000
> HDR1PLAYBOY.RABBIT POSTER00010050 77054 000000000000
> HDR1PLAYBOY.RABBIT POSTER00010051 77054 000000000000
> HDR1NUDE POSTER00010052 77054 000000000000
> HDR1NUDE POSTER00010053 77054 000000000000
> HDR1NUDE POSTER00010054 77054 000000000000
> HDR1NUDE.DOT POSTER00010055 77054 000000000000
> HDR1NUDE.MIRROR POSTER00010056 77054 000000000000
> HDR1NUDE.MISS.JUNE POSTER00010057 77054 000000000000
> HDR1NUDE.RECLING POSTER00010058 77054 000000000000
> HDR1NUDE.RECLING POSTER00010059 77054 000000000000
> HDR1NUDE.STOOL POSTER00010060 77054 000000000000
> HDR1NUDE.STOOL POSTER00010061 77054 000000000000
> HDR1NUDE.STOOL POSTER00010062 77054 000000000000
> HDR1NUDE.STOOL POSTER00010063 77054 000000000000
> HDR1NUDE.STOOL POSTER00010064 77054 000000000000
> HDR1NUDE.STOOL POSTER00010065 77054 000000000000
> HDR1NUDE.STOOL POSTER00010066 77054 000000000000
> HDR1LBJ POSTER00010067 77054 000000000000
> HDR1XMAS.VIRGIN.MARY POSTER00010068 77054 000000000000
> HDR1XMAS.WREATH POSTER00010069 77054 000000000000
> HDR1XMAS.WREATH.MCHNYPOSTER00010070 77054 000000000000
> HDR1XMAS.SANTA POSTER00010071 77055 000000000000
> HDR1XMAS.SOLTICE POSTER00010072 77055 000000000000
> HDR1XMAS.JOY POSTER00010073 77055 000000000000
> HDR1XMAS.WISE.MEN POSTER00010074 77055 000000000000
> HDR1XMAS.MERRY.XMAS POSTER00010075 77055 000000000000
> HDR1XMAS.MERRY.XMAS POSTER00010076 77055 000000000000
> HDR1XMAS.RAINDEER POSTER00010077 77055 000000000000
> HDR1XMAS.RAINDEER POSTER00010078 77055 000000000000
> HDR1XMAS.RAINDEER POSTER00010079 77060 000000000000
> HDR1PLI.UNCOBOL POSTER00010080 77335 000000000000
> HDR1SNOOPY.RUDE POSTER00010081 77343 000000000000
> HDR1LINUS.PEACE POSTER00010082 77343 000000000000
> HDR1SNOOPY.HOP POSTER00010083 77343 000000000000
> HDR1STARSHIP POSTER00010084 80034 000000000000IBM OS/VS 370382 &
> HDR1STARWARS POSTER00010085 81199 000000000000IBM OS/VS 370383 &
I recall a Snoopy (calendar, IIRC) but the porn passed me by; please repost! (smiley)
--
Bah, and indeed Humbug.
|
|
|
|
Members
Search
Help
Register
Login
Home
