| rebuild 1403 printer chain [message #176729] |
Tue, 12 November 2013 18:44  |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
recently i saw a request from the computer history museum for somebody
that could rebuild a 1403 printer chain (for the 1401 exhibit)
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: rebuild 1403 printer chain [message #177701 is a reply to message #176729] |
Wed, 13 November 2013 12:52  |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Anne & Lynn Wheeler wrote:
>
> recently i saw a request from the computer history museum for somebody
> that could rebuild a 1403 printer chain (for the 1401 exhibit)
>
Gee, I don't think it is all that hard, as long as there are no
damaged or broken type bars. All you have to do is work very
carefully in a place where you can't drop and lose irreplaceable
pieces. (This pretty much rules out MY shop!) These things are not
at all high-tech, and the trains (not chains) lift out of the printer
very easily. You just swing up two hooks that retract locking pins
and lift it out by the hooks.
I know the IBM FEs did not like to take them apart, and would just
run buckets of solvent through the channels to remove the dried
ink+paper dust. You were NOT supposed to do this on the printer
due to the risk of fire, but I saw them do exactly that many
times.
Jon
|
|
|
|
| Re: rebuild 1403 printer chain [message #180645 is a reply to message #177701] |
Thu, 14 November 2013 15:49 |
Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
In <yIGdnb536PPQIR7PnZ2dnUVZ_sKdnZ2d@giganews.com>, on 11/13/2013
at 11:52 AM, Jon Elson <elson@pico-systems.com> said:
> Gee, I don't think it is all that hard, as long as there are no
> damaged or broken type bars. All you have to do is work very
> carefully in a place where you can't drop and lose irreplaceable
> pieces. (This pretty much rules out MY shop!) These things are
> not at all high-tech, and the trains (not chains) lift out of the
> printer very easily.
The original model of the 1403 used a chain; the train caqme in on a
later model. Since this is for a 1401, it would be the model with a
chain.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
|
|
|
|
| Re: rebuild 1403 printer chain [message #180776 is a reply to message #180645] |
Fri, 15 November 2013 16:32 |
Nick Spalding
Messages: 165
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Shmuel wrote, in <5285375f$9$fuzhry+tra$mr2ice@news.patriot.net>
on Thu, 14 Nov 2013 15:49:35 -0500:
> In <yIGdnb536PPQIR7PnZ2dnUVZ_sKdnZ2d@giganews.com>, on 11/13/2013
> at 11:52 AM, Jon Elson <elson@pico-systems.com> said:
>
>> Gee, I don't think it is all that hard, as long as there are no
>> damaged or broken type bars. All you have to do is work very
>> carefully in a place where you can't drop and lose irreplaceable
>> pieces. (This pretty much rules out MY shop!) These things are
>> not at all high-tech, and the trains (not chains) lift out of the
>> printer very easily.
>
> The original model of the 1403 used a chain; the train caqme in on a
> later model. Since this is for a 1401, it would be the model with a
> chain.
Which would be better described as a train. The type elements weren't
linked together.
--
Nick Spalding
|
|
|
|
| Re: rebuild 1403 printer chain [message #180910 is a reply to message #180645] |
Fri, 15 November 2013 17:40 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Shmuel (Seymour J.) Metz wrote:
> In <yIGdnb536PPQIR7PnZ2dnUVZ_sKdnZ2d@giganews.com>, on 11/13/2013
> at 11:52 AM, Jon Elson <elson@pico-systems.com> said:
>
>> Gee, I don't think it is all that hard, as long as there are no
>> damaged or broken type bars. All you have to do is work very
>> carefully in a place where you can't drop and lose irreplaceable
>> pieces. (This pretty much rules out MY shop!) These things are
>> not at all high-tech, and the trains (not chains) lift out of the
>> printer very easily.
>
> The original model of the 1403 used a chain; the train caqme in on a
> later model. Since this is for a 1401, it would be the model with a
> chain.
>
OK, didn't know that. I'm fairly sure our computing facilities
had a 1403 on their 1401, and it was later updated and attached to our
S/360 systems. I'm REALLY sure the print trains were interchangeable
on the two printers. I can easily believe the 1401 was a later
model machine, and may have had the later version of the printer.
Jon
|
|
|
|
| Re: rebuild 1403 printer chain [message #180919 is a reply to message #180910] |
Fri, 15 November 2013 18:10 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 11/15/2013 5:40 PM, Jon Elson wrote:
>>
> OK, didn't know that. I'm fairly sure our computing facilities
> had a 1403 on their 1401, and it was later updated and attached to our
> S/360 systems. I'm REALLY sure the print trains were interchangeable
> on the two printers. I can easily believe the 1401 was a later
> model machine, and may have had the later version of the printer.
>
It also may be that the assembly holding the slugs was interchangable,
whether it held a chain or a train. [I'm too lazy to look right now]
--
Pete
|
|
|
|
| Re: rebuild 1403 printer chain [message #180930 is a reply to message #180910] |
Fri, 15 November 2013 18:48 |
Paul
Messages: 19
Registered: January 2012
Karma: 0
|
Junior Member |
|
|
Jon Elson <jmelson@wustl.edu> wrote in
news:Y6GdndNAKoxhPxvPnZ2dnUVZ_rCdnZ2d@giganews.com:
> OK, didn't know that. I'm fairly sure our computing facilities
> had a 1403 on their 1401, and it was later updated and attached to
> our S/360 systems. I'm REALLY sure the print trains were
> interchangeable on the two printers. I can easily believe the
> 1401 was a later model machine, and may have had the later version
> of the printer.
IIRC, our 2 1403s were still around "after IBM" and were attached to
the DEC-10s somehow. One 1403 sat in the corridor for months after
the DEC-10s were shut down. I probably could have hauled it home if
I had wanted.
--
Paul
|
|
|
|
| Re: rebuild 1403 printer chain [message #182282 is a reply to message #180930] |
Sat, 16 November 2013 18:55 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Paul wrote:
> Jon Elson <jmelson@wustl.edu> wrote in
> news:Y6GdndNAKoxhPxvPnZ2dnUVZ_rCdnZ2d@giganews.com:
>
>> OK, didn't know that. I'm fairly sure our computing facilities
>> had a 1403 on their 1401, and it was later updated and attached to
>> our S/360 systems. I'm REALLY sure the print trains were
>> interchangeable on the two printers. I can easily believe the
>> 1401 was a later model machine, and may have had the later version
>> of the printer.
>
> IIRC, our 2 1403s were still around "after IBM" and were attached to
> the DEC-10s somehow. One 1403 sat in the corridor for months after
> the DEC-10s were shut down. I probably could have hauled it home if
> I had wanted.
>
Requires 3-phase power, and the controller has all the electronics
in it. The hammer coils are just wired to huge bundles of yellow/black
twisted pairs on a couple great big cables with connectors that look like
they came off a 7090. They certainly were TOUGH pieces of machinery,
though. I think it was the old printer off the 1403 that caught fire
with company checks running through it. IBM came in, cleaned it up
just a bit, replaced a few parts and had it back on line in a couple
hours!
I can imagine somebody made a universal printer controller for it,
due to the reliability of the printer.
Jon
|
|
|
|
| Re: rebuild 1403 printer chain [message #182402 is a reply to message #182282] |
Sat, 16 November 2013 20:48 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 11/16/2013 6:55 PM, Jon Elson wrote:
> Paul wrote:
>
>> Jon Elson <jmelson@wustl.edu> wrote in
>> news:Y6GdndNAKoxhPxvPnZ2dnUVZ_rCdnZ2d@giganews.com:
>>
>>> OK, didn't know that. I'm fairly sure our computing facilities
>>> had a 1403 on their 1401, and it was later updated and attached to
>>> our S/360 systems. I'm REALLY sure the print trains were
>>> interchangeable on the two printers. I can easily believe the
>>> 1401 was a later model machine, and may have had the later version
>>> of the printer.
>>
>> IIRC, our 2 1403s were still around "after IBM" and were attached to
>> the DEC-10s somehow. One 1403 sat in the corridor for months after
>> the DEC-10s were shut down. I probably could have hauled it home if
>> I had wanted.
>>
> Requires 3-phase power, and the controller has all the electronics
> in it. The hammer coils are just wired to huge bundles of yellow/black
> twisted pairs on a couple great big cables with connectors that look like
> they came off a 7090. They certainly were TOUGH pieces of machinery,
> though. I think it was the old printer off the 1403 that caught fire
> with company checks running through it. IBM came in, cleaned it up
> just a bit, replaced a few parts and had it back on line in a couple
> hours!
>
> I can imagine somebody made a universal printer controller for it,
> due to the reliability of the printer.
>
I think people found it easier to cob up something that looked like a
channel and connected the controller to it.
--
Pete
|
|
|
|
| Re: rebuild 1403 printer chain [message #182524 is a reply to message #182402] |
Sat, 16 November 2013 22:44 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Peter Flass wrote:
>>
>> I can imagine somebody made a universal printer controller for it,
>> due to the reliability of the printer.
>>
>
> I think people found it easier to cob up something that looked like a
> channel and connected the controller to it.
>
>
Yow! I guess you could do that, and it would make more sense
if you wanted to interface to the card equipment, too, as generally
the printer and card reader/punch controller was all sort of integrated
in the "unit record" controller. The IBM channel interface had
sort of odd electrical interface specs, but you could probably
interface it with open collector TTL chips. All the smarts were
in the channel, but maybe that would be an advantage in such a
retrofit situation, you don't have to engineer around a complex
protocol in the controller.
Jon
|
|
|
|
| Re: rebuild 1403 printer chain [message #189711 is a reply to message #180910] |
Thu, 21 November 2013 19:14 |
Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
In <Y6GdndNAKoxhPxvPnZ2dnUVZ_rCdnZ2d@giganews.com>, on 11/15/2013
at 04:40 PM, Jon Elson <jmelson@wustl.edu> said:
> OK, didn't know that. I'm fairly sure our computing facilities had a
> 1403 on their 1401,
But was it a 1403-3, which used a train, or an older model? AFAIK the
1403-3, 1403-7 and 1403-N1 used the same trains and that the 1403-1
and 1403-2 used the same chains,
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
|
|
|
|
| Re: rebuild 1403 printer chain [message #189712 is a reply to message #180776] |
Thu, 21 November 2013 19:08 |
Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
In <rj4d891km96tah1r56tnjj9dirjm1jhrhd@4ax.com>, on 11/15/2013
at 09:32 PM, Nick Spalding <spalding@iol.ie> said:
> Shmuel wrote, in <5285375f$9$fuzhry+tra$mr2ice@news.patriot.net>
> on Thu, 14 Nov 2013 15:49:35 -0500:
>> In <yIGdnb536PPQIR7PnZ2dnUVZ_sKdnZ2d@giganews.com>, on 11/13/2013
>> at 11:52 AM, Jon Elson <elson@pico-systems.com> said:
>>
>>> Gee, I don't think it is all that hard, as long as there are no
>>> damaged or broken type bars. All you have to do is work very
>>> carefully in a place where you can't drop and lose irreplaceable
>>> pieces. (This pretty much rules out MY shop!) These things are
>>> not at all high-tech, and the trains (not chains) lift out of the
>>> printer very easily.
>>
>> The original model of the 1403 used a chain; the train caqme in on a
>> later model. Since this is for a 1401, it would be the model with a
>> chain.
> Which would be better described as a train. The type elements
> weren't linked together.
The 1403-3 used a train, but the original 1403 used a chain and there
was a connecting band between characters.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
|
|
|
|
| Re: rebuild 1403 printer chain [message #189824 is a reply to message #189712] |
Fri, 22 November 2013 09:53 |
Nick Spalding
Messages: 165
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Shmuel wrote, in <528ea09a$31$fuzhry+tra$mr2ice@news.patriot.net>
on Thu, 21 Nov 2013 19:08:58 -0500:
> In <rj4d891km96tah1r56tnjj9dirjm1jhrhd@4ax.com>, on 11/15/2013
> at 09:32 PM, Nick Spalding <spalding@iol.ie> said:
>
>> Shmuel wrote, in <5285375f$9$fuzhry+tra$mr2ice@news.patriot.net>
>> on Thu, 14 Nov 2013 15:49:35 -0500:
>
>>> In <yIGdnb536PPQIR7PnZ2dnUVZ_sKdnZ2d@giganews.com>, on 11/13/2013
>>> at 11:52 AM, Jon Elson <elson@pico-systems.com> said:
>>>
>>>> Gee, I don't think it is all that hard, as long as there are no
>>>> damaged or broken type bars. All you have to do is work very
>>>> carefully in a place where you can't drop and lose irreplaceable
>>>> pieces. (This pretty much rules out MY shop!) These things are
>>>> not at all high-tech, and the trains (not chains) lift out of the
>>>> printer very easily.
>>>
>>> The original model of the 1403 used a chain; the train caqme in on a
>>> later model. Since this is for a 1401, it would be the model with a
>>> chain.
>
>> Which would be better described as a train. The type elements
>> weren't linked together.
>
> The 1403-3 used a train, but the original 1403 used a chain and there
> was a connecting band between characters.
Oh dear. My memory had it reversed!
--
Nick Spalding
|
|
|
|
|
|
| Re: rebuild 1403 printer chain [message #190109 is a reply to message #189832] |
Fri, 22 November 2013 15:06 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Shmuel (Seymour J.) Metz wrote:
> In <PfmdnT4g9PYCphXPnZ2dnUVZ_uednZ2d@giganews.com>, on 11/16/2013
> at 09:44 PM, Jon Elson <elson@pico-systems.com> said:
>
>> All the smarts were in the channel,
>
> The channel was, and by its nature had to be, fairly simple[1]; the
> smarts were in the controller.
OK, I really didn't say what I meant, there. The smarts of interfacing
to the CPU memory were in the channel. Yes, of course, the controller
had the difficult task of figuring out what character was in front of
which hammer at every instant, made a lot more complicated by the fact
there was a DIFFERENT character in front of each hammer, unlike most
drum printers that had all the same chars in a row. As I recall, the
spacing of the chars on the train was different than the spacing of
the hammers, so you never needed to fire more than a few hammers at
any time.
>
> [1] Yes, there were simpler channels, but even with the more
> complicated ESCON and FICON channels you didn't have nearly
> the complexity of the typical controller.
>
Back in the 360 days, the controllers needed to be pretty simple, and
the design of the devices was made such that the controllers didn't
get too complex.
Jon
|
|
|
|
| Re: rebuild 1403 printer chain [message #190221 is a reply to message #180645] |
Fri, 22 November 2013 16:10 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Thursday, November 14, 2013 3:49:35 PM UTC-5, Seymour J. Shmuel Metz wrote:
> The original model of the 1403 used a chain; the train caqme in on a
> later model. Since this is for a 1401, it would be the model with a
> chain.
I'm surprised they didn't give the 1403 printer a new model number for S/360 use. It seemed like they did so for various other peripherals (2xxx series), even if the changes were relatively minor. For the 1403, they changed from a chain to a train and also significantly increased the speed (600 lpm to 1,000 lpm). The external appearance was improved, too.
Well into the 1970s I remember reading in Datamation how the 1403 was the printer of choice of industry despite newer models being available.
FWIW, we liked ours, and never had any trouble with it. Given the mechanical complexity and what it was expected to do accurately (line up and print a row of 132 columns of characters 16 times a second, it was a very amazing machine.
|
|
|
|
| Re: rebuild 1403 printer chain [message #190222 is a reply to message #180910] |
Fri, 22 November 2013 16:13 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Friday, November 15, 2013 5:40:56 PM UTC-5, Jon Elson wrote:
> OK, didn't know that. I'm fairly sure our computing facilities
> had a 1403 on their 1401, and it was later updated and attached to our
> S/360 systems. I'm REALLY sure the print trains were interchangeable
> on the two printers. I can easily believe the 1401 was a later
> model machine, and may have had the later version of the printer.
I'm not a hardware expert, but I doubt they used the same physical printer. I don't believe the 1401 used control units for the printer, while S/360 did. Also, the 1401 was a 6 bit character machine, while S/360 was 8 bit.
|
|
|
|
| Re: rebuild 1403 printer chain [message #190223 is a reply to message #189832] |
Fri, 22 November 2013 16:17 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Friday, November 22, 2013 9:41:37 AM UTC-5, Seymour J. Shmuel Metz wrote:
> [1] Yes, there were simpler channels, but even with the more
> complicated ESCON and FICON channels you didn't have nearly
> the complexity of the typical controller.
Just for sake of discussion, say someone owned a 1403 printer that they liked and wanted to keep using. Could they still connect it to a modern Z series ESCON or FICON channel, or would all sorts of special interfaces be required to make it work? (and for that matter, a 2314 or 3330 disk drive).
|
|
|
|
| Re: rebuild 1403 printer chain [message #190224 is a reply to message #190109] |
Fri, 22 November 2013 16:34 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Jon Elson <jmelson@wustl.edu> writes:
> Back in the 360 days, the controllers needed to be pretty simple, and
> the design of the devices was made such that the controllers didn't
> get too complex.
one of the 360 channel trade-offs was that memory was very expensive and
scarce ... so everything relied on processor memory ... with the i/o
infrastructure constantly referencing processor memory.
this really shows up in dasd ckd operations ... rather than having
filesystem structure cached in memory ... it was outboard on disk
.... and system made use of search operations to try and find things
.... furthermore the argument for the search operation was in processor
memory and had to be refetched for every compare operation ... for
instance if searching on key-equal ... every time the disk encountered a
key on disk, the search key argument was refetched from processor memory
for every compare. this was technology trade-off that conserved
electronic storage at the expense of enormous amounts of i/o and
bandwidth resources.
at least by the mid-70s, this trade-off was inverting ... with
electronic memory become significantly more plentiful and i/o and
bandwidth resources becoming bottlenecked resource.
in late 70s, ibm introduced fixed-block-architecture (FBA) for entry and
mid-range ... but continued to support CKD dasd because of MVS operating
system inability to move off the paradigm. by the late 80s, nobody was
making ckd dasd anymore ... and it was necessary to have hardware
simulation for the CKD dasd operations on industry standard fixed-block
disks (something that continues now to this day).
http://www.garlic.com/~lynn/submain.html#dasd
I had offered to provide MVS FBA support ... but was told that I needed
a $26M business case to cover training and new documentation ... and I
couldn't use total life time cost savings ... only incremental new disk
sales ... basically couple hundred million in new disks sold that
otherwise wouldn't be sold w/o FBA support. Then I was told that
customers were buying disks as fast as they could be made ... so it
would be possible to show any incremental disk sales.
in 1980, the ibm santa teresa lab was bursting at the seams and they
decided to move 300 people from IMS group to offsite bldg. They had been
offerred "remote 3270" terminal support back into the STL datacenter
.... but found the human factors of remote 3270 totally unacceptable. I
was con'ed into doing channel extender support for the group
.... basically a channel emulation box was placed at the remote site
.... to which "local" channel attached 3270 controlleres were connected.
Channel extender support involved high efficient full-duplex network
operations that downloaded channel programs to the remote box ... and
the emulated channel protocol chatter only ran between the channel
emulation box and the controller ... significantly offloading a lot of
activity off the real local channel. This had the effect of people at
the remote site not seeing any difference between real local 3270
operation in STL and simulated local 3270 operation at the remote
bldg. It also had the side effoect of improving the throughput of the
affected systems in the STL datacenter ... since it improved their real
channel operation and reduced total real channel busy for the 3270
operations. some HSDT posts including discussion of getting
channel speed throughput over what would be considered network links
http://www.garlic.com/~lynn/subnetwork.html#hsdt
for instance the original mainframe tcp/ip product was done in vs/pascal
but had some performance issues getting 44kbytes/sec using nearly whole
3090 processor. I did the changes for rfc1044 and in some tuning tests
at cray research got channel speed throughput between cray and 4341
using only modest amount of 4341 cpu (possibly 500 times improvement
in bytes moved per instruction executed)
http://www.garlic.com/~lynn/subnetwork.html#1044
I've mentioned in 1988 being asked to help LLNL standardize some serial
stuff they had ... which morphs in fibre-channel standard
http://en.wikipedia.org/wiki/Fibre_Channel
part of fibre channel standard is download of i/o programs to the remote
end ... significantly cutting chatter and end-to-end protocol latency
over the link.
some POK channel engineers then become involved in FCS and define a
heavy-duty protocol layer on top of FCS that retains a lot of
end-to-end protocol chatter and latency that drastically cuts
the throughput compared to native FCS throughput .... which eventually
morphs into something called FICON
http://www.garlic.com/~lynn/submisc.html#ficon
recent z196 peak i/o benchmark used 104 FICON (running on 104 FCS) to
achieve 2M IOPS. by comparison, there was recent FCS announced for
e5-2600 claiming over million IOPS (for sincle native FCS, aka two such
native with higher throughput than the z196 peak i/o benchmark getting
2M IOPS)
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: rebuild 1403 printer chain [message #190232 is a reply to message #190224] |
Fri, 22 November 2013 17:34 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Anne & Lynn Wheeler wrote:
>
> Jon Elson <jmelson@wustl.edu> writes:
>> Back in the 360 days, the controllers needed to be pretty simple, and
>> the design of the devices was made such that the controllers didn't
>> get too complex.
>
> one of the 360 channel trade-offs was that memory was very expensive and
> scarce ... so everything relied on processor memory ... with the i/o
> infrastructure constantly referencing processor memory.
>
You bet! Lower-end 360's had all the registers in an extra section
of core memory, only the 65 and up had electronic registers.
> this really shows up in dasd ckd operations ... rather than having
> filesystem structure cached in memory ... it was outboard on disk
> ... and system made use of search operations to try and find things
> ... furthermore the argument for the search operation was in processor
> memory and had to be refetched for every compare operation ... for
> instance if searching on key-equal ... every time the disk encountered a
> key on disk, the search key argument was refetched from processor memory
> for every compare. this was technology trade-off that conserved
> electronic storage at the expense of enormous amounts of i/o and
> bandwidth resources.
Of course, with an arbitrary-length search key, you had to read it
from CPU memory each time. I never knew how much this sort of function
was actually used in real software, but searching an entire disk pack
for a customer record seems insane. It would lock out the DASD channel
for the entire search, which kind of turns the multiprogramming 360
into a 1401. Obviously, you can't have the entire database in core, or
even the entire set of search keys, but any sane big database would
have to have a method of searching hash tables of some kind for
a good place to start looking. Searching an entire track for a specific
record would not hurt that much, as you might have to search half a
track just to read a record that you knew the address of, anyway.
Since this is in a 1403 printer thread, anyway, how DID the 360 print
controller work, anyway? Was there a map of the mounted print train
in memory, and the controller compared the line to be printed against
the train map? I sort of thought this is how it worked, as there was
an OS procedure for loading the train map when the operator changed the
train. Unless the arrangement of type bars was algorithmically easy,
it would be too complicated to have it know the arrangement of
several trains.
>
> at least by the mid-70s, this trade-off was inverting ... with
> electronic memory become significantly more plentiful and i/o and
> bandwidth resources becoming bottlenecked resource.
>
> in late 70s, ibm introduced fixed-block-architecture (FBA) for entry and
> mid-range ... but continued to support CKD dasd because of MVS operating
> system inability to move off the paradigm. by the late 80s, nobody was
> making ckd dasd anymore
No kidding! If used very wisely, it could be quite effective. If
used stupidly, you could cut all your disks down to 51% usability, just by
picking the wrong record size for your big database. The other problem
is allocation by cylinders. It largely avoids the fragmentation problem,
but ends up wasting a LOT of space at the ends of cylinders that aren't
filled. Still, in the modern world of Linux, running off the end of your
original allocation of cylinders seems like a REALLY antiquated way of
computing. (You have to go to the head of DP and ask him to allocate
X cylinders for you, and don't ask for too many!)
> ... and it was necessary to have hardware
> simulation for the CKD dasd operations on industry standard fixed-block
> disks (something that continues now to this day).
> http://www.garlic.com/~lynn/submain.html#dasd
>
Well, that can be messy, but at least you have some sort of choice, volume
by volume, I guess.
Jon
|
|
|
|
| Re: rebuild 1403 printer chain [message #190233 is a reply to message #190222] |
Fri, 22 November 2013 17:41 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com wrote:
> On Friday, November 15, 2013 5:40:56 PM UTC-5, Jon Elson wrote:
>
>
>> OK, didn't know that. I'm fairly sure our computing facilities
>> had a 1403 on their 1401, and it was later updated and attached to our
>> S/360 systems. I'm REALLY sure the print trains were interchangeable
>> on the two printers. I can easily believe the 1401 was a later
>> model machine, and may have had the later version of the printer.
>
> I'm not a hardware expert, but I doubt they used the same physical
> printer. I don't believe the 1401 used control units for the printer,
> while S/360 did. Also, the 1401 was a 6 bit character machine, while
> S/360 was 8 bit.
But, the printer was MASSIVELY low-level, ALL electromechanical.
So, there were some relays that turned on the train motor and the
paper feed drive motor and puller. There were some solenoid
coils that advanced the paper, and some kind of sensor that detected
the paper feed tape and out of paper, jam, etc. switches. And there
was a sensor for the train position and the hammers. That was it!
The 1403 had some sort of integrated controller, and it probably was
a fair bit of logic in SMS family components. I can easily imagine
the 1401 was not so easy to swap print trains on, although I guess an
inventive programmer could just figure out a translation table and
make it work anyway.
So, the character bit-size made no difference, and there was no electronics
in the printer, with the possible exception of a sensor or two.
I think they DID have to have the printer modified a bit by IBM
for the change-over, but they were able to do it.
Jon
|
|
|
|
| Re: rebuild 1403 printer chain [message #190237 is a reply to message #190221] |
Fri, 22 November 2013 17:48 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com wrote:
> On Thursday, November 14, 2013 3:49:35 PM UTC-5, Seymour J. Shmuel Metz
> wrote:
>
>> The original model of the 1403 used a chain; the train caqme in on a
>> later model. Since this is for a 1401, it would be the model with a
>> chain.
>
> I'm surprised they didn't give the 1403 printer a new model number for
> S/360 use. It seemed like they did so for various other peripherals (2xxx
> series), even if the changes were relatively minor. For the 1403, they
> changed from a chain to a train and also significantly increased the speed
> (600 lpm to 1,000 lpm). The external appearance was improved, too.
>
I think the 360-attached printers were called the 1403-N1 and 1403-N3.
The N3 was the slower one, and stood on legs, the paper box was just
on the floor below it. The N1 was the faster one, and was in a
fully-enclosed cabinet, with doors that could be opened to slide
the paper box in. it had a motorized cover that raised when the
printer got a check such as a stacker jam or an out of paper condition.
Jon
|
|
|
|
| Re: rebuild 1403 printer chain [message #190344 is a reply to message #190232] |
Fri, 22 November 2013 19:42 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Jon Elson <jmelson@wustl.edu> writes:
> Anne & Lynn Wheeler wrote:
>
> Since this is in a 1403 printer thread, anyway, how DID the 360 print
> controller work, anyway? Was there a map of the mounted print train
> in memory, and the controller compared the line to be printed against
> the train map? I sort of thought this is how it worked, as there was
> an OS procedure for loading the train map when the operator changed the
> train. Unless the arrangement of type bars was algorithmically easy,
> it would be too complicated to have it know the arrangement of
> several trains.
Looking at my White S/370 reference card, I see 2 I/O command codes:
FB Load UCSB without folding
F3 Load UCSB with folding
If I remember right, if you wanted to use a different print train
you used these commands to load the print train arrangement into
the printer controller.
Someone mentioned the 1403 being a 6 bit printer. I'm pretty sure
by the time it got to the S/360 it could handle 8 bits. If I recall
right, lower case was an option.
--
Dan Espen
|
|
|
|
| Re: rebuild 1403 printer chain [message #190964 is a reply to message #190221] |
Sat, 23 November 2013 07:56 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 11/22/2013 4:10 PM, hancock4@bbs.cpcn.com wrote:
> On Thursday, November 14, 2013 3:49:35 PM UTC-5, Seymour J. Shmuel
> Metz wrote:
>
>> The original model of the 1403 used a chain; the train caqme in on
>> a later model. Since this is for a 1401, it would be the model with
>> a chain.
>
> I'm surprised they didn't give the 1403 printer a new model number
> for S/360 use. It seemed like they did so for various other
> peripherals (2xxx series), even if the changes were relatively minor.
> For the 1403, they changed from a chain to a train and also
> significantly increased the speed (600 lpm to 1,000 lpm). The
> external appearance was improved, too.
A lot of things they didn't change. The 1442 reader/punch. the 1443
printer, etc.
>
> Well into the 1970s I remember reading in Datamation how the 1403 was
> the printer of choice of industry despite newer models being
> available.
>
> FWIW, we liked ours, and never had any trouble with it. Given the
> mechanical complexity and what it was expected to do accurately (line
> up and print a row of 132 columns of characters 16 times a second, it
> was a very amazing machine.
>
We tend to forget the amount of work that went into keeping them in
tiptop shape. I believe it was a regular item for weekly PM.
--
Pete
|
|
|
|
| Re: rebuild 1403 printer chain [message #190965 is a reply to message #190109] |
Sat, 23 November 2013 08:01 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 11/22/2013 3:06 PM, Jon Elson wrote:
> Shmuel (Seymour J.) Metz wrote:
>
>> In <PfmdnT4g9PYCphXPnZ2dnUVZ_uednZ2d@giganews.com>, on 11/16/2013
>> at 09:44 PM, Jon Elson <elson@pico-systems.com> said:
>>
>>> All the smarts were in the channel,
>>
>> The channel was, and by its nature had to be, fairly simple[1]; the
>> smarts were in the controller.
> OK, I really didn't say what I meant, there. The smarts of interfacing
> to the CPU memory were in the channel. Yes, of course, the controller
> had the difficult task of figuring out what character was in front of
> which hammer at every instant, made a lot more complicated by the fact
> there was a DIFFERENT character in front of each hammer, unlike most
> drum printers that had all the same chars in a row.
On the other hand, the 1132 had no intelligence. The 1130 CPU had to
build a line of bits for each character as it came around on the drum
and tell the printer to fire. I forget just how manay characters were
on a drum, but this might mean up to 64 I/O operations and associated
bit-twiddling to print one line.
As I recall, the
> spacing of the chars on the train was different than the spacing of
> the hammers, so you never needed to fire more than a few hammers at
> any time.
>>
>> [1] Yes, there were simpler channels, but even with the more
>> complicated ESCON and FICON channels you didn't have nearly
>> the complexity of the typical controller.
>>
> Back in the 360 days, the controllers needed to be pretty simple, and
> the design of the devices was made such that the controllers didn't
> get too complex.
>
Everything was hardwired logic in those days, I believe.
--
Pete
|
|
|
|
| Re: rebuild 1403 printer chain [message #190966 is a reply to message #190222] |
Sat, 23 November 2013 08:05 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 11/22/2013 4:13 PM, hancock4@bbs.cpcn.com wrote:
> On Friday, November 15, 2013 5:40:56 PM UTC-5, Jon Elson wrote:
>
>
>> OK, didn't know that. I'm fairly sure our computing facilities
>> had a 1403 on their 1401, and it was later updated and attached to our
>> S/360 systems. I'm REALLY sure the print trains were interchangeable
>> on the two printers. I can easily believe the 1401 was a later
>> model machine, and may have had the later version of the printer.
>
> I'm not a hardware expert, but I doubt they used the same physical printer. I don't believe the 1401 used control units for the printer, while S/360 did. Also, the 1401 was a 6 bit character machine, while S/360 was 8 bit.
>
Different models. It seems the model might denote different control
logic for the same hardware. The 1442 reader/punch had seven models and
attached variously to 14xx machines, S/360, 1130, and System/3. The
same hardware was used for a couple of remote batch terminals.
--
Pete
|
|
|
|
| Re: rebuild 1403 printer chain [message #190967 is a reply to message #190223] |
Sat, 23 November 2013 08:07 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 11/22/2013 4:17 PM, hancock4@bbs.cpcn.com wrote:
> On Friday, November 22, 2013 9:41:37 AM UTC-5, Seymour J. Shmuel Metz wrote:
>
>> [1] Yes, there were simpler channels, but even with the more
>> complicated ESCON and FICON channels you didn't have nearly
>> the complexity of the typical controller.
>
> Just for sake of discussion, say someone owned a 1403 printer that they liked and wanted to keep using. Could they still connect it to a modern Z series ESCON or FICON channel, or would all sorts of special interfaces be required to make it work? (and for that matter, a 2314 or 3330 disk drive).
>
>
I think there are ESCON to parallel adapters. I don't know about FICON.
Possibly the channel protocol is robust enough to handle the
differences in speeds.
--
Pete
|
|
|
|
| Re: rebuild 1403 printer chain [message #190968 is a reply to message #190237] |
Sat, 23 November 2013 08:11 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 11/22/2013 5:48 PM, Jon Elson wrote:
> hancock4@bbs.cpcn.com wrote:
>
>> On Thursday, November 14, 2013 3:49:35 PM UTC-5, Seymour J. Shmuel Metz
>> wrote:
>>
>>> The original model of the 1403 used a chain; the train caqme in on a
>>> later model. Since this is for a 1401, it would be the model with a
>>> chain.
>>
>> I'm surprised they didn't give the 1403 printer a new model number for
>> S/360 use. It seemed like they did so for various other peripherals (2xxx
>> series), even if the changes were relatively minor. For the 1403, they
>> changed from a chain to a train and also significantly increased the speed
>> (600 lpm to 1,000 lpm). The external appearance was improved, too.
>>
> I think the 360-attached printers were called the 1403-N1 and 1403-N3.
> The N3 was the slower one, and stood on legs, the paper box was just
> on the floor below it. The N1 was the faster one, and was in a
> fully-enclosed cabinet, with doors that could be opened to slide
> the paper box in. it had a motorized cover that raised when the
> printer got a check such as a stacker jam or an out of paper condition.
>
I believe you could also use other models. The Model 3 (not N3) was
(IIRC) common.
--
Pete
|
|
|
|
| Re: rebuild 1403 printer chain [message #191094 is a reply to message #189824] |
Sat, 23 November 2013 10:34 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Nick Spalding wrote:
> Shmuel wrote, in <528ea09a$31$fuzhry+tra$mr2ice@news.patriot.net>
> on Thu, 21 Nov 2013 19:08:58 -0500:
>
>> In <rj4d891km96tah1r56tnjj9dirjm1jhrhd@4ax.com>, on 11/15/2013
>> at 09:32 PM, Nick Spalding <spalding@iol.ie> said:
>>
>>> Shmuel wrote, in <5285375f$9$fuzhry+tra$mr2ice@news.patriot.net>
>>> on Thu, 14 Nov 2013 15:49:35 -0500:
>>
>>>> In <yIGdnb536PPQIR7PnZ2dnUVZ_sKdnZ2d@giganews.com>, on 11/13/2013
>>>> at 11:52 AM, Jon Elson <elson@pico-systems.com> said:
>>>>
>>>> >Gee, I don't think it is all that hard, as long as there are no
>>>> >damaged or broken type bars. All you have to do is work very
>>>> >carefully in a place where you can't drop and lose irreplaceable
>>>> >pieces. (This pretty much rules out MY shop!) These things are
>>>> >not at all high-tech, and the trains (not chains) lift out of the
>>>> >printer very easily.
>>>>
>>>> The original model of the 1403 used a chain; the train caqme in on a
>>>> later model. Since this is for a 1401, it would be the model with a
>>>> chain.
>>
>>> Which would be better described as a train. The type elements
>>> weren't linked together.
>>
>> The 1403-3 used a train, but the original 1403 used a chain and there
>> was a connecting band between characters.
>
> Oh dear. My memory had it reversed!
which is better than reserved. ;-)
/BAH
|
|
|
|
| Re: rebuild 1403 printer chain [message #191106 is a reply to message #190964] |
Sat, 23 November 2013 10:35 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass wrote:
> On 11/22/2013 4:10 PM, hancock4@bbs.cpcn.com wrote:
>> On Thursday, November 14, 2013 3:49:35 PM UTC-5, Seymour J. Shmuel
>> Metz wrote:
>>
>>> The original model of the 1403 used a chain; the train caqme in on
>>> a later model. Since this is for a 1401, it would be the model with
>>> a chain.
>>
>> I'm surprised they didn't give the 1403 printer a new model number
>> for S/360 use. It seemed like they did so for various other
>> peripherals (2xxx series), even if the changes were relatively minor.
>> For the 1403, they changed from a chain to a train and also
>> significantly increased the speed (600 lpm to 1,000 lpm). The
>> external appearance was improved, too.
>
> A lot of things they didn't change. The 1442 reader/punch. the 1443
> printer, etc.
>>
>> Well into the 1970s I remember reading in Datamation how the 1403 was
>> the printer of choice of industry despite newer models being
>> available.
>>
>> FWIW, we liked ours, and never had any trouble with it. Given the
>> mechanical complexity and what it was expected to do accurately (line
>> up and print a row of 132 columns of characters 16 times a second, it
>> was a very amazing machine.
>>
>
> We tend to forget the amount of work that went into keeping them in
> tiptop shape. I believe it was a regular item for weekly PM.
I think people have forgotten that weekly and monthly PMS were
part of having a computer. Now they just throw it away.
/BAH
|
|
|
|
| Re: rebuild 1403 printer chain [message #191108 is a reply to message #190344] |
Sat, 23 November 2013 11:03 |
Joe Morris
Messages: 324
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"Dan Espen" <despen@verizon.net> wrote:
> Looking at my White S/370 reference card, I see 2 I/O command codes:
> FB Load UCSB without folding
> F3 Load UCSB with folding
Heh...I had forgotten the folding option on the UCS load. Essentially it
caused the logic that decided if it was time to throw a print hammer to act
as if the x'40' bit was always on, thus "folding" lower-case characters into
uppercase.
> If I remember right, if you wanted to use a different print train
> you used these commands to load the print train arrangement into
> the printer controller.
That assumes that you have the UCS feature installed on the 2821 control
unit. Without it, you had to use either an "A" or "H" train and handle the
BCD code point collisions in your application.
Without folding, if you attempted to print a mixed-case data stream your
print speed went down the toilet. Any print line containing one or more
characters not mapped to at least one of the 240 glyphs on a print train
would not be considered complete until the print train had passed its home
position twice (thus guaranteeing that every print position on the printer
had been exposed to every glyph on the train). Additionally, unless
suppressed this situation resulted in a unit check with "data check" sense,
causing the operating system to go through error recovery.
> Someone mentioned the 1403 being a 6 bit printer. I'm pretty sure
> by the time it got to the S/360 it could handle 8 bits. If I recall
> right, lower case was an option.
With UCS the 2821 could map each of the 240 glyphs on a print train to any
byte value other than X'00' and X'40' (which were spaces). Each standard
train came with a small deck of IBM cards that could be used with the tools
in the operating system to load the UCS buffer with the mapping appropriate
for that train. There wasn't anything unique about lower case; mapping
train glyph 123 to "a" was no different from mapping train glyph 123 to "%".
Joe
|
|
|
|
| Re: rebuild 1403 printer chain [message #191109 is a reply to message #190965] |
Sat, 23 November 2013 11:07 |
Joe Morris
Messages: 324
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"Peter Flass" <Peter_Flass@Yahoo.com> wrote:
> On 11/22/2013 3:06 PM, Jon Elson wrote:
>> Back in the 360 days, the controllers needed to be pretty simple, and
>> the design of the devices was made such that the controllers didn't
>> get too complex.
> Everything was hardwired logic in those days, I believe.
Most peripherals were hardwired (such as the 2821 control unit, which
supported printers, card readers, and card punches) but some used microcode
(such as the 2314, which used TROS).
Joe
|
|
|
|
| Re: rebuild 1403 printer chain [message #191113 is a reply to message #191108] |
Sat, 23 November 2013 11:17 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"Joe Morris" <j.c.morris@verizon.net> writes:
> "Dan Espen" <despen@verizon.net> wrote:
>
>> Looking at my White S/370 reference card, I see 2 I/O command codes:
>
>> FB Load UCSB without folding
>> F3 Load UCSB with folding
>
> Heh...I had forgotten the folding option on the UCS load. Essentially it
> caused the logic that decided if it was time to throw a print hammer to act
> as if the x'40' bit was always on, thus "folding" lower-case characters into
> uppercase.
Sometime in the 90s on our first large mainframe project written in C,
we got our first dump back from a customer via the normal electronic
transmission.
We'd been testing for years and since we were using C we had lots of
lower case eyecatchers, function names, etc.
We needed to ask this customer to send us a new dump with the fold
option turned on for the dump. Up until then, the customer had no
need to see lower case in dumps.
>> If I remember right, if you wanted to use a different print train
>> you used these commands to load the print train arrangement into
>> the printer controller.
>
> That assumes that you have the UCS feature installed on the 2821 control
> unit. Without it, you had to use either an "A" or "H" train and handle the
> BCD code point collisions in your application.
Yes, I see a notation on my reference card about the UCS buffer being an
option.
> Without folding, if you attempted to print a mixed-case data stream your
> print speed went down the toilet. Any print line containing one or more
> characters not mapped to at least one of the 240 glyphs on a print train
> would not be considered complete until the print train had passed its home
> position twice (thus guaranteeing that every print position on the printer
> had been exposed to every glyph on the train). Additionally, unless
> suppressed this situation resulted in a unit check with "data check" sense,
> causing the operating system to go through error recovery.
I don't remember any of that. No reduced speed, no unit checks.
--
Dan Espen
|
|
|
|
| Re: rebuild 1403 printer chain [message #191114 is a reply to message #191106] |
Sat, 23 November 2013 11:22 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
jmfbahciv <See.above@aol.com> writes:
> Peter Flass wrote:
>> On 11/22/2013 4:10 PM, hancock4@bbs.cpcn.com wrote:
>>> On Thursday, November 14, 2013 3:49:35 PM UTC-5, Seymour J. Shmuel
>>> Metz wrote:
>>>
>>>> The original model of the 1403 used a chain; the train caqme in on
>>>> a later model. Since this is for a 1401, it would be the model with
>>>> a chain.
>>>
>>> I'm surprised they didn't give the 1403 printer a new model number
>>> for S/360 use. It seemed like they did so for various other
>>> peripherals (2xxx series), even if the changes were relatively minor.
>>> For the 1403, they changed from a chain to a train and also
>>> significantly increased the speed (600 lpm to 1,000 lpm). The
>>> external appearance was improved, too.
>>
>> A lot of things they didn't change. The 1442 reader/punch. the 1443
>> printer, etc.
>>>
>>> Well into the 1970s I remember reading in Datamation how the 1403 was
>>> the printer of choice of industry despite newer models being
>>> available.
>>>
>>> FWIW, we liked ours, and never had any trouble with it. Given the
>>> mechanical complexity and what it was expected to do accurately (line
>>> up and print a row of 132 columns of characters 16 times a second, it
>>> was a very amazing machine.
>>>
>>
>> We tend to forget the amount of work that went into keeping them in
>> tiptop shape. I believe it was a regular item for weekly PM.
>
> I think people have forgotten that weekly and monthly PMS were
> part of having a computer. Now they just throw it away.
Cite?
I haven't forgotten and I don't think many of the people that were
around then have either.
Sure, people throw away drives that have stopped working, but we
don't throw away machinery that costs as much as a 1403 printer
or any of that other machinery that got PMs.
Not sure if I'm picking on you or not.
Your attitude annoys me.
--
Dan Espen
|
|
|
|
| Re: rebuild 1403 printer chain [message #191224 is a reply to message #191108] |
Sat, 23 November 2013 12:31 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"Joe Morris" <j.c.morris@verizon.net> writes:
> Without folding, if you attempted to print a mixed-case data stream your
> print speed went down the toilet. Any print line containing one or more
> characters not mapped to at least one of the 240 glyphs on a print train
> would not be considered complete until the print train had passed its home
> position twice (thus guaranteeing that every print position on the printer
> had been exposed to every glyph on the train). Additionally, unless
> suppressed this situation resulted in a unit check with "data check" sense,
> causing the operating system to go through error recovery.
re:
http://www.garlic.com/~lynn/2013n.html#32 rebuild 1403 printer chain
http://www.garlic.com/~lynn/2013n.html#54 rebuild 1403 printer chain
for more trivia & topic drift ... because unit check status was in the
channel ... the channel went into contingent connection (no other
operations could be performed) until sense information had been
retrieved.
unit check also had to be associated with specific operation ... I got
sucked into resolving a problem that the 3880 disk control unit people
were causing. 3880 used much slower processor for control opertaions
than previous 3830 ... but there was requirement that 3880 had to be
within 5-10% performance of the 3830. One of the problems was that the
3880 processor was really, really slow cleaning everything up at the end
of i/o program ... and so to make it look faster ... they tried
presenting ending status interrupt early ... before it finished
everything (hoping that it could finish before operating system latency
got around to trying next operation).
when I was first wandered around the disk engineering & developing bldgs
.... they had lots of 370s in their machine rooms running single device,
stand-alone testing ... machines pre-scheduled 7x24 around the clock.
at one point they had tried running MVS for concurrent testing ... but
found it had 15min MTBF in that environment (requiring manual reboot).
I offerred to rewrite I/O supervisor making it bullet proof and never
fail ... so they can do on-demand, anytime, concurrent testing ... which
significantly improved productivity.
since even concurrent testing of all available testcells used only a few
percent of the machine ... they also setup a 3033 to also provide online
interactive service ... using 16 surplus 3330 disks and 3830
controllere. one monday morning I got a call that their online
interactive performance had gone into the can and wanted to know what I
had done over the weekend. Analysis eventually showed up that they had
replaced the 3830 with engineering 3880 ... and the controller overhead
(throughput latency problem) was much worse than anybody modeled.
There was also problem with my rewrite of I/O supervisor ... part of the
rewrite was to make the device redrive pathlength as short as possible.
370/xa SSCH was being justified because operating systems left a lot of
device idle time between the end of an operation and the redrive of the
next pending queued operation. I wanted to show nearly all of the SSCH
justification was passed on really terrible operating system software
and that efficient implementation could come very close to architectured
SSCH (which would allow a separate dedicated processor for redrive).
it turns out the redrive code was hitting the 3880 while it was still
busy cleaning up the previous operation ... and controller busy
condition required presenting SM+BUSY (operation not started). Then
later, since it had presented SM+BUSY ... it had to present a separate
CUE interrupt. Besides significantly increasing channel busy and
operations now taking much longer (than with 3830) ... the operating
system processing had to try starting each operation twice and getting
twice the number of interrupts. Fortunately this was six months before
3880 ship to customers and there was some additional problem masking
they could do (but couldn't totally eliminate the problem).
misc. past posts getting to play disk engineer in bldgs 14&15
http://www.garlic.com/~lynn/subtopic.html#disk
it also turns out 3880 presenting ending status early precipitated a
sperate problem. There are certain kinds of error that could be
identified with cleanup ... that aren't directly associated with
previous data transfer. The 3880 developers then decided that they would
present unsolicited unit check interrupt when this happens. Turns out I
pointed out that this is violation of channel architecture ... every
unit check hass to be associated with an operation. This eventually
escalated into conference calls with POK channel engineers with me
sitting with the disk engineers mediated. It was eventually resolved
.... but afterwards they wanted me to sit in on all conference calls with
POK channel engineers.
The resolution to the unsolicited unit check was to save it until the
next time an operation was started on that device ... and present cc=1,
immediate status, operation not started, channel status stored ... with
the unit check set then. There is some flaky stuff that they had to
played with ... since things are sort of in contingent connection (not
allowing things to start) ... but the unit check hadn't actually been
presented ... so you don't know which device address you have to do a
sense operation for (and you can't present cc1, unit check for device or
controller on the same channel unrelated to the unit check).
as i've mentioned before while they eventually managed to mask much of
the 3880 problems to minimize additional operating systeme overhead
.... they couldn't mask the significant increase in channel busy.
this shows up in 3090 design ... it was configured with number of
channels assuming 3830 busy. when they found out how bad the 3880
channel busy overhead was ... it required them to significantly increase
the number of channels (in order to reach IOPS targets/throughput).
This required additional TCM and increasing 3090 manufacturing
costs. There were semi-humorous references to the POK 3090 group billing
the 3880 group with the increase in 3090 manufacturing.
Marketing respun the significant increase in the number of 3090 channels
as indication of the enormous i/o capacity of the machine (as opposed to
compensating for the enormous increase in 3880 channel busy
overhead). this marketing spin continues to this day with FICON ... as
mentioned in previous posts
http://www.garlic.com/~lynn/submisc.html#ficon
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: rebuild 1403 printer chain [message #191236 is a reply to message #191106] |
Sat, 23 November 2013 13:22 |
Rod Speed
Messages: 3507
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
jmfbahciv <See.above@aol.com> wrote
> Peter Flass wrote
>> hancock4@bbs.cpcn.com wrote
>>> Seymour J. Shmuel
>>>> Metz wrote:
>>>> The original model of the 1403 used a chain; the train caqme in on a
>>>> later model. Since this is for a 1401, it would be the model with a
>>>> chain.
>>> I'm surprised they didn't give the 1403 printer a new model
>>> number for S/360 use. It seemed like they did so for various
>>> other peripherals (2xxx series), even if the changes were relatively
>>> minor. For the 1403, they changed from a chain to a train and
>>> also significantly increased the speed (600 lpm to 1,000 lpm).
>>> The external appearance was improved, too.
>> A lot of things they didn't change. The 1442 reader/punch. the 1443
>> printer, etc.
>>> Well into the 1970s I remember reading in Datamation how the 1403 was
>>> the printer of choice of industry despite newer models being available.
>>> FWIW, we liked ours, and never had any trouble with it. Given the
>>> mechanical complexity and what it was expected to do accurately (line
>>> up and print a row of 132 columns of characters 16 times a second, it
>>> was a very amazing machine.
>> We tend to forget the amount of work that went into keeping them in
>> tiptop shape. I believe it was a regular item for weekly PM.
> I think people have forgotten that weekly and
> monthly PMS were part of having a computer.
Because there isnt any useful PM you can do now.
> Now they just throw it away.
They don’t do any PM because there is
no PM you can usefully do anymore.
And what you do when something breaks isnt PM anyway.
|
|
|
|
| Re: rebuild 1403 printer chain [message #191346 is a reply to message #191224] |
Sat, 23 November 2013 14:56 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
In article <m361rjja8u.fsf@garlic.com>, lynn@garlic.com
(Anne & Lynn Wheeler) writes:
> unit check also had to be associated with specific operation ... I got
> sucked into resolving a problem that the 3880 disk control unit people
> were causing. 3880 used much slower processor for control opertaions
> than previous 3830 ... but there was requirement that 3880 had to be
> within 5-10% performance of the 3830. One of the problems was that the
> 3880 processor was really, really slow cleaning everything up at the end
> of i/o program ... and so to make it look faster ... they tried
> presenting ending status interrupt early ... before it finished
> everything (hoping that it could finish before operating system latency
> got around to trying next operation).
[horror story snipped]
I've always been quite vocal about how much I hate it when a system
lies to me. Yours is an excellent explanation of why.
--
/~\ 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.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
|
|
|
|
| Re: rebuild 1403 printer chain [message #191347 is a reply to message #191224] |
Sat, 23 November 2013 15:28 |
Walter Bushell
Messages: 1834
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <m361rjja8u.fsf@garlic.com>,
Anne & Lynn Wheeler <lynn@garlic.com> wrote:
> Marketing respun the significant increase in the number of 3090 channels
> as indication of the enormous i/o capacity of the machine (as opposed to
> compensating for the enormous increase in 3880 channel busy
> overhead). this marketing spin continues to this day with FICON ... as
> mentioned in previous posts
> http://www.garlic.com/~lynn/submisc.html#ficon
Marketing probably didn't understand why the channels were necessary,
or just didn't care. Why let the ugly facts get in the way of a good
story? A frequent attitude.
--
Gambling with Other People's Money is the meth of the fiscal industry.
me -- in the spirit of Karl and Groucho Marx
|
|
|
|
| Re: rebuild 1403 printer chain [message #191352 is a reply to message #176729] |
Sat, 23 November 2013 16:20 |
Rod Speed
Messages: 3507
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Dave Garland <dave.garland@wizinfo.com> wrote
> Rod Speed wrote
>> jmfbahciv <See.above@aol.com> wrote
>>> Peter Flass wrote
>>>> hancock4@bbs.cpcn.com wrote
>>>> > Seymour J. Shmuel
>>>> >> Metz wrote:
>>>> >> The original model of the 1403 used a chain; the train caqme in on a
>>>> >> later model. Since this is for a 1401, it would be the model with a
>>>> >> chain.
>>>> > I'm surprised they didn't give the 1403 printer a new model
>>>> > number for S/360 use. It seemed like they did so for various
>>>> > other peripherals (2xxx series), even if the changes were relatively
>>>> > minor. For the 1403, they changed from a chain to a train and
>>>> > also significantly increased the speed (600 lpm to 1,000 lpm).
>>>> > The external appearance was improved, too.
>>>> A lot of things they didn't change. The 1442 reader/punch. the 1443
>>>> printer, etc.
>>>> > Well into the 1970s I remember reading in Datamation how the 1403 was
>>>> > the printer of choice of industry despite newer models being
>>>> > available.
>>>> > FWIW, we liked ours, and never had any trouble with it. Given the
>>>> > mechanical complexity and what it was expected to do accurately (line
>>>> > up and print a row of 132 columns of characters 16 times a second, it
>>>> > was a very amazing machine.
>>>> We tend to forget the amount of work that went into keeping them
>>>> in tiptop shape. I believe it was a regular item for weekly PM.
>>> I think people have forgotten that weekly and
>>> monthly PMS were part of having a computer.
>> Because there isnt any useful PM you can do now.
> Not a lot.
None in fact with modern printers except change the ink
cartridge when it is empty etc and that’s not PM anyway.
> Occasionally blow the dust bunnies out,
I don’t bother and I don’t even have the covers on at all.
> clean the gunk out of the keyboard,
I don’t bother.
> run CCleaner
Don’t bother with that either.
> and defrag,
Or with that in spades. Completely pointless with modern
fast seeking drives used sensibly with the system on 24/7 and
only rebooted every month or so when it slows down a bit with
all the stuff you use much at all open on the desktop all the time.
Even more pointless with media files where the speed of movement
thru the file is entirely determined by the media play speed.
> do a virus scan.
That’s completely automated and isnt PM anyway.
Don’t even bother doing that on the better designed iOS systems.
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
