6 Aug
2015
6 Aug
'15
3:32 a.m.
Wow. I'll never complain again that it takes too long to boot Windows...
6 Aug
6 Aug
9:16 a.m.
On Thu, 6 Aug 2015, Marc Verdiell wrote:
Wow. I'll never complain again that it takes too
long to boot Windows...
One thing I don't understand - why can't the machine boot on its own? Why
would IBM design a computer that required another computer just to boot
it?
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
9:38 a.m.
Gene wrote...
-----
One thing I don't understand - why can't the machine boot on its own? Why
would IBM design a computer that required another computer just to boot it?
----
To report higher sales of OS2/Warp? ;)
Not the only one though, ISTR the 11/780 used a 11/03 to boot?
J
9:52 a.m.
On Aug 6, 2015, at 9:47 AM, William Donzelli
<wdonzelli at gmail.com> wrote:
A lot of machines have I/O processors of some sort, and often those boot first. You can
go back to the CDC 6600 and the Electrologica EL-X8 in the early 1960s, perhaps further.
Cray, ILLIAC IV, KL-10, ... lots of other examples.
paul
To report higher sales of OS2/Warp? ;)
Not the only one though, ISTR the 11/780 used a 11/03 to boot?
Quite a lots of larger machines do. 
2:21 p.m.
On 8/6/2015 7:47 AM, William Donzelli wrote:
That don't bother me as much as the hidden source software
used with modern (mad laugh) OS code. Ben.
To report
higher sales of OS2/Warp? ;)
Not the only one though, ISTR the 11/780 used a 11/03 to boot?
Quite a lots of larger machines do. 
9:54 a.m.
On 06/08/15 14:38, Jay West wrote:
Gene wrote...
-----
One thing I don't understand - why can't the machine boot on its own? Why
would IBM design a computer that required another computer just to boot it?
----
To report higher sales of OS2/Warp? ;)
Not the only one though, ISTR the 11/780 used a 11/03 to boot?
I think many of the larger VAXen had another processor in there to boot.
The VAX 8500/8700/8000 used a PRO iirc.
I think the VAX 9000 used a Microvax II CPU as the boot processor.
I always assumed that DEC had a warehouse full of the whatever was used
that they needed to shift :-)
Antonio
10:10 a.m.
On Thu, 6 Aug 2015, Jay West wrote:
Gene wrote...
-----
One thing I don't understand - why can't the machine boot on its own? Why
would IBM design a computer that required another computer just to boot it?
----
To report higher sales of OS2/Warp? ;)
I'll rate that as "Midly Plausible". :)
Not the only one though, ISTR the 11/780 used a 11/03
to boot?
I guess I just don't understand WHY. Wouldn't it be more economical (both
from a manufacturing and sales standpoint) to design a
mini or mainframe
that could boot with nothing more than a dumb terminal as a
system
console?
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
2:24 p.m.
On 8/6/2015 8:10 AM, geneb wrote:
I guess I just don't understand WHY. Wouldn't
it be more economical
(both from a manufacturing and sales standpoint) to design a mini or
mainframe that could boot with nothing more than a dumb terminal as a
system console?
g.
Whispers Time Sharing... Sell big fat systems.
10:33 a.m.
On 8/6/15 6:16 AM, geneb wrote:
One thing I don't understand - why can't the
machine boot on its own?
Why would IBM design a computer that required another computer just to
boot it?
Main processor microcode is in RAM. Putting microcode in ram and having
a small computer load it was actually pretty common in the 70's and 80's
in larger systems since then you didn't have to manage the hassle of
patching microcode in ROM.
Apple ended up putting a small TI microcontroller in the G5 because it
also couldn't boot on its own. There was a bunch of volatile state you
had to set up before it would fetch its first instruction.
10:56 a.m.
On 08/06/2015 07:33 AM, Al Kossow wrote:
Main processor microcode is in RAM. Putting microcode
in ram and having
a small computer load it was actually pretty common in the 70's and 80's
in larger systems since then you didn't have to manage the hassle of
patching microcode in ROM.
Apple ended up putting a small TI microcontroller in the G5 because it
also couldn't boot on its own. There was a bunch of volatile state you
had to set up before it would fetch its first instruction.
And really big iron almost always had some sort of maintenance control
processor--some with their own mass storage. Have a separate, simpler
processor handle the management of a larger one made a lot of sense,
particularly when it came to diagnostic activity.
Think Cray, CDC,...
--Chuck
11:04 a.m.
And so it remains today; most servers sold for data center applications
include a little service processor ... I've found it's usually a little
embedded ARM or PPC ... that you can use for remote console, remote power
control, etc. Although these are not required to bootstrap the system, of
course.
If you think the MP3000 is a slow booter, we just got some new 4U machines
in where I work; 1.5TB RAM; those things take almost 20 minutes to POST -
no joke!
Best,
Sean
On Thu, Aug 6, 2015 at 10:56 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 08/06/2015 07:33 AM, Al Kossow wrote:
Main processor microcode is in RAM. Putting microcode in ram and having
a small computer load it was actually pretty
common in the 70's and 80's
in larger systems since then you didn't have to manage the hassle of
patching microcode in ROM.
Apple ended up putting a small TI microcontroller in the G5 because it
also couldn't boot on its own. There was a bunch of volatile state you
had to set up before it would fetch its first instruction.
And really big iron almost always had some sort of maintenance control
processor--some with their own mass storage. Have a separate, simpler
processor handle the management of a larger one made a lot of sense,
particularly when it came to diagnostic activity.
Think Cray, CDC,...
--Chuck
11:09 a.m.
BTW I love your little terminal room there ... these things are on the
fantasy list for me right next to the LISP Machine and TOAD-1, LOL. I
wonder if it runs MTS? :O At least I've got Hercules :O
Best,
Sean
On Thu, Aug 6, 2015 at 11:04 AM, Sean Caron <scaron at umich.edu> wrote:
And so it remains today; most servers sold for data
center applications
include a little service processor ... I've found it's usually a little
embedded ARM or PPC ... that you can use for remote console, remote power
control, etc. Although these are not required to bootstrap the system, of
course.
If you think the MP3000 is a slow booter, we just got some new 4U machines
in where I work; 1.5TB RAM; those things take almost 20 minutes to POST -
no joke!
Best,
Sean
On Thu, Aug 6, 2015 at 10:56 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 08/06/2015 07:33 AM, Al Kossow wrote:
Main processor microcode is in RAM. Putting microcode in ram and having
a small computer load it was actually pretty
common in the 70's and 80's
in larger systems since then you didn't have to manage the hassle of
patching microcode in ROM.
Apple ended up putting a small TI microcontroller in the G5 because it
also couldn't boot on its own. There was a bunch of volatile state you
had to set up before it would fetch its first instruction.
And really big iron almost always had some sort of maintenance control
processor--some with their own mass storage. Have a separate, simpler
processor handle the management of a larger one made a lot of sense,
particularly when it came to diagnostic activity.
Think Cray, CDC,...
--Chuck
12:24 p.m.
On 08/06/2015 08:04 AM, Sean Caron wrote:
If you think the MP3000 is a slow booter, we just got
some new 4U
machines in where I work; 1.5TB RAM; those things take almost 20
minutes to POST - no joke!
Booting an old CDC 6000-series machine meant mounting a "deadstart"
tape, pushing the button just below the screens on the DD60, entering or
editing the equipment status table, then going out for a smoke (not me)
or a cup of coffee, while the system copied the deadstart tape to disk.
The next prompt was to enter the date and time.
People are too impatient today.
--Chuck
1:07 p.m.
Even modern SOCs and the processor in your PC/laptop have a
micro-controller or PMIC that brings ups the rest of the chip. In the PC
case (verses mainframe) it is on the same die and fabric as the CPU (and
the scads of other CPUs, GPUs, Sensor Hubs, vision processors, etc).
Lee C.
On Thu, Aug 6, 2015 at 9:24 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 08/06/2015 08:04 AM, Sean Caron wrote:
If you think the MP3000 is a slow booter, we just got some new 4U
--
Lee Courtney
+1-650-704-3934 cell
machines in where I work; 1.5TB RAM; those things
take almost 20
minutes to POST - no joke!
Booting an old CDC 6000-series machine meant mounting a "deadstart" tape,
pushing the button just below the screens on the DD60, entering or editing
the equipment status table, then going out for a smoke (not me) or a cup of
coffee, while the system copied the deadstart tape to disk. The next
prompt was to enter the date and time.
People are too impatient today.
--Chuck
1:41 p.m.
In many cases more than one! ;-)
But more to the point, having a separate processor handing the booting
chores frees the
main CPU from those tasks. Initialization can be a pain just look at
the x86 ISA and the
hoops it makes the S/W (BIOS & OS) just to get to the point where the OS
can really start
it's own initialization! And that doesn't even cover the "magic" that
goes on just so that
the x86 CPU can fetch the first instruction.
As folks have mentioned, a lot of larg(er) system have service
processors to handle the
booting chores. However, it's more than that. The service processor
(as the name
implies) is doing a whole lot more than just booting. It is also
responsible for running
low level diagnostics and capturing the results of hard crashes for
later diagnosis.
For example, the RS/6000 series, had a service processor. It was even
responsible for
loading the OS kernel image into RAM. This made the OS's like much easier.
Back to the MP 3000. There are a number of CPUs in the box. Two are
the most
obvious: the SBC running OS/2 and the actual S/390 CPU. However, there
is another
S/390 CPU in the box as well. It is not visible (at least directly) to
S/W. It is responsible
for providing the high performance I/O capabilities (like native disk
access and making
them appear as conventional channel attached devices instead of RAID-5
SSA drives).
The OS/2 SBC is there to emulate some of the slower devices (card
reader/punch,
direct attached 3270s, etc).
TTFN - Guy
On 8/6/15 10:07 AM, Lee Courtney wrote:
Even modern SOCs and the processor in your PC/laptop
have a
micro-controller or PMIC that brings ups the rest of the chip. In the PC
case (verses mainframe) it is on the same die and fabric as the CPU (and
the scads of other CPUs, GPUs, Sensor Hubs, vision processors, etc).
Lee C.
On Thu, Aug 6, 2015 at 9:24 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 08/06/2015 08:04 AM, Sean Caron wrote:
If you think the MP3000 is a slow booter, we just got some new 4U
machines in where I work; 1.5TB RAM; those things
take almost 20
minutes to POST - no joke!
Booting an old CDC 6000-series machine meant mounting a "deadstart"
tape,
pushing the button just below the screens on the DD60, entering or editing
the equipment status table, then going out for a smoke (not me) or a cup of
coffee, while the system copied the deadstart tape to disk. The next
prompt was to enter the date and time.
People are too impatient today.
--Chuck
2:05 p.m.
On Thu, Aug 6, 2015 at 12:41 PM, Guy Sotomayor <ggs at shiresoft.com> wrote:
Back to the MP 3000. There are a number of CPUs in
the box. Two are the
most
obvious: the SBC running OS/2 and the actual S/390 CPU. However, there is
another
S/390 CPU in the box as well. It is not visible (at least directly) to S/W.
It is responsible
for providing the high performance I/O capabilities (like native disk access
and making
them appear as conventional channel attached devices instead of RAID-5 SSA
drives).
The OS/2 SBC is there to emulate some of the slower devices (card
reader/punch,
direct attached 3270s, etc).
So the OS/2 computer is actually a component of the mainframe's
control processor, not a separate PC?
2:43 p.m.
On 8/6/15 11:05 AM, Eric Christopherson wrote:
On Thu, Aug 6, 2015 at 12:41 PM, Guy Sotomayor <ggs
at shiresoft.com> wrote:
In various other S/390 and z/Series machines,
there is a laptop that is
the "service element" with
special S/W (now I think on Linux). On the MP3000, it is a single board
computer that is on what
looks like a big PCI card. By it's nature it is hooked into various
parts of the MP3000 system through
the various other things that sit on the PCI bus. Note that the PCI bus
is shared between the SBC
and the other parts of the MP3000.
If you don't fire up the system element software the OS/2 system would
appear as a somewhat
"normal" PC with a bunch of special device drivers.
There's a great diagram (too complicated to reproduce in ASCII art) that
illustrates all of the major
components in the MP3000. It's located in the IBM Redbook "Multiprise
3000 Technical Introduction".
It's Figure 1 on page 8 of the redbook. This is a really great
introduction on the MP3000.
TTFN - Guy
Back to the MP 3000. There are a number of CPUs
in the box. Two are the
most
obvious: the SBC running OS/2 and the actual S/390 CPU. However, there is
another
S/390 CPU in the box as well. It is not visible (at least directly) to S/W.
It is responsible
for providing the high performance I/O capabilities (like native disk access
and making
them appear as conventional channel attached devices instead of RAID-5 SSA
drives).
The OS/2 SBC is there to emulate some of the slower devices (card
reader/punch,
direct attached 3270s, etc).
So the OS/2 computer is actually a component of the
mainframe's
control processor, not a separate PC?
3:29 p.m.
Another reason for an attached service processor is to handle twiddling
of things that the main machine shouldn't have access to. Reconfiguring
memory, adjusting operating margins, monitoring water temperature,
getting hold of detailed status information, etc. In at least one case,
I'm aware of a machine where the MCU could reconfigure memory so that
the CPU could continue running while the MCU ran diagnostics on the
invisible (to the CPU) memory. Other than somewhat degraded memory
size, the CPU was none the wiser.
Some CDC MCUs employed a drum for its own program as well as for storing
microcode--and had its own (separate) display console.
--Chuck
10:11 p.m.
If you want to see how it works on bigger iron, here's a rare beast
indeed: my Application Starterpak 3000 - internal IBM codename
'Warthog'. A real S/390 in a half-height chassis. First video is a
power-up; let it play to the end and it segues into the next video,
IPLing the beast!
https://www.youtube.com/watch?v=ytMgyrZm87A
Cheers
Mike
On Fri, Aug 7, 2015 at 6:43 AM, Guy Sotomayor <ggs at shiresoft.com> wrote:
On 8/6/15 11:05 AM, Eric Christopherson wrote:
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
On Thu, Aug 6, 2015 at 12:41 PM, Guy Sotomayor <ggs at shiresoft.com> wrote:
In various other S/390 and z/Series machines, there is a laptop that is the
"service element" with
special S/W (now I think on Linux). On the MP3000, it is a single board
computer that is on what
looks like a big PCI card. By it's nature it is hooked into various parts
of the MP3000 system through
the various other things that sit on the PCI bus. Note that the PCI bus is
shared between the SBC
and the other parts of the MP3000.
If you don't fire up the system element software the OS/2 system would
appear as a somewhat
"normal" PC with a bunch of special device drivers.
There's a great diagram (too complicated to reproduce in ASCII art) that
illustrates all of the major
components in the MP3000. It's located in the IBM Redbook "Multiprise 3000
Technical Introduction".
It's Figure 1 on page 8 of the redbook. This is a really great introduction
on the MP3000.
TTFN - Guy
Back to the MP 3000. There are a number of CPUs in the box. Two are the
most
obvious: the SBC running OS/2 and the actual S/390 CPU. However, there
is
another
S/390 CPU in the box as well. It is not visible (at least directly) to
S/W.
It is responsible
for providing the high performance I/O capabilities (like native disk
access
and making
them appear as conventional channel attached devices instead of RAID-5
SSA
drives).
The OS/2 SBC is there to emulate some of the slower devices (card
reader/punch,
direct attached 3270s, etc).
So the OS/2 computer is actually a component of the mainframe's
control processor, not a separate PC?
11:08 p.m.
Is it really "bigger" than the MP3000 or is just a repackaged MP2000
where there
is no emulated I/O?
My MP3000 in addition to 2 72GB Raid-5 arrays has 2 ethernet interfaces,
2 parallel channel
attach points and 2 ESCON channel attach points.
I'm also jealous that you have a 3279 terminal. I've been looking for
3278s and/or 3279s
and haven't found any (except for the ridiculously priced 3278 on ebay
right now).
TTFN - Guy
On 8/6/15 7:11 PM, Mike Ross wrote:
If you want to see how it works on bigger iron,
here's a rare beast
indeed: my Application Starterpak 3000 - internal IBM codename
'Warthog'. A real S/390 in a half-height chassis. First video is a
power-up; let it play to the end and it segues into the next video,
IPLing the beast!
https://www.youtube.com/watch?v=ytMgyrZm87A
Cheers
Mike
On Fri, Aug 7, 2015 at 6:43 AM, Guy Sotomayor <ggs at shiresoft.com> wrote:
On 8/6/15 11:05 AM, Eric Christopherson wrote:
On Thu, Aug 6, 2015 at 12:41 PM, Guy Sotomayor
<ggs at shiresoft.com> wrote:
In various other S/390 and z/Series
machines, there is a laptop that is the
"service element" with
special S/W (now I think on Linux). On the MP3000, it is a single board
computer that is on what
looks like a big PCI card. By it's nature it is hooked into various parts
of the MP3000 system through
the various other things that sit on the PCI bus. Note that the PCI bus is
shared between the SBC
and the other parts of the MP3000.
If you don't fire up the system element software the OS/2 system would
appear as a somewhat
"normal" PC with a bunch of special device drivers.
There's a great diagram (too complicated to reproduce in ASCII art) that
illustrates all of the major
components in the MP3000. It's located in the IBM Redbook "Multiprise 3000
Technical Introduction".
It's Figure 1 on page 8 of the redbook. This is a really great introduction
on the MP3000.
TTFN - Guy
Back to the MP 3000. There are a number of CPUs
in the box. Two are the
most
obvious: the SBC running OS/2 and the actual S/390 CPU. However, there
is
another
S/390 CPU in the box as well. It is not visible (at least directly) to
S/W.
It is responsible
for providing the high performance I/O capabilities (like native disk
access
and making
them appear as conventional channel attached devices instead of RAID-5
SSA
drives).
The OS/2 SBC is there to emulate some of the slower devices (card
reader/punch,
direct attached 3270s, etc).
So the OS/2 computer is actually a component of the
mainframe's
control processor, not a separate PC?
11:46 p.m.
Oh it's much bigger. Somewhere I have a photo of them side by side... ah yes:
http://www.corestore.org/ASP3000-IS390.jpg
That's the Warthog next to an Integrated Server 3006 - which uses the
same chassis as the MP3K. So it's both - it's a repackaged MP2000,
*and* it's much bigger than an MP3K! Also much much heavier; built out
of Real Mainframe gauge steel :-)
I'm jealous that you have an operational MP3K!!! I've sweated blood
over mine for weeks, to no avail. If it works, it works for ever. If
it doesn't work, and it isn't a simple hardware fix, it needs an IBM
CE with a bunch of super secret software tools to tickle it into life,
it seems...
Mike
On Fri, Aug 7, 2015 at 3:08 PM, Guy Sotomayor <ggs at shiresoft.com> wrote:
Is it really "bigger" than the MP3000 or is
just a repackaged MP2000 where
there
is no emulated I/O?
My MP3000 in addition to 2 72GB Raid-5 arrays has 2 ethernet interfaces, 2
parallel channel
attach points and 2 ESCON channel attach points.
I'm also jealous that you have a 3279 terminal. I've been looking for 3278s
and/or 3279s
and haven't found any (except for the ridiculously priced 3278 on ebay right
now).
TTFN - Guy
On 8/6/15 7:11 PM, Mike Ross wrote:
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
If you want to see how it works on bigger iron, here's a rare beast
indeed: my Application Starterpak 3000 - internal IBM codename
'Warthog'. A real S/390 in a half-height chassis. First video is a
power-up; let it play to the end and it segues into the next video,
IPLing the beast!
https://www.youtube.com/watch?v=ytMgyrZm87A
Cheers
Mike
On Fri, Aug 7, 2015 at 6:43 AM, Guy Sotomayor <ggs at shiresoft.com> wrote:
On 8/6/15 11:05 AM, Eric Christopherson wrote:
On Thu, Aug 6, 2015 at 12:41 PM, Guy Sotomayor <ggs at shiresoft.com>
wrote:
>
> Back to the MP 3000. There are a number of CPUs in the box. Two are
> the
> most
> obvious: the SBC running OS/2 and the actual S/390 CPU. However, there
> is
> another
> S/390 CPU in the box as well. It is not visible (at least directly) to
> S/W.
> It is responsible
> for providing the high performance I/O capabilities (like native disk
> access
> and making
> them appear as conventional channel attached devices instead of RAID-5
> SSA
> drives).
> The OS/2 SBC is there to emulate some of the slower devices (card
> reader/punch,
> direct attached 3270s, etc).
So the OS/2 computer is actually a component of the mainframe's
control processor, not a separate PC?
In various other S/390 and z/Series machines, there is a laptop that is
the
"service element" with
special S/W (now I think on Linux). On the MP3000, it is a single board
computer that is on what
looks like a big PCI card. By it's nature it is hooked into various
parts
of the MP3000 system through
the various other things that sit on the PCI bus. Note that the PCI bus
is
shared between the SBC
and the other parts of the MP3000.
If you don't fire up the system element software the OS/2 system would
appear as a somewhat
"normal" PC with a bunch of special device drivers.
There's a great diagram (too complicated to reproduce in ASCII art) that
illustrates all of the major
components in the MP3000. It's located in the IBM Redbook "Multiprise
3000
Technical Introduction".
It's Figure 1 on page 8 of the redbook. This is a really great
introduction
on the MP3000.
TTFN - Guy
11:54 p.m.
Cool! I've toyed with the idea of getting a larger mainframe (zSeries)
but the aspect of trying
to get and configure storage for it is the main stumbling block.
I didn't realize how lucky I was with mine until I started hearing about
the horror stories from
others. I think what helped was that mine wasn't "molested" before I
received it. In addition
to arriving in the original IBM shipping crate (really? who keeps
that?) it also had all of the
"extras" in terms of cables, terminators, etc still unopened. The only
thing that I'm missing
is some of the software and diagnostics that were supplied on either
tape or CD.
I *really* have to figure out a backup solution for this so that I don't
get stuck but that
supposes that I have a way to re-create the OS/2 image that's already
there if I do have to
do a full from scratch restore.
TTFN - Guy
On 8/6/15 8:46 PM, Mike Ross wrote:
Oh it's much bigger. Somewhere I have a photo of
them side by side... ah yes:
http://www.corestore.org/ASP3000-IS390.jpg
That's the Warthog next to an Integrated Server 3006 - which uses the
same chassis as the MP3K. So it's both - it's a repackaged MP2000,
*and* it's much bigger than an MP3K! Also much much heavier; built out
of Real Mainframe gauge steel :-)
I'm jealous that you have an operational MP3K!!! I've sweated blood
over mine for weeks, to no avail. If it works, it works for ever. If
it doesn't work, and it isn't a simple hardware fix, it needs an IBM
CE with a bunch of super secret software tools to tickle it into life,
it seems...
Mike
On Fri, Aug 7, 2015 at 3:08 PM, Guy Sotomayor <ggs at shiresoft.com> wrote:
Is it really "bigger" than the MP3000
or is just a repackaged MP2000 where
there
is no emulated I/O?
My MP3000 in addition to 2 72GB Raid-5 arrays has 2 ethernet interfaces, 2
parallel channel
attach points and 2 ESCON channel attach points.
I'm also jealous that you have a 3279 terminal. I've been looking for 3278s
and/or 3279s
and haven't found any (except for the ridiculously priced 3278 on ebay right
now).
TTFN - Guy
On 8/6/15 7:11 PM, Mike Ross wrote:
> If you want to see how it works on bigger iron, here's a rare beast
> indeed: my Application Starterpak 3000 - internal IBM codename
> 'Warthog'. A real S/390 in a half-height chassis. First video is a
> power-up; let it play to the end and it segues into the next video,
> IPLing the beast!
>
> https://www.youtube.com/watch?v=ytMgyrZm87A
>
> Cheers
>
> Mike
>
> On Fri, Aug 7, 2015 at 6:43 AM, Guy Sotomayor <ggs at shiresoft.com> wrote:
>>
>> On 8/6/15 11:05 AM, Eric Christopherson wrote:
>>> On Thu, Aug 6, 2015 at 12:41 PM, Guy Sotomayor <ggs at shiresoft.com>
>>> wrote:
>>>> Back to the MP 3000. There are a number of CPUs in the box. Two are
>>>> the
>>>> most
>>>> obvious: the SBC running OS/2 and the actual S/390 CPU. However, there
>>>> is
>>>> another
>>>> S/390 CPU in the box as well. It is not visible (at least directly) to
>>>> S/W.
>>>> It is responsible
>>>> for providing the high performance I/O capabilities (like native disk
>>>> access
>>>> and making
>>>> them appear as conventional channel attached devices instead of RAID-5
>>>> SSA
>>>> drives).
>>>> The OS/2 SBC is there to emulate some of the slower devices (card
>>>> reader/punch,
>>>> direct attached 3270s, etc).
>>> So the OS/2 computer is actually a component of the mainframe's
>>> control processor, not a separate PC?
>> In various other S/390 and z/Series machines, there is a laptop that is
>> the
>> "service element" with
>> special S/W (now I think on Linux). On the MP3000, it is a single board
>> computer that is on what
>> looks like a big PCI card. By it's nature it is hooked into various
>> parts
>> of the MP3000 system through
>> the various other things that sit on the PCI bus. Note that the PCI bus
>> is
>> shared between the SBC
>> and the other parts of the MP3000.
>>
>> If you don't fire up the system element software the OS/2 system would
>> appear as a somewhat
>> "normal" PC with a bunch of special device drivers.
>>
>> There's a great diagram (too complicated to reproduce in ASCII art) that
>> illustrates all of the major
>> components in the MP3000. It's located in the IBM Redbook "Multiprise
>> 3000
>> Technical Introduction".
>> It's Figure 1 on page 8 of the redbook. This is a really great
>> introduction
>> on the MP3000.
>>
>> TTFN - Guy
>>
>
7 Aug
7 Aug
8:57 a.m.
Backing up your console: Clonezilla is your friend.
On 8/6/2015 10:54 PM, Guy Sotomayor wrote:
I *really* have to figure out a backup solution for this so that I don't
get stuck but that
supposes that I have a way to re-create the OS/2 image that's already
there if I do have to
do a full from scratch restore.
TTFN - Guy
2:08 p.m.
On 8/6/2015 8:54 PM, Guy Sotomayor wrote:
Cool! I've toyed with the idea of getting a larger
mainframe (zSeries)
but the aspect of trying
to get and configure storage for it is the main stumbling block.
I didn't realize how lucky I was with mine until I started hearing
about the horror stories from
others. I think what helped was that mine wasn't "molested" before I
received it. In addition
to arriving in the original IBM shipping crate (really? who keeps
that?) it also had all of the
"extras" in terms of cables, terminators, etc still unopened. The
only thing that I'm missing
is some of the software and diagnostics that were supplied on either
tape or CD.
It may have been packed by IBM for the customer. This is standard
service available to mainframe shops. Most of them who have assets
which have value get them packaged by IBM either under their current
maintenance contract, or at extra cost if they are not on their plan.
The service used to be called MSL, I think, but it has been a long time
since I dealt with such.
Even if you bought it from a scrapper, the original shops frequently
just have them packed like that and then rolled off the floor for
storage, because when IBM packs them they are certified ready to go back
into service with a lot less if any re-certification charges for
maintenance. If you disconnect the components yourself (and who do you
know in IT does that unless they are getting it for scrap if the
hardware guys will do it) that can / does void that they can go back
online w/o a big fee.
IBM dropped a huge bomb on the third party business of doing this and
trading equipment by making it free in the early 90's which wiped out a
large number of equipment dealers who were buying / refurbing /
reselling peripherals. There were a few bad players, and IBM's take on
that was to make the profit part for the dealers free, and wiping them
all out.
I lost the home for my systems when that happened.
Thanks
Jim
I *really* have to figure out a backup solution for
this so that I
don't get stuck but that
supposes that I have a way to re-create the OS/2 image that's already
there if I do have to
do a full from scratch restore.
TTFN - Guy
3:15 p.m.
On 8/7/15 11:08 AM, jwsmobile wrote:
On 8/6/2015 8:54 PM, Guy Sotomayor wrote:
This was the original shipping crate from when the MP3000 was
manufactured and delivered to
the original customer as it had all of the original IBM manufacturing
stickers and original shipping
labels still attached.
There were also contents in the crate that were not originally from
IBM. It looks like who ever packed
this, took all of the equipment that was related to the MP3000 (some 1U
servers and KVM switches
as well as the MP3000 kit) so I don't think IBM did the packaging of this.
TTFN - Guy
Cool! I've toyed with the idea of getting a
larger mainframe
(zSeries) but the aspect of trying
to get and configure storage for it is the main stumbling block.
I didn't realize how lucky I was with mine until I started hearing
about the horror stories from
others. I think what helped was that mine wasn't "molested" before I
received it. In addition
to arriving in the original IBM shipping crate (really? who keeps
that?) it also had all of the
"extras" in terms of cables, terminators, etc still unopened. The
only thing that I'm missing
is some of the software and diagnostics that were supplied on either
tape or CD.
It may have been packed by IBM for the customer. This is standard
service available to mainframe shops. Most of them who have assets
which have value get them packaged by IBM either under their current
maintenance contract, or at extra cost if they are not on their plan.
The service used to be called MSL, I think, but it has been a long
time since I dealt with such.
Even if you bought it from a scrapper, the original shops frequently
just have them packed like that and then rolled off the floor for
storage, because when IBM packs them they are certified ready to go
back into service with a lot less if any re-certification charges for
maintenance. If you disconnect the components yourself (and who do
you know in IT does that unless they are getting it for scrap if the
hardware guys will do it) that can / does void that they can go back
online w/o a big fee. 
2:27 a.m.
On Fri, Aug 07, 2015 at 02:11:01PM +1200, Mike Ross wrote:
If you want to see how it works on bigger iron,
here's a rare beast
indeed: my Application Starterpak 3000 - internal IBM codename
'Warthog'. A real S/390 in a half-height chassis. First video is a
power-up; let it play to the end and it segues into the next video,
IPLing the beast!
https://www.youtube.com/watch?v=ytMgyrZm87A
Youtubes related video suggestion mirrors my sentiment:
https://www.youtube.com/watch?v=8iuo31_GsuM
/P
6 Aug
6 Aug
3:05 p.m.
On Thu, 6 Aug 2015, Guy Sotomayor wrote:
In many cases more than one! ;-)
But more to the point, having a separate processor handing the booting chores
frees the
main CPU from those tasks. Initialization can be a pain just look at the x86
ISA and the
hoops it makes the S/W (BIOS & OS) just to get to the point where the OS can
really start
it's own initialization! And that doesn't even cover the "magic" that
goes
on just so that
the x86 CPU can fetch the first instruction.
As folks have mentioned, a lot of larg(er) system have service processors to
handle the
booting chores. However, it's more than that. The service processor (as the
name
implies) is doing a whole lot more than just booting. It is also responsible
for running
low level diagnostics and capturing the results of hard crashes for later
diagnosis.
Thanks for the info Guy (and others!). The biggest machine I ever owed
was a VAX 8250 that I got straight out of the machine room at
Mannesmann-Tally in Kent, WA. Fun machine, but made my upstairs floor sag
noticeably(sp). It had four RA-81s and a TU-81+. :)
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
1:43 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck
Guzis
Sent: 06 August 2015 17:24
To: General at classiccmp.org; Discussion at classiccmp.org:On-Topic and Off-
Topic Posts <cctalk at classiccmp.org>
Subject: Re: Booting an IBM MP 3000 S/390 System
On 08/06/2015 08:04 AM, Sean Caron wrote:
Actually I remember booting an IBM4381 from cold after we shut it down over Christmas.
Just pressing the Power button powered it up eventually, but I am pretty sure it took
nearly an hour to get to the IPL prompt. So it did disk drives, then tape drives, then
other bits and bobs. But when it spun up the disks it brought them up one at a time so the
startup surges didn't trip the main breaker. The same with the tape drives. Then it
loaded the microcode into all the controllers. Then it booted the OS. As we were running
VM this last bit took a few seconds (I think). I do know if VM crashed you screen logo
frequently re-appeared before you had time to think.
Dave Wade
G4UGM
If you think the MP3000 is a slow booter, we just
got some new 4U
machines in where I work; 1.5TB RAM; those things take almost 20
minutes to POST - no joke!
Booting an old CDC 6000-series machine meant mounting a "deadstart"
tape, pushing the button just below the screens on the DD60, entering or
editing the equipment status table, then going out for a smoke (not me) or a
cup of coffee, while the system copied the deadstart tape to disk.
The next prompt was to enter the date and time.
People are too impatient today.
--Chuck
1:54 p.m.
On 8/6/15 10:43 AM, Dave G4UGM wrote:
What freaked me out
about the MP3000 is how long it takes from the time
you hit the power switch until *anything* happens (like fans spinning).
There's a lot being checked out during power up and that takes time.
TTFN - Guy
-----Original
Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck
Guzis
Sent: 06 August 2015 17:24
To: General at classiccmp.org; Discussion at classiccmp.org:On-Topic and Off-
Topic Posts <cctalk at classiccmp.org>
Subject: Re: Booting an IBM MP 3000 S/390 System
On 08/06/2015 08:04 AM, Sean Caron wrote:
Actually I remember booting an IBM4381 from cold after we shut it down
over Christmas. Just pressing the Power button powered it up eventually, but I am pretty
sure it took nearly an hour to get to the IPL prompt. So it did disk drives, then tape
drives, then other bits and bobs. But when it spun up the disks it brought them up one at
a time so the startup surges didn't trip the main breaker. The same with the tape
drives. Then it loaded the microcode into all the controllers. Then it booted the OS. As
we were running VM this last bit took a few seconds (I think). I do know if VM crashed you
screen logo frequently re-appeared before you had time to think. If you think the MP3000 is a slow booter, we just
got some new 4U
machines in where I work; 1.5TB RAM; those things take almost 20
minutes to POST - no joke!
Booting an old CDC 6000-series machine meant mounting a
"deadstart"
tape, pushing the button just below the screens on the DD60, entering or
editing the equipment status table, then going out for a smoke (not me) or a
cup of coffee, while the system copied the deadstart tape to disk.
The next prompt was to enter the date and time.
People are too impatient today.
--Chuck 
2:07 p.m.
On Thu, 6 Aug 2015, Dave G4UGM wrote:
Spinning off on this tangent, when I was learning how to fire up my Sun
E10k I didn't realise it took so ruddy long for the SSP and the E10k to
speak to each other.
So I was constantly asking the SSP for the E10k's power status (to see if
they were communicating) and being told the SSP "wasn't the master".
I'd powered things up repeatedly and made all sorts of changes to the SSP
config and just couldn't figure out what wasn't working. So one day I'm
messing with it again and I'd walked over to the other side of the shop
for a manual and gotten distracted and maybe ten minuted passed and all of
a sudden all of the blowers dropped RPM and evened out. The SSP and E10k
had finally finished their secret masonic handshake and the SSP did the
equivalent of "Hey, dude, it's not 7000 degrees in here, you can chillax
now".
"People are too impatient today" -- Chuck G
True enough. I just didn't know enough to know I should be patient.
- JP
Booting an old
CDC 6000-series machine meant mounting a "deadstart"
tape, pushing the button just below the screens on the DD60, entering or
editing the equipment status table, then going out for a smoke (not me) or a
cup of coffee, while the system copied the deadstart tape to disk.
The next prompt was to enter the date and time.
People are too impatient today.
--Chuck
Actually I remember booting an IBM4381 from cold after we shut it down over Christmas.
Just pressing the Power button powered it up eventually, but I am pretty sure it took
nearly an hour to get to the IPL prompt. So it did disk drives, then tape drives, then
other bits and bobs. But when it spun up the disks it brought them up one at a time so the
startup surges didn't trip the main breaker. The same with the tape drives. Then it
loaded the microcode into all the controllers. Then it booted the OS. As we were running
VM this last bit took a few seconds (I think). I do know if VM crashed you screen logo
frequently re-appeared before you had time to think.
10:59 a.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Al Kossow
Sent: 06 August 2015 15:34
To: cctalk at classiccmp.org
Subject: Re: Booting an IBM MP 3000 S/390 System
On 8/6/15 6:16 AM, geneb wrote:
On a "normal" 360/370/390/Z there are multiple independent I/O processors,
called Channels. When you hit the IPL button it is one of the i/o processors
that actually loads the OS.
On an MP3000 the PC does some of the I/O work so it may be needed to IPL.
Most IBM Mainframes from 370 onwards have control processors to manage the
main CPU. Some even have smaller mainframes, so one has a 43xx box running
VM/CMS as the control box...
I believe that Gene Amdahl patented the use of a control processor and IBM
paid him licence fees for every Mainframe with a control processor.
Of course IBM owned the patents on Virtual Memory so Gene had to pay IBM to
use those....
One thing I don't understand - why can't
the machine boot on its own?
Why would IBM design a computer that required another computer just to
boot it?
Main processor microcode is in RAM. Putting microcode in ram and having a
small computer load it was actually pretty common in the 70's and 80's in
larger systems since then you didn't have to manage the hassle of patching
microcode in ROM.
Apple ended up putting a small TI microcontroller in
the G5 because it
also
couldn't boot on its own. There was a bunch of
volatile state you had to
set
up before it would fetch its first instruction.
Lots of newer servers have some sort of control processor. I am used to IBM
"X" series which have a control CPU, and on payment of the appropriate
licence fee, you can enable remote console support which provides a Java app
which can be used to boot the server, power the main CPU up and down, and
even map a remove floppy/CD/DVD so you can remotely install an OS. Before
anyone asks it has a separate RJ45 jack. As long ago as 2000 I remember
Compaq having a RIB board which did the same. I think it is now standard..
Dave
G4UGM
7 Aug
7 Aug
8:26 a.m.
As Al says, the microcode was dynamic and loaded from the boot console.
I remember our (Deluxe Coachlines, Australia, 1987-1990) VAX 8550s and 8820
had PRO based boot consoles.
When we had both 8550s failing with double CPU faults the DEC engineers
loaded new microcode onto the consoles to diagnose the problem.
On 6 August 2015 at 15:33, Al Kossow <aek at bitsavers.org> wrote:
On 8/6/15 6:16 AM, geneb wrote:
--
4.4 > 5.4
One thing I don't understand - why can't
the machine boot on its own?
Why would IBM design a computer that required another computer just to
boot it?
Main processor microcode is in RAM. Putting microcode in ram and having a
small computer load it was actually pretty common in the 70's and 80's in
larger systems since then you didn't have to manage the hassle of patching
microcode in ROM.
Apple ended up putting a small TI microcontroller in the G5 because it
also couldn't boot on its own. There was a bunch of volatile state you
had to set up before it would fetch its first instruction.
6 Aug
6 Aug
11:27 a.m.
Lots of machines have had console processors that were required for the
machine to run. The PDP-10 had a PDP-11 console processor. The Amdahl
470 had a DG Nova for a console processor, etc. etc.
On 8/6/2015 8:16 AM, geneb wrote:
On Thu, 6 Aug 2015, Marc Verdiell wrote:
Wow. I'll never complain again that it takes
too long to boot Windows...
One thing I don't understand - why can't the machine boot on its own?
Why would IBM design a computer that required another computer just to
boot it?
g. 
3:03 p.m.
On Thu, Aug 6, 2015 at 9:27 AM, Jay Jaeger <cube1 at charter.net> wrote:
The PDP-10 had a PDP-11 console processor.
The early PDP-10 models used the KA10 and KI10 CPUs, which did not
have any separate processor for console/boot/diagnostics. It was
common, however, to have a PDP-8 based communication subsystem, such
as the 680 or 680I.
The later models, using the KL10 and KS10 main CPUs, had console processors.
The KL10 used a PDP-11/40 console processor, which had special access
to the KL10 diagnostic data paths, and an RH11 Massbus adapter to a
dual-port of one of the RP06 drives. In a DECsystem-10, it also had
DECtape or floppy, and only handled boot, diagnostics, and the console
terminal (usually an LA36 DECwriter). In a DECSYSTEM-20, it had
floppy, and also handled additional terminals and unit-record
equipment.
KL10-based DECsystem-10 configurations and larger KL10-based
DECsystem20 configurations tended to have additional PDP-11
communication processors; all but the smallest KL10 CPU configurations
could support up to four DTE20 (DEC Ten to Eleven) Unibuses, one of
which was for the PDP-11/40 console processor.
The KS10 used an 8080-based console subsystem for the same purposes.
2:21 p.m.
> Wow. I'll never complain again that it takes
too long to boot Windows...
On Thu, 6 Aug 2015, geneb wrote:
One thing I don't understand - why can't the
machine boot on its own? Why
would IBM design a computer that required another computer just to boot it?
"Why CAN'T the operating system have full functionality during booting?"
I had an interesting conversation almost 30 years ago with a published
expert on operating systemes and C programming, when he was bothered by
why IO.SYS/IBMBIO.COM and DOS.SYS/IBMDOS.COM had to be in specific places
on the drive.
"Booting" is of course short for "bootstrapping", which is a
multi-hundred year old term for a obviously ridiculously impossible
task: "pulling yourself up by your bootstraps".
I had always thought that that derived from Baron Von Munchausen,
but a little research turns up that the baron had lifted himself
and his horse out of the swamp by his pigtail, not his bootstraps.
It wasn't until early 1800s that "bootstrapping" became the iconic
example.
The reason that IPL is called "booting" is because it is such an
obviously ridiculously impossible task.
"You can't use the operating system to load the operating system."
Obviously it is simplest if somebody (or machine) outside, loads
the code into memory, and then triggers a GOTO.
Which is cheaper, or more reliable, a "trained" operator, or a
smaller external machine?
The really clever way, though, was to toggle in, or have a little ROM,
to load a TINY bit of stored code ("boot sector") into RAM, GOTO it,
and it could contain enough code to load a bigger chunk, which could
have plenty of code to load the rest.
Why not just put the OS in ROM?
That would require more ROM, would make bug-fixes more difficult,
and would make it more difficult to modify the OS to add new
features, such as security holes.
2:43 p.m.
Acch. All this modern/complicated stuff. Once you powered on an IBM
1410 (2 seconds), you could have it (141O O/S: 1410-PR-155) running in
as little as a minute, counting the tape drive mount:
Mount tape on unit 0 [30 seconds tops, as tape is probably already there]
Storage Scan to +1
Sense switches to a blank character
[The above two were normally left that way]
Mode switch to CE
Computer Reset
Start
00000 [This clears storage]
Computer Reset
Move Mode Switch to Display
Start
00000 [Display before altering]
Press margin release on console typewriter while it types out "bbbbb"
Computer Reset
Move Mode Switch to Alter
00000
A(WM)L%B000012$(WM)N [Read tape to end of core/record to loc 12]
Computer Reset
Start
[Wait about 10 seconds for 1410-PR-155 to load]
:)
On 8/6/2015 1:21 PM, Fred Cisin wrote:
> Wow.
I'll never complain again that it takes too long to boot Windows...
On Thu, 6 Aug 2015, geneb wrote:
One thing I don't understand - why can't
the machine boot on its own?
Why would IBM design a computer that required another computer just to
boot it?
"Why CAN'T the operating system have full functionality during booting?"
I had an interesting conversation almost 30 years ago with a published
expert on operating systemes and C programming, when he was bothered by
why IO.SYS/IBMBIO.COM and DOS.SYS/IBMDOS.COM had to be in specific
places on the drive.
"Booting" is of course short for "bootstrapping", which is a
multi-hundred year old term for a obviously ridiculously impossible
task: "pulling yourself up by your bootstraps".
I had always thought that that derived from Baron Von Munchausen,
but a little research turns up that the baron had lifted himself
and his horse out of the swamp by his pigtail, not his bootstraps.
It wasn't until early 1800s that "bootstrapping" became the iconic
example.
The reason that IPL is called "booting" is because it is such an
obviously ridiculously impossible task.
"You can't use the operating system to load the operating system."
Obviously it is simplest if somebody (or machine) outside, loads
the code into memory, and then triggers a GOTO.
Which is cheaper, or more reliable, a "trained" operator, or a
smaller external machine?
The really clever way, though, was to toggle in, or have a little ROM,
to load a TINY bit of stored code ("boot sector") into RAM, GOTO it,
and it could contain enough code to load a bigger chunk, which could
have plenty of code to load the rest.
Why not just put the OS in ROM?
That would require more ROM, would make bug-fixes more difficult,
and would make it more difficult to modify the OS to add new
features, such as security holes.
2:43 p.m.
PDP-8 with OS/8 on an RK05. From power up until booted and ready was
basically the time for the disk to spin up, which was about 10 seconds.
The actual booting of the system is about 0.3 seconds. Add 5 seconds if
you had to manually enter the bootstrap.
Johnny
On 2015-08-06 20:43, Jay Jaeger wrote:
Acch. All this modern/complicated stuff. Once you
powered on an IBM
1410 (2 seconds), you could have it (141O O/S: 1410-PR-155) running in
as little as a minute, counting the tape drive mount:
Mount tape on unit 0 [30 seconds tops, as tape is probably already there]
Storage Scan to +1
Sense switches to a blank character
[The above two were normally left that way]
Mode switch to CE
Computer Reset
Start
00000 [This clears storage]
Computer Reset
Move Mode Switch to Display
Start
00000 [Display before altering]
Press margin release on console typewriter while it types out "bbbbb"
Computer Reset
Move Mode Switch to Alter
00000
A(WM)L%B000012$(WM)N [Read tape to end of core/record to loc 12]
Computer Reset
Start
[Wait about 10 seconds for 1410-PR-155 to load]
:)
On 8/6/2015 1:21 PM, Fred Cisin wrote:
>>> Wow. I'll never complain again that it takes too long to boot Windows...
>
> On Thu, 6 Aug 2015, geneb wrote:
>> One thing I don't understand - why can't the machine boot on its own?
>> Why would IBM design a computer that required another computer just to
>> boot it?
>
> "Why CAN'T the operating system have full functionality during
booting?"
> I had an interesting conversation almost 30 years ago with a published
> expert on operating systemes and C programming, when he was bothered by
> why IO.SYS/IBMBIO.COM and DOS.SYS/IBMDOS.COM had to be in specific
> places on the drive.
>
> "Booting" is of course short for "bootstrapping", which is a
> multi-hundred year old term for a obviously ridiculously impossible
> task: "pulling yourself up by your bootstraps".
> I had always thought that that derived from Baron Von Munchausen,
> but a little research turns up that the baron had lifted himself
> and his horse out of the swamp by his pigtail, not his bootstraps.
> It wasn't until early 1800s that "bootstrapping" became the iconic
example.
>
> The reason that IPL is called "booting" is because it is such an
> obviously ridiculously impossible task.
> "You can't use the operating system to load the operating system."
>
> Obviously it is simplest if somebody (or machine) outside, loads
> the code into memory, and then triggers a GOTO.
> Which is cheaper, or more reliable, a "trained" operator, or a
> smaller external machine?
>
> The really clever way, though, was to toggle in, or have a little ROM,
> to load a TINY bit of stored code ("boot sector") into RAM, GOTO it,
> and it could contain enough code to load a bigger chunk, which could
> have plenty of code to load the rest.
>
>
> Why not just put the OS in ROM?
> That would require more ROM, would make bug-fixes more difficult,
> and would make it more difficult to modify the OS to add new
> features, such as security holes.
>
>
>
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5 p.m.
I should think that a set of manually entered bootstrap instructions
(i.e., not on a diode ROM board) would take considerably longer than 5s. ;)
On 8/6/2015 1:43 PM, Johnny Billquist wrote:
PDP-8 with OS/8 on an RK05. From power up until booted
and ready was
basically the time for the disk to spin up, which was about 10 seconds.
The actual booting of the system is about 0.3 seconds. Add 5 seconds if
you had to manually enter the bootstrap.
Johnny
On 2015-08-06 20:43, Jay Jaeger wrote:
Acch. All this modern/complicated stuff. Once
you powered on an IBM
1410 (2 seconds), you could have it (141O O/S: 1410-PR-155) running in
as little as a minute, counting the tape drive mount:
Mount tape on unit 0 [30 seconds tops, as tape is probably already there]
Storage Scan to +1
Sense switches to a blank character
[The above two were normally left that way]
Mode switch to CE
Computer Reset
Start
00000 [This clears storage]
Computer Reset
Move Mode Switch to Display
Start
00000 [Display before altering]
Press margin release on console typewriter while it types out "bbbbb"
Computer Reset
Move Mode Switch to Alter
00000
A(WM)L%B000012$(WM)N [Read tape to end of core/record to loc 12]
Computer Reset
Start
[Wait about 10 seconds for 1410-PR-155 to load]
:)
On 8/6/2015 1:21 PM, Fred Cisin wrote:
>>> Wow. I'll never complain again that it takes too long to boot
>>> Windows...
>
> On Thu, 6 Aug 2015, geneb wrote:
>> One thing I don't understand - why can't the machine boot on its own?
>> Why would IBM design a computer that required another computer just to
>> boot it?
>
> "Why CAN'T the operating system have full functionality during
booting?"
> I had an interesting conversation almost 30 years ago with a published
> expert on operating systemes and C programming, when he was bothered by
> why IO.SYS/IBMBIO.COM and DOS.SYS/IBMDOS.COM had to be in specific
> places on the drive.
>
> "Booting" is of course short for "bootstrapping", which is a
> multi-hundred year old term for a obviously ridiculously impossible
> task: "pulling yourself up by your bootstraps".
> I had always thought that that derived from Baron Von Munchausen,
> but a little research turns up that the baron had lifted himself
> and his horse out of the swamp by his pigtail, not his bootstraps.
> It wasn't until early 1800s that "bootstrapping" became the iconic
> example.
>
> The reason that IPL is called "booting" is because it is such an
> obviously ridiculously impossible task.
> "You can't use the operating system to load the operating system."
>
> Obviously it is simplest if somebody (or machine) outside, loads
> the code into memory, and then triggers a GOTO.
> Which is cheaper, or more reliable, a "trained" operator, or a
> smaller external machine?
>
> The really clever way, though, was to toggle in, or have a little ROM,
> to load a TINY bit of stored code ("boot sector") into RAM, GOTO it,
> and it could contain enough code to load a bigger chunk, which could
> have plenty of code to load the rest.
>
>
> Why not just put the OS in ROM?
> That would require more ROM, would make bug-fixes more difficult,
> and would make it more difficult to modify the OS to add new
> features, such as security holes.
>
>
>
>
5:03 p.m.
On 2015-08-06 23:00, Jay Jaeger wrote:
I should think that a set of manually entered
bootstrap instructions
(i.e., not on a diode ROM board) would take considerably longer than 5s. ;)
You might think so. But when you see the bootstrap for the RK05 on a
PDP-8, you realize that it takes about 5s to toggle it in and run it.
It's only two 12-bit words that you need to write after all...
In short:
0030 LOAD ADDRESS
6743 DEP
5031 DEP
0030 LOAD ADDDRESS
START
When you've done it a few times, you get fairly proficient at it, and
it's not hard to remember... Even faster on a PDP-8/A which have a
numeric keypad frontpanel.
Johnny
On 8/6/2015 1:43 PM, Johnny Billquist wrote:
> PDP-8 with OS/8 on an RK05. From power up until booted and ready was
> basically the time for the disk to spin up, which was about 10 seconds.
> The actual booting of the system is about 0.3 seconds. Add 5 seconds if
> you had to manually enter the bootstrap.
>
> Johnny
>
> On 2015-08-06 20:43, Jay Jaeger wrote:
>> Acch. All this modern/complicated stuff. Once you powered on an IBM
>> 1410 (2 seconds), you could have it (141O O/S: 1410-PR-155) running in
>> as little as a minute, counting the tape drive mount:
>>
>> Mount tape on unit 0 [30 seconds tops, as tape is probably already there]
>> Storage Scan to +1
>> Sense switches to a blank character
>> [The above two were normally left that way]
>> Mode switch to CE
>> Computer Reset
>> Start
>> 00000 [This clears storage]
>> Computer Reset
>> Move Mode Switch to Display
>> Start
>> 00000 [Display before altering]
>> Press margin release on console typewriter while it types out "bbbbb"
>> Computer Reset
>> Move Mode Switch to Alter
>> 00000
>> A(WM)L%B000012$(WM)N [Read tape to end of core/record to loc 12]
>> Computer Reset
>> Start
>> [Wait about 10 seconds for 1410-PR-155 to load]
>>
>> :)
>>
>>
>>
>> On 8/6/2015 1:21 PM, Fred Cisin wrote:
>>>>> Wow. I'll never complain again that it takes too long to boot
>>>>> Windows...
>>>
>>> On Thu, 6 Aug 2015, geneb wrote:
>>>> One thing I don't understand - why can't the machine boot on its
own?
>>>> Why would IBM design a computer that required another computer just to
>>>> boot it?
>>>
>>> "Why CAN'T the operating system have full functionality during
booting?"
>>> I had an interesting conversation almost 30 years ago with a published
>>> expert on operating systemes and C programming, when he was bothered by
>>> why IO.SYS/IBMBIO.COM and DOS.SYS/IBMDOS.COM had to be in specific
>>> places on the drive.
>>>
>>> "Booting" is of course short for "bootstrapping", which
is a
>>> multi-hundred year old term for a obviously ridiculously impossible
>>> task: "pulling yourself up by your bootstraps".
>>> I had always thought that that derived from Baron Von Munchausen,
>>> but a little research turns up that the baron had lifted himself
>>> and his horse out of the swamp by his pigtail, not his bootstraps.
>>> It wasn't until early 1800s that "bootstrapping" became the
iconic
>>> example.
>>>
>>> The reason that IPL is called "booting" is because it is such an
>>> obviously ridiculously impossible task.
>>> "You can't use the operating system to load the operating
system."
>>>
>>> Obviously it is simplest if somebody (or machine) outside, loads
>>> the code into memory, and then triggers a GOTO.
>>> Which is cheaper, or more reliable, a "trained" operator, or a
>>> smaller external machine?
>>>
>>> The really clever way, though, was to toggle in, or have a little ROM,
>>> to load a TINY bit of stored code ("boot sector") into RAM, GOTO
it,
>>> and it could contain enough code to load a bigger chunk, which could
>>> have plenty of code to load the rest.
>>>
>>>
>>> Why not just put the OS in ROM?
>>> That would require more ROM, would make bug-fixes more difficult,
>>> and would make it more difficult to modify the OS to add new
>>> features, such as security holes.
>>>
>>>
>>>
>>>
>
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5:17 p.m.
I see - I would have guessed quite a few more instructions than that,
based on my PDP-11 experience (my 8/L has only paper tape).
The PDP-12, which I have more experience at, takes about the same amount
of effort/time, but just the one I/O instruction in the switch register
(but then you have to enter the start address, and start the machine).
On 8/6/2015 4:03 PM, Johnny Billquist wrote:
On 2015-08-06 23:00, Jay Jaeger wrote:
I should think that a set of manually entered
bootstrap instructions
(i.e., not on a diode ROM board) would take considerably longer than
5s. ;)
You might think so. But when you see the bootstrap for the RK05 on a
PDP-8, you realize that it takes about 5s to toggle it in and run it.
It's only two 12-bit words that you need to write after all...
In short:
0030 LOAD ADDRESS
6743 DEP
5031 DEP
0030 LOAD ADDDRESS
START
When you've done it a few times, you get fairly proficient at it, and
it's not hard to remember... Even faster on a PDP-8/A which have a
numeric keypad frontpanel.
Johnny
On 8/6/2015 1:43 PM, Johnny Billquist wrote:
> PDP-8 with OS/8 on an RK05. From power up until booted and ready was
> basically the time for the disk to spin up, which was about 10 seconds.
> The actual booting of the system is about 0.3 seconds. Add 5 seconds if
> you had to manually enter the bootstrap.
>
> Johnny
>
> On 2015-08-06 20:43, Jay Jaeger wrote:
>> Acch. All this modern/complicated stuff. Once you powered on an IBM
>> 1410 (2 seconds), you could have it (141O O/S: 1410-PR-155) running in
>> as little as a minute, counting the tape drive mount:
>>
>> Mount tape on unit 0 [30 seconds tops, as tape is probably already
>> there]
>> Storage Scan to +1
>> Sense switches to a blank character
>> [The above two were normally left that way]
>> Mode switch to CE
>> Computer Reset
>> Start
>> 00000 [This clears storage]
>> Computer Reset
>> Move Mode Switch to Display
>> Start
>> 00000 [Display before altering]
>> Press margin release on console typewriter while it types out "bbbbb"
>> Computer Reset
>> Move Mode Switch to Alter
>> 00000
>> A(WM)L%B000012$(WM)N [Read tape to end of core/record to loc 12]
>> Computer Reset
>> Start
>> [Wait about 10 seconds for 1410-PR-155 to load]
>>
>> :)
>>
>>
>>
>> On 8/6/2015 1:21 PM, Fred Cisin wrote:
>>>>> Wow. I'll never complain again that it takes too long to boot
>>>>> Windows...
>>>
>>> On Thu, 6 Aug 2015, geneb wrote:
>>>> One thing I don't understand - why can't the machine boot on its
own?
>>>> Why would IBM design a computer that required another computer
>>>> just to
>>>> boot it?
>>>
>>> "Why CAN'T the operating system have full functionality during
>>> booting?"
>>> I had an interesting conversation almost 30 years ago with a published
>>> expert on operating systemes and C programming, when he was
>>> bothered by
>>> why IO.SYS/IBMBIO.COM and DOS.SYS/IBMDOS.COM had to be in specific
>>> places on the drive.
>>>
>>> "Booting" is of course short for "bootstrapping", which
is a
>>> multi-hundred year old term for a obviously ridiculously impossible
>>> task: "pulling yourself up by your bootstraps".
>>> I had always thought that that derived from Baron Von Munchausen,
>>> but a little research turns up that the baron had lifted himself
>>> and his horse out of the swamp by his pigtail, not his bootstraps.
>>> It wasn't until early 1800s that "bootstrapping" became the
iconic
>>> example.
>>>
>>> The reason that IPL is called "booting" is because it is such an
>>> obviously ridiculously impossible task.
>>> "You can't use the operating system to load the operating
system."
>>>
>>> Obviously it is simplest if somebody (or machine) outside, loads
>>> the code into memory, and then triggers a GOTO.
>>> Which is cheaper, or more reliable, a "trained" operator, or a
>>> smaller external machine?
>>>
>>> The really clever way, though, was to toggle in, or have a little ROM,
>>> to load a TINY bit of stored code ("boot sector") into RAM, GOTO
it,
>>> and it could contain enough code to load a bigger chunk, which could
>>> have plenty of code to load the rest.
>>>
>>>
>>> Why not just put the OS in ROM?
>>> That would require more ROM, would make bug-fixes more difficult,
>>> and would make it more difficult to modify the OS to add new
>>> features, such as security holes.
>>>
>>>
>>>
>>>
>
>
6:46 p.m.
I should think that a set of manually entered
bootstrap instructions
(i.e., not on a diode ROM board) would take considerably longer than
5s. ;)
I feel fairly sure you overestimate either the length of the bootstrap
or the per-word time required.
I once used an HP machine with a front-panel-buttons bootstrap. It was
only some four or five words long, and after entering it a few dozen
times I feel reasonably sure I could enter it from muscle memory in
well under a second per. (Weasel words are because this was in the
late '70s and the memory is now rather fuzzy.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
3:07 p.m.
On Thu, 6 Aug 2015, Jay Jaeger wrote:
Acch. All this modern/complicated stuff. Once you
powered on an IBM
1410 (2 seconds), you could have it (141O O/S: 1410-PR-155) running in
as little as a minute, counting the tape drive mount:
Mount tape on unit 0 [30 seconds tops, as tape is probably already there]
Storage Scan to +1
Sense switches to a blank character
[The above two were normally left that way]
Mode switch to CE
Computer Reset
Start
00000 [This clears storage]
Computer Reset
Move Mode Switch to Display
Start
00000 [Display before altering]
Press margin release on console typewriter while it types out "bbbbb"
Computer Reset
Move Mode Switch to Alter
00000
A(WM)L%B000012$(WM)N [Read tape to end of core/record to loc 12]
Computer Reset
Start
[Wait about 10 seconds for 1410-PR-155 to load]
:)
Obviously it is simplest if somebody (or machine) outside, loads
the code into memory, and then triggers a GOTO.
Which is cheaper, or more reliable, a "trained" operator, or a
smaller external machine?
Your expertise is the simplest and most reliable way to do it.
But, if adequately appreciated, you are probably no longer the cheapest.
So, they tried to replace you with a machine.
5:01 p.m.
Until that console processor fails with no backups. I seem to recall
having 4 or 5 "backups" (aka operators). ;)
On 8/6/2015 2:07 PM, Fred Cisin wrote:
On Thu, 6 Aug 2015, Jay Jaeger wrote:
Acch. All this modern/complicated stuff. Once
you powered on an IBM
1410 (2 seconds), you could have it (141O O/S: 1410-PR-155) running in
as little as a minute, counting the tape drive mount:
Mount tape on unit 0 [30 seconds tops, as tape is probably already there]
Storage Scan to +1
Sense switches to a blank character
[The above two were normally left that way]
Mode switch to CE
Computer Reset
Start
00000 [This clears storage]
Computer Reset
Move Mode Switch to Display
Start
00000 [Display before altering]
Press margin release on console typewriter while it types out "bbbbb"
Computer Reset
Move Mode Switch to Alter
00000
A(WM)L%B000012$(WM)N [Read tape to end of core/record to loc 12]
Computer Reset
Start
[Wait about 10 seconds for 1410-PR-155 to load]
:)
Obviously it is simplest if somebody (or machine) outside, loads
the code into memory, and then triggers a GOTO.
Which is cheaper, or more reliable, a "trained" operator, or a
smaller external machine?
Your expertise is the simplest and most reliable way to do it.
But, if adequately appreciated, you are probably no longer the cheapest.
So, they tried to replace you with a machine.
8:13 p.m.
On 08/06/2015 04:01 PM, Jay Jaeger wrote:
Until that console processor fails with no backups. I
seem to recall
having 4 or 5 "backups" (aka operators). ;)
Well, the idea is that the console or diagnostic processor
is WAY simpler than the mainframe CPU. So, if the console
computer dies, you can troubleshoot it and be sure it is
running in just a few minutes, and then get on to the real
problem.
The VAX 11/780 had an LSI-11 with a floppy controller and an
interface board to the VAX, so I think it was down to 3
boards or something.
Jon
8:35 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
On the subject of slow booting, perhaps someone can help me with a very
annoying case of the slowboots.
I've got a dual slot-1 P3 system here--a Supermicro P6DGE, which uses a
440GX chipset and 2GB of registered SDRAM with two 900MHz CPUs. When it
finally get around to s booting, it's a great workhorse, with 2,
count'em 2 well-behaved ISA slots. It's frisky enough to run Windows 7
and proudly proclaims that it was made in the USA.
The problem is, that even with the "Fast boot" BIOS setting, it takes
well over a minute to get to the point where it tries to boot.
Does anyone have a clue on why it's so slow? Even getting the POST down
to 15-20 seconds would be wonderful.
--Chuck
9:21 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
On Thu, 6 Aug 2015, Chuck Guzis wrote:
The problem is, that even with the "Fast
boot" BIOS setting, it takes well
over a minute to get to the point where it tries to boot.
Does anyone have a clue on why it's so slow? Even getting the POST down to
15-20 seconds would be wonderful.
Slow boot can be really annoying. Especially when there aren't adequate
indications that it IS making progress towards it. I was very pleased in
booting MS-DOS when BIOS's starting counting off the memory being tested.
(Remember when that change was?)
It's usually JUST an annoyance. But what about the cumulative totals?
If you were to take the boot time, of all the copies, and all the users,
and add it up, then divide by median lifetime, . . . How many LIVES have
been wasted by it? That doesn't make it a mass-murderer, does it?
9:24 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
Aside from memory tests, in my experience, sometimes slowness can be
caused by a disk controller ROM (often on a SCSI controller) that gets
invoked during the POST that slows things down - particularly if it also
enumerates what is on the SCSI bus.
On 8/6/2015 7:35 PM, Chuck Guzis wrote:
On the subject of slow booting, perhaps someone can
help me with a very
annoying case of the slowboots.
I've got a dual slot-1 P3 system here--a Supermicro P6DGE, which uses a
440GX chipset and 2GB of registered SDRAM with two 900MHz CPUs. When it
finally get around to s booting, it's a great workhorse, with 2,
count'em 2 well-behaved ISA slots. It's frisky enough to run Windows 7
and proudly proclaims that it was made in the USA.
The problem is, that even with the "Fast boot" BIOS setting, it takes
well over a minute to get to the point where it tries to boot.
Does anyone have a clue on why it's so slow? Even getting the POST down
to 15-20 seconds would be wonderful.
--Chuck
9:34 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
For sure. When I quoted the 20 minute post time on new 4U machines earlier,
I didn't include the time the four HBAs on those particular machines spent
enumerating each one of the 360 drives connected ... only to poop out at
the end of the process anyway because it runs out of memory in a fixed data
structure and wants you to whack the space bar a bunch of times to
acknowledge the warning. Then the hardware RAID. And the PXE BIOS on the
NICs. And the configuration prompt for the management controller. Now they
want to bake UEFI into these things and the silly "lifecycle controller"
wants to drop in, take inventory and disconnect and what good that does me,
I will never know ...
Mostly it's an issue at deployment time; you are usually doing a few quick
reboots in succession when loading the system and, while I admit, patience
is definitely a virtue, watching these things POST can get frustrating when
you're at work and other stuff is going on in the mean-time. Once they're
up, they don't tend to get rebooted much.
Best,
Sean
On Thu, Aug 6, 2015 at 9:24 PM, Jay Jaeger <cube1 at charter.net> wrote:
Aside from memory tests, in my experience, sometimes
slowness can be
caused by a disk controller ROM (often on a SCSI controller) that gets
invoked during the POST that slows things down - particularly if it also
enumerates what is on the SCSI bus.
On 8/6/2015 7:35 PM, Chuck Guzis wrote:
On the subject of slow booting, perhaps someone
can help me with a very
annoying case of the slowboots.
I've got a dual slot-1 P3 system here--a Supermicro P6DGE, which uses a
440GX chipset and 2GB of registered SDRAM with two 900MHz CPUs. When it
finally get around to s booting, it's a great workhorse, with 2,
count'em 2 well-behaved ISA slots. It's frisky enough to run Windows 7
and proudly proclaims that it was made in the USA.
The problem is, that even with the "Fast boot" BIOS setting, it takes
well over a minute to get to the point where it tries to boot.
Does anyone have a clue on why it's so slow? Even getting the POST down
to 15-20 seconds would be wonderful.
--Chuck
11:02 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
On 08/06/2015 06:24 PM, Jay Jaeger wrote:
Aside from memory tests, in my experience, sometimes
slowness can be
caused by a disk controller ROM (often on a SCSI controller) that
gets invoked during the POST that slows things down - particularly if
it also enumerates what is on the SCSI bus.
Nope, same-oh, same-oh right down to a configuration with nothing more
than a single IDE drive and a video card. The diagnosis of 2GB memory
is immediate and then the thing just sits for a minute or more before
finally showing the configuration (attached drives, etc.)
--Chuck
11:20 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
You might check whether the BIOS config is set to autodetect drives at startup; in many
BIOSes each IDE channel can be set to Auto/None or a specific config. Try setting all
installed drives to a specific configuration, and any unused channels to None.
Autodetection can sometimes take a long time. I also find that detection of cd/dvd drives
is sometimes very slow...
(apologies for top-posting, responding on my phone which has a primitive editor...)
- Josh
-----Original Message-----
From: "Chuck Guzis" <cclist at sydex.com>
Sent: ?8/?6/?2015 11:02 PM
To: "General at classiccmp.org" <General at classiccmp.org>;
"Discussion at classiccmp.org:On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Subject: Re: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
On 08/06/2015 06:24 PM, Jay Jaeger wrote:
Aside from memory tests, in my experience, sometimes
slowness can be
caused by a disk controller ROM (often on a SCSI controller) that
gets invoked during the POST that slows things down - particularly if
it also enumerates what is on the SCSI bus.
Nope, same-oh, same-oh right down to a configuration with nothing more
than a single IDE drive and a video card. The diagnosis of 2GB memory
is immediate and then the thing just sits for a minute or more before
finally showing the configuration (attached drives, etc.)
--Chuck
11:56 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
On 08/06/2015 08:20 PM, Josh Dersch wrote:
You might check whether the BIOS config is set to
autodetect drives
at startup; in many BIOSes each IDE channel can be set to Auto/None
or a specific config. Try setting all installed drives to a specific
configuration, and any unused channels to None. Autodetection can
sometimes take a long time. I also find that detection of cd/dvd
drives is sometimes very slow...
(apologies for top-posting, responding on my phone which has a
primitive editor...)
I already do that. Note that the "dead time" occurs before getting the
message "Inspecting IDE configuration", so I don't think it's that.
Network boot is turned off, BTW.
--Chuck
7 Aug
7 Aug
1:26 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
On 07/08/15 04:56, Chuck Guzis wrote:
On 08/06/2015 08:20 PM, Josh Dersch wrote:
I don't think I have your exact supermicro board but ones I've used in
the past have had on board SCSI that had to be disabled
otherwise it would sit there for 30s thinking about why things were so
quiet on the bus.
Similarly PXE boot takes a while, but you say you've turned that off.
I don't think I got the one I was playing with down to much less than
30s ... which felt like an age even though I wasn't booting it very often.
Antonio
You might check whether the BIOS config is set to
autodetect drives
at startup; in many BIOSes each IDE channel can be set to Auto/None
or a specific config. Try setting all installed drives to a specific
configuration, and any unused channels to None. Autodetection can
sometimes take a long time. I also find that detection of cd/dvd
drives is sometimes very slow...
(apologies for top-posting, responding on my phone which has a
primitive editor...)
I already do that. Note that the "dead time" occurs before getting
the message "Inspecting IDE configuration", so I don't think it's
that. Network boot is turned off, BTW.
2:35 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
On 08/07/2015 10:26 AM, Antonio Carlini wrote:
I don't think I have your exact supermicro board
but ones I've used
in the past have had on board SCSI that had to be disabled otherwise
it would sit there for 30s thinking about why things were so quiet on
the bus.
I think that supermicro still has the specs for the board up:
http://www.supermicro.com/products/motherboard/archive/PentiumIII/440GX/P6D…
As you can see, it's pretty basic. It's pretty hard to find reasonably
fast boards with fully-functional ISA slots nowadays.
--Chuck
8 Aug
8 Aug
3:42 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
On 07/08/15 19:35, Chuck Guzis wrote:
I think that supermicro still has the specs for the board up:
http://www.supermicro.com/products/motherboard/archive/PentiumIII/440GX/P6D…
As you can see, it's pretty basic. It's pretty hard to find
reasonably fast boards with fully-functional ISA slots nowadays.
I think I have that mobo around somewhere!
The manual seems to be here:
http://www.supermicro.com/manuals/motherboard/440GX/MNL-018.pdf
The only obvious things I can see are Quick Boot Enable (doesn't wait
for disks, doesn't test beyond 1MB of memory), On-Board SCSI (disable,
so it doesn't probe for SCSI disks).
Beyond that, I don't see any obvious options (unless you've got some
card plugged in that slows the whole thing down, but I don't think you
mentioned any such cards).
Antonio
8:56 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
It probably is not this, but maybe you can try it.
For a while HP servers had the extremely annoying property of the
boot being rate-limited by the serial console speed if you had been
unfortunate enough to enable it by default. You would not notice
anything other than the slowness on a video monitor, but if you
plugged a serial cable in you could see it struggle.
I've never seen this on anything other than HPs and for good reason.
mcl
10:01 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
On 08/08/2015 05:56 PM, Mark Linimon wrote:
It probably is not this, but maybe you can try it.
For a while HP servers had the extremely annoying property of the
boot being rate-limited by the serial console speed if you had been
unfortunate enough to enable it by default. You would not notice
anything other than the slowness on a video monitor, but if you
plugged a serial cable in you could see it struggle.
I've never seen this on anything other than HPs and for good reason.
Interesting, but you're right--not applicable here.
I note that Supermicro's ftp site has a late beta version of the BIOS
for this system. I"m going to give it a try to see if it improves anything.
--Chuck
11:20 p.m.
New subject: OT: Slow booting,
Did you say that the slow boot problem that you were having was a
machine with ISA?
Would it make sense to put in a POST card, and make a new [temporary] BIOS
with its POST peppered with OUTs? Just seeing any output that would let
you know WHERE in the process it was getting bogged down might help.
It could be as trivial as it trying to access hardware that isn't there,
and not moving on until it gets a timeout error.
10 Aug
10 Aug
7:21 p.m.
New subject: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System
Just a follow-up on the problem of a Supermicro P6DGE taking forever to
boot up.
I tried several versions of the BIOS with pretty much the same result.
Since each reset the configuration (CMOS) memory, there was little issue
of an overlooked setting contributing to the slow boot.
I tested the "fast boot" in both enabled and disabled settings and found
that the POST took almost exactly the same time--the only difference was
that the memory check "odometer" didn't display in the "fast boot"
setting.
Could it be that the presence of ECC registered SDRAM requires that
every memory location get written before boot-up can proceed? There's
2GB of the stuff, so that could be the difference.
--Chuck
6 Aug
6 Aug
9:22 p.m.
Four, I expect:
CPU, Memory, VAX Interface, Floppy Controller.
I have one in pieces floating around here somewhere.
One of those puppies (probably the one I have) held our VAX hostage for
DAYS while the service folks from the OEM (Intergraph) tried to figure
out what was wrong - they kept blaming the console processor which was
not the problem. Turned out to be a recently added power supply - which
I had pointed out to them was something that changed, and something we
could do without as a test. Sigh.
On 8/6/2015 7:13 PM, Jon Elson wrote:
On 08/06/2015 04:01 PM, Jay Jaeger wrote:
Until that console processor fails with no
backups. I seem to recall
having 4 or 5 "backups" (aka operators). ;)
Well, the idea is that the console or diagnostic processor is WAY
simpler than the mainframe CPU. So, if the console computer dies, you
can troubleshoot it and be sure it is running in just a few minutes, and
then get on to the real problem.
The VAX 11/780 had an LSI-11 with a floppy controller and an interface
board to the VAX, so I think it was down to 3 boards or something.
Jon
3303
days inactive
3307
days old
61 comments
28 participants
participants (28)
-
a.carlini＠ntlworld.com -
aek＠bitsavers.org -
arcarlini＠iee.org -
bfranchuk＠jetnet.ab.ca -
bqt＠update.uu.se -
cclist＠sydex.com -
cisin＠xenosoft.com -
cube1＠charter.net -
dave.g4ugm＠gmail.com -
derschjo＠gmail.com -
echristopherson＠gmail.com -
elson＠pico-systems.com -
geneb＠deltasoft.com -
ggs＠shiresoft.com -
guy＠cuillin.org.uk -
jplist2008＠kiwigeek.com -
jwest＠classiccmp.org -
jws＠jwsss.com -
leec2124＠gmail.com -
linimon＠lonesome.com -
marc.verdiell＠gmail.com -
mouse＠Rodents-Montreal.ORG -
paulkoning＠comcast.net -
pontus＠Update.UU.SE -
scaron＠umich.edu -
spacewar＠gmail.com -
tmfdmike＠gmail.com -
wdonzelli＠gmail.com