Discussion:
iSeries/AS400
(too old to reply)
Tom Young
2003-07-19 00:25:19 UTC
Permalink
hercules is a great product... excellent for that matter, but I was
also wondering if anyone knew of a similar product for iSeries -
AS/400 hardware?? I have access to a 400 which I am able to learn
user tasks, but I would like to learn system administration as well.

If anyone can be of some help I would appreciate it.

Thanks


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Naturally Painless & Spray Away Backaches & Joint Pain. $19.97
http://www.challengerone.com/t/l.asp?cid=2867&lp=m331.html
http://us.click.yahoo.com/tJIe0D/79VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
ivan_warhead
2003-07-19 00:34:53 UTC
Permalink
Post by Tom Young
hercules is a great product... excellent for that matter, but I was
also wondering if anyone knew of a similar product for iSeries -
AS/400 hardware?? I have access to a 400 which I am able to learn
user tasks, but I would like to learn system administration as
well.
Post by Tom Young
If anyone can be of some help I would appreciate it.
Thanks
I don't know if there is any similar product like hercules that
would emulate an IBM e(logo)Server iSeries-AS/400, but the fact is
that it is a slightly different issue.

Although the S/360/370/XA/ESA/390/z architecture is extensivelly
documented, fixed and known, the AS/400 architecture is not fixed.
OS/400 uses an abstraction layer (can you say 'HAL' ?) to adapt to
various hardware protocols. So emulating the AS/400 would really
mean emulating this abstraction layer.. but it is part of OS/400 !

So.. not a simple thing (not to say that hercules is 'simple' per-
se) !

--Ivan


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Paul A. Scott
2003-07-20 03:22:29 UTC
Permalink
Post by ivan_warhead
Although the S/360/370/XA/ESA/390/z architecture is extensivelly
documented, fixed and known, the AS/400 architecture is not fixed.
OS/400 uses an abstraction layer (can you say 'HAL' ?) to adapt to
various hardware protocols. So emulating the AS/400 would really
mean emulating this abstraction layer.. but it is part of OS/400 !
Keeping with the hercules paradigm, you would NOT want to emulate the
abstraction layer. If you emulate the abstraction layer, you might be able
to run applications, but you couldn't run the OS! The fact that OS/400
implements an abstraction layer has no significance. You simply want to
emulate the underlying hardware. The question then becomes one of whether
the hardware (including the processor) is documented well enough. There are
a number of different processors (PowerPC based I believe) but very little
information available to the layman. Still, I think there's enough available
(with cheap hardware for reverse engineering) that you could probably do a
complete implementation. I for one would love to tackle that problem except
I just don't have the time. If someone wants to pay me to do it though ...

Paul
--
Paul A. Scott
mailto:pscott-***@public.gmane.org
http://skycoast.us/pscott/


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-20 05:58:33 UTC
Permalink
Post by Paul A. Scott
Post by ivan_warhead
Although the S/360/370/XA/ESA/390/z architecture is extensivelly
documented, fixed and known, the AS/400 architecture is not fixed.
OS/400 uses an abstraction layer (can you say 'HAL' ?) to adapt to
various hardware protocols. So emulating the AS/400 would really
mean emulating this abstraction layer.. but it is part of OS/400 !
Keeping with the hercules paradigm, you would NOT want to emulate the
abstraction layer. If you emulate the abstraction layer, you might be able
to run applications, but you couldn't run the OS! The fact that OS/400
implements an abstraction layer has no significance. You simply want to
emulate the underlying hardware. The question then becomes one of whether
the hardware (including the processor) is documented well enough. There are
a number of different processors (PowerPC based I believe) but very little
information available to the layman. Still, I think there's enough available
(with cheap hardware for reverse engineering) that you could probably do a
complete implementation. I for one would love to tackle that problem except
I just don't have the time. If someone wants to pay me to do it though ...
I have a Mac with a PPC 604e CPU at 200 Mhz. I bought as part of a lot
of four or so for about $AU70.

The PPC 604e is still used in current iSeries and pSeries computers, and
not all that much faster either.

Presumably anyone who can write an assembler and/or an OS to run on
these machines has the information needed to emulate them. However, most
of the references I could find using google refer to emulating the MAC:
I guess that means emulating the BIOS too, and that's entirely
different.
Post by Paul A. Scott
Paul
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Ronald Tatum
2003-07-20 16:35:15 UTC
Permalink
John, Paul,

Strange thing re both the AS/400 and RS6000 families of machines: some
years ago ('96? 97? whenever) I tried to get the equivalent of a "Principles
of Operation" manual for the RS6000; scanned the web, called the local IBM
sales office here in Lubbock, TX, some folks I knew elsewhere. *Nobody*
could tell me a doc number or even knew if such a thing existed. (But then,
at least one IBM sales type didn't even know what I was talking about when I
said "the equivalent of a Principles of Operation such as what is available
for mainframes from IBM" - wonder where he came from and why they kept him
around). Apparently the Power PC chip is micro-programmable at the chip
manufacturing stage (not a cheap or feasible thing for anything other than
an OEM or a foundry, of course) so perhaps at least one of the personal 370
machines was powered by a PowerPC chip altered at some level to be a 3x0 in
some real sense. Also, apparently the "original" AS/400 was built using one
series of chips, the later ones are actually using the same basic chip set
as the Risc 6000, and of course Apple's latest and greatest is using yet
another variant of the same basic chip set or CPU chip alone.
I'd *love* to see a machine-level "PoO" for the things ...

P.S. John, thanks for the update (albeit indirect) re the "strange" OS: I
thought you were saying you'd just ignore me and hope I'd go away when I
didn't hear back from you. Turns out it was my ISP or something else
altogether. Shouldn't have thought ill of you. I'll get this mess
straightened out one way or another ...
----- Original Message -----
From: "John Summerfield" <spam-***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Sent: Sunday, July 20, 2003 12:58 AM
Subject: Re: [hercules-390] Re: iSeries/AS400
Post by John Summerfield
Post by Paul A. Scott
Post by ivan_warhead
Although the S/360/370/XA/ESA/390/z architecture is extensivelly
documented, fixed and known, the AS/400 architecture is not fixed.
OS/400 uses an abstraction layer (can you say 'HAL' ?) to adapt to
various hardware protocols. So emulating the AS/400 would really
mean emulating this abstraction layer.. but it is part of OS/400 !
Keeping with the hercules paradigm, you would NOT want to emulate the
abstraction layer. If you emulate the abstraction layer, you might be able
to run applications, but you couldn't run the OS! The fact that OS/400
implements an abstraction layer has no significance. You simply want to
emulate the underlying hardware. The question then becomes one of whether
the hardware (including the processor) is documented well enough. There are
a number of different processors (PowerPC based I believe) but very little
information available to the layman. Still, I think there's enough available
(with cheap hardware for reverse engineering) that you could probably do a
complete implementation. I for one would love to tackle that problem except
I just don't have the time. If someone wants to pay me to do it though ...
I have a Mac with a PPC 604e CPU at 200 Mhz. I bought as part of a lot
of four or so for about $AU70.
The PPC 604e is still used in current iSeries and pSeries computers, and
not all that much faster either.
Presumably anyone who can write an assembler and/or an OS to run on
these machines has the information needed to emulate them. However, most
I guess that means emulating the BIOS too, and that's entirely
different.
Post by Paul A. Scott
Paul
--
Cheers
John.
Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.
http://groups.yahoo.com/group/hercules-390
http://www.conmicro.cx/hercules
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-20 20:48:47 UTC
Permalink
Post by Ronald Tatum
John, Paul,
Strange thing re both the AS/400 and RS6000 families of machines: some
years ago ('96? 97? whenever) I tried to get the equivalent of a "Principles
of Operation" manual for the RS6000; scanned the web, called the local IBM
sales office here in Lubbock, TX, some folks I knew elsewhere. *Nobody*
could tell me a doc number or even knew if such a thing existed. (But then,
at least one IBM sales type didn't even know what I was talking about when I
said "the equivalent of a Principles of Operation such as what is available
for mainframes from IBM" - wonder where he came from and why they kept him
around). Apparently the Power PC chip is micro-programmable at the chip
manufacturing stage (not a cheap or feasible thing for anything other than
an OEM or a foundry, of course) so perhaps at least one of the personal 370
machines was powered by a PowerPC chip altered at some level to be a 3x0 in
some real sense. Also, apparently the "original" AS/400 was built using one
series of chips, the later ones are actually using the same basic chip set
as the Risc 6000, and of course Apple's latest and greatest is using yet
another variant of the same basic chip set or CPU chip alone.
I'd *love* to see a machine-level "PoO" for the things ...
Years go, when the Sytem/36, System/38 and (I think) others were running
out of puff, there was a lot of speculaton about their replacement.

The replacement was the AS/400. While IBM dropped some minicomputer
lines, others migrated to the AS/400.I never used such things _we_ used
"mainframes" not "minicomputers," so I never discovered the details, but
I don't recall hearing that those affected were unhappy either.

Remember, too, that Apple also took software intended for a different
architecture (the 68000 series) and ran it on the PPC.
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
Free shipping on orders $50 or more to the US and Canada.
http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Terry Myhrer
2003-07-20 16:14:40 UTC
Permalink
Keeping with the AS/400 paradigm you WOULD want to emulate the abstraction
layer since this is what the OS runs on. The OS has no knowledge of the
actual hardware it runs on, only the abstraction layer.

-Terry

-----Original Message-----
From: Paul A. Scott [mailto:pscott-***@public.gmane.org]
Sent: Saturday, July 19, 2003 11:22 PM
To: hercules-390-***@public.gmane.org
Subject: Re: [hercules-390] Re: iSeries/AS400
Post by ivan_warhead
Although the S/360/370/XA/ESA/390/z architecture is extensivelly
documented, fixed and known, the AS/400 architecture is not fixed.
OS/400 uses an abstraction layer (can you say 'HAL' ?) to adapt to
various hardware protocols. So emulating the AS/400 would really
mean emulating this abstraction layer.. but it is part of OS/400 !
Keeping with the hercules paradigm, you would NOT want to emulate the
abstraction layer. If you emulate the abstraction layer, you might be able
to run applications, but you couldn't run the OS! The fact that OS/400
implements an abstraction layer has no significance. You simply want to
emulate the underlying hardware. The question then becomes one of whether
the hardware (including the processor) is documented well enough. There are
a number of different processors (PowerPC based I believe) but very little
information available to the layman. Still, I think there's enough available
(with cheap hardware for reverse engineering) that you could probably do a
complete implementation. I for one would love to tackle that problem except
I just don't have the time. If someone wants to pay me to do it though ...

Paul

--
Paul A. Scott
mailto:pscott-***@public.gmane.org
http://skycoast.us/pscott/
Paul A. Scott
2003-07-20 17:36:40 UTC
Permalink
We have two statements 180 degrees out of phase.
So emulating the AS/400 would really mean emulating this
abstraction layer.. but it is part of OS/400 !
If the AL is part of the OS, then the OS has knowledge of the hardware.
The OS has no knowledge of the actual hardware it runs on,
only the abstraction layer.
If the OS has no knowledge of the hardware, then the AL is not part of the
OS.

Which of these cases true on AS/400?

What exactly does the AS/400 AL abstract?

In any case, this discussion is inappropriate on the hercules groups, and
should be taken elsewhere.
--
Paul A. Scott
mailto:pscott-***@public.gmane.org
http://skycoast.us/pscott/


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Natural Vitamins for Good Prostate & Male Health. $28.97
http://www.challengerone.com/t/l.asp?cid=2865&lp=prosta2.html
http://us.click.yahoo.com/qJIe0D/89VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Terry Myhrer
2003-07-20 20:05:52 UTC
Permalink
It is hardware -> abstraction Layer -> OS

Just like 360, etc. is: Hardware -> Microcode Abstraction Layer (360, etc.
API) -> OS

-Terry

-----Original Message-----
From: Paul A. Scott [mailto:pscott-***@public.gmane.org]
Sent: Sunday, July 20, 2003 1:37 PM
To: hercules-390-***@public.gmane.org
Subject: Re: [hercules-390] Re: iSeries/AS400


We have two statements 180 degrees out of phase.
So emulating the AS/400 would really mean emulating this
abstraction layer.. but it is part of OS/400 !
If the AL is part of the OS, then the OS has knowledge of the hardware.
The OS has no knowledge of the actual hardware it runs on,
only the abstraction layer.
If the OS has no knowledge of the hardware, then the AL is not part of the
OS.

Which of these cases true on AS/400?

What exactly does the AS/400 AL abstract?

In any case, this discussion is inappropriate on the hercules groups, and
should be taken elsewhere.

--
Paul A. Scott
mailto:pscott-***@public.gmane.org
http://skycoast.us/pscott/
Paul A. Scott
2003-07-20 20:57:41 UTC
Permalink
Post by Terry Myhrer
It is hardware -> abstraction Layer -> OS
From what I've seen, the AL is semi-transparent, such that certain hardware
features are directly accessible from the OS (e.g. CPU). If it were totally
opaque, then the AL would itself be a complete, functional emulator (a la
Java VM), which would severely impact performance of the overlying OS and
its applications.

What do you know about the details of the AL that you can pass along? And,
again, what does the AL actually abstract?

Paul
--
Paul A. Scott
mailto:pscott-***@public.gmane.org
http://skycoast.us/pscott/


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
Free shipping on orders $50 or more to the US and Canada.
http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Terry Myhrer
2003-07-20 22:30:56 UTC
Permalink
The details I have are from my friend who worked at IBM Rochester on the
s/34, s/36 lines (predecessors of the s/38 and as/400) in the mid 80's. The
abstraction layer abstracted a machine that *at the time* did not exist. It
abstracted machine had something like 48 address bits and ran on real
hardware that had fewer address bits. There were two types of microcode on
the machine called vertical microcode and horizontal microcode. One ran the
real hardware and the other ran the abstracted hardware, not sure which was
which though. That is why I say the OS knew the abstracted machine only.
They could rewrite the abstraction code to run on other hardware without
changing the OS.

-Terry

-----Original Message-----
From: Paul A. Scott [mailto:pscott-***@public.gmane.org]
Sent: Sunday, July 20, 2003 4:58 PM
To: hercules-390-***@public.gmane.org
Subject: Re: [hercules-390] Re: iSeries/AS400
Post by Terry Myhrer
It is hardware -> abstraction Layer -> OS
From what I've seen, the AL is semi-transparent, such that certain hardware
features are directly accessible from the OS (e.g. CPU). If it were totally
opaque, then the AL would itself be a complete, functional emulator (a la
Java VM), which would severely impact performance of the overlying OS and
its applications.

What do you know about the details of the AL that you can pass along? And,
again, what does the AL actually abstract?

Paul

--
Paul A. Scott
mailto:pscott-***@public.gmane.org
http://skycoast.us/pscott/
Ronald Tatum
2003-07-21 01:45:13 UTC
Permalink
As a possible side branch in the evolution of "smaller scale" machines with
which IBM more or less experimented and then let die, consider the 8100
(industrial automation *and* small/mid-size office automation). The "real
time" PS3640 programs (the assembler language apps) appear to have actually
executed directly under DPPX (I can't say for sure since I never got to see
the manuals for that part, I just had to administer the lunacy and try to
keep the system up at one place I'd as soon forget about) but the apps that
manipulated the data collected in "real time" were written in COBOL and I
was told that the programs were being executed interpretively.

From what I *could* observe, I'd believe the interpretive bit - that was
a DOG as far as performance went. If one's hardware is suficiently powerful,
interpretive execution may be feasible, but certainly the hardware available
for minis/micros in the early 1980s was not up to the challenge with the
interpreters that were extant on at least for that machine.

Now back to simulated mainframes, enough of the business/shop minis ...

Regards,
Ron Tatum


----- Original Message -----
From: "Terry Myhrer" <yahoogroups-c9vi3MJ+y9QJmq/***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Sent: Sunday, July 20, 2003 5:30 PM
Subject: RE: [hercules-390] Re: iSeries/AS400
Post by Terry Myhrer
The details I have are from my friend who worked at IBM Rochester on the
s/34, s/36 lines (predecessors of the s/38 and as/400) in the mid 80's. The
abstraction layer abstracted a machine that *at the time* did not exist. It
abstracted machine had something like 48 address bits and ran on real
hardware that had fewer address bits. There were two types of microcode on
the machine called vertical microcode and horizontal microcode. One ran the
real hardware and the other ran the abstracted hardware, not sure which was
which though. That is why I say the OS knew the abstracted machine only.
They could rewrite the abstraction code to run on other hardware without
changing the OS.
-Terry
-----Original Message-----
Sent: Sunday, July 20, 2003 4:58 PM
Subject: Re: [hercules-390] Re: iSeries/AS400
Post by Terry Myhrer
It is hardware -> abstraction Layer -> OS
From what I've seen, the AL is semi-transparent, such that certain hardware
features are directly accessible from the OS (e.g. CPU). If it were totally
opaque, then the AL would itself be a complete, functional emulator (a la
Java VM), which would severely impact performance of the overlying OS and
its applications.
What do you know about the details of the AL that you can pass along? And,
again, what does the AL actually abstract?
Paul
--
Paul A. Scott
http://skycoast.us/pscott/
http://groups.yahoo.com/group/hercules-390
http://www.conmicro.cx/hercules
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
http://groups.yahoo.com/group/hercules-390
http://www.conmicro.cx/hercules
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Natural Vitamins for Good Prostate & Male Health. $28.97
http://www.challengerone.com/t/l.asp?cid=2865&lp=prosta2.html
http://us.click.yahoo.com/qJIe0D/89VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-21 01:55:17 UTC
Permalink
Post by Ronald Tatum
As a possible side branch in the evolution of "smaller scale" machines with
which IBM more or less experimented and then let die, consider the 8100
(industrial automation *and* small/mid-size office automation). The "real
time" PS3640 programs (the assembler language apps) appear to have actually
executed directly under DPPX (I can't say for sure since I never got to see
the manuals for that part, I just had to administer the lunacy and try to
keep the system up at one place I'd as soon forget about) but the apps that
manipulated the data collected in "real time" were written in COBOL and I
was told that the programs were being executed interpretively.
From what I *could* observe, I'd believe the interpretive bit - that was
a DOG as far as performance went. If one's hardware is suficiently powerful,
interpretive execution may be feasible, but certainly the hardware available
for minis/micros in the early 1980s was not up to the challenge with the
interpreters that were extant on at least for that machine.
Now back to simulated mainframes, enough of the business/shop minis ...
Bear in mind that most S/370 machines had microcode. The 168 didn't, and
ran VM like a 135. Gene Amdahl used hard-wired logic as a selling-point
- his designs were faster because they didn't have slushware gluing
things up.

One of the features of the microcode was that it could be
updated/overwritten by IPLing something. At one time we genned VS1 for a
148 and ran it on our 145 using the microcode assists.
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sOykFB/k9VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
vmsyspgmr
2003-07-21 12:51:48 UTC
Permalink
It seems to me that another problem would be getting a "public
domain" version of the O/S. Otherwise only a few would benefit from
it when running a "backup" copy of the O/S. Since this would
probably be a limited number of users, it would seem like a lot of
work for those users. I suppose you do get bragging rights having
done it.
Regards,
Steve Gentry


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get a FREE REFINANCE QUOTE - click here!
http://us.click.yahoo.com/nHYuCC/ca0FAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
jeffsavit
2003-07-21 21:57:27 UTC
Permalink
A base canard, sir! As previously noted, the 168 did have microcode,
and ran VM just fine - including running MVT faster under VM than
natively (if you had the large-system mods), and certainly for running
CMS. It was only when running MVS without VM assist that you felt the
pain. What do you expect when the guest OS does things like "LRA
R2,0", which is a pretty expensive way to set R2 to 0! Zapping that
one instruction, IIRC, was a 10-20% improvement to MVS guest
performance.

When Cornell upgraded its 168 to a 168-III, the $125K upgrade came in
a little box, which was pretty underwhelming packaging considering the
money spent, and included a microcode update.

FWIW, according to Case and Padegs, "Architecture of the IBM
System/370", Communications of the ACM, January 1978, the 360/44, 75,
91 and 195 had no microcode; all 370s did except for the 195. I guess
the 370/195 was just the 360/195 with a darker front panel and
(maybe?) MVCL.

cheers, Jeff
Post by John Summerfield
Bear in mind that most S/370 machines had microcode. The 168
didn't, and
Post by John Summerfield
ran VM like a 135. Gene Amdahl used hard-wired logic as a
selling-point
Post by John Summerfield
- his designs were faster because they didn't have slushware gluing
things up.
.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get a FREE REFINANCE QUOTE - click here!
http://us.click.yahoo.com/nHYuCC/ca0FAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Gregg C Levine
2003-07-21 22:02:53 UTC
Permalink
Hello from Gregg C Levine
Which is what I've been pushing all along. Jeff, where did you find
that reference again? I have been trying to find a collection of
references, on this subject, and one of them, is a book concerning
APL, and the author, Gerritt Blaau. I imagine I've spelled his name
wrong.
-------------------
Gregg C Levine hansolofalcon-XfrvlLN1Pqtfpb/***@public.gmane.org
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
Post by Terry Myhrer
-----Original Message-----
Sent: Monday, July 21, 2003 5:57 PM
Subject: [hercules-390] 168s and microcode. Was: Re: iSeries/AS400
A base canard, sir! As previously noted, the 168 did have microcode,
and ran VM just fine - including running MVT faster under VM than
natively (if you had the large-system mods), and certainly for
running
Post by Terry Myhrer
CMS. It was only when running MVS without VM assist that you felt the
pain. What do you expect when the guest OS does things like "LRA
R2,0", which is a pretty expensive way to set R2 to 0! Zapping that
one instruction, IIRC, was a 10-20% improvement to MVS guest
performance.
When Cornell upgraded its 168 to a 168-III, the $125K upgrade came in
a little box, which was pretty underwhelming packaging considering the
money spent, and included a microcode update.
FWIW, according to Case and Padegs, "Architecture of the IBM
System/370", Communications of the ACM, January 1978, the 360/44, 75,
91 and 195 had no microcode; all 370s did except for the 195. I guess
the 370/195 was just the 360/195 with a darker front panel and
(maybe?) MVCL.
cheers, Jeff
Post by John Summerfield
Bear in mind that most S/370 machines had microcode. The 168
didn't, and
Post by John Summerfield
ran VM like a 135. Gene Amdahl used hard-wired logic as a
selling-point
Post by John Summerfield
- his designs were faster because they didn't have slushware
gluing
Post by Terry Myhrer
Post by John Summerfield
things up.
.
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
jeffsavit
2003-07-22 14:07:55 UTC
Permalink
Hi Gregg,

It's a little embarrassing to admit, but I looked in the bibliography
in chapter 7 of "IBM Mainframes, 2nd edition", 1994, (Prasad and
Savit). That means I probably have the original CACM buried somewhere
in my attic, too. Oh, the spelling is "Blaauw". -- Jeff
Post by Gregg C Levine
Which is what I've been pushing all along. Jeff, where did you find
that reference again? I have been trying to find a collection of
references, on this subject, and one of them, is a book concerning
APL, and the author, Gerritt Blaau. I imagine I've spelled his name
Post by Terry Myhrer
-----Original Message-----
FWIW, according to Case and Padegs, "Architecture of the IBM
System/370", Communications of the ACM, January 1978, the 360/44,
75,
Post by Terry Myhrer
91 and 195 had no microcode; all 370s did except for the 195.
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-21 23:20:27 UTC
Permalink
Post by jeffsavit
A base canard, sir! As previously noted, the 168 did have microcode,
and ran VM just fine - including running MVT faster under VM than
natively (if you had the large-system mods), and certainly for running
CMS. It was only when running MVS without VM assist that you felt the
pain. What do you expect when the guest OS does things like "LRA
R2,0", which is a pretty expensive way to set R2 to 0! Zapping that
one instruction, IIRC, was a 10-20% improvement to MVS guest
performance.
I personally was not involved, but I spoke with those who were actually
trying to do this. As I understand it, at that time the interest was in
running VS1: MVS hadn't yet surfaced, but we were running VS1 in our
state offices.

Comments made around that time revolved around "hard-wired logic" and
"serious computing."

It may well be that the picture changed later, but at that time IBM had
no answer for the performance problems.

_I_ would want to check the POP to verify that "LRA 2,0" does in fact
set GPR2=0.
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Breakthrough Natural Health Specialties at VitaminBoost.com $20 to $40
Oral Sprays for Fast Results and Greater Absorption.
http://www.challengerone.com/t/l.asp?cid=2880
http://us.click.yahoo.com/3oMABA/muYGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-22 00:49:19 UTC
Permalink
Post by John Summerfield
Post by jeffsavit
A base canard, sir! As previously noted, the 168 did have microcode,
and ran VM just fine - including running MVT faster under VM than
natively (if you had the large-system mods), and certainly for running
CMS. It was only when running MVS without VM assist that you felt the
pain. What do you expect when the guest OS does things like "LRA
R2,0", which is a pretty expensive way to set R2 to 0! Zapping that
one instruction, IIRC, was a 10-20% improvement to MVS guest
performance.
I personally was not involved, but I spoke with those who were actually
trying to do this. As I understand it, at that time the interest was in
running VS1: MVS hadn't yet surfaced, but we were running VS1 in our
state offices.
Comments made around that time revolved around "hard-wired logic" and
"serious computing."
It may well be that the picture changed later, but at that time IBM had
no answer for the performance problems.
I've been reading a TNL I found at
http://www.spies.com/~aek/pdf/ibm/370/ which is working again. See
http://www.spies.com/~aek/pdf/ibm/370/GN20-3575_370-168updFeb76.pdf
page number 126 (29 according to xpdf). The model 1 has 512K words of
WCS, the model 3 1024K. Doesn't say what the word-size is.

In a table a little further, "virtual machine assist" as listed as an
RPQ feature, and that might have been the fly in our ointment, and the
reason others found it worked well.

Oh, it also lists the S360/65 as being able to be connected in a
multiprocessor configuration (unless I misinterpret the language; it
does explicitly mention shared storage though).
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
Free shipping on orders $50 or more to the US and Canada.
http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Ronald Tatum
2003-07-22 15:42:52 UTC
Permalink
John,

At least as of OS Rel 20.1 the 360/65 was available in a multiprocessor
configuration (apparently two processors, it's not clear if they shared all
memory on such a system or could have some common, some disjoint memory).

Found that confirmation looking in GC28-6628-7, IBM System/360
Operating System System Control Blocks.

Technical question: I can't find any control blocks for the MICR devices
(those machines that read checks with the odd-looking symbols across the
bottom and such). I'm sure that DOS (which a lot of banks used to favor over
OS) had support for those devices. But I know of at least one bank that ran
OS/MVT and they had three of the big check processors; so far as I know,
they didn't have the 1401 emulator feature on any of their 158/168 machines.
So how were they supporting the machines?

Did they home-grow the support (unlikely, given the expertise of their
coders) or did IBM support the machines under OS and just not document the
support for the much larger world? After all, there really aren't that many
banks in the total population of mainframe users.

Regards,
Ron Tatum
----- Original Message -----
From: "John Summerfield" <spam-***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Sent: Monday, July 21, 2003 7:49 PM
Subject: Re: [hercules-390] 168s and microcode. Was: Re: iSeries/AS400
Post by John Summerfield
Post by John Summerfield
Post by jeffsavit
A base canard, sir! As previously noted, the 168 did have microcode,
and ran VM just fine - including running MVT faster under VM than
natively (if you had the large-system mods), and certainly for running
CMS. It was only when running MVS without VM assist that you felt the
pain. What do you expect when the guest OS does things like "LRA
R2,0", which is a pretty expensive way to set R2 to 0! Zapping that
one instruction, IIRC, was a 10-20% improvement to MVS guest
performance.
I personally was not involved, but I spoke with those who were actually
trying to do this. As I understand it, at that time the interest was in
running VS1: MVS hadn't yet surfaced, but we were running VS1 in our
state offices.
Comments made around that time revolved around "hard-wired logic" and
"serious computing."
It may well be that the picture changed later, but at that time IBM had
no answer for the performance problems.
I've been reading a TNL I found at
http://www.spies.com/~aek/pdf/ibm/370/ which is working again. See
http://www.spies.com/~aek/pdf/ibm/370/GN20-3575_370-168updFeb76.pdf
page number 126 (29 according to xpdf). The model 1 has 512K words of
WCS, the model 3 1024K. Doesn't say what the word-size is.
In a table a little further, "virtual machine assist" as listed as an
RPQ feature, and that might have been the fly in our ointment, and the
reason others found it worked well.
Oh, it also lists the S360/65 as being able to be connected in a
multiprocessor configuration (unless I misinterpret the language; it
does explicitly mention shared storage though).
--
Cheers
John.
Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.
http://groups.yahoo.com/group/hercules-390
http://www.conmicro.cx/hercules
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-22 16:21:08 UTC
Permalink
Post by Ronald Tatum
John,
At least as of OS Rel 20.1 the 360/65 was available in a multiprocessor
configuration (apparently two processors, it's not clear if they shared all
memory on such a system or could have some common, some disjoint memory).
Found that confirmation looking in GC28-6628-7, IBM System/360
Operating System System Control Blocks.
Technical question: I can't find any control blocks for the MICR devices
(those machines that read checks with the odd-looking symbols across the
bottom and such). I'm sure that DOS (which a lot of banks used to favor over
OS) had support for those devices. But I know of at least one bank that ran
OS/MVT and they had three of the big check processors; so far as I know,
they didn't have the 1401 emulator feature on any of their 158/168 machines.
So how were they supporting the machines?
Did they home-grow the support (unlikely, given the expertise of their
coders) or did IBM support the machines under OS and just not document the
support for the much larger world? After all, there really aren't that many
banks in the total population of mainframe users.
I know a bloke who can answer that;-) I was (informally) his boss at one
time. He joined the Bank of New South Wales, and showed me round when I
visited one time.

I witnessed cheques being sorted. The mainframes were 158s I think, but
on minimal reflection I suspect the sorting was driven by a Model 20.
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy No Snore & Get a Good Night's Sleep. Natural Oral Spray -- $24.95
(1 bottle, 1 month supply, with sweet almond oil, eucalyptus oil & more).
http://www.challengerone.com/t/l.asp?cid=2881&lp=h515.html
http://us.click.yahoo.com/2oMABA/nuYGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
dougbarc
2003-07-22 20:28:34 UTC
Permalink
I was pretty green with MVT, but got pretty involved by the time we
were running SVS v1.7.

Though we didn't have MICR readers specifically, there were a number
of ways to handle devices that didn't have control block data
specifically. One usually had some other recognized device for
purposes of doing the IOGEN. (Probably some unit record device for
MICR.)

Then you either wrote your own code or, in larger shops, one could
actually bring in IBM to write code. Once one got fairly familiar
with EXCP you could have a great deal of control over I/O for a
device.

So.. it might have worked with MICR readers, just with some
customization. I know we had a 'file' that spanned about 12 3350's
back then, with the code written by IBM. (For MICR, the vendors may
have provided the necessary code.)

You could even do things IBM said wouldn't work... long as you could
run in supervisor state. I remember writing some code that, for
security reasons, never went through open/close. It was code written
as an SVC and used for TSO during user logon to get some information
and provide authorization for some services by reading from the jobq
back when that was just a file on disk. The code built it's
own 'open' DCB, DEB, and the I/O appendages, as if it'd gone through
open. Yet if there was a dump or if someone put in code to run
control blocks, it never appeared. One never saw the data in DCB's,
DEB's because the control blocks were never on the DCB or DEB chains,
etc. Of course all of that went away once we got to MVS. IBM had a
little more checking in their code at that point. :)

Doug (remembering back in the days when coding was REALLY fun)
Post by Ronald Tatum
John,
At least as of OS Rel 20.1 the 360/65 was available in a
multiprocessor
Post by Ronald Tatum
configuration (apparently two processors, it's not clear if they shared all
memory on such a system or could have some common, some disjoint memory).
Found that confirmation looking in GC28-6628-7, IBM System/360
Operating System System Control Blocks.
Technical question: I can't find any control blocks for the MICR devices
(those machines that read checks with the odd-looking symbols
across the
Post by Ronald Tatum
bottom and such). I'm sure that DOS (which a lot of banks used to favor over
OS) had support for those devices. But I know of at least one bank that ran
OS/MVT and they had three of the big check processors; so far as I know,
they didn't have the 1401 emulator feature on any of their 158/168 machines.
So how were they supporting the machines?
Did they home-grow the support (unlikely, given the expertise of their
coders) or did IBM support the machines under OS and just not
document the
Post by Ronald Tatum
support for the much larger world? After all, there really aren't that many
banks in the total population of mainframe users.
Regards,
Ron Tatum
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sOykFB/k9VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Gregg C Levine
2003-07-22 21:16:43 UTC
Permalink
Hello from Gregg C Levine
How many of us, pay attention to things, when we visit our banks? I
do. Mine, First Union/Wachovia, is still using much the same ideas, as
expounded upon in this thread. Doug, draw yourself a cigar out of
petty cash, your right.
-------------------
Gregg C Levine hansolofalcon-XfrvlLN1Pqtfpb/***@public.gmane.org
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
Post by Terry Myhrer
-----Original Message-----
Sent: Tuesday, July 22, 2003 4:29 PM
Subject: [hercules-390] 168s and microcode. Was: Re: iSeries/AS400
I was pretty green with MVT, but got pretty involved by the time we
were running SVS v1.7.
Though we didn't have MICR readers specifically, there were a number
of ways to handle devices that didn't have control block data
specifically. One usually had some other recognized device for
purposes of doing the IOGEN. (Probably some unit record device for
MICR.)
Then you either wrote your own code or, in larger shops, one could
actually bring in IBM to write code. Once one got fairly familiar
with EXCP you could have a great deal of control over I/O for a
device.
So.. it might have worked with MICR readers, just with some
customization. I know we had a 'file' that spanned about 12 3350's
back then, with the code written by IBM. (For MICR, the vendors may
have provided the necessary code.)
You could even do things IBM said wouldn't work... long as you could
run in supervisor state. I remember writing some code that, for
security reasons, never went through open/close. It was code written
as an SVC and used for TSO during user logon to get some information
and provide authorization for some services by reading from the jobq
back when that was just a file on disk. The code built it's
own 'open' DCB, DEB, and the I/O appendages, as if it'd gone through
open. Yet if there was a dump or if someone put in code to run
control blocks, it never appeared. One never saw the data in DCB's,
DEB's because the control blocks were never on the DCB or DEB
chains,
Post by Terry Myhrer
etc. Of course all of that went away once we got to MVS. IBM had a
little more checking in their code at that point. :)
Doug (remembering back in the days when coding was REALLY fun)
Post by Ronald Tatum
John,
At least as of OS Rel 20.1 the 360/65 was available in a
multiprocessor
Post by Ronald Tatum
configuration (apparently two processors, it's not clear if they
shared all
Post by Ronald Tatum
memory on such a system or could have some common, some disjoint
memory).
Post by Ronald Tatum
Found that confirmation looking in GC28-6628-7, IBM
System/360
Post by Terry Myhrer
Post by Ronald Tatum
Operating System System Control Blocks.
Technical question: I can't find any control blocks for the
MICR
Post by Terry Myhrer
devices
Post by Ronald Tatum
(those machines that read checks with the odd-looking symbols
across the
Post by Ronald Tatum
bottom and such). I'm sure that DOS (which a lot of banks used to
favor over
Post by Ronald Tatum
OS) had support for those devices. But I know of at least one bank
that ran
Post by Ronald Tatum
OS/MVT and they had three of the big check processors; so far as I
know,
Post by Ronald Tatum
they didn't have the 1401 emulator feature on any of their 158/168
machines.
Post by Ronald Tatum
So how were they supporting the machines?
Did they home-grow the support (unlikely, given the expertise
of their
Post by Ronald Tatum
coders) or did IBM support the machines under OS and just not
document the
Post by Ronald Tatum
support for the much larger world? After all, there really aren't
that many
Post by Ronald Tatum
banks in the total population of mainframe users.
Regards,
Ron Tatum
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy No Snore & Get a Good Night's Sleep. Natural Oral Spray -- $24.95
(1 bottle, 1 month supply, with sweet almond oil, eucalyptus oil & more).
http://www.challengerone.com/t/l.asp?cid=2881&lp=h515.html
http://us.click.yahoo.com/2oMABA/nuYGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Greg Smith
2003-07-23 00:45:31 UTC
Permalink
Post by dougbarc
You could even do things IBM said wouldn't work... long as you could
run in supervisor state. I remember writing some code that, for
security reasons, never went through open/close. It was code written
as an SVC and used for TSO during user logon to get some information
and provide authorization for some services by reading from the jobq
back when that was just a file on disk. The code built it's
own 'open' DCB, DEB, and the I/O appendages, as if it'd gone through
open. Yet if there was a dump or if someone put in code to run
control blocks, it never appeared. One never saw the data in DCB's,
DEB's because the control blocks were never on the DCB or DEB chains,
etc. Of course all of that went away once we got to MVS. IBM had a
little more checking in their code at that point. :)
I coded something similar a few years ago, the offlindr program.
Basically the program would dump to a dsorg=ps dataset an offline
dasd unit, track image by track image. No open. Runs on z/os.
Didn't try to hide the control blocks though.

One of the wierder programs I wrote was about 20 yrs ago on vse.
It coded a wait and the wait exit then modified the main psw to
supervisor state/key 0. When the program resumed, it modified the
psw in the power partition to point to some code in this program
and waited. When power woke up, it executed this code, which copied
code into the power partition. Then attached the copied code as
a subtask (I forget the vse terminology for this). Now the original
program ended. The subtask woke up every 10 seconds or so, calculated
some statistics, and wrote them to a file (without taking up a partition).
These statistics were exactly the same that vollie would show (when
doing the equivalent of `sdsf da'), but you could see it on another
computer that shared the dasd. This was on a 370-158 driving our
(you guessed it) MICR machine so the app programmers could so what was
going on on the machine.

Greg


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sOykFB/k9VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-23 02:41:03 UTC
Permalink
Post by Greg Smith
Post by dougbarc
You could even do things IBM said wouldn't work... long as you could
run in supervisor state. I remember writing some code that, for
security reasons, never went through open/close. It was code written
as an SVC and used for TSO during user logon to get some information
and provide authorization for some services by reading from the jobq
back when that was just a file on disk. The code built it's
own 'open' DCB, DEB, and the I/O appendages, as if it'd gone through
open. Yet if there was a dump or if someone put in code to run
control blocks, it never appeared. One never saw the data in DCB's,
DEB's because the control blocks were never on the DCB or DEB chains,
etc. Of course all of that went away once we got to MVS. IBM had a
little more checking in their code at that point. :)
I coded something similar a few years ago, the offlindr program.
Basically the program would dump to a dsorg=ps dataset an offline
dasd unit, track image by track image. No open. Runs on z/os.
Didn't try to hide the control blocks though.
I cheated.

The Heath Dept, new owners of 'our' 168s installed a user svc to get one
into superfighter state, key zero.

It is, of course, pretty easy to find user SVCs, so this was no
secret;-)

One only, I coded and ran a program that opened a file on disk, so it
had all the right control blocks.

I then used this SVC to change the UCB pointer in the DEB to point to a
local 3270.

Back in Clark Kent mode, I wrote a buffer of 3270 datastream to the file
& closed it.

As expected, I wrote sucessfully on the screen.


Reading from these devices is trickier: you need an attention routine
linked in some place so as to get control when a user presses an
attention key so you know _when_ to read it.

The official way was to code these appendages, install them in LPALIB or
somewhere, then re-ipl. _I_ would have loaded them myself, and put the
correct pointers in the DEB. I could have done that without disrupting
the other poor sods trying to use the computer at the time.

Years later, I revisited this, officially this time. For Wang-related
reasons we were using three-character userids.

Now, you can't encode much information into three characters, especially
when you are going to have 2000 or more users (not all at once on the
same computer, thankfully).

The plot was to have a table that would map the users into the group
membership (needed for ACF/2) and their location (needed for
distributing printouts, and on occasion, to discover which building or
even city to find someone).

The Security folk quickly won the nomination to maintain this information, the remaining questions were
1. Where to put it?
2. How do we get it there?
3. How do we validate the crud the security people code up?

My suggestion (accepted probably because I was sole advicer), was to put
it in CSA, we'd use CVTUSER to point to a series of pointers, one of
which pointed to this table. (This structure because I'm loathe to use
something that might be wanted for something else, and in fact, there
was something else).

I proposed a program I'd write that would get it there, and in order to
do it "properly" it needed to be ACF-authorised.

There was also the question of checking the data - no REXX back then -
and I suggested ASSEMBLER macroes, and I'd wrap it all into ISPF
dialogues (I was the king of them anyway).

There were lots of ways to do this - could have used TSO command
procedures to check the data, could have written it to a flat file (and
who knows, the security boffins could then have tampered with them).

What I proposed was that I create an object deck which we'd then link
into a load module.

Now, APF barks if an authorised program loads a load module from an
unauthorised library, and giving access to Security to an APF-authorised
library would be a security breech. (If they change the ACF/2 rules,
that's entirly their affair, but we're not making material changes to
the safety of the system).

No worries. Here's how it's done:

1. Open DCB.
2. Slip into key zero.
3. Mark the DEB authorised.
4. Load the module into CSA using the newly-authorised DCB.
5. Update the pointer to point to the new table.
6. Free the old one, if it exists.
6. Back to Duffer Mode.
7. Close.
8. SVC3.




How I violated ACF/2 security can wait for another day;-)
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Breakthrough Natural Health Specialties at VitaminBoost.com $20 to $40
Oral Sprays for Fast Results and Greater Absorption.
http://www.challengerone.com/t/l.asp?cid=2880
http://us.click.yahoo.com/3oMABA/muYGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Shawn Goodin
2003-07-23 16:08:51 UTC
Permalink
Ah, the good ol' days.....

I really enjoyed my time back at Aldens in 1980 -- back when the
sysprogs were gods. We were administrators, data security,
tech support, and operations gurus. I hooked up hardware
performance monitors to various boards within the frames in the
370/168 and the 3033. My favorite task was in debugging exits
for the DBA staff.

I needed an easy way to debug some user exits that had been
installed by the DBA. I found that I could fire up the multi-user
database control region inside TSO. Since it used user SVC's
for communications, the control region did not run authorized.

I defined another TSO user for me to use, went into test mode,
and ran some simple database update routines to test the exits.

It was great -- I set breakpoints, viewed and altered storage,
loaded new routines, and was able to thoroughly test the exits in
question. The DBA staff was amazed at what I could do with
TSO TEST. My thanks to the fine folks at the University of
Missouri at Rolla who insisted on teaching us all facets of TSO
and MVS back in 1975, including TEST.

My favorite "How'd you do that that??" always came from
operators who were amazed that I could see their consoles on
my desk (for MVS). After I went to a VS1 shop for a while
(Sunbeam), I wrote a similar program to run under CICS and
VS1. Wowed them there too.

Alas, like many of the others here, I've been looking for work for
the last year. Getting damned tired of staying at home....

Shawn
Post by John Summerfield
1. Open DCB.
2. Slip into key zero.
3. Mark the DEB authorised.
4. Load the module into CSA using the newly-authorised DCB.
5. Update the pointer to point to the new table.
6. Free the old one, if it exists.
6. Back to Duffer Mode.
7. Close.
8. SVC3.
How I violated ACF/2 security can wait for another day;-)
--
Cheers
John.
Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sOykFB/k9VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Ronald Tatum
2003-07-22 14:10:42 UTC
Permalink
John,
Assuming that LRA works the same on all boxes that have that instruction
(apparently nothing's certain at some level), I find this in SA22-7200-0
(ESA/370 POP) in the chapter on "Control Instructions":
Load Real Address
LRA R1,D2(X2,B2) [RX]
The real address corresponding to the second operand address is placed in
general register R1.

The virtual address specified by the X2, B2, and D2 fields s translated by
means of the dynamic-address facility, regardless of whether DAT is on or
off.

DAT is performed by using a segment-table designation that depends on the
current value of the address-space-control bits, bits 16 and 17 of the PSW
as shown in the following table:

[I've snipped the remainder, it goes on for another page and a half or so,
and it's grim stuff}

However, the programming note is quite interesting:
"Caution must be exercised in the use of LOAD REAL ADDRESS in a
multiprocessing configuration. Since INVALIDATE PAGE TABLE ENTRY may set the
1 bit in storage to one before causing the corresponding entries in TLBs of
other CPUs to be cleared, the simultaneous execution of LOAD REAL ADDRESS on
the CPU and INVALIDATE PAGE TABLE ENTRY on another CPU may produce
*inconsistent results* [emphasis -RHT]. Because LOAD REAL ADDRTESS accesses
the tables in storage, the page-table entry may appear to be invalid
(condition code 2) even though the corresponding TLB entry has not been
cleared, and the TLB entry may remain in the TLB until the completion of
INVALIDATE PAGE TABLE ENTRY on the other CPU. *There is no guaranteed limit
to the number of instructions which may occur between the completion of LOAD
REAL ADDRESS and the TLB being cleared of the entry* [emphasis -RHT].

I haven't quite figured out if LRA Rn,0 which assembles as LRA
Rn,0(0,0) goes through all the contortions the POP describes or if it's a
"relatively" innocuous thing that just runs more slowly than a simple LA
Rn,0 or SR Rn,Rn or XR Rn,Rn or not. From what the poster said earlier, it
seems to have been a bit of nonsense some coders within IBM did for whatever
reason. Far as I *can* tell, it probably just made some things crawl
...weird in any case.
Regards,
Ron T.
----- Original Message -----
From: "John Summerfield" <spam-***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Sent: Monday, July 21, 2003 6:20 PM
Subject: Re: [hercules-390] 168s and microcode. Was: Re: iSeries/AS400
Post by John Summerfield
Post by jeffsavit
A base canard, sir! As previously noted, the 168 did have microcode,
and ran VM just fine - including running MVT faster under VM than
natively (if you had the large-system mods), and certainly for running
CMS. It was only when running MVS without VM assist that you felt the
pain. What do you expect when the guest OS does things like "LRA
R2,0", which is a pretty expensive way to set R2 to 0! Zapping that
one instruction, IIRC, was a 10-20% improvement to MVS guest
performance.
I personally was not involved, but I spoke with those who were actually
trying to do this. As I understand it, at that time the interest was in
running VS1: MVS hadn't yet surfaced, but we were running VS1 in our
state offices.
Comments made around that time revolved around "hard-wired logic" and
"serious computing."
It may well be that the picture changed later, but at that time IBM had
no answer for the performance problems.
_I_ would want to check the POP to verify that "LRA 2,0" does in fact
set GPR2=0.
--
Cheers
John.
Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.
http://groups.yahoo.com/group/hercules-390
http://www.conmicro.cx/hercules
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
jeffsavit
2003-07-22 14:15:42 UTC
Permalink
Well, it would have to: this is a guest referring to its "guest real"
location 0, which would map into 0 whether the guest was in DAT mode
(PSW's DAT bit on) or not. Robert Fisher of TI zapped the LRA to SR
2,2 and got a 15% improvement (this was under SVS, actually but would
still apply under MVS), and presented his results in public repeatedly
starting with SHARE XLVI, in February, 1976. Source: Melinda Varian's
history of VM and the VM user community. -- Jeff
Post by John Summerfield
_I_ would want to check the POP to verify that "LRA 2,0" does in fact
set GPR2=0.
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Jay Maynard
2003-07-22 14:21:33 UTC
Permalink
Post by jeffsavit
Well, it would have to: this is a guest referring to its "guest real"
location 0, which would map into 0 whether the guest was in DAT mode
(PSW's DAT bit on) or not. Robert Fisher of TI zapped the LRA to SR
2,2 and got a 15% improvement (this was under SVS, actually but would
still apply under MVS), and presented his results in public repeatedly
starting with SHARE XLVI, in February, 1976. Source: Melinda Varian's
history of VM and the VM user community. -- Jeff
One would hope he zapped it to SR 2,2; NOPR 0. (Gotta soak up those other
two bytes, you know.) :-)

Any ideas on how to find this in the Turnkey MVS version? Even though
Hercules on anything recent runs MVS quite a bit faster than a 168, 15%
never hurts.

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
jeffsavit
2003-07-22 14:47:58 UTC
Permalink
Hi Jay,

He might have even had access to source code (gasp!) since it was SVS,
and even shorted the code by the two bytes; otherwise, he must have.
Or violated the laws of conservation!

Under modern VM you could use a TRACE INST command with the offending
instruction, and then run the guest. That would slow execution a lot,
but once you found it you could ZAP it. Under VM/370 you would have to
apply the University of Maine PER command mods (which became IBM's
TRACE command in VM/ESA), otherwise you would have to resort to doing
TRACE PRIV RUN and then looking at the ENORMOUS trace listing to find
the right instructions. Too big to be practical! Under Hercules
without VM, I think the easiest and nastiest thing to do would be to
put special code in control.c in load_real_address(), enabled by an
#if, that checked for b,d,x being 0 and logging it.

I *hope* the code no longer exists, even in MVS 3.8.

BTW, the case was simpler than it would be today, since the guests
were uniprocessor only and there was no such thing as primary/seconday
address space mode. This was in 370 days, not 390!

cheers, Jeff
Post by Jay Maynard
One would hope he zapped it to SR 2,2; NOPR 0. (Gotta soak up those other
two bytes, you know.) :-)
Any ideas on how to find this in the Turnkey MVS version? Even though
Hercules on anything recent runs MVS quite a bit faster than a 168, 15%
never hurts.
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Breakthrough Natural Health Specialties at VitaminBoost.com $20 to $40
Oral Sprays for Fast Results and Greater Absorption.
http://www.challengerone.com/t/l.asp?cid=2880
http://us.click.yahoo.com/3oMABA/muYGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Binyamin Dissen
2003-07-22 15:46:19 UTC
Permalink
On Tue, 22 Jul 2003 23:42:35 +0800 (WST) John Summerfield
<spam-***@public.gmane.org> wrote:

:>On Tue, 22 Jul 2003, jeffsavit wrote:
:>
:>> Hi Jay,
:>>
:>> He might have even had access to source code (gasp!) since it was SVS,
:>> and even shorted the code by the two bytes; otherwise, he must have.
:>> Or violated the laws of conservation!
:>>
:>> Under modern VM you could use a TRACE INST command with the offending
:>> instruction, and then run the guest. That would slow execution a lot,
:>> but once you found it you could ZAP it. Under VM/370 you would have to
:>> apply the University of Maine PER command mods (which became IBM's
:>> TRACE command in VM/ESA), otherwise you would have to resort to doing
:>> TRACE PRIV RUN and then looking at the ENORMOUS trace listing to find
:>> the right instructions. Too big to be practical! Under Hercules
:>> without VM, I think the easiest and nastiest thing to do would be to
:>> put special code in control.c in load_real_address(), enabled by an
:>> #if, that checked for b,d,x being 0 and logging it.
:>>
:>> I *hope* the code no longer exists, even in MVS 3.8.
:>>
:>> BTW, the case was simpler than it would be today, since the guests
:>> were uniprocessor only and there was no such thing as primary/seconday
:>> address space mode. This was in 370 days, not 390!
:>
:>I believe Primary/Secondary came in with XA. However, when we were
:>planning XA, I was the Panvalet/Panexec/ISPF dialogue king.

DAS came in with SP1.3 (pre-XA).

--
Binyamin Dissen <bdissen-***@public.gmane.org>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-22 15:42:35 UTC
Permalink
Post by jeffsavit
Hi Jay,
He might have even had access to source code (gasp!) since it was SVS,
and even shorted the code by the two bytes; otherwise, he must have.
Or violated the laws of conservation!
Under modern VM you could use a TRACE INST command with the offending
instruction, and then run the guest. That would slow execution a lot,
but once you found it you could ZAP it. Under VM/370 you would have to
apply the University of Maine PER command mods (which became IBM's
TRACE command in VM/ESA), otherwise you would have to resort to doing
TRACE PRIV RUN and then looking at the ENORMOUS trace listing to find
the right instructions. Too big to be practical! Under Hercules
without VM, I think the easiest and nastiest thing to do would be to
put special code in control.c in load_real_address(), enabled by an
#if, that checked for b,d,x being 0 and logging it.
I *hope* the code no longer exists, even in MVS 3.8.
BTW, the case was simpler than it would be today, since the guests
were uniprocessor only and there was no such thing as primary/seconday
address space mode. This was in 370 days, not 390!
I believe Primary/Secondary came in with XA. However, when we were
planning XA, I was the Panvalet/Panexec/ISPF dialogue king.
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Binyamin Dissen
2003-07-22 14:31:01 UTC
Permalink
On Tue, 22 Jul 2003 14:15:42 -0000 "jeffsavit" <jsavit-***@public.gmane.org> wrote:

:>Well, it would have to: this is a guest referring to its "guest real"
:>location 0, which would map into 0 whether the guest was in DAT mode
:>(PSW's DAT bit on) or not. Robert Fisher of TI zapped the LRA to SR
:>2,2 and got a 15% improvement (this was under SVS, actually but would
:>still apply under MVS), and presented his results in public repeatedly
:>starting with SHARE XLVI, in February, 1976. Source: Melinda Varian's
:>history of VM and the VM user community. -- Jeff

LRA Rx,0(0,0)

will always set Rx to zero (or will get a priv-op).

S/370 memory has three levels - virtual, real, and absolute.

In general absolute = real with the exception of page zero which is affected
by the prefix register.

If bits 1-19 (or 0-51) of the generated real address is zero, the absolute
address of the referenced page is in the prefix register.

If bits 1-19 (or 0-51) of the generated real address match the prefix
register, absolute page zero will be used.

As a side point, virtual addresses have multiple types (home, primary,
secondary, ALET qualified, etc.)

:>--- In hercules-390-***@public.gmane.org, John Summerfield <***@c...> wrote:

:>> _I_ would want to check the POP to verify that "LRA 2,0" does in fact
:>> set GPR2=0.

--
Binyamin Dissen <bdissen-***@public.gmane.org>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Naturally Painless & Spray Away Backaches & Joint Pain. $19.97
http://www.challengerone.com/t/l.asp?cid=2867&lp=m331.html
http://us.click.yahoo.com/tJIe0D/79VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
ivan_warhead
2003-07-22 16:14:11 UTC
Permalink
<snip />
Post by Binyamin Dissen
LRA Rx,0(0,0)
will always set Rx to zero (or will get a priv-op).
Hmmmmm ?? (<== surprised look)


LRA 2,0 always store value 0 in GPR2 ???? I don't think so...

0 in this case is a virtual address. If the segment table pointed by
CR1 is ok and If the PTL in the 1st STE is not 0 and the 1st entry
in the 1st segment table points to a non-invalidated PTE, bits 8-19
or 8-20 (Depending on CR0 bits 8 & 9) or bits 1-19 (XA/ESA) or
whatever in 64 bits mode will contain bits 0-11/0-12 or 0-19 of the
PTE. In plain english (sorta) this means if 0 is a virtual address
that can be translated to a real address, GPR2 will contain the real
address for this virtual address (which can be any real address -
including an address beyond addressable storage - LRA doesn't check
for addressability of the final real address or for PSW Key/Storage
Key comformance - just deals with address translation).

LRA doesn't generate Segment/Page/Addressing/Translation exceptions
but can generate privop (and the operation is suppressed).. If LRA
cannot translate virtual address 0 to a real address in accordance
with the DAT tables, this is reflected in the CC.

If DAS is in effect, the STE/PTE used depends on CR0 Bit 5.. Some
other modifications if running in ESA mode with access registers
(but I don't know (yet) how that works :P )

Sorry folks.. I'm not very good at ESA and z/Arch.. but anyway.. I
don't think that LRA R1,D2(X2,B2) always sets R1 to 0 when D2 X2 and
B2 are set to 0.

--Ivan


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Natural Vitamins for Good Prostate & Male Health. $28.97
http://www.challengerone.com/t/l.asp?cid=2865&lp=prosta2.html
http://us.click.yahoo.com/qJIe0D/89VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Binyamin Dissen
2003-07-22 16:35:08 UTC
Permalink
On Tue, 22 Jul 2003 16:14:11 -0000 "ivan_warhead" <ivan-lnHwE90NT89Ooi3Kub+***@public.gmane.org> wrote:

:>> LRA Rx,0(0,0)

:>> will always set Rx to zero (or will get a priv-op).

:>Hmmmmm ?? (<== surprised look)


:>LRA 2,0 always store value 0 in GPR2 ???? I don't think so...

:>0 in this case is a virtual address. If the segment table pointed by
:>CR1 is ok and If the PTL in the 1st STE is not 0 and the 1st entry
:>in the 1st segment table points to a non-invalidated PTE, bits 8-19
:>or 8-20 (Depending on CR0 bits 8 & 9) or bits 1-19 (XA/ESA) or
:>whatever in 64 bits mode will contain bits 0-11/0-12 or 0-19 of the
:>PTE. In plain english (sorta) this means if 0 is a virtual address
:>that can be translated to a real address, GPR2 will contain the real
:>address for this virtual address (which can be any real address -
:>including an address beyond addressable storage - LRA doesn't check
:>for addressability of the final real address or for PSW Key/Storage
:>Key comformance - just deals with address translation).

You are correct.

My mistake.

:>LRA doesn't generate Segment/Page/Addressing/Translation exceptions
:>but can generate privop (and the operation is suppressed).. If LRA
:>cannot translate virtual address 0 to a real address in accordance
:>with the DAT tables, this is reflected in the CC.

It can also generate exceptions if the STO or segment/page table entries are
not properly formatted.

--
Binyamin Dissen <bdissen-***@public.gmane.org>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
Free shipping on orders $50 or more to the US and Canada.
http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
ivan_warhead
2003-07-22 16:47:02 UTC
Permalink
<snip />
Post by Binyamin Dissen
It can also generate exceptions if the STO or segment/page table entries are
not properly formatted.
Correct ! My bad :P (it can generate Addressing if the STO or PTO
are not addressable or Translation exception if (I think) there is a
malformed STE ot PTE - or if CR0 bits 8-12 have an invalid
combination))

--Ivan



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
Free shipping on orders $50 or more to the US and Canada.
http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Tony Harminc
2003-07-21 17:33:39 UTC
Permalink
Post by John Summerfield
Bear in mind that most S/370 machines had microcode. The 168 didn't, and
ran VM like a 135. Gene Amdahl used hard-wired logic as a selling-point
- his designs were faster because they didn't have slushware gluing
things up.
The 168 most certainly did have microcode, albeit nothing like the
microcode on the smaller machines like the 138, 145, and so on.
Post by John Summerfield
One of the features of the microcode was that it could be
updated/overwritten by IPLing something. At one time we genned VS1 for a
148 and ran it on our 145 using the microcode assists.
The 168 had an ill-documented Load Microprogram instruction. Opcode
B9, IIRC.

Tony H.

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
Free shipping on orders $50 or more to the US and Canada.
http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Ronald Tatum
2003-07-21 18:00:18 UTC
Permalink
I seem to recall that one of the differences between the 155/165 370s and
the 158/168s was that the "5" varieties had read-only control stores and the
"8" machines had what one wag at Rice University called "read-mostly" memory
in that there was indeed at least some, if not all, portion of the control
store that could be written by various means. The only 360 IIRC that was
"hard-wired" was the 360/75 - the technologies for control stores at the
time just weren't fast enough for the 75 to hit IBM's targeted markets for
that class of mainframe. I've heard different stories about the 90 series,
all of which may be true since there were different varieties. Anyone want
to tell the rest of us just what IBM did to make a 360/195 into a 370/195?
McDonnell Automation and TI both had 360 varieties that they somehow
upgraded to 370s in the early 1970s.
Regards,
Ron T.
----- Original Message -----
From: "Tony Harminc" <tony-***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Sent: Monday, July 21, 2003 12:33 PM
Subject: Re: [hercules-390] Re: iSeries/AS400
Post by Tony Harminc
Post by John Summerfield
Bear in mind that most S/370 machines had microcode. The 168 didn't, and
ran VM like a 135. Gene Amdahl used hard-wired logic as a selling-point
- his designs were faster because they didn't have slushware gluing
things up.
The 168 most certainly did have microcode, albeit nothing like the
microcode on the smaller machines like the 138, 145, and so on.
Post by John Summerfield
One of the features of the microcode was that it could be
updated/overwritten by IPLing something. At one time we genned VS1 for a
148 and ran it on our 145 using the microcode assists.
The 168 had an ill-documented Load Microprogram instruction. Opcode
B9, IIRC.
Tony H.
http://groups.yahoo.com/group/hercules-390
http://www.conmicro.cx/hercules
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Breakthrough Natural Health Specialties at VitaminBoost.com $20 to $40
Naturally Painless Spray, Coral Calcium, No Snore, EZ Appetite Suppressant.
http://www.challengerone.com/t/l.asp?cid=2882
http://us.click.yahoo.com/yoMABA/ruYGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Gregg C Levine
2003-07-21 19:21:19 UTC
Permalink
Hello from Gregg C Levine
Good question. I'm familiar with most of what's going on here. And
quite personally, Ron, all I can recall, is that the big differences
were solved in microcode. But I can't remember how. I just remember
that the issue surfaced in a book written to explain the way the
entire IBM S/360/370, and yes the S/390 lines took shape.
-------------------
Gregg C Levine hansolofalcon-XfrvlLN1Pqtfpb/***@public.gmane.org
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
Post by Terry Myhrer
-----Original Message-----
Sent: Monday, July 21, 2003 2:00 PM
Subject: Re: [hercules-390] Re: iSeries/AS400
I seem to recall that one of the differences between the 155/165 370s and
the 158/168s was that the "5" varieties had read-only control stores and the
"8" machines had what one wag at Rice University called
"read-mostly" memory
Post by Terry Myhrer
in that there was indeed at least some, if not all, portion of the control
store that could be written by various means. The only 360 IIRC that was
"hard-wired" was the 360/75 - the technologies for control stores at the
time just weren't fast enough for the 75 to hit IBM's targeted
markets for
Post by Terry Myhrer
that class of mainframe. I've heard different stories about the 90 series,
all of which may be true since there were different varieties.
Anyone want
Post by Terry Myhrer
to tell the rest of us just what IBM did to make a 360/195 into a 370/195?
McDonnell Automation and TI both had 360 varieties that they somehow
upgraded to 370s in the early 1970s.
Regards,
Ron T.
----- Original Message -----
Sent: Monday, July 21, 2003 12:33 PM
Subject: Re: [hercules-390] Re: iSeries/AS400
Post by Tony Harminc
Post by John Summerfield
Bear in mind that most S/370 machines had microcode. The 168 didn't, and
ran VM like a 135. Gene Amdahl used hard-wired logic as a
selling-point
Post by Terry Myhrer
Post by Tony Harminc
Post by John Summerfield
- his designs were faster because they didn't have slushware gluing
things up.
The 168 most certainly did have microcode, albeit nothing like the
microcode on the smaller machines like the 138, 145, and so on.
Post by John Summerfield
One of the features of the microcode was that it could be
updated/overwritten by IPLing something. At one time we genned VS1 for a
148 and ran it on our 145 using the microcode assists.
The 168 had an ill-documented Load Microprogram instruction.
Opcode
Post by Terry Myhrer
Post by Tony Harminc
B9, IIRC.
Tony H.
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sOykFB/k9VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-21 21:19:17 UTC
Permalink
Post by Ronald Tatum
I seem to recall that one of the differences between the 155/165 370s and
the 158/168s was that the "5" varieties had read-only control stores and the
"8" machines had what one wag at Rice University called "read-mostly" memory
in that there was indeed at least some, if not all, portion of the control
store that could be written by various means. The only 360 IIRC that was
"hard-wired" was the 360/75 - the technologies for control stores at the
time just weren't fast enough for the 75 to hit IBM's targeted markets for
that class of mainframe. I've heard different stories about the 90 series,
all of which may be true since there were different varieties. Anyone want
to tell the rest of us just what IBM did to make a 360/195 into a 370/195?
McDonnell Automation and TI both had 360 varieties that they somehow
upgraded to 370s in the early 1970s.
Regards,
Ron T.
The 155, 165 had no DAT (initially), and used core memory (like the
S/360s).

The 168 had 4K DRAM chips. It did have writable control storage, but its
use didn't amount to reprogramming as we did with the 145.

The manual I think most likely to clarify is IBM (1974). IBM system/370
model 168 functional characteristics. Form GA22-7010, 3rd ed. (May
1974). IBM Corp. Sys. Product Div., Poughkeepsie, NY, but I cannot find
a copy.
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
ivan_warhead
2003-07-21 21:53:50 UTC
Permalink
this URL : http://www.beagle-
ears.com/lars/engineer/comphist/model360.htm seems to have a little
bit of info on the early S/360 and S/370 models..

But this link : http://ukcc.uky.edu/~ukccinfo.291/
would seem to contradict the fact that the 370/165 had no DAT (if it
was running VM/370 it *HAD* to have DAT capability)..

Anyway.. googling with 370/165 and such gives a bit of info (yet
sometimes contracting - could be some of those people had a few
double bit errors with no ECC)

(sorry folks.. me be a newbie.. oldest model I ever came accross was
a 370/138 II)

--Ivan


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get a FREE REFINANCE QUOTE - click here!
http://us.click.yahoo.com/nHYuCC/ca0FAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
jeffsavit
2003-07-21 22:01:16 UTC
Permalink
Ivan, the 370/155 and /165 did not have DAT - and shortly afterwards
IBM shipped machines that did, and then offered an expensive upgrade
to convert them into the 155-II and 165-II models, which did have DAT,
and could run VM, VS1, SVS. There was a lot of displeasure from early
purchasers of the non-DAT versions for having paid a lot of money for
a box that very soon was made useless for running IBM's OSes. -- Jeff
Post by ivan_warhead
But this link : http://ukcc.uky.edu/~ukccinfo.291/
would seem to contradict the fact that the 370/165 had no DAT (if it
was running VM/370 it *HAD* to have DAT capability)..
--Ivan
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Tony Harminc
2003-07-21 22:50:45 UTC
Permalink
Post by jeffsavit
Ivan, the 370/155 and /165 did not have DAT - and shortly afterwards
IBM shipped machines that did, and then offered an expensive upgrade
to convert them into the 155-II and 165-II models, which did have DAT,
and could run VM, VS1, SVS. There was a lot of displeasure from early
purchasers of the non-DAT versions for having paid a lot of money for
a box that very soon was made useless for running IBM's OSes. -- Jeff
I worked at the University of Toronto in 1975 when they upgraded
their 165 to a 165-II. This took IBM around four working days of
three shifts each, and involved replacing most if not all of the CPU
frames, and making major changes to the standalone 2860, 2870, and
2880 channel boxes (to support IDA). This made a machine much like a
168, but still with slow (2 uS) core storage, and with a small enough
cache and STO stack that MVS performance was *much much* worse than
MVT.

Two changes from a 165 to a 165-II (other than virtual storage) were
the addition of the Monitor Call instruction, and the removal of
imprecise program interrupts.

Tony H.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sOykFB/k9VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-21 23:11:37 UTC
Permalink
Post by ivan_warhead
this URL : http://www.beagle-
ears.com/lars/engineer/comphist/model360.htm seems to have a little
bit of info on the early S/360 and S/370 models..
It has some errors.
370/168 - same as 360/165 with dynamic address...
I believe the Model 165 had core memory. The 168 certianly had 4K DRAM
memory.

4361 - small cpu, used as service (maintenance) processor for 3090
Maybe. The 4300 series were small mainframs in their own right though. I
understand the 158s were reused in channels.

4381 - a larger mini
Not minis. Whether they were minis is an architecture thing, and these
ran IBM's OS and DOS family of operating systens. The 4380-3 was
comparable with a 168. I believe they were CMOS, air-cooled.

3081 ... the first dual that could not be split into two separate
systems.

Not so. There were two multiple-processor options with the 158, 168 and
some other machines of the time (including Amdahl):
MP. Two complete systems, could be separated into two, even while
running.
AP Second processor had no I/O capability.
Post by ivan_warhead
But this link : http://ukcc.uky.edu/~ukccinfo.291/
would seem to contradict the fact that the 370/165 had no DAT (if it
was running VM/370 it *HAD* to have DAT capability)..
That would be a model III. DAT was added as a field upgrade.
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Natural Vitamins for Good Prostate & Male Health. $28.97
http://www.challengerone.com/t/l.asp?cid=2865&lp=prosta2.html
http://us.click.yahoo.com/qJIe0D/89VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Peter J Farley III
2003-07-22 04:37:23 UTC
Permalink
--- In hercules-390-***@public.gmane.org, John Summerfield <***@c...>
wrote:
<Snipped>
Post by John Summerfield
4361 - small cpu, used as service (maintenance) processor for 3090
Maybe. The 4300 series were small mainframs in their own right
though. I understand the 158s were reused in channels.
Certainly was a mainframe in its own right. I personally supervised
a shop that ran VM/SP2 and VSE/SP2 on one, and it was capable of
running MVS (if you could afford the software fees and the personnel
required to service the beast).

There was also the baby of the family, the 4321 -- came only with
FBA DASD (3310/70), and a "user friendly" maintenance and
development environment version of DOS called SSX/VSE. Targeted at
the DOS/VS R34 shops that were still resisting paying for hardware
upgrades and new software, if I remember the IBM marketing hype
correctly.
Post by John Summerfield
4381 - a larger mini
Not minis. Whether they were minis is an architecture thing, and
these ran IBM's OS and DOS family of operating systens. The 4380-3
was comparable with a 168. I believe they were CMOS, air-cooled.
And the box they came in was indistinguishable from their companion
3380 disk units or the correspoonding disk control unit. Nothing but
practically featureless boxes strewn about the computer room. First
time I saw one, I realized how much I missed the 370/145 console... :)

Interesting fact -- a systems fellow at a major NYC corp once showed
me the service processor for one of their multiple 30xx series
water-cooled machines because he know I was a fan of VM. I *think*
they were 3090's but it's been too long and I don't remember now --
circa 1985 era. In any case, the "service processor" for the
water-cooled monster was a 4381 CPU with it's own pair of 3370 FBA
disks, and it ran VM/370!

Jeff Savit, was it you who showed me that interesting bit of trivia,
back in the day?

Regards,

Peter


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Breakthrough Natural Health Specialties at VitaminBoost.com $20 to $40
Naturally Painless Spray, Coral Calcium, No Snore, EZ Appetite Suppressant.
http://www.challengerone.com/t/l.asp?cid=2882
http://us.click.yahoo.com/yoMABA/ruYGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
bellomyj
2003-07-22 05:49:40 UTC
Permalink
Actually the 4341's came in two models known as a 4341-1 and 4341-2,
and in the late 70's and early 80's I install two mod2's to run a
large California banks entire Visa and MC processing in a new
datacenter in an office complex that we bought. All running on
MVS/SE-II, under VTAM and CICS. We also had a mod1 that supported
all of the TSO and Roscoe application developers. IBM said it was
too small to work, but it suprised them when it worked just great
for over 5 years.
Post by Peter J Farley III
<Snipped>
Post by John Summerfield
4361 - small cpu, used as service (maintenance) processor for 3090
Maybe. The 4300 series were small mainframs in their own right
though. I understand the 158s were reused in channels.
Certainly was a mainframe in its own right. I personally
supervised
Post by Peter J Farley III
a shop that ran VM/SP2 and VSE/SP2 on one, and it was capable of
running MVS (if you could afford the software fees and the
personnel
Post by Peter J Farley III
required to service the beast).
There was also the baby of the family, the 4321 -- came only with
FBA DASD (3310/70), and a "user friendly" maintenance and
development environment version of DOS called SSX/VSE. Targeted at
the DOS/VS R34 shops that were still resisting paying for hardware
upgrades and new software, if I remember the IBM marketing hype
correctly.
Post by John Summerfield
4381 - a larger mini
Not minis. Whether they were minis is an architecture thing, and
these ran IBM's OS and DOS family of operating systens. The 4380-
3
Post by Peter J Farley III
Post by John Summerfield
was comparable with a 168. I believe they were CMOS, air-cooled.
And the box they came in was indistinguishable from their
companion
Post by Peter J Farley III
3380 disk units or the correspoonding disk control unit. Nothing but
practically featureless boxes strewn about the computer room.
First
Post by Peter J Farley III
time I saw one, I realized how much I missed the 370/145
console... :)
Post by Peter J Farley III
Interesting fact -- a systems fellow at a major NYC corp once
showed
Post by Peter J Farley III
me the service processor for one of their multiple 30xx series
water-cooled machines because he know I was a fan of VM. I
*think*
Post by Peter J Farley III
they were 3090's but it's been too long and I don't remember now --
circa 1985 era. In any case, the "service processor" for the
water-cooled monster was a 4381 CPU with it's own pair of 3370 FBA
disks, and it ran VM/370!
Jeff Savit, was it you who showed me that interesting bit of
trivia,
Post by Peter J Farley III
back in the day?
Regards,
Peter
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sOykFB/k9VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
ivan_warhead
2003-07-22 07:48:13 UTC
Permalink
Post by bellomyj
Actually the 4341's came in two models known as a 4341-1 and 4341-
2,
<snip />
I think there was also a model 4341-12 (with 12 Mb of main)..
but never saw any of these beasts..
--Ivan


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sOykFB/k9VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-22 14:13:34 UTC
Permalink
Post by Peter J Farley III
<Snipped>
Post by John Summerfield
4361 - small cpu, used as service (maintenance) processor for 3090
Maybe. The 4300 series were small mainframs in their own right
though. I understand the 158s were reused in channels.
Certainly was a mainframe in its own right. I personally supervised
a shop that ran VM/SP2 and VSE/SP2 on one, and it was capable of
running MVS (if you could afford the software fees and the personnel
required to service the beast).
There was also the baby of the family, the 4321 -- came only with
One of the highlights of the 43xx series, to my mind, is that in
Australia, IBM became a PCM.

IBM had offended the Australian Govt bureaucracy in a story for another
day (it may be in the archives), and consequently Facom (Fujitsu) mainly
but also Amdhal were doing rather well, and I think it rubbed off a
little into private business.

Facom was selling its own line of computers running the OSIV family of
operating systems. Both the computers and the software were more-or-less
supersets of IBM's offerings.

What was IBM to do to get these customers back? Why, a microcode update
to the 43xx to implement the additional Facom instructions so they could
run Fujitsu software.

I do not know what IBM did about channel DAT - one of the Facom
refinements was the ability of the channels to translate the virtual
addresses to real.

"Facom" == "Fujitsu Automatic Computer." Also, for many years, the name
of the Australian subsidiary.
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
jeffsavit
2003-07-22 14:20:25 UTC
Permalink
Yup, that was me! It may not have been a 4381 (I think it was a
smaller thing like a 4331), but yes, there were 2 4300s in there with
their own FBA DASD, running a hacked up version of VM. I even gave a
copy of the computer game 'Zork' to the CEs so they could play the
game on the service processor when nobody was looking. :-)
Post by Peter J Farley III
Interesting fact -- a systems fellow at a major NYC corp once showed
me the service processor for one of their multiple 30xx series
water-cooled machines because he know I was a fan of VM. I *think*
they were 3090's but it's been too long and I don't remember now --
circa 1985 era. In any case, the "service processor" for the
water-cooled monster was a 4381 CPU with it's own pair of 3370 FBA
disks, and it ran VM/370!
Jeff Savit, was it you who showed me that interesting bit of trivia,
back in the day?
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-22 14:27:49 UTC
Permalink
Post by jeffsavit
Yup, that was me! It may not have been a 4381 (I think it was a
smaller thing like a 4331), but yes, there were 2 4300s in there with
their own FBA DASD, running a hacked up version of VM. I even gave a
copy of the computer game 'Zork' to the CEs so they could play the
game on the service processor when nobody was looking. :-)
I was at an IBM presentation here last month. Some of their current boxes
have Thinkpads in them for service processors.
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
ivan_warhead
2003-07-22 07:46:55 UTC
Permalink
Post by John Summerfield
4361 - small cpu, used as service (maintenance) processor for 3090
Maybe. The 4300 series were small mainframs in their own right
though. I
Post by John Summerfield
understand the 158s were reused in channels.
Hmm.. funny enough, I was under the impression that the 3092 (the
3090 service processor) was a pair of 4331 refurbished gates crammed
into a 3090 style box (each gate ran as a backup for the other side -
one being active, the other being passive). The fact that it ran a
heavily modified version of VM/370 R6 + BSEPP made it fun to play
with.

--Ivan


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sOykFB/k9VGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-22 14:00:42 UTC
Permalink
Post by John Summerfield
Post by John Summerfield
4361 - small cpu, used as service (maintenance) processor for 3090
Maybe. The 4300 series were small mainframs in their own right
though. I
Post by John Summerfield
understand the 158s were reused in channels.
Hmm.. funny enough, I was under the impression that the 3092 (the
3090 service processor) was a pair of 4331 refurbished gates crammed
into a 3090 style box (each gate ran as a backup for the other side -
one being active, the other being passive). The fact that it ran a
heavily modified version of VM/370 R6 + BSEPP made it fun to play
with.
Quite possibly. The 158s would have been used int he 303x group.
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
Free shipping on orders $50 or more to the US and Canada.
http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
xlonglife
2003-08-21 08:21:41 UTC
Permalink
--- In hercules-390-***@public.gmane.org, "Ronald Tatum" <***@d...>
wrote:
<..snip..>
...Anyone want
to tell the rest of us just what IBM did to make a 360/195 into a 370/195?
I used a pair of 195's in the 1970's and the basic difference was
that a 370 had the additional instructions ICM, MVCL, CLCL but still
no DAT..... so no VM :(

Steve


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/W4wwlB/TM
---------------------------------------------------------------------~->
Ronald Tatum
2003-07-21 18:29:26 UTC
Permalink
Another item from the distant past re microcoded machines versus
"hard-wired" machines.

Amdahl tried to sell a company a 470 and touted their speed advantage with
their "hard-wired" design over IBM's microcoded 370s. Made some very good
points.

The "systems programmeur" at the company started throwing FUD about IBM
would start putting just *all* kinds of pieces of future releases of the
OSes into the microcode (even PTFs, if you can believe such nonsense) so the
company wouldn't be able to upgrade releases, even fix known probs,
yada-yada .....

The Amdahl guys, for whatever reasons, didn't shoot that nonsense down:
After all, if they could build those large boards full of ASICs, standard
ICs, etc., so they had binary-level compatability with IBM's hardware, who
would think that they couldn't incorporate any stuff that IBM might migrate
from where it really belonged into writable control store? Well, really ...

The "programmeur", turned out, had been appearing at the company, then
vanishing every day: Been working a second job 9 to 5 a couple of blocks
away for a couple of years. Quit when he was told he had to be available to
and *listen* to user problems/requests. The company only found out about his
double-dealing after he left. Never tried to prosecute/sue him for the fraud
he'd perpetrated. (BTW it was the *other* PP.)

Company did finally wind up getting a V6. Worked fine, lasted a long time,
and writing stuff into control storage never became an issue ...
Regards,
Ron T.
----- Original Message -----
From: "Tony Harminc" <tony-***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Sent: Monday, July 21, 2003 12:33 PM
Subject: Re: [hercules-390] Re: iSeries/AS400
Post by Tony Harminc
Post by John Summerfield
Bear in mind that most S/370 machines had microcode. The 168 didn't, and
ran VM like a 135. Gene Amdahl used hard-wired logic as a selling-point
- his designs were faster because they didn't have slushware gluing
things up.
The 168 most certainly did have microcode, albeit nothing like the
microcode on the smaller machines like the 138, 145, and so on.
Post by John Summerfield
One of the features of the microcode was that it could be
updated/overwritten by IPLing something. At one time we genned VS1 for a
148 and ran it on our 145 using the microcode assists.
The 168 had an ill-documented Load Microprogram instruction. Opcode
B9, IIRC.
Tony H.
http://groups.yahoo.com/group/hercules-390
http://www.conmicro.cx/hercules
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Breakthrough Natural Health Specialties at VitaminBoost.com $20 to $40
Oral Sprays for Fast Results and Greater Absorption.
http://www.challengerone.com/t/l.asp?cid=2880
http://us.click.yahoo.com/3oMABA/muYGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
John Summerfield
2003-07-21 21:11:50 UTC
Permalink
Post by Tony Harminc
Post by John Summerfield
Bear in mind that most S/370 machines had microcode. The 168 didn't, and
ran VM like a 135. Gene Amdahl used hard-wired logic as a selling-point
- his designs were faster because they didn't have slushware gluing
things up.
The 168 most certainly did have microcode, albeit nothing like the
microcode on the smaller machines like the 138, 145, and so on.
Post by John Summerfield
One of the features of the microcode was that it could be
updated/overwritten by IPLing something. At one time we genned VS1 for a
148 and ran it on our 145 using the microcode assists.
The 168 had an ill-documented Load Microprogram instruction. Opcode
B9, IIRC.
It could load _something_ off its floppy, but AFAIK it was nothing like
the "lesser" S/370s loaded.

I tried to get more at http://www.spies.com/~aek/pdf/ibm/370/ but it's
timing out. Maybe the site has Rons problem?
--
Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
shupe7
2003-07-23 23:27:03 UTC
Permalink
They used to call that VLIC and HLIC, where LIC=Licensed Internal
Code. Nowadays they lump it all together and just call it SLIC, where
S=System.

I am not aware of a PoP-like book for OS/400. Perhaps inside of IBM.
There is, however, an excellent book that talks more at a conceptual
level, called "Inside the AS/400" by Dr. Frank Soltis, the chief IBM
scientist for the iSeries and its predecessors. Make sure you get the
2nd edition.

There is not much info about assembler on AS/400, at least outside of
IBM. The closest customers can get to assembler is a language called
MI (machine interface) which corresponds to the hardware abstraction
layer which is called TIMI, Technology-Independent Machine Interface.
MI looks like C and assembler combined. Very few people (including
me) program in MI and the documentation is very sparse. The only
documentation I have seen is in some of the older C and System C
manuals for OS/400 (like V2).

For doc, go to:

http://as400bks.rochester.ibm.com/pubs/html/as400/infocenter.htm

http://publib.boulder.ibm.com/pubs/html/as400/online/homeeng1.htm

There is an active technical mailing list, midrange-l-***@public.gmane.org
If you go out to www.midrange.com they also have searchable archives
that are full of info. They also run an MI list where you could
probably find people who know more.

Whoever said something about getting a public domain OS/400 - I
agree. Not in a million years.
Post by Terry Myhrer
The details I have are from my friend who worked at IBM Rochester on the
s/34, s/36 lines (predecessors of the s/38 and as/400) in the mid 80's. The
abstraction layer abstracted a machine that *at the time* did not exist. It
abstracted machine had something like 48 address bits and ran on real
hardware that had fewer address bits. There were two types of
microcode on
Post by Terry Myhrer
the machine called vertical microcode and horizontal microcode. One ran the
real hardware and the other ran the abstracted hardware, not sure which was
which though. That is why I say the OS knew the abstracted machine only.
They could rewrite the abstraction code to run on other hardware without
changing the OS.
-Terry
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
Free shipping on orders $50 or more to the US and Canada.
http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->
Continue reading on narkive:
Loading...