OS Design for Hercules

On Sun, Sep 16, 2007 at 02:33:23PM -0500, Tim Pinkawa wrote:
...

Shhh...don't tell anyone, but I'm writing an OS ;)

Post by Tim Pinkawa
Some of the discussions on the list over the past week have sparked
interest in trying to write something very basic that I can IPL
Hercules with.

What a coincidence ;)

Post by Tim Pinkawa
In the simplest terms, I believe I would need an assembler that
outputs plain object code, correct? Is there an easy (and free) way to
develop this on an x86 PC and test with Hercules or would I need to
use something like IFOX00 and transfer the object code back to my PC
to test?

Are you on a linux environment? If so, it's pretty easy.

Post by Tim Pinkawa
I've never really done anything like this before so I apologize for
the dumb questions. :)

Here's what I had few days ago (I posted it before):

http://josefsipek.net/ipl-fun.tar.gz

It IPLs from a deck of cards. I'm in the process of changing things to IPL
from a tape - punched cards are just too much pain ;)

Josef 'Jeff' Sipek.

--
I already backed up the [server] once, I can do it again.

Josef Sipek

2007-09-16 21:39:35 UTC

Post by Josef Sipek
...
Shhh...don't tell anyone, but I'm writing an OS ;)

Post by Tim Pinkawa
Some of the discussions on the list over the past week have sparked
interest in trying to write something very basic that I can IPL
Hercules with.

What a coincidence ;)

Are you on a linux environment? If so, it's pretty easy.

On linux:

1) grab the latest version of binutils [1]
2) untar
3)

$ mkdir binutils.build
$ cd binutils.build
$ ../binutils-2..../configure --prefix=$HOME/bin/s390x --target=s390x-linux
$ make
$ make install

Ok, you're done building! At this point, you want to add
$HOME/bin/s390x/bin/ to your path (temporarily or permanently).

This'll do it temporarily:
export PATH=$HOME/bin/s390x/bin/:$PATH

At this point, you can run:

$ s390x-linux-as -m31 -o outputfile input.asm

or

$ s390x-linux-as -m64 -o outputfile input.asm

Depending if you want z/Arch instructions :)

I wrote these steps from storage..err..memory ;) and therefore I may be off
with some of the details :)

Jeff.

[1] http://www.gnu.org/software/binutils/

--
Computer Science is no more about computers than astronomy is about
telescopes.
- Edsger Dijkstra

Ivan Warren

2007-09-16 21:52:00 UTC

Post by Josef Sipek
$ s390x-linux-as -m31 -o outputfile input.asm
or
$ s390x-linux-as -m64 -o outputfile input.asm
Depending if you want z/Arch instructions :)

The problem (kinda sorta) here is that

1) You are probably limited to S/390 instructions (how do you do this if
you want to do S/370 ?)
2) Does binutil's 'as' support control instructions ? (SSCH, LCTL, etc..)
3) The output file is going to be an XCOFF format file (or something
similar).. Hardly IPL'able ! (Maybe some some invocation of ld+objdump
along the way might help).

--Ivan

Josef Sipek

2007-09-16 23:19:07 UTC

Post by Josef Sipek
$ s390x-linux-as -m31 -o outputfile input.asm
or
$ s390x-linux-as -m64 -o outputfile input.asm
Depending if you want z/Arch instructions :)

The problem (kinda sorta) here is that
1) You are probably limited to S/390 instructions (how do you do this if
you want to do S/370 ?)

Couldn't you limit yourself to s/370 instruction set? ;)

Post by Ivan Warren
2) Does binutil's 'as' support control instructions ? (SSCH, LCTL, etc..)

Haven't tried it.

Post by Ivan Warren
3) The output file is going to be an XCOFF format file (or something
similar).. Hardly IPL'able ! (Maybe some some invocation of ld+objdump
along the way might help).

Right. I get elf out out of it, on which I do objcopy of the .text section.

Josef 'Jeff' Sipek.

--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)

Tim Pinkawa

2007-09-17 02:06:27 UTC

Thanks for the help, everyone! I've been going off Jeff's code, some
of Rafael's code, and the Principles of Operation trying to figure
this out. At the moment I'm using xdd to dump ASCII hex to binary
files.

I've been trying to get the three card loader working, but my IPL has
been failing.

HHCCP029E S/370 mode IPL failed: CSW status=0E40
Sense=80000000

Card 1:

PSW:
000C000080000018

This is based off Jeff's code with some minor modifications. Since I
have a program on card 2, I set the next instruction to 0x18 which
should be the first byte of the second card, assuming the PSW, CCW 1,
and CCW 2 occupy the first 24 (0x18) bytes.

CCW1:
0200001860000050

Read 80 bytes, store at location 0x18. This card has a small loop program.

CCW2:
0200006860000050

Read 80 bytes, store at location 0x68. This card is just a dummy card
filled with 0x40.

The rest of the first card is filled with 0x40.

At this point, I think I should have cards 2 and 3 (160 bytes of data)
in memory beginning at 0x18. The CPU should branch to 0x18 and start
executing my code and go into an infinite loop. This is merely what I
THINK should be happening, apparently it's not.

I have a feeling I'm not understanding some part of this with relation
to where stuff ends up in memory. Anyone have an idea what I'm trying
to get at? :)

Thanks,
Tim

Josef Sipek

2007-09-17 03:10:03 UTC

My reply didn't get back to me yet, and I want to go to bed, so here's the
followup....

One note about CCW command-chaining. Since you left it on in the second CCW,
the system was trying to interpret the data at 0x18 as a CCW. And it failed
to do so as instruction stream generally doesn't look like a CCW.

Josef 'Jeff' Sipek.

--
You measure democracy by the freedom it gives its dissidents, not the
freedom it gives its assimilated conformists.
- Abbie Hoffman

Tim Pinkawa

2007-09-17 04:03:37 UTC

Post by Josef Sipek
My reply didn't get back to me yet, and I want to go to bed, so here's the
followup....
One note about CCW command-chaining. Since you left it on in the second CCW,
the system was trying to interpret the data at 0x18 as a CCW. And it failed
to do so as instruction stream generally doesn't look like a CCW.
Josef 'Jeff' Sipek.

Thanks, Jeff. I got your short reply, changed the CCW to not chain,
and it IPLed. After a little tweaking, it looks like my code is
finally running. (woohoo!) With regard to the second reply, System/370
also uses 24-bit addressing like the 360. In this case I was looking
to point to 0x000018 and it seems to have worked.

Thanks again, getting it to IPL made my evening. :)

Some academic questions for the list readers:
I learned about two different PSW formats in an assembler programming
class, EC and BC. When using ASSIST we only dealt with BC and that's
about the extent of my PSW knowledge. What's the reasoning behind the
two PSW formats and how does it relate to the hardware? (is it only
available on newer hardware?) When I IPL my deck on Hercules emulating
System/370, which PSW format is being used?

And secondly, in my primitive example, I issue two CCWs to read all my
data, then start executing. In Jeff's code, he issues significantly
more CCWs to read a lot more data, but both occur before executing any
code. There's nothing stopping you from issuing a few CCWs, running
some code, then issuing more CCWs, is there? If not, is one better
than the other for any technical reasons?

Thanks!
Tim

Ivan Warren

2007-09-17 05:12:48 UTC

Post by Tim Pinkawa

I learned about two different PSW formats in an assembler programming
class, EC and BC. When using ASSIST we only dealt with BC and that's
about the extent of my PSW knowledge. What's the reasoning behind the
two PSW formats and how does it relate to the hardware? (is it only
available on newer hardware?) When I IPL my deck on Hercules emulating
System/370, which PSW format is being used?

Ok.. BC Mode PSW is for S/370 and S/370 *ONLY*.. BC mode is the
original S/360 format and one of the less used bit in the S/360 PSW
(EBCDIC/ASCII mode) was reused to allow for a new format for the PSW
that would allow extra information to be conveyed. Basically, a lot of
bits were wasted in the PSW, especially when stored during an
interruption (Old BC PSWs contain the ILC and the interruption codes -
and must be ignored in the actual PSW so that a LPSW can be issued on
the interrupt OLD PSW locations). When using an EC mode PSW, the
"interrupt" codes and ILCs are stored elsewhere in PSA, leaving more
space for extra information in the PSW.

EC Mode is new with S/370 and is available (afaik) on all S/370 systems.

EC Mode also changes the location and the meaning of some of the bits..
so it has some major differences !

BC mode is deprecated in ESA/390.

Note that in z/Architecture (note : this is not relevant to IPL since
you always IPL in ESA/390 mode even on a z/Architecture machine - you
switch to z/Architecture AFTER IPL) the PSW is always EC mode but bit 12
must be 0 (Bit 1 in a z/Arch PSW in invalid). Note that the LPSW
instruction (which is still valid in z/Architecture) will convert a
S/390 mode PSW to z/Architecture (so in that case, bit 12 must still be
1 - it will be turned to 0 by the LPSW instruction).. If the LPSWE
instruction is used, then bit 12 must be 0.

With EC mode comes a whole new set of features : DAT, PER, 31 bit
addressing (ESA/390 only), Address Space control - feature (if
implemented) that are not usable with a BC mode PSW.

As to the question, what PSW is used at IPL : Well, the PSW format is
the one you put in the first 8 bytes of the IPL record (Bit 12 = 1 : EC
mode, Bit 12 = 0 : BC Mode).

Since BC Mode is S/370 only, having Bit 12 set to 0 in ESA/390 will
result in a early specification exception, so if your IPL'able program
is intended to be usable both in S/370 and ESA/390 mode, then it should
be an EC mode PSW [1]. So IPLing an IPL device which specifies a BC mode
PSW in ESA/390 mode will simply lead to an IPL error.

Post by Tim Pinkawa
And secondly, in my primitive example, I issue two CCWs to read all my
data, then start executing. In Jeff's code, he issues significantly
more CCWs to read a lot more data, but both occur before executing any
code. There's nothing stopping you from issuing a few CCWs, running
some code, then issuing more CCWs, is there? If not, is one better
than the other for any technical reasons?

Well.. Simple :

If you *KNOW* for sure how many blocks you are going to need to read
from the IPL device in advance, then you can chain the CCWs off from the
IPL CCWs to some loaded by those CCWs. If you don't want to use low
pages (that is, you would like to your PSA safe) you can have the 2nd
CCW as a TIC.. (remember : In S/370 mode, location X'50' won't be
retaining your data.. it is the location of the interval timer !)..

So you could do :
Card 1 :
PSW = 00080000 00020XXX (20XXX being the address of the 1st instruction
to execute)
CCW1 = 02020000 60000050 : Load 1st card at location X'020000'
CCW2 = 08020000 60000000 : Execute next CCW at location X'020000'

Card 2 :
02020050 60000050 : Load next card at 020050
020200A0 60000050 : "" "" "" 0200A0
Etc..

However, if your 'IPL Loader' program is going to be reading a variable
amount of data (like until the end of the medium), you can't use that
technique to read the WHOLE thing... If the Original IPL CCW chain finds
an exception (like end of media), the IPL will not complete and the PSW
will not get loaded.. So in that case, the CCW chain must be able to
load just enough of your code and that code will have to handle the
loading of the rest of the data by itself by repeatedly issuing read
I/Os to the IPL device until the end condition is reached .. and then
execute some actual "workload" code if you like !

So you usually combine BOTH techniques.. One to read more than just 2
cards.. The second to have a programmable and controlled way for reading
the rest of your program into main storage.

--Ivan

[1] Now you may wonder.. But how does one determine the IPL device
address and the current architecture mode : Ok.. If you have a BC mode
PSW, the I/O address of the IPL device is at X'02' and X'03' (and it's
S/370 since BC mode PSWs don't IPL in ESA/390 mode).. If you use a EC
mode PSW, the IPL device address is at X'B8'-X'BB' (4 bytes).. If
operating in ESA/390 mode, then X'B9' will be non-zero (and X'B8'-X'BB'
contain a 'subsystem identification' aka subchannel number).. in S/370
mode, X'BA'-X'BB' contain the device number. In ESA/390 mode you can
issue a SSCH directly to this device without having to enable it first
(with MSCH) since it is already enabled by default.

Josef Sipek

2007-09-17 10:59:18 UTC

On Mon, Sep 17, 2007 at 07:12:48AM +0200, Ivan Warren wrote:
...

If you *KNOW* for sure how many blocks you are going to need to read
from the IPL device in advance, then you can chain the CCWs off from the
IPL CCWs to some loaded by those CCWs. If you don't want to use low
pages (that is, you would like to your PSA safe) you can have the 2nd
CCW as a TIC.. (remember : In S/370 mode, location X'50' won't be
retaining your data.. it is the location of the interval timer !)..
PSW = 00080000 00020XXX (20XXX being the address of the 1st instruction
to execute)
CCW1 = 02020000 60000050 : Load 1st card at location X'020000'
CCW2 = 08020000 60000000 : Execute next CCW at location X'020000'
02020050 60000050 : Load next card at 020050
020200A0 60000050 : "" "" "" 0200A0
Etc..
However, if your 'IPL Loader' program is going to be reading a variable
amount of data (like until the end of the medium), you can't use that
technique to read the WHOLE thing... If the Original IPL CCW chain finds
an exception (like end of media), the IPL will not complete and the PSW
will not get loaded.. So in that case, the CCW chain must be able to
load just enough of your code and that code will have to handle the
loading of the rest of the data by itself by repeatedly issuing read
I/Os to the IPL device until the end condition is reached .. and then
execute some actual "workload" code if you like !

That's what I changed my code to recently. This makes things a whole lot
easier... Now I have (on a tape):

1) PSW
2) 2xCCW that read a simple "loader"
3) simple loader that reads the kernel (I still need to figure out a way to
send the CCWs to read to the device)
4) kernel image

Post by Ivan Warren
So you usually combine BOTH techniques.. One to read more than just 2
cards.. The second to have a programmable and controlled way for reading
the rest of your program into main storage.

I have to mention that IPL from a tape is a whole lot easier because you can
specify length >80 bytes. It actually allowed me to load the ~200 byte
loader with just 2 CCWs (which are read by the IPL procedure).

Post by Ivan Warren
[1] Now you may wonder.. But how does one determine the IPL device
address and the current architecture mode : Ok.. If you have a BC mode
PSW, the I/O address of the IPL device is at X'02' and X'03' (and it's
S/370 since BC mode PSWs don't IPL in ESA/390 mode).. If you use a EC
mode PSW, the IPL device address is at X'B8'-X'BB' (4 bytes).. If
operating in ESA/390 mode, then X'B9' will be non-zero (and X'B8'-X'BB'
contain a 'subsystem identification' aka subchannel number).. in S/370
mode, X'BA'-X'BB' contain the device number. In ESA/390 mode you can
issue a SSCH directly to this device without having to enable it first
(with MSCH) since it is already enabled by default.

I've read about the subsystem id at the magic location, but I wasn't sure
what is needed to do IO. It seems like I need to set up an ORB, and any CCWs
I want to execute and then I issue a SSCH. Is that all?

Josef 'Jeff' Sipek.

--
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein

Ivan Warren

2007-09-17 13:36:10 UTC

Post by Josef Sipek
I've read about the subsystem id at the magic location, but I wasn't sure
what is needed to do IO. It seems like I need to set up an ORB, and any CCWs
I want to execute and then I issue a SSCH. Is that all?
Josef 'Jeff' Sipek.

Err.. Basically.. Yep.. That's it !

1) Load R1 with the Subsystem ID (L 1,X'B8' for the IPL dev)
2) Set your I/O interrupt vector (the I/O New PSW)
3) Build your CCWs
4) Setup your ORB (Set the CCW address, CCW Format, set the LPM to a non
0 value)
5) Issue SSCH
6) Load Control Register 6 with a non 0 value (it's the I/O interrupt
subclass mask)
7) Enable the PSW for I/O interrupts and go into wait state (you need
bits 6, 12 & 14 set to 1 in the PSW : X'020A000000000000' is a good example)
8) (I/O Interrupt fired) : Check B8-BB if this is your guy
9) If no, LPSW the old I/O PSW
10) Issue TSCH and check the SCSW (you need to wait for Device End).. If
CE Only : LPSW Old I/O PSW
11) If Unit check or Channel Status|=0 : An I/O error occurred and act
accordingly
12) If unit exception : End of media (for tape & cards) and act accordingly
13) If device end : I/O Completed.. Perform post I/O stuff (like
advancing your pointers) and back to step 3

Note that depending on conditions, implementation, environment and
timing, CE (Channel End) and DE (Device End) may be presented together
or separately.

If an error occured, remember you have no one to return to.. So it is
customary to load a disabled wait PSW (X'000A0000XXXXXXXX') which will
put the system in manual mode.. You can use the PSW Instruction Address
field to give a preliminary reason/cause for the error to the user/operator.

PS : Channel End indicates data transfer between storage and the control
unit has completed. Device End indicates the device has completed the
operation. No subsequent I/Os can be issued to a device until Device End
is received.

Don't enable interrupts your PSW for interrupts you don't have a handler
for.. Otherwise, your program will surely fail ! (For example don't
enable External interrupts unless you did set up a New External PSW -
there is a good chance one will fire almost immediately (CPU Timer is
initialized to 0 during Initial CPU Reset so it will turn negative very
quickly !).. You may also want to avoid enabling the Machine Check
interrupt mask at this point - especially in ESA/390 since Machine Check
interrupts may occur for events that are NOT really machine checks [1] !)

Of course you may need to do a bit of extra housekeeping (establishing
addressability, saving/restoring regs, etc..).. What I do is I usually
store at a known locations the address of where to go if I/O succeeds
and another address to go when the I/O fails, and finally the I/O
address expected for the interrupt. You also probably need to check for
Condition Codes after issuing the various I/O instructions.

This is of course very crude I/O.. But it works well for loading stuff
off a sequential IPL device. Another option is to just issue a loop of
TSCH instead of loading a wait PSW and having interrupts. But I always
thought it was inelegant to do it that way.

Once your "OS" is started, then of course you'll have to turn your I/O
interrupt handler to a FLIH/SLIH model and/or WAIT/POST/ECB style
mechanism so that your 'workload' programs can concurrently issue I/Os
to other devices.

In my experience, doing a simple card/tape IPL loader that's relatively
solid and works both in S/370 and ESA/390 is a 200-300 lines of
assembler thing. Doing a DASD IPL Loader is slightly more complicated.

Class dismissed ! (sorry guys for the long lecture..)

--Ivan

[1] The reason IBM elected to report Channel Report Words (i.e. I/O
reconfiguration) through a Machine Check [2] instead of an External
interrupt still eludes me !
[2] But hopefully, since CRW pending indications are not "repressible"
machine checks, your system won't enter a check stop if the interrupt is
made pending while your PSW is disabled for Machine Check interrupts.

Gerhard Postpischil

2007-09-17 14:38:23 UTC

Post by Ivan Warren
This is of course very crude I/O.. But it works well for loading stuff
off a sequential IPL device. Another option is to just issue a loop of
TSCH instead of loading a wait PSW and having interrupts. But I always
thought it was inelegant to do it that way.

A TSCH (or in BC mode, TIO) loop might work under Hercules, but
it fails in the real world, as I found out the hard way. For
example, if you are using a CRT (3270 type) console, or reading
from DASD, some other device on that controller may need
attention, and the controller won't accept or finish your
request until the other device is serviced. And the easiest way
of "servicing" the other device is to have interrupts enabled;
once the interrupt is taken, resume your own request. While it
may be possible to test every device on the controller for each
I/O, it's not really efficient.

Gerhard Postpischil
Bradford, VT

new e-mail address: gerhardp (at) charter (dot) net

Ivan Warren

2007-09-17 15:42:03 UTC

Post by Gerhard Postpischil
A TSCH (or in BC mode, TIO) loop might work under Hercules, but
it fails in the real world, as I found out the hard way. For
example, if you are using a CRT (3270 type) console, or reading
from DASD, some other device on that controller may need
attention, and the controller won't accept or finish your
request until the other device is serviced. And the easiest way
of "servicing" the other device is to have interrupts enabled;
once the interrupt is taken, resume your own request. While it
may be possible to test every device on the controller for each
I/O, it's not really efficient.
Gerhard Postpischil
Bradford, VT

Well.. (I'm assuming you mean "TIO in S/370 mode" since TIO works quite
well with a EC mode PSW in S/370 !), we were talking about an IPL loader
really, so what we are looking at is I/O to a single I/O device (there
should be no outstanding I/O for any other devices)..

In S/390 mode, no problem will occur since none of the devices (except
for the IPL device itself) are enabled - so they can't influence the system.

If you have a 3x74 type CU attached to the same channel as your IPL
device, having an attention pending for a device on that CU shouldn't be
a problem (unless you are careless enough to have attached that CU to a
selector channel !). I do agree that, if you attempt to issue console
messages during the IPL process, a TIO/TSCH loop might fail (simply
because a 3x74 CU is a shared control unit).

Finally, if you are IPLing from a DASD, there shouldn't be any
outstanding I/O requests on any other dasds (still talking about an IPL
loader !). If there were any outstanding requests PRIOR to IPL, they
will have been cleared by the I/O Subsystem reset operation that occurs
during the IPL process.

There could be ONE case where it wouldn't work : If during the IPL of a
3420 attached to a 3803 (you can't attach 3420s to anything else anyway)
and there are more than 1 devices attached to that 3803, then making one
of the other drives go from not-ready to ready (effectively making an
unsolicited DE pending on the channel by that CU) could be a problem..
3480 & beyond do not have this problem because the 3480 CU is unshared.

Now.. I'm just being my pedantic nitpicking self.. Because I agree it's
better to enable the PSW for I/O and wait for an interrupt ANYWAY !

PS : And you are right too in stating that on hercules, it's never a
problem since all CUs are unshared and all channels act as byte
multiplexors never operating in burst mode (or simply that each device
has a dedicated CU and a dedicated Channel) - so hercules never returns
a CU Busy condition and channels are never busy (except when the device
itself is busy or status pending).

DMKBSL (and later HCPBSL) the VM "3CARD Loader" (a misnomer for HCPBSL
since it is a 5 card loader !) itself doesn't do WAIT/INTERRUPT.. it
goes into a TIO/TSCH loop (this would tend to mean that on "real"
hardware, it's still a valid option - since those components are IBM
supported (well.. HCPBSL is anyway !))

--Ivan

Gerhard Postpischil

2007-09-17 18:49:32 UTC

Post by Ivan Warren
Well.. (I'm assuming you mean "TIO in S/370 mode" since TIO works quite
well with a EC mode PSW in S/370 !), we were talking about an IPL loader
really, so what we are looking at is I/O to a single I/O device (there
should be no outstanding I/O for any other devices)..

I phrased it as I did because I never used TIO in EC mode, not
because it wasn't possible. As to the I/O, I was addressing
subsequent I/O requests after the IPL I/O completes.

My experience comes from shops where the processors were on one
floor, tapes and unit record equipment on another, and displays
dispersed throughout the building. As such I ran into all sort
of interesting problems, e.g., an 08,1B error (loss of display
space integrity or some such) in the network solicitor because
an operator puts her handbag on the keyboard before logging in
and disables the terminal. <g>

Gerhard Postpischil
Bradford, VT

new e-mail address: gerhardp (at) charter (dot) net

Harold Grovesteen

2007-09-18 10:59:29 UTC

Ivan, is it just personal preference, or is there a reason 6) is
following 5)? BTW, great explanations in your emails. For those of us
interested in these topics they are absolutely not too pedantic. They
add to our collective understanding.

Thanks,
Harold Grovesteen

Post by Josef Sipek
I've read about the subsystem id at the magic location, but I wasn't

sure

Post by Josef Sipek
what is needed to do IO. It seems like I need to set up an ORB, and

any CCWs

Post by Josef Sipek
I want to execute and then I issue a SSCH. Is that all?
Josef 'Jeff' Sipek.

Err.. Basically.. Yep.. That's it !
1) Load R1 with the Subsystem ID (L 1,X'B8' for the IPL dev)
2) Set your I/O interrupt vector (the I/O New PSW)
3) Build your CCWs
4) Setup your ORB (Set the CCW address, CCW Format, set the LPM to a non
0 value)
5) Issue SSCH
6) Load Control Register 6 with a non 0 value (it's the I/O interrupt
subclass mask)
7) Enable the PSW for I/O interrupts and go into wait state (you need
bits 6, 12 & 14 set to 1 in the PSW : X'020A000000000000' is a good example)
8) (I/O Interrupt fired) : Check B8-BB if this is your guy
9) If no, LPSW the old I/O PSW
10) Issue TSCH and check the SCSW (you need to wait for Device End).. If
CE Only : LPSW Old I/O PSW
11) If Unit check or Channel Status|=0 : An I/O error occurred and act
accordingly
12) If unit exception : End of media (for tape & cards) and act accordingly
13) If device end : I/O Completed.. Perform post I/O stuff (like
advancing your pointers) and back to step 3
Note that depending on conditions, implementation, environment and
timing, CE (Channel End) and DE (Device End) may be presented together
or separately.
If an error occured, remember you have no one to return to.. So it is
customary to load a disabled wait PSW (X'000A0000XXXXXXXX') which will
put the system in manual mode.. You can use the PSW Instruction Address
field to give a preliminary reason/cause for the error to the
user/operator.
PS : Channel End indicates data transfer between storage and the control
unit has completed. Device End indicates the device has completed the
operation. No subsequent I/Os can be issued to a device until Device End
is received.
Don't enable interrupts your PSW for interrupts you don't have a handler
for.. Otherwise, your program will surely fail ! (For example don't
enable External interrupts unless you did set up a New External PSW -
there is a good chance one will fire almost immediately (CPU Timer is
initialized to 0 during Initial CPU Reset so it will turn negative very
quickly !).. You may also want to avoid enabling the Machine Check
interrupt mask at this point - especially in ESA/390 since Machine Check
interrupts may occur for events that are NOT really machine checks [1] !)
Of course you may need to do a bit of extra housekeeping (establishing
addressability, saving/restoring regs, etc..).. What I do is I usually
store at a known locations the address of where to go if I/O succeeds
and another address to go when the I/O fails, and finally the I/O
address expected for the interrupt. You also probably need to check for
Condition Codes after issuing the various I/O instructions.
This is of course very crude I/O.. But it works well for loading stuff
off a sequential IPL device. Another option is to just issue a loop of
TSCH instead of loading a wait PSW and having interrupts. But I always
thought it was inelegant to do it that way.
Once your "OS" is started, then of course you'll have to turn your I/O
interrupt handler to a FLIH/SLIH model and/or WAIT/POST/ECB style
mechanism so that your 'workload' programs can concurrently issue I/Os
to other devices.
In my experience, doing a simple card/tape IPL loader that's relatively
solid and works both in S/370 and ESA/390 is a 200-300 lines of
assembler thing. Doing a DASD IPL Loader is slightly more complicated.
Class dismissed ! (sorry guys for the long lecture..)
--Ivan
[1] The reason IBM elected to report Channel Report Words (i.e. I/O
reconfiguration) through a Machine Check [2] instead of an External
interrupt still eludes me !
[2] But hopefully, since CRW pending indications are not "repressible"
machine checks, your system won't enter a check stop if the interrupt is
made pending while your PSW is disabled for Machine Check interrupts.

Rob van der Heij

2007-09-18 11:10:03 UTC

Post by Ivan Warren
Class dismissed ! (sorry guys for the long lecture..)

As for IPL from DASD, one thing that troubled me when I went from
virtual machine to the bare metal was that the I/O subsystem insisted
to present me an interrupt for each channel to the disk before I could
issue subsequent SSCH against it...
My Linux bootstrap loader mostly did the same:
http://vm.marist.edu/~rvdheij/linuxipl.txt

Rob

Josef Sipek

2007-09-22 17:44:32 UTC

Err.. Basically.. Yep.. That's it !

I finally got enough time to dive into this. And it almost works :)

Everything works, the io completes (with DE), but...

Post by Ivan Warren
8) (I/O Interrupt fired) : Check B8-BB if this is your guy
9) If no, LPSW the old I/O PSW
10) Issue TSCH and check the SCSW (you need to wait for Device End).. If
CE Only : LPSW Old I/O PSW
11) If Unit check or Channel Status|=0 : An I/O error occurred and act
accordingly
12) If unit exception : End of media (for tape & cards) and act accordingly
13) If device end : I/O Completed.. Perform post I/O stuff (like
advancing your pointers) and back to step 3

Whenever I return from the interrupt handler (via LPSWE of the ols IO PSW),
it loads the PSW that had the wait state bit set. So, the IO gets done, but
the cpu goes back to waiting instead of resuming execution.

Any hints how to break out of this nasty loop? A simple hack would be to
tweak the old PSW to not have the wait bit set. :)

Josef 'Jeff' Sipek.

--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan

Mike Schwab

2007-09-17 04:29:11 UTC

I think BC was the 24bit 360/370 mode, EC is the 31bit XA/ESA mode,
and there is another format for 64bit z mode.

The amount of CCWs depends on how big a program you want to load
before you start running the program. Once your program starts
running, your design will dictate when you need to start CCWS.

On 9/16/07, Tim Pinkawa <timpinkawa-***@public.gmane.org> wrote:
<deleted>

Post by Tim Pinkawa
I learned about two different PSW formats in an assembler programming
class, EC and BC. When using ASSIST we only dealt with BC and that's
about the extent of my PSW knowledge. What's the reasoning behind the
two PSW formats and how does it relate to the hardware? (is it only
available on newer hardware?) When I IPL my deck on Hercules emulating
System/370, which PSW format is being used?
And secondly, in my primitive example, I issue two CCWs to read all my
data, then start executing. In Jeff's code, he issues significantly
more CCWs to read a lot more data, but both occur before executing any
code. There's nothing stopping you from issuing a few CCWs, running
some code, then issuing more CCWs, is there? If not, is one better
than the other for any technical reasons?
Thanks!
Tim

--
Mike A Schwab, Springfield IL USA http://geocities.com/maschwab/ for
software links

Josef Sipek

2007-09-17 03:04:57 UTC

Post by Tim Pinkawa
Thanks for the help, everyone! I've been going off Jeff's code, some
of Rafael's code, and the Principles of Operation trying to figure
this out. At the moment I'm using xdd to dump ASCII hex to binary
files.
I've been trying to get the three card loader working, but my IPL has
been failing.
HHCCP029E S/370 mode IPL failed: CSW status=0E40
Sense=80000000

Hrm. I haven't tried IPL on non zarch.

Post by Tim Pinkawa
000C000080000018
This is based off Jeff's code with some minor modifications. Since I
have a program on card 2, I set the next instruction to 0x18 which
should be the first byte of the second card, assuming the PSW, CCW 1,
and CCW 2 occupy the first 24 (0x18) bytes.

The 80000018 is address 0x18, with 31-bit addressing. The 360 was the one
with only 24-bit addressing, right? That should work.

Post by Tim Pinkawa
0200001860000050
Read 80 bytes, store at location 0x18. This card has a small loop program.
0200006860000050
Read 80 bytes, store at location 0x68. This card is just a dummy card
filled with 0x40.

Not sure which bit this is, but make sure that you don't have
command-chaning on in the second CCW. Yeah..try changing it to:

0200006820000050
^

Post by Tim Pinkawa
The rest of the first card is filled with 0x40.

It hit me some time after I sent the emails, that 0x50 bytes == 80 bytes ==
1 card. It seems like reading 0x18 bytes means reading a full card and
discarding bytes 0x18..0x50.

Post by Tim Pinkawa
At this point, I think I should have cards 2 and 3 (160 bytes of data)
in memory beginning at 0x18. The CPU should branch to 0x18 and start
executing my code and go into an infinite loop. This is merely what I
THINK should be happening, apparently it's not.

I'd suggest you turn on CCW tracing for your card reader (t+c). This'll give
you more info about which CCW is causing problems - if any.

Post by Tim Pinkawa
I have a feeling I'm not understanding some part of this with relation
to where stuff ends up in memory. Anyone have an idea what I'm trying
to get at? :)

I spend a few days on some of these things, and my head hurts - but it's
really simple once you figure it out!

Fun, isn't it? :)

Jeff.

--
Real Programmers consider "what you see is what you get" to be just as bad a
concept in Text Editors as it is in women. No, the Real Programmer wants a
"you asked for it, you got it" text editor -- complicated, cryptic,
powerful, unforgiving, dangerous.

royfusa1946

2007-09-17 04:49:36 UTC

Hrm. I haven't tried IPL on non zarch.

The 80000018 is address 0x18, with 31-bit addressing. The 360 was the one
with only 24-bit addressing, right? That should work.

Not sure which bit this is, but make sure that you don't have
0200006820000050
^

Post by Tim Pinkawa
The rest of the first card is filled with 0x40.

It hit me some time after I sent the emails, that 0x50 bytes == 80 bytes ==
1 card. It seems like reading 0x18 bytes means reading a full card and
discarding bytes 0x18..0x50.

I'd suggest you turn on CCW tracing for your card reader (t+c). This'll give
you more info about which CCW is causing problems - if any.

Post by Tim Pinkawa
I have a feeling I'm not understanding some part of this with relation
to where stuff ends up in memory. Anyone have an idea what I'm trying
to get at? :)

I spend a few days on some of these things, and my head hurts - but it's
really simple once you figure it out!
Fun, isn't it? :)
Jeff.
--
Real Programmers consider "what you see is what you get" to be just as bad a
concept in Text Editors as it is in women. No, the Real Programmer wants a
"you asked for it, you got it" text editor -- complicated, cryptic,
powerful, unforgiving, dangerous.

The SYS1.SAMPLIB from your OS/360 system should contain a copy of
IBCDASDI and ADRDMPRS. (They might be in SYS1.ASAMPLIB instead.) They
are card images ready to IPL. I think both of them start with a 3 card
loader. One of them loads TXT cards as written to SYSPUNCH by the
assembler. Again, as I recall, the other one is quite different. They
work in 370 mode. It's pretty easy to figure out what's happening in
such a short program and the one that loads TXT cards can be used for
anything so long as your program loads to the correct location in
memory. I believe the same standalone programs were available through
MVS 3.8 also. They use SIO and TIO so they won't work in ESA mode.

Roy Frederick

Ivan Warren

2007-09-17 02:11:57 UTC

Post by Tim Pinkawa
0200006860000050

Your 2nd CCW has command chaining set..

If whatever is on the 2nd card isn't a CCW, you're in trouble !

I'd suggest (based on your data :)

000C0000800000180200001820000050... (the rest is irrelevant)
and just 1 card after that (this IPL card will read just 1 extra card)..

--Ivan

Tony Harminc

2007-09-17 18:00:39 UTC

I've been trying to get the three card loader working, but my IPL has been failing.

I gather you've got this resolved, but just a suggestion...

Stay well away from low core except for those things that have to be
there. You can directly address higher address in CCWs, and you can
set up a base register in your code right at the start using BALR or
the like (you don't have to save your caller's registers because you
weren't exactly called...). So load your code out of the way of
nasties like the interval timer and the various old PSWs and related
baggage that may "happen" to you if you are down in the bottom 1K or
so.

Tony H.

Harold Grovesteen

2007-09-18 10:53:37 UTC

The area from 0x200-0x11FF (4K) is available for programming.
0x1200-0x13FF is the z/Architecture Store-Status/Machine-Check save
area. You are safe to use from 0x1400 and above. Prefixing will drive
its own set of issues, but these values are safe in the context of a
single running CPU as is the case after IPL.

Harold Grovesteen

Post by Tim Pinkawa
I've been trying to get the three card loader working, but my IPL

has been failing.
I gather you've got this resolved, but just a suggestion...
Stay well away from low core except for those things that have to be
there. You can directly address higher address in CCWs, and you can
set up a base register in your code right at the start using BALR or
the like (you don't have to save your caller's registers because you
weren't exactly called...). So load your code out of the way of
nasties like the interval timer and the various old PSWs and related
baggage that may "happen" to you if you are down in the bottom 1K or
so.
Tony H.

Josef Sipek

2007-09-18 13:20:40 UTC

Post by Harold Grovesteen
The area from 0x200-0x11FF (4K) is available for programming.

That's just far too painful. In my design, I decided to have the 0-8K area
per-cpu via prefixing (I haven't looked into it more as I want to have the
thing running on one cpu first).

Post by Harold Grovesteen
0x1200-0x13FF is the z/Architecture Store-Status/Machine-Check save
area. You are safe to use from 0x1400 and above. Prefixing will drive
its own set of issues,

Oh? Like what?

Josef 'Jeff' Sipek.

Ivan Warren

2007-09-18 18:00:25 UTC

Post by Josef Sipek
That's just far too painful. In my design, I decided to have the 0-8K area
per-cpu via prefixing (I haven't looked into it more as I want to have the
thing running on one cpu first).

Err.. I fail to see the rationale behind using the prefix register
here.. Basically, all it does is swap a 4K page real addresses/absolute
address view for that CPU. I think it just makes everything more
complicated.

(for those who wonder : a "real address" is what is seen by a CPU with
DAT off, an "absolute" address is the actual "physical" sequence of
storage locations - and absolute addresses also work for channel access,
IPL & Store Status manual operations. Prefixing works like this : When
prefix=0, then real=absolute.. When prefix=X then a "L 1,Y (with
0<=Y<4096) will load register 1 with the word at absolute address X+Y
and L 1,Y (with X<=Y<X+4096) will load 1 with the word at absolute
location Y&0xfff.. For example with PFX=0x4000 then L 1,0 will load the
value at absolute 0x4000 and L 1,32(2) (assuming 2 contains X'4000')
will return the word at absolute address X'20'. Now.. The *REASON* for
prefixing is to allow for multiprocessoring - each CPU has a different
prefix so that each CPU can have its own set of interrupt vectors (but
not only that) since locations such as OLD/NEW PSWs are in REAL
addresses).. When running z/Arch, replace all the 4096 above with 8192.

Also, I can't see where the problem or difficulty lies jumping over to
some safe area, leaving page 0 alone.. It's just a matter of setting the
right address in the IPL CCWs and PSW (and.. If you have to issue more
than 2 CCWs, doing a TIC isn't THAT complicated.. Command Code X'08',
address is the address of the next CCW to execute and length should/must
be 0)..

I mean... You want an IPL program that runs outside PSA :

Card 1
00080000000400000204000020000050.. (Fill with anything for 80 bytes)
Card 2
05C017114610C0048200C00E00000000000A000001234567 .. Fill with anything
for 80 bytes

Put this in a file with an hex editor and IPL it in a card reader.. GPR
1 should countdown for some time (~30 seconds to 1 minute on a P4 3Ghz
I'd say) and the final PSW should be 000A000001234567, GPR 1 should be 0
and GPR12 should be X'00040002'.. The PSW being an EC mode PSW, this
should IPL regardless of the architecture (Note that this is handwritten
machine code - no assembler involved so result is not guaranteed!) but
This should mean :

Card 1
DC X'00080000',X'00040000'
CCW X'02',X'40000',X'20',80
Card 2
BALR 12,0
USING *,12
XR 1,1
BCT 1,*
LPSW A
DS 0D
A DC X'000A0000',X'01234567'
LTORG
END

Ah.. and .. Prefix register is only available on implementations
supporting multiprocessoring (which is an optional feature in S/370)..
For example, a VM/370 virtual machine won't have one nor will S/370
models 135, 138, 148 (168 may have been AP capable) and 4321, 4331,
4341, 4361, 9370 (I'm not sure, but I think UP models of MP capable CPUs
or line of CPUs had the control instructions implemented). in XA &
beyond, I believe the MP instructions were standard issue even on non MP
capable systems.

Finally, why 8K ? the prefix only addresses a 4K page in S/370 and S/390
(it's 8K in z/Arch but only after you've done the architecture switch SIGP).

--Ivan

Andre Rosenthal

2007-09-18 18:38:50 UTC

Yall

I just added myself to this list so pardon if this has been already asked. I spent many moons under the TPF OS and am wondering if anyone has ever heard of a port onto Hercules.

Best regards, Andre Rosenthal

[Non-text portions of this message have been removed]

Josef Sipek

2007-09-18 18:41:20 UTC

Oh, right, only one page. Wouldn't you want each CPU to have it's own PSA?
But PSA is in the second page. Bah, what's prefixing good for again?

...

Post by Ivan Warren
Now.. The *REASON* for prefixing is to allow for multiprocessoring - each
CPU has a different prefix so that each CPU can have its own set of
interrupt vectors (but not only that) since locations such as OLD/NEW PSWs
are in REAL addresses).. When running z/Arch, replace all the 4096 above
with 8192.

Ah :) I haven't even read about interrupts.

Post by Ivan Warren
Also, I can't see where the problem or difficulty lies jumping over to
some safe area, leaving page 0 alone.. It's just a matter of setting the
right address in the IPL CCWs and PSW (and.. If you have to issue more
than 2 CCWs, doing a TIC isn't THAT complicated.. Command Code X'08',
address is the address of the next CCW to execute and length should/must
be 0)..

Right. It's pretty easy.

...

Post by Ivan Warren
Put this in a file with an hex editor and IPL it in a card reader.. GPR
1 should countdown for some time (~30 seconds to 1 minute on a P4 3Ghz
I'd say) and the final PSW should be 000A000001234567, GPR 1 should be 0
and GPR12 should be X'00040002'.. The PSW being an EC mode PSW, this
should IPL regardless of the architecture (Note that this is handwritten
machine code - no assembler involved so result is not guaranteed!) but
Card 1
DC X'00080000',X'00040000'
CCW X'02',X'40000',X'20',80

Wow, is CCW a magic keyword in VM/MVS assembler?

...

Post by Ivan Warren
Finally, why 8K ? the prefix only addresses a 4K page in S/370 and S/390
(it's 8K in z/Arch but only after you've done the architecture switch SIGP).

Is the 8K the page size or the size affected by prefixing?

Josef 'Jeff' Sipek.

--
NT is to UNIX what a doughnut is to a particle accelerator.

Ivan Warren

2007-09-18 19:41:56 UTC

Post by Josef Sipek
Oh, right, only one page. Wouldn't you want each CPU to have it's own PSA?
But PSA is in the second page. Bah, what's prefixing good for again?

I maybe wrongfully be defining PSA as the area of storage that's for
machine usage which is actually only the 1st 512 bytes in ESA/390. For
a CPU, that's real addresses 0-511.. For the system and channels, that's
absolute addresses 0-511.. The rest (512-4095) can be used as CPU
private work storage. Prefixing *IS* the mean for each CPUs in a MP
setup to have it's own private area starting at real address 0.

You may want to look at "Assigned Storage Locations' in your favorite Poo.

Post by Tim Pinkawa
Card 1
DC X'00080000',X'00040000'
CCW X'02',X'40000',X'20',80

Wow, is CCW a magic keyword in VM/MVS assembler?

Yeah.. (well.. Not *magic* :P ) BAL assembler defines a handy CCW pseudo
opcode that formats a CCW for you.. I think HASM & beyond also have CCW0
& CCW1 for format 0 & format 1 CCWs (IPL CCWs are always format 0)

Post by Josef Sipek
...

Post by Tim Pinkawa
Finally, why 8K ? the prefix only addresses a 4K page in S/370 and S/390
(it's 8K in z/Arch but only after you've done the architecture switch SIGP).

Is the 8K the page size or the size affected by prefixing?

Only the size affected by prefixing. 4K for S/370 & S/390, 8K for
z/Arch.. a "Page" is indeed a misnomer here.. A "Page" can be viewed as
the span of storage with the smallest granularity for address
translation (so it depends on DAT format but can be 2K(S/370) or
4K(All)) *OR* it can also define the storage key granularity (2K or 4K..
2K is S/370 only and is implementation defined since it only exists when
the Extended Storage Key feature is not implemented for the architecture
- and S/390 + z/Arch always have Extended Storage Key - so Always 4K
storage keys). A page may also indicate the maximum reach of the
displacement field in an instruction (4K) (not taking into account
z/Arch long displacement facility).

Harold Grovesteen

2007-09-19 10:38:44 UTC

When you assign multiple prefix areas to different CPU's, the prefix
area of one CPU is physically available to the other CPU's, just at
their normal real==absolute addresses. So the program running needs to
understand where all of the prefix areas are physically located and that
when it mucks around with its own swapped region it is really mucking
around with absolute 0-4095 (or 0-8191) as seen by the other CPU's in
some other spot. In other words, what is safe for your program (from
the perspective of the assigned storage locations) is really a whole lot
more complicated when prefixing enters the picture.

By the way, read the sections on interrupts. You need to understand
interrupts to do any of this work.

Harold Grovesteen

Post by Harold Grovesteen
The area from 0x200-0x11FF (4K) is available for programming.

That's just far too painful. In my design, I decided to have the 0-8K area
per-cpu via prefixing (I haven't looked into it more as I want to have the
thing running on one cpu first).

Post by Harold Grovesteen
0x1200-0x13FF is the z/Architecture Store-Status/Machine-Check save
area. You are safe to use from 0x1400 and above. Prefixing will drive
its own set of issues,

Oh? Like what?
Josef 'Jeff' Sipek.
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan

Josef Sipek

2007-09-19 17:49:00 UTC

Post by Harold Grovesteen
When you assign multiple prefix areas to different CPU's, the prefix
area of one CPU is physically available to the other CPU's, just at
their normal real==absolute addresses. So the program running needs to
understand where all of the prefix areas are physically located and that
when it mucks around with its own swapped region it is really mucking
around with absolute 0-4095 (or 0-8191) as seen by the other CPU's in
some other spot. In other words, what is safe for your program (from
the perspective of the assigned storage locations) is really a whole lot
more complicated when prefixing enters the picture.

It sounds like if you want to load-balance interrupt handlers, you have to
use prefixing.

Post by Harold Grovesteen
By the way, read the sections on interrupts. You need to understand
interrupts to do any of this work.

I know. And I know interrupts will not be fun to deal with, but it needs to
be done.

Josef 'Jeff' Sipek.

--
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein

Ivan Warren

2007-09-19 19:24:50 UTC

Post by Josef Sipek
It sounds like if you want to load-balance interrupt handlers, you have to
use prefixing.

Nah nah nah...

PREFIX is irrelevant when only 1 CPU is active and MUST be used in a
multi CPU environment.

Ok.. Here is a crash course on interrupts..

How interrupts are distributed among CPUs is not controlled by prefixing
but by the architecture and by CPU interrupt masking & subclass masking.

Interrupts come in 2 flavors : Floating and non-floating. Floating
interrupts are interrupts that can trigger a PSW switch on any
operational CPU in a configuration. Notably, I/O interrupts are floating
(and only in S/390 & z/Arch).. Some Machine Checks may also be floating
(External Damage may be floating).

There are 6 classes of interrupts :
- Program Interrupt : They relate to an exception or condition
encountered during execution of an instruction. They may be related to
the operation code, operation parameters, address translation, tracing,
etc..
- SVC Interrupt : Every time the SVC instruction is executed
- I/O : Pertains the a device meaning to present some status to the CPU
- which may be solicited - the result of an ongoing I/O operation, or
unsolicited (Attention or not-ready to ready state switch)
- External : Various non-damage conditions : Timing, inter-cpu
communication, Service Processor communication, the 'External' operator
button, etc.. (there are more)
- Machine check : Various possibly damage conditions : System damage,
instruction damage, External Damage (I/O damage goes there IIRC) and
some non damage conditions such as I/O reconfiguration.. Machine check
may also be presented to indicate an error occurred but was fixed
internally like when a single bit error in storage was fixed by ECC.
- Restart : Operator initiated non maskable interrupt (depending on the
Operating System, this may be used to trigger a dump when the system has
entered a disabled loop). Note that the RESTART new PSW is at the same
location as the IPL PSW - which means that on simple IPLable programs,
RESTART will actually restart the program from the beginning !

Now.. Interrupts are not THAT complicated. Some interrupts are
synchronous (and deal with the execution of instructions). These are the
Program and SVC interrupts. Others are asynchronous (in that they can
occur when executing instructions or when being in a wait state but are
not usually the direct consequence of the execution of a particular
instruction) : I/O, EXT and RESTART. Machine check can be both
(depending on the reason for the machine check).

Except for the RESTART Interrupt, asynchronous Interrupts may be masked.
The primary mask is in the PSW (and is called the System Mask which can
be manipulated with SSM, STNSM, STOSM and of course LPSW).. There are
also subclass masks that can more finely mask interrupts (CR0 contain
EXT related subclass masks while CR2 (in S/370) and CR6 (in S/390 &
z/Arch) contain I/O subclass masks. The primary reason why the control
register was changed is probably related to the fact that the masking
mechanism was changed from Channel number based to a subchannel
customizable parameter).

The interrupt process itself is fairly simple : The current PSW is
stored at the 'OLD PSW' location and the 'NEW PSW' is loaded in the
actual PSW. Those fields are located in the famous low storage area we
have been discussing. Each interrupt class has its own OLD/NEW PSW
locations and are defined by the architecture. Since z/Architecture has
128 bit PSWs (not to mention a fairly different format), they had to be
relocated in order not to conflict with previously existing locations.

Some interrupts are cleared simply by them firing : I/O, Machine Check,
Program, SVC, Restart. For External, it depends on the cause but
basically Clock Comparator and CPU Timer interrupts are NOT cleared by
taking the interrupt (they are only cleared when the respective reason
for the interrupt is cleared). For non self clearing interrupts - having
a NEW PSW that is enabled for the interrupt class will lead to an
interrupt loop.

The location of the interrupt code (the *reason* for the interrupt or
the I/O device causing the interrupt) is located, again, in the low
storage area. The location is dependent on both the architecture and the
PSW format used (BC or EC). This code allows the interrupt handler to
determine what action to take. This really IS the main reason that each
CPU needs its own low storage area and the primary reason for the Prefix
register & mechanism.

I/O interrupts for a specific device can also sometimes merge - and the
status bits in the CSW/SCSW will have been OR'd (there are some merging
conditions though.. they will not ALWAYS merge).

Interrupts also have defined priorities, so if more than 1 interrupt
class is pending, the order in which they will be presented to the CPU
is determined.

Although Machine Check interrupts can be masked, if the machine check is
a repressible machine check (like instruction damage or system damage)
then the system will enter a check stop state because it is no longer
safe to continue operations. This may also occur if a machine check
interrupt occurs while there is already a machine check interrupt being
processed (even with the machine check mask enabled).

If you look at it, interrupts on S/370, S/390 and z/Arch are a whole lot
simpler than it is on x86 for example (there is no need for internal
knowledge of PICs & bus interrupt mechanism) and the interrupt process
is perfectly well defined by the architecture itself - that is - it is
not implementation dependent.

Finally, here is a (not even tried) small sample program that can be
IPLed (it's 3CARD LOADER Compatible since there are no ADCONs) that will
loop for 1 second until the CPU Timer interrupt occurs and then loads a
disabled wait PSW. There may be some errors since I haven't even tried
to compile it - and it may not even work - but if it doesn't it
shouldn't be hard to fix ! It should give you an idea of how simple
handling interrupts is.

START1 CSECT *
ORG *+X'20000'
START DS 0H
BALR 12,0 * ESTABLISH ADDRESSABILITY
USING *,12
MVC EXTNPSW(8),MYEXTN * SET NEW EXT PSW
LA 1,EXTH * GET HANDLER ADDRESS
ST 1,EXTNPSW+4 * SAVE IN NEW PSW
STCTL 0,0,WORK1 * GET CR0
OI WORK1+2,X'04' * ENABLE CPU TIMER SUBCLASS
NI WORK1+2,X'7F' * DISABLE CLOCK COMP
LCTL 0,0,WORK1 * RELOAD MODIFIED CR0
SCPT SEC1SEC * SET THE CPU TIMER VALUE (~1SEC)
LA 1,CONT * LOAD LOOP ADDR
ST 1,CONTPSW+4 * SAVE IN PSW
LPSW CONTPSW * THAT WE LOAD NOW
CONT DS 0H
TM FIRED,X'80' * HAS THE CPU TIMER FIRE ?
BNZ CONT * NOPE.. LOOP SOME MORE
LPSW DISAWAIT * YES.. EOJ
*
* EXTERNAL INTERRUPT HANDLER
* (NOTE WE ASSUME WE HAVE ADDRESSABILITY)
*
EXTH DS 0H
CLC EXTINT(2),=XL2'1005' * CPT INT ?
BNZ NOTCPT * NOPE
OI FIRED,X'80' * INDICATE CPT FIRED
NOTCPT DS 0H
LPSW EXTOPSW * BACK WHENCE WE CAME FROM
*
* END OF EXT HANDLER
*
DS 0D
SEC1SEC DC AL4(1),AL4(0) *APPROX. 1 SEC
MYEXTN DC X'00080000',AL4(*-*)
CONTPSW DC X'02080000',AL4(*-*)
DISAPSW DC X'000A0000',AL4(0)
*
WORK1 DS F
FIRED DC X'00'
* SOME PSA LOCATIONS
EXTNPSW EQU X'58'
EXTOPSW EQU X'18'
EXTINT EQU X'86'
LTORG
END START

--Ivan

Tony Harminc

2007-09-19 22:46:57 UTC

Post by Ivan Warren
PREFIX is irrelevant when only 1 CPU is active and MUST be used in a
multi CPU environment.

Actually there is a very cute use of prefixing on a single CPU, but
it's not what it was intended for.

Post by Ivan Warren
Ok.. Here is a crash course on interrupts..

Good crash (uh, course). :-)

Post by Ivan Warren
Now.. Interrupts are not THAT complicated. Some interrupts are
synchronous (and deal with the execution of instructions). These are the
Program and SVC interrupts. Others are asynchronous (in that they can
occur when executing instructions or when being in a wait state but are
not usually the direct consequence of the execution of a particular
instruction) : I/O, EXT and RESTART. Machine check can be both
(depending on the reason for the machine check).

Many architectures distinguish between these by calling the
instruction-related interrupts "traps", and only the externally
generated ones "interrupts". But don't try using this terminology
here; it may be confused with something else.

It's also worth stating a golden principle of the architecture that
says that a machine check (either interrupt or red light kind of
thing) cannot be caused by programming. No matter how badly you screw
up your code (even privileged code), you cannot make the machine
malfunction, or indicate that it has malfunctioned. This too is very
different from many other architectures. Some RISC machines can even
get red lights from a bad compiler-generated code sequence. (Well, of
course one can argue that this isn't strictly true, but it is true if
you stay away from the Diagnose instruction, and just possibly from
certain undocumented SIGP operations. And some early /370 models had
undocumented op codes that could get dangerous, e.g. the /168's Load
Micro Program (LMP) instruction.)

Perhaps even more generally, one must learn to read the PofO. It has
special terms that are defined at the front, and understanding them
makes life easier. For example, "undefined" is used very precisely to
describe the results of executing a certain instruction under certain
circumstances; it is not a vague "we don't know what will happen".

As Roger just said, the interrupt system, and indeed many other parts
of the architecture, are both elegant and programmer friendly. There
are warts that have sprouted here and there (and one or two congenital
ones), and it is often argued that S/360 is cleaner than S370, and so
on, but even z/Arch is pretty good.

Tony H.

Josef Sipek

2007-09-19 23:42:20 UTC

Post by Ivan Warren
PREFIX is irrelevant when only 1 CPU is active and MUST be used in a
multi CPU environment.

Actually there is a very cute use of prefixing on a single CPU, but
it's not what it was intended for.

You can't just say that there's a neat way to use prefixing and not say
_what_ it is.

Post by Ivan Warren
Ok.. Here is a crash course on interrupts..

Good crash (uh, course). :-)

One would hope that's true :)

Post by Tony Harminc
And some early /370 models had undocumented op codes that could get
dangerous, e.g. the /168's Load Micro Program (LMP) instruction.)

I want to be comfortable with the documented bits before I start venturing
to the uncharted^Wundocumented territories.

Post by Tony Harminc
Perhaps even more generally, one must learn to read the PofO.

Agreed. About a month and a half ago, I found one website that did a tour of
the S/370 (IIRC) PoO. But that alone didn't help me in some cases; for
example, it came to me as a nasty surprise that bit 0 is the _most_
significant bit. Only after two days of reading random (well, not random,
but jumping from place to place to build a mental picture of what's
happening) sections of the z Poo,

Post by Tony Harminc
As Roger just said, the interrupt system, and indeed many other parts
of the architecture, are both elegant and programmer friendly.

The IPL process is beautiful compared to say x86 :)

Post by Tony Harminc
There are warts that have sprouted here and there (and one or two
congenital ones), and it is often argued that S/360 is cleaner than S370,
and so on, but even z/Arch is pretty good.

I haven't looked specifically, but it seems like there are rather major
differences between S/360 and 370. Or at least they feel like "oh, that
didn't work as well as we hoped, let's change this".

Backwards compatibility always causes pain...just look at the evolution of
x86.

Josef 'Jeff' Sipek.

--
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein

Ivan Warren

2007-09-20 01:07:29 UTC

Post by Josef Sipek
I haven't looked specifically, but it seems like there are rather major
differences between S/360 and 370. Or at least they feel like "oh, that
didn't work as well as we hoped, let's change this".

Actually, No (if you don't mind me contradicting you all the time..
Sorry - I'm known to do that).. S/360 & S/370 are very close. What S/370
does is *ADD* some additional that S/360 was sorely missing (and there
is only 1 Single incompatible change : EBCDIC/ASCII mode which was
dropped - mainly because no-one used it !)..

Technically speaking, actually, S/360 and S/370 are not differentiated
by the architecture but by the hardware implementation (S/360 used core
storage, S/370 used FETs - Although I've heard there was even something
in between but can't remember what it is.. film memory or something)..

Some of the important features that became standard (even if not stated
as such in the Poo) are :

- Dynamic Address Translation (although there are a few, very few
S/370[1] systems without DAT - notably the S/370 model 165)
- TOD Clock
- CPU Timer
- Clock Comparator

Post by Josef Sipek
Backwards compatibility always causes pain...just look at the evolution of
x86.

That's one of the other beauties of the architecture.. You can take a
"user" program written in the mid 60's on a S/360 and run it UNMODIFIED
(without even recompiling) on the latest z9 - there are very good
chances it will still work as designed (albeit "slightly" faster).
Backward compatibility [2] has apparently always been a major design
with the mainframe architects at IBM.. And frankly.. It's probably one
of the chief reason those mainframes are still here today !

--Ivan

[1] Apparently there was a raging debate in the early S/370 systems..
Some of the folks thought that DAT was a bloated feature and that it
shouldn't be implemented systematically.. It seems (from what I have
read) that there was also a lot of political reasons for that (some of
this involving a VM/370 vs TSS/370 battle or something).. But anyway..
DAT was finally made pretty much standard - to the point where a lot of
people consider that DAT was _the_ true difference between S/360 & S/370
(although, again, some of the late S/360 models had their own Dynamic
Address Translation mechanism - which was somewhat (if not completely)
incompatible with the S/370 version)

[2] <ShameLessSelfPromotion>You may want to check on the S/370 article
on Wikipedia.. there is a chapter there about the architecture (which I
"contributed" to :P) - it gives a it of an explanation about the
backward compatibility aspects</ShameLessSelfPromotion>

Josef Sipek

2007-09-20 01:57:01 UTC

Actually, No (if you don't mind me contradicting you all the time..
Sorry - I'm known to do that)..

That's perfectly fine...as long as you're right ;)

Post by Ivan Warren
S/360 & S/370 are very close. What S/370 does is *ADD* some additional
that S/360 was sorely missing

I suppose I looked at DAT (which you mention later) a change not an
addition, but it really should be considered as an addition as a program
MUST NOT be aware of it.

Post by Ivan Warren
(and there is only 1 Single incompatible change : EBCDIC/ASCII mode which
was dropped - mainly because no-one used it !)..

This actually reminded me of a fun little story...the other day, when I was
trying to debug my loader, I was inspecting the memory in hercules (r) and I
tried to save myself some effort, and so I looked at the symbolic version of
the data not the hex...I was looking for 'ELF' as a string, but I could not
find it. After more than an hour, I realized that hercules must be
displaying EBCDIC instead of ASCII. The string was right where it was
supposed to be, but my offset was wrong. :)

Post by Ivan Warren
Technically speaking, actually, S/360 and S/370 are not differentiated
by the architecture but by the hardware implementation (S/360 used core
storage, S/370 used FETs - Although I've heard there was even something
in between but can't remember what it is.. film memory or something)..

Good point.

Post by Ivan Warren
Some of the important features that became standard (even if not stated
- Dynamic Address Translation (although there are a few, very few
S/370[1] systems without DAT - notably the S/370 model 165)
- TOD Clock
- CPU Timer
- Clock Comparator

Post by Josef Sipek
Backwards compatibility always causes pain...just look at the evolution of
x86.

I'm sure some IBM engineers spend great many sleepless nights pulling their
hair out trying to figure out a way to do something in a backwards
compatible way. I suppose the thing that saved the mainframe from becoming
a monster like the x86 is the fact that the mainframe didn't get as many
"revisions" as the desktop has - as well as multiple vendor abuse (3dnow,
mmx, sse, ...)

360->370->390->z (I'm sure I forgot to include some...e.g., I'm not sure
what ESA/390 XA is considered as.)

4004->8008->8088->8086->286->386->486->pentium->pII->pIII->p4...

Even if you drop the early versions, you have a whole lot more
"generations".

Post by Ivan Warren
[1] Apparently there was a raging debate in the early S/370 systems..

Interesting.

Post by Ivan Warren
[2] <ShameLessSelfPromotion>You may want to check on the S/370 article
on Wikipedia.. there is a chapter there about the architecture (which I
"contributed" to :P) - it gives a it of an explanation about the
backward compatibility aspects</ShameLessSelfPromotion>

I think I read it months ago, but I'll reread :)

Josef 'Jeff' Sipek.

--
Don't drink and derive. Alcohol and algebra don't mix.

Peter J Farley III

2007-09-20 04:25:44 UTC

--- In hercules-390-***@public.gmane.org, Ivan Warren <***@...> wrote:
<Snipped>

Post by Ivan Warren
- Dynamic Address Translation (although there are a few, very few
S/370[1] systems without DAT - notably the S/370 model 165)

Also the S/370 model 155. I know because I worked on one that ran MVT
21.8. The 155 Mod II and 165 Mod II upgrades added DAT (for a very
large price). That "upgrade" path was, I believe, made expensive to
promote sales of the models 158 and 168 that were released near that
same time. But ICBW about that.

Peter

P.S. -- Most interesting discussion and training session, I appreciate
it -- Even if some of it is "old hat", I too learned some things --
See, old dogs *can* learn new tricks!.

Tony Harminc

2007-09-20 15:46:19 UTC

Post by Tony Harminc
Perhaps even more generally, one must learn to read the PofO.

Which part of 'Within each group of bytes, bits are numbered in a
left-to-right sequence. The leftmost bits are sometimes referred to as
the "high-order" bits and the rightmost bits as the "low-order" bits.
Bit numbers are not storage addresses, however. Only bytes can be
addressed. To operate on individual bits of a byte in storage, it is
necessary to access the entire byte. The bits in a byte are numbered 0
through 7, from left to right.' did you not understand...? :-)

Post by Josef Sipek
Only after two days of reading random (well, not random, but jumping from place
to place to build a mental picture of what's happening) sections of the z Poo,

Well, while the PofO is not really an instruction manual, it does make
sense to mostly read it in order.

Tony H.

Josef Sipek

2007-09-20 17:41:52 UTC

Post by Tony Harminc
Perhaps even more generally, one must learn to read the PofO.

Ah, you misunderstood me. What I meant to say, is that I did _not_ read that
part of the PoO, and when I looked at the PSW information, bit numbering was
reverse of what I expected (bit number 0 being least significant). :)

Post by Josef Sipek
Only after two days of reading random (well, not random, but jumping from place
to place to build a mental picture of what's happening) sections of the z Poo,

Well, while the PofO is not really an instruction manual, it does make
sense to mostly read it in order.

I took the approach of there's no way I'm reading >1200 pages cover to
cover; let me read the sections as I need them. With that said, I did read
the beginning of the introduction (until it gets into the changes since last
revision part), and most of the organization chapter.

Josef 'Jeff' Sipek.

--
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein

Roger Bowler

2007-09-20 21:44:14 UTC

I did read the beginning of the introduction (until it gets into
the changes since last revision part)

IMO it's worth also reading the sections headed "the ESA/390 base" and
"the ESA/370 and 370-XA base" later in that introductory chapter,
these will help you to identify what are the really basic features of
the architecture and what are the newer additions.

My point being that because it's an evolutionary architecture you can
still do a lot if you know the basics without necessarily knowing the
newer stuff, but not vice versa.

Roger Bowler

Tony Harminc

2007-09-26 15:44:45 UTC

Post by Ivan Warren
PREFIX is irrelevant when only 1 CPU is active and MUST be used in a
multi CPU environment.

Actually there is a very cute use of prefixing on a single CPU, but
it's not what it was intended for.

You can't just say that there's a neat way to use prefixing and not say _what_ it is.

It is possible to implement what is now commonly known as
para-virtualization on S/370 arch. This requires minor, perhaps
on-the-fly or perhaps static, updates to the guest OS so that it
doesn't issue certain dangerous instructions, and then the guest can
be dispatched in real supervisor state on the hardware, with some
realistic hope of the hypervisor getting control back.

There was a product from Amdahl called VM/PE (VM Performance
Enhancement) that did just this, and I believe we have a list member
who worked on it.

Anyway - the prefix register can be used in such a scheme to keep
separate prefix areas for the hypervisor and the (single) privileged
guest, to allow for faster context switching.

Tony H.

pfg504

2007-09-27 17:12:40 UTC

Just a quick VM/PE summary:

I developed and support VM/PE version 2. The basics: VM/BSEPP, VM/SEPP or VM/SP
generated with a V=R area. Guests could be SVS, MVS, or MVS/SP. Yes it was a major pain
to manage the matrix. The code was developed on a 370/158 without any of the
additional Amdahl software products. All variations were tested with new updates coming
out within weeks of an IBM released PUT. Several clients were running it on IBM processors
including the IBM center in Gaithersburg, MD.

IBM later announced a crude hardware implementation which was slower and had less
capabilities than VM/PE.

Code was added to both VM and MVS. Priv-ops that alter machine state were trapped and
handled by way of a hyper-visor (HV). In simpler terms, we added a supervisor to handle
the swapping of MVS and VM when needed.

Part of the time MVS would run as a guest, usually when virtual I/O was being performed
which included spooled UR I/O. The HV would take care of scheduling and dispatching
MVS and VM.

If a VM ABEND occurred, HV managed the dump taking and then transfer control back to
MVS. The operator could then issue a START command to "re-ipl" VM.

Control was passed back and forth between VM <-> HV <-> MVS. When MVS was
dispatch, the dispatch period was the same as if VM/PE was not there. The causes of MVS
to give up it's dispatched cycle were the same as native VM - V=R/MVS.

When MVS was started, a table of Virt=Real devices, and Virtual devices was maintained. If
I/O was to a V=V device control was transfer back via the HV to VM to handle.

A modification was added to VM so that DIAL GRAF devices dialed V=R instead of the
normal first available method. This was done to allow MVS users to continue to work when
VM crashed.

Major instructions trapped: LPSW, SIO, SIOF, CLRCH, CLRIO, CONCS, DISCS, HDV, LASP,
LCTL, RIO, SCK, SCKC, SIGP, SPT, SPX, TCH, TIO, TPROT, WRD, RDD and i several of the
other priv-ops that altered the machine state but I can not remember exactly which one
anymore.

If you want me to drag up more stuff, e-mail me off line...

Version 3 of VM/PE was an entire re-write and re-engineering of the product. By that time
I had moved to the Eastern Support Center for Amdahl as a second VM specialist and took
on development and deployment of a Zenith Z89/90 HDOS support console (AMDAC) to
the field specialist.

That product allowed the regional support specialist to take the first call from a customer,
start the analysis process to determine what was needed for the repair and then dispatch
the FE to the site. If the specialist needed assistance, then the support center could dial
into the Z89 and either watch the specialist or take control and have the specialist what
him.

I also worked on a replacement for the console processor using a Z100. It had an S-100
buss in it to which I engineered a processor interface card. The 580 came along and
negated the need to deploy this solution.

Paul

Wayne Bickerdike

2007-09-28 01:44:01 UTC

Crikey,

The "ubiquitous" S100 Bus. Back in 1979 I was working on application
development on a Cromemco System/3 which had the S100 Bus architecture.
Beautiful looking machine but the Persci 8" floppy drives plain didn't work.
About the same time we had an Altos 8000 which was a single board machine
with a 10MB Winchester drive. Used to take 2 minutes to rev-up.

Sorry for the diversion.....Nice nostalgia trip.

Wayne

Post by pfg504
I developed and support VM/PE version 2. The basics: VM/BSEPP, VM/SEPP or VM/SP
generated with a V=R area. Guests could be SVS, MVS, or MVS/SP. Yes it was a major pain
to manage the matrix. The code was developed on a 370/158 without any of the
additional Amdahl software products. All variations were tested with new updates coming
out within weeks of an IBM released PUT. Several clients were running it on IBM processors
including the IBM center in Gaithersburg, MD.
IBM later announced a crude hardware implementation which was slower and had less
capabilities than VM/PE.
Code was added to both VM and MVS. Priv-ops that alter machine state were trapped and
handled by way of a hyper-visor (HV). In simpler terms, we added a supervisor to handle
the swapping of MVS and VM when needed.
Part of the time MVS would run as a guest, usually when virtual I/O was being performed
which included spooled UR I/O. The HV would take care of scheduling and dispatching
MVS and VM.
If a VM ABEND occurred, HV managed the dump taking and then transfer control back to
MVS. The operator could then issue a START command to "re-ipl" VM.
Control was passed back and forth between VM <-> HV <-> MVS. When MVS was
dispatch, the dispatch period was the same as if VM/PE was not there. The causes of MVS
to give up it's dispatched cycle were the same as native VM - V=R/MVS.
When MVS was started, a table of Virt=Real devices, and Virtual devices was maintained. If
I/O was to a V=V device control was transfer back via the HV to VM to handle.
A modification was added to VM so that DIAL GRAF devices dialed V=R instead of the
normal first available method. This was done to allow MVS users to continue to work when
VM crashed.
Major instructions trapped: LPSW, SIO, SIOF, CLRCH, CLRIO, CONCS, DISCS, HDV, LASP,
LCTL, RIO, SCK, SCKC, SIGP, SPT, SPX, TCH, TIO, TPROT, WRD, RDD and i several of the
other priv-ops that altered the machine state but I can not remember exactly which one
anymore.
If you want me to drag up more stuff, e-mail me off line...
Version 3 of VM/PE was an entire re-write and re-engineering of the product. By that time
I had moved to the Eastern Support Center for Amdahl as a second VM specialist and took
on development and deployment of a Zenith Z89/90 HDOS support console (AMDAC) to
the field specialist.
That product allowed the regional support specialist to take the first
call from a customer,
start the analysis process to determine what was needed for the repair and then dispatch
the FE to the site. If the specialist needed assistance, then the support center could dial
into the Z89 and either watch the specialist or take control and have the specialist what
him.
I also worked on a replacement for the console processor using a Z100. It had an S-100
buss in it to which I engineered a processor interface card. The 580 came along and
negated the need to deploy this solution.
Paul

--
Wayne V. Bickerdike

[Non-text portions of this message have been removed]

Binyamin Dissen

2007-09-20 12:54:06 UTC

On Wed, 19 Sep 2007 18:46:57 -0400 "Tony Harminc" <tharminc-***@public.gmane.org> wrote:

:>It's also worth stating a golden principle of the architecture that
:>says that a machine check (either interrupt or red light kind of
:>thing) cannot be caused by programming. No matter how badly you screw
:>up your code (even privileged code), you cannot make the machine
:>malfunction, or indicate that it has malfunctioned.

Except for X'83'.

I believe that it is also possible to cause a machine check by screwing with
page tables while an instruction using it is being decoded (one can cause the
CPU to serialize to avoid that problem).

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

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Tony Harminc

2007-09-20 15:37:38 UTC

Post by Binyamin Dissen
:>It's also worth stating a golden principle of the architecture that
:>says that a machine check (either interrupt or red light kind of
:>thing) cannot be caused by programming. No matter how badly you screw
:>up your code (even privileged code), you cannot make the machine
:>malfunction, or indicate that it has malfunctioned.
Except for X'83'.

Which is what I said in the rest of the paragraph that you didn't quote.

Post by Binyamin Dissen
I believe that it is also possible to cause a machine check by screwing with
page tables while an instruction using it is being decoded (one can cause the
CPU to serialize to avoid that problem).

According to the PofO, "A machine check is caused by a machine
malfunction and not by data or instructions." The only exceptions I
have seen are for Diagnose, and for those I/O related machine check
interruptions that e.g. indicate the availability of a device.

Tony H.

Binyamin Dissen

2007-09-20 17:41:13 UTC

On Thu, 20 Sep 2007 11:37:38 -0400 "Tony Harminc" <tharminc-***@public.gmane.org> wrote:

:>On 20/09/2007, Binyamin Dissen <bdissen-***@public.gmane.org> wrote:
:>> On Wed, 19 Sep 2007 18:46:57 -0400 "Tony Harminc" <tharminc-***@public.gmane.org> wrote:
:>>
:>> :>It's also worth stating a golden principle of the architecture that
:>> :>says that a machine check (either interrupt or red light kind of
:>> :>thing) cannot be caused by programming. No matter how badly you screw
:>> :>up your code (even privileged code), you cannot make the machine
:>> :>malfunction, or indicate that it has malfunctioned.

:>> Except for X'83'.

:>Which is what I said in the rest of the paragraph that you didn't quote.

Sorry. Missed it.

:>> I believe that it is also possible to cause a machine check by screwing with
:>> page tables while an instruction using it is being decoded (one can cause the
:>> CPU to serialize to avoid that problem).

:>According to the PofO, "A machine check is caused by a machine
:>malfunction and not by data or instructions." The only exceptions I
:>have seen are for Diagnose, and for those I/O related machine check
:>interruptions that e.g. indicate the availability of a device.

Look at "Delayed Access Exception".

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

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Gerhard Postpischil

2007-09-20 19:28:52 UTC

Post by Tony Harminc
According to the PofO, "A machine check is caused by a machine
malfunction and not by data or instructions." The only exceptions I
have seen are for Diagnose, and for those I/O related machine check
interruptions that e.g. indicate the availability of a device.

This brings back fond memories - in the sixties I worked at
Applied Data Research when we upgraded a 360/40 to a 360/50. The
new machine appeared to run fine, but every few hours it would
get a machine check and come to a screeching halt. The C.E. ran
diagnostics, but was unable to find any problems with them. He
concluded that the problem was a software error!

After studying the system log and console sheets, we noticed
that the error occurred whenever we had a WTO with ROUTCDE=1,
DESC=1. One of our local changes, for this condition, was to
chain an ALARM CCW(ring the bell) to the 1052 master console.
The bell was faulty, and triggered the machine check. When
confronted with our evidence, the C.E. persisted in claiming
system error. I powered down the machine, powered it up, and
loaded a simple SIO/TIO loop into memory, and hit Start (no
IPL). We got an immediate machine check and the C.E. had no
system to blame it on.....

One of my PC games is Sim City. It has a "calamity" option that
allows the program to introduce, at random intervals, fires,
tornadoes, floods, earthquakes, and what-not. As long as I don't
have to do the work, I'd like to see something similar
introduced as a Hercules option. In real life I had a box of
known bad tapes, and used them to check error detection and
processing in local and third party programs (and I worked for a
software vendor whose software got an 0C4 when a write error
occurred during CLOSE - the original author misinterpreted IBM's
comment that the exit registers were the same as at WRITE time).
An occasional machine check or I/O error might be nice to debug
error handling <G>

Gerhard Postpischil
Bradford, VT

new e-mail address: gerhardp (at) charter (dot) net

Ivan Warren

2007-09-20 15:57:58 UTC

That'd be the day ! I really can't see how modifying a PTE would cause a
machine check.. Even if the PTE is being modified by another CPU, the
CPU using the PTE will get one version or the other.. In the end, the
instruction will either be fetched, a translation specification
exception may be recognized (if the PTE entry is badly formated) or a
translation exception (if the PTE was invalidated).. If the PTE was
fetched BEFORE the messing around with it, then the entry is in the TLB
and unless the target CPU issues a PTLB, IPTE or any other instruction
that implicitly purges the TLB (or parts thereof), or another CPU issues
an instruction to purge all CPUs TBLs then the modified entry will not
have any effect.

Also note that CPU Serialization on hercules has no effect because CPUs
are always serialized (there are basically no CPU Local caches). You'll
note that although there are serialization macros embedded throughout
instructions, those macros resolve to nothing ! Same goes for Checkpoint
synchronization since we don't do instruction retries !

I can tell ya.. If ANYTHING performed by the CPU (besides X'83') -
including any and all control instructions - can cause a damaging
machine check condition to be recognized on hercules it's either a BUG
(it happens.. The last one we had was when you had an I/O interrupt
pending but that interrupt was disabled by CR6 yet CR6 was non 0 and the
PSW was enabled for I/O.. we would loop in the instruction execution
loop forever - and our execution instruction watchdog would fire and
cause a machine check.. NOTE : It's FIXED !) or you actually DO have a
hardware problem !

--Ivan

Binyamin Dissen

2007-09-20 17:41:52 UTC

On Thu, 20 Sep 2007 17:57:58 +0200 Ivan Warren <ivan-lnHwE90NT89Ooi3Kub+***@public.gmane.org> wrote:

:>Binyamin Dissen wrote:
:>> I believe that it is also possible to cause a machine check by screwing with
:>> page tables while an instruction using it is being decoded (one can cause the
:>> CPU to serialize to avoid that problem).

:>That'd be the day ! I really can't see how modifying a PTE would cause a
:>machine check.

Look at "Delayed Access Exception".

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

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Roger Bowler

2007-09-20 21:36:36 UTC

Post by Binyamin Dissen
Look at "Delayed Access Exception".

Most interesting. I never knew that!

It's mentioned in both ESA/390 and z/Arch Principles of Operation,
although z/Arch gives a fuller explanation of what can cause it.

Roger Bowler

Ivan Warren

2007-09-20 22:29:30 UTC

Post by Binyamin Dissen
Look at "Delayed Access Exception".

Good catch ! And apparently this is the only one condition noted with a
"programing note" :

Programming Note: The occurrence of a
delayed access exception normally indicates that
the program is using an improper procedure to
update the DAT tables.

Now.. this is a *subclass modifier* bit.. what I am saying is that there
probably has to be some underlying condition (instruction retry maybe)
so that instruction processing damage gets reported with a delayed
access exception (an instruction processing failed - the processor
attempted to retry it - but THEN, reading the DAT tables yielded a
translation exception/translation specification exception - in which
case, all that it is saying, is that : OK, I have an instruction
processing damage - and THEN I couldn't even fix it because some dude
cut the grass under my feet [1])..

I haven't read the z/Arch Pop which, according to Roger, seems to shed
some light on that one.. I guess I should do that !

--Ivan

[1] This is the translation of a French expression (se faire couper
l'herbe sous les pieds) which might not translate properly in English
as-is ! The meaning is that something unexpected happened due to lack of
coordination.

Josef Sipek

2007-09-19 23:26:37 UTC

Post by Josef Sipek
It sounds like if you want to load-balance interrupt handlers, you have to
use prefixing.

Riiight. I remember bits and pieces about that from my reading of the PSW
format docs.

Post by Ivan Warren
Interrupts come in 2 flavors : Floating and non-floating. Floating
interrupts are interrupts that can trigger a PSW switch on any
operational CPU in a configuration. Notably, I/O interrupts are floating
(and only in S/390 & z/Arch).. Some Machine Checks may also be floating
(External Damage may be floating).

And non-floating must occur on CPU that triggered it?

Post by Ivan Warren
- Program Interrupt : They relate to an exception or condition
encountered during execution of an instruction. They may be related to
the operation code, operation parameters, address translation, tracing,
etc..

Makes sense.

Post by Ivan Warren
- SVC Interrupt : Every time the SVC instruction is executed

Simple, I like it.

Post by Ivan Warren
- I/O : Pertains the a device meaning to present some status to the CPU
- which may be solicited - the result of an ongoing I/O operation, or
unsolicited (Attention or not-ready to ready state switch)

Ok.

Post by Ivan Warren
- External : Various non-damage conditions : Timing, inter-cpu
communication, Service Processor communication, the 'External' operator
button, etc.. (there are more)

This reminds me of a "problem" I have with the whole architecture. It does
too many things. For example, how many different ways to address are there?
AR, Home, Primary, Secondary, ... I only skimmed through the Storage chapter
of the PoO. Trying to sort out what's best used where, and making sure that
the other cases are handled in case something checks/depends on some bits.
But overall, I still love it :)

Post by Ivan Warren
- Machine check : Various possibly damage conditions : System damage,
instruction damage, External Damage (I/O damage goes there IIRC) and
some non damage conditions such as I/O reconfiguration.. Machine check
may also be presented to indicate an error occurred but was fixed
internally like when a single bit error in storage was fixed by ECC.

Neat.

Post by Ivan Warren
- Restart : Operator initiated non maskable interrupt (depending on the
Operating System, this may be used to trigger a dump when the system has
entered a disabled loop). Note that the RESTART new PSW is at the same
location as the IPL PSW - which means that on simple IPLable programs,
RESTART will actually restart the program from the beginning !

Interesting.

Makes sense.

...

Post by Ivan Warren
The interrupt process itself is fairly simple : The current PSW is
stored at the 'OLD PSW' location and the 'NEW PSW' is loaded in the
actual PSW. Those fields are located in the famous low storage area we
have been discussing.

:)

...

Post by Ivan Warren
I/O interrupts for a specific device can also sometimes merge - and the
status bits in the CSW/SCSW will have been OR'd (there are some merging
conditions though.. they will not ALWAYS merge).

Ouch! This sounds painful to deal with, but I guess I'll get to see when I
start poking around interrupts (probably sooner than later :) ).

Post by Ivan Warren
If you look at it, interrupts on S/370, S/390 and z/Arch are a whole lot
simpler than it is on x86 for example (there is no need for internal
knowledge of PICs & bus interrupt mechanism) and the interrupt process
is perfectly well defined by the architecture itself - that is - it is
not implementation dependent.

Agreed.

Post by Ivan Warren
Finally, here is a (not even tried) small sample program that can be
IPLed (it's 3CARD LOADER Compatible since there are no ADCONs) that will
loop for 1 second until the CPU Timer interrupt occurs and then loads a
disabled wait PSW.

Neat!

Josef 'Jeff' Sipek.

--
A CRAY is the only computer that runs an endless loop in just 4 hours...

Ivan Warren

2007-09-20 00:43:50 UTC

Post by Josef Sipek
And non-floating must occur on CPU that triggered it?

Not necessarily ! For example, for I/O, in S/370 - yes - it will be the
case because a channel (and associated control units & devices) are at
any particular point in time, dedicated to a CPU.. So the Interrupt will
be presented to the CPU which is connected to that channel (or more
accurately to that Channel Set). In S/390 & Beyond, Channel Paths are no
longer bound to any particular CPU, meaning that, not only can ANY CPU
in a configuration initiate an I/O on ANY device, but an I/O interrupt
may be received on a CPU that is different than the one that initiated
the I/O.

The rule of thumb is : If it affects THAT particular CPU, then the
interrupt will only be made pending for THAT CPU.. If it is a system
wide event, then it will float.

Post by Josef Sipek
This reminds me of a "problem" I have with the whole architecture. It does
too many things. For example, how many different ways to address are there?
AR, Home, Primary, Secondary, ... I only skimmed through the Storage chapter
of the PoO. Trying to sort out what's best used where, and making sure that
the other cases are handled in case something checks/depends on some bits.
But overall, I still love it :)

The fact that "storage" is the first chapter is really what throw people
off ! (although it is necessary, because they define essential terms for
the architecture to have a complete definition).. Remember, it's a
reference manual, so they don't even try to teach you stuff ! They put
it out bluntly.. So don't fret about not understanding all the various
address types just yet ! Just look at other 'reference manual'.. Like
the C ref manual.. Statements like 'if()' and 'for(;;)' might be talked
about like halfway through the manual (think that they first have to
define what "statements", "expressions", "declaration", "definition",
etc are !)

For the 'problem' state (user program), what really matter is the
"logical address" or the "effective address" (which are *almost* the
same) - They won't see the difference between the various addressing
modes (with the exception of AR mode - but usually, the "problem" state
program will have specifically requested something to the operating
system for this to be a concern).
For privileged state program (operating system), this depends on stuff
you may have setup. But basically :
- Absolute : The physical layout
- Real : Absolute + Prefixing
- Primary, Secondary, Home : Segment Table Origin in CR1/CR7/CR13 -
PSW+CR0 Controls which CR to use (see the T & AS bits in the PSW)
- Access Register : Segment table origin specified indirectly by the
Access Register with the same number as the Base Register Used (Ex : L
1,0(2) will use AR 2 for the 2nd operand). Access Register mode allows
an operating system to make a large number of different address spaces
available to a program.. Again, primarily controlled by some PSW bits..

Primary, Secondary, Home, AR modes are all related to dynamic address
translation (virtual memory stuff !). Don't worry, when you get to the
point where you want to deal with DAT, virtual address spaces, etc..,
you'll be proficient enough to deal with those terms ubiquitously (I
love this term although I'm not even sure it means anything !). In the
meantime, rest assured ! I don't even really understand how AR mode
works (because I never had to deal with it ! For hercules, I let the AR
guys (basically Jan, Greg & Roger.. And some others) deal with those
aspects !)

When you start (IPL), all logical addresses will be absolute addresses..
If you have more than one CPU, you may change the Prefix (then most
"logical" addresses will become "real addresses").. Then you may elect
to modify some Control Register, set some PSW bits at which point your
"logical" addresses will become virtual.

Ouch! This sounds painful to deal with, but I guess I'll get to see when I
start poking around interrupts (probably sooner than later :) ).

Don't panic.. Let me give you simple example.. Ok.. You start an I/O on
a device (say, you punch a card on a card punch device). Historically, 2
interrupts will be presented (if everything goes smoothly) : One will be
"Channel End" (to indicate the data has been transfered from storage to
the control unit/device).. Then "Device End" (which will indicate the
card punch operation is actually complete)... If you remain I/O
interrupt disabled long enough so that the "Channel End" remains pending
until the "Device End" gets reported, then you may find yourself with
only 1 interrupt combining both CE and DE. Your I/O interrupt routine
will just need to check for each bit individually and will usually elect
to declare that the operation is over when the "DE" is seen (Since CE
indicates that the channel is now available, it's just an opportunity
that can be used to start another I/O on another device on the same
channel for channels that do not support concurrent I/Os on the same
channel while a data transfer is in progress). Anyway (and for the time
being), on hercules, CE and DE are always presented simultaneously
(which is sometimes a problem for some old programs which expect those
to be presented separately).

In most cases, you really only care to see if you have DE and no
'trouble' bits (Unit Check, Unit Exception, Control Unit Busy, non 0
channel status, etc..)

Basically, only 'final' statuses can be merged.. Attention, PCI (Program
Controlled Interrupt - not the Personal Computer Interface thing),
unsolicited statuses and channel statuses don't get merged !

Also (and this is an interesting point) interrupts only occur for the
FINAL CCW executed in a CCW chain (unless an error occurs).. So what you
can do to make SURE you only get a single final interrupt is chain a
CTL-NOOP at the end of your chain.. Since CTL-NOOP is an "immediate
command" and performs no device operation in itself (an Immediate
Command is a CCW command that will return "Channel End" without having
claimed any data from the channel) "DE" will be made available
simultaneously with CE. This is a trick usually done when dealing with a
tape rewind because the time diff between the CE - which is returned
immediately - and DE which may take literally minutes.

--Ivan

rhtatum

2007-09-20 02:01:02 UTC

An interesting thing - the "data security erase" command for tapes requires a channel program that is chained to another chanprog that is a "control no-op" critter ... Don't know why they did it that way. Had a systems programmeur tell me I couldn't run a program that erased (BOT to EOT) a tape because:"that would tie up the channel so other jobs couldn't use any tapes." Told the RHCS that was not true; ran a job that wrote a Calcomp tape at the same time my "blocking" was running. Surprise! no problem - the Calcomp pgm made one of the drives go clickety-clack while the drive I was addressing screamed madly (had to restrain the operator because he wanted to knock off the power as it was obvious there was a runaway tape). THen the RHCS had the temerity to tell me "well it ties up that tape
drive." As if the other jobs running and using tapes didn't tie up their drives until those jobs terminated ...
----- Original Message -----
From: Ivan Warren
To: hercules-390-***@public.gmane.org
Sent: Wednesday, September 19, 2007 7:43 PM
Subject: Re: [hercules-390] OS Design for Hercules

Post by Josef Sipek
And non-floating must occur on CPU that triggered it?

Ouch! This sounds painful to deal with, but I guess I'll get to see when I
start poking around interrupts (probably sooner than later :) ).

Gerhard Postpischil

2007-09-20 06:49:58 UTC

Post by rhtatum
An interesting thing - the "data security erase" command for
tapes requires a channel program that is chained to another
chanprog that is a "control no-op" critter ... Don't know
why they did it that way.

I vaguely seem to recall that tape CCWs other than
Read/Write/Sense issued a Device End when the command was
accepted and not chained, thus the issuer could not tell whether
the command completed successfully without issuing another I/O
to verify completion. And at the time CPU time was more precious
than tying up a selector channel for relatively rare commands.
Chaining the NOP allowed the issuer (normally Open/Close/EOV) to
know that the request ended. I don't remember this being a
problem when tape controllers were on byte or block multiplexer
channels, but we never had a tape controller on a byte mux, and
our block mux tape controllers had two-channel access.

Gerhard Postpischil
Bradford, VT

new e-mail address: gerhardp (at) charter (dot) net

Binyamin Dissen

2007-09-20 13:03:17 UTC

On Wed, 19 Sep 2007 19:26:37 -0400 Josef Sipek <jsipek-2jbElX+***@public.gmane.org>
wrote:

:>> Interrupts come in 2 flavors : Floating and non-floating. Floating
:>> interrupts are interrupts that can trigger a PSW switch on any
:>> operational CPU in a configuration. Notably, I/O interrupts are floating
:>> (and only in S/390 & z/Arch).. Some Machine Checks may also be floating
:>> (External Damage may be floating).

:>And non-floating must occur on CPU that triggered it?

Each CPU has its own set of timers (the TOD clock is shared). So when a timer
interrupt (there are several) occurs, it is sent to that CPU alone.

Also, one CPU can send an interrupt to another CPU.

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

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Ivan Warren

2007-09-20 16:00:14 UTC

.. Grumble.. Yahoo Groups ate that one again.. So retransmitting ..

Post by Binyamin Dissen
Each CPU has its own set of timers (the TOD clock is shared). So when a timer
interrupt (there are several) occurs, it is sent to that CPU alone.

The TOD clock "MAY" be shared (and it is the case under hercules)..
There are some implementations that have non-shared TOD clocks.. (I'm
pretty sure a 4 way 3081 had 1 TOD clock per side - hence 2 TOD clocks..
A 3090 Mod 600 probably had 2 TOD clocks as well).

From S/390 Pop (page 4-29 of SA22-7201-08)

"In a configuration with more than one CPU, each
CPU may have a separate TOD clock, or more
than one CPU may share a clock, depending on
the model. In all cases, each CPU has access to
a single clock."

If the TOD clocks become out of sync, a "TOD CLOCK SYNC CHECK" external
interrupt is generated with code X'1003'. This is not a floating
interrupt - because every group of CPUs sharing a TOD clock is owed an
interrupt. (For example, if you have 4 CPUs and 2 TOD Clocks, CPU 0&1 on
TOD 0 and CPU 2&3 on TOD1 then CPU 0 & CPU 2 will get the TCSC Ext).

So, to determine the number of TOD clocks : Have each CPU set a
different value to the TOD clock.. Wait ~1 sec (you may want to use the
CPU Timer for that !) look how many CPUs get a TCSC interrupt : That's
your number of individual TOD Clocks !

TCSC is a persistent condition & interrupts may be generated as long as
the condition exists (that is, the interrupt doesn't clear the condition).

In hercules, there is a single TOD clock shared by all CPUs so a Tod
Clock Sync Check condition is never recognized and no Tod Clock Sync
Check ext interrupt ever occurs.

The Tod Clock Comparator (CC) register isn't really a timer 'per-se'.
The value doesn't change over time.. But nonetheless, there is one
individual CC per CPU and the CC interrupt will be generated for that
CPU if the value in the CC register becomes less than the Tod Clock
value visible for that CPU.

CPU Timer is a timer and there is one per CPU.

In S/370, there is 1 interval timer per CPU. This timer is NOT a
register but is in low storage ("REAL" address 50 or X'38') - Yet
another reason to use Prefixing in a MP setup ! (Contrary to CC & CPT,
The interval timer interrupt CLEARS the condition. The interrupt is
generated when the value at X'38' goes from 0 to X'FFFFFFFF'. Also, if
the interrupt is not taken and the interval timer is allowed to loop
back (it takes less than a day IIRC) then the previous interrupt will be
lost). Interval timer doesn't exist in XA & beyond.

--Ivan

Ivan Warren

2007-09-20 14:21:59 UTC

Post by Binyamin Dissen
Each CPU has its own set of timers (the TOD clock is shared). So when a timer
interrupt (there are several) occurs, it is sent to that CPU alone.

Roger Bowler

2007-09-20 21:31:16 UTC

Post by Josef Sipek
This reminds me of a "problem" I have with the whole architecture.
It does too many things. For example, how many different ways to
address are there? AR, Home, Primary, Secondary, ... I only
skimmed through the Storage chapter of the PoO. Trying to sort out
what's best used where, and making sure that the other cases are
handled in case something checks/depends on some bits.
But overall, I still love it :)

What you have to remember is that you are looking at the result of an
evolutionary process spanning more than 40 years. AR, Home, Primary,
Secondary, 24 bits, 31 bits, 64 bits, program call, linkage stack, all
of these were added to the architecture piece by piece. If there seems
to be more than one way of doing some things, that's because many new
methods have superseded old methods, but the old methods have been
retained so that existing programs do not have to be rewritten (they
do not even need to be recompiled). IBM refers to this as "preserving
customer investment" and it's a feature of the traditional mainframe
operating systems which is absent in (for example) Linux [1]

The way I would tackle learning the architecture is this:

1. To get a solid grounding in the instruction set, start with the
System/360 Assembler Self Study books (the classic assembler course)
at pdf/ibm/360/training/ in bitsavers (although probably too
elementary for you Josef)

2. Supplement this with the S/360 Principles of Operation (also at
bitsavers). BC mode only, and at that time the architecture was still
simple enough that it's within the grasp of a single person to
understand everything in this book.

3. Move on to the S/370 Principles of Operation to learn about EC mode
and virtual storage. Here you can also learn about cross-memory (dual
address space) and this is when your head starts to hurt.

4. Study the 370-XA Principles of Operation to learn about 31-bit
addressing and the channel subsystem (SSCH, ORB, etc) which is where
the XA architecture diverges incompatibly from S/370 (while cleverly
maintaining problem state compatability). Not sure if this book is at
bitsavers, but if not then the ESA/390 Principles of Operation has the
same information because ESA/390 evolved from 370-XA.

5. Study the ESA/390 Principles of Operation (still current and
available from ibm bookmanager sites) to learn about data spaces,
access registers, linkage stack, and other stuff I cannot think of
right now.

6. Study the z/Architecture Principles of Operation to find out about
64 bit addressing, region tables, and hundreds upon hundreds of new
instructions. This mammoth size book mixes almost the whole 40 years
of evolution in its 1200 pages and I would not envy anyone who decides
to plunge into it as an introductory text.

Regards,
Roger Bowler

--
[1] The episode which prompted me to give up serious development under
Linux was in 2000 when I resurrected a program which I had written
about 3 years earlier but which I had not run for at least 2 years. To
my dismay, it no longer worked. IIRC, it had been linked with glibc
version 1 but Linux had since moved on to glibc version 2. So it would
not even load. Nor would it recompile against glibc version 2 without
modification. Linux is what I would call a moving target. MVS in
general is not. You can still get by as a programmer even if you have
never heard of the new things that have been added since 1990. Whether
this is a good or bad thing, of course, depends on your point of view :-)

Tony Harminc

2007-09-21 20:13:53 UTC

Post by Roger Bowler
What you have to remember is that you are looking at the result of an
evolutionary process spanning more than 40 years. AR, Home, Primary,
Secondary, 24 bits, 31 bits, 64 bits, program call, linkage stack, all
of these were added to the architecture piece by piece. If there seems
to be more than one way of doing some things, that's because many new
methods have superseded old methods, but the old methods have been
retained so that existing programs do not have to be rewritten (they
do not even need to be recompiled).

They often don't even need to be relinked! There are binaries last
linked on OS/360 in 1969 that run on z/OS 1.8 today. Something
unmatched by any other architecture in history.
[...]

Post by Roger Bowler
2. Supplement this with the S/360 Principles of Operation (also at
bitsavers). BC mode only, and at that time the architecture was still
simple enough that it's within the grasp of a single person to
understand everything in this book.

Not only was it simple enough that many people understood it all, but
many knew all the 150 or so opcodes by heart. This isn't such a feat,
because of the way both the opcodes and the mnemonics are laid out
with several orthogonal views. This isn't made entirely clear in the
later PofOs, so let me explain at the risk of stating the obvious:

The first two bits of the op code specify the length of the
instruction (this is still true even in z/Arch):
00->2 bytes
01->4 bytes
10->4 bytes
11->6 bytes

In S/360, all opcodes are one byte, and the instruction formats also
divide neatly according to the first two bits:
00->RR format (with the four exceptions of SPM, SSK, ISK, SVC)
01->RX format
10->RS or SI format (with exceptions for LPSW, DIAG, SIO, TIO, HIO, TCH)
11->SS format

Common functions are assigned where possible to the right four bits of
the opcode, so e.g. the add function is X'A', and therefore
AR is 1A Add registers
A is 5A Add a storage fullword to a register
AH is 4A Add a storage halfword to a register
AP is FA Add a packed decimal number in storage to another.
ADR is 2A Add a long floating point number in registers
and so on.

So if you see an xA opcode, you are pretty sure it's an add of some
sort, and the left four bits tells you something about the kind of
operands. If you see a 5x opcode, it is a fullword to register
instruction, while a 2x or 3x will be double and single precision
floating point, respectively.

There are exceptions, but there are no gratuitous exceptions, and it
is mostly remarkably simple and orthogonal.

Post by Roger Bowler
3. Move on to the S/370 Principles of Operation to learn about EC mode
and virtual storage. Here you can also learn about cross-memory (dual
address space) and this is when your head starts to hurt.

The original S/370 PofO was actually a 15 page supplement to the S/360
PofO. The only changes were the addition of a handful of instructions,
including the first few two-byte opcodes in the B2xx series, a new
Time of Day (TOD) Clock, relaxation of the alignment rules for most
storage operands, and a new kind of I/O channel and disk devices,
though the I/O architecture stayed essentially unchanged. A set of 16
Control Registers was defined to add granularity to the bits in the
PSW, although initially only a couple were implemented. No virtual
storage. ASCII mode for decimal numbers was removed.

Anyone could still understand all of this with little trouble.

Then came virtual storage, and S/370 started to diverge a bit from
S/360, though not incompatibly. Many places ran S/360 operating
systems on S/370 hardware with no problem.

Anyone could still understand all of this with little trouble, though
with a fair bit of effort to fully understand how to set up page and
segment tables, and manage channel program translation (since channels
don't deal with the DAT hardware in the CPU).

This would be a good point to learn something about the original VM
(VM/370), since it not only takes advantage ot the virtual storage
architecture, but provides an introduction to the concepts of
virtualization and a virtualizable architecture, which S/370 is, and
370-XA and higher (and e.g. i386 and Power) are not. There is a very
good VM internals course on bitsavers. Understanding how shadow page
tables work is an eye-opener.

Multi-processing returned here, in a fairly usable way. (One S/360
model was capable of having two CPUs in one box, but it was
architecturally inefficient, and not common.) There are several
instructions related to two synchonizing two (or more) CPUs sharing
main storage, and the concept of prefixing is important.

Post by Roger Bowler
4. Study the 370-XA Principles of Operation to learn about 31-bit
addressing and the channel subsystem (SSCH, ORB, etc) which is where
the XA architecture diverges incompatibly from S/370 (while cleverly
maintaining problem state compatability). Not sure if this book is at
bitsavers, but if not then the ESA/390 Principles of Operation has the
same information because ESA/390 evolved from 370-XA.

Somewhere in here the Dual Address Space facility came along. This is
now deprecated, but was the first piece of the architecture that
allowed a single instruction to reference data in more than a single
address space (or indeed to execute in one space while referencing
data in another). It is a good deal easier to understand than the
current access register scheme with all its warty add-ons.

Anyone could still understand all of this with some fair degree of
hard work. Memorizing all the instructions became a pretty unlikely
and not too useful thing.

Somewhere else around here, the now-gone Vector Facility was
introduced. This provided a hundred+ new opcodes, and was a market
flop (no pun intended). This was probably the low point of the
uglification of the architecture.

Post by Roger Bowler
5. Study the ESA/390 Principles of Operation (still current and
available from ibm bookmanager sites) to learn about data spaces,
access registers, linkage stack, and other stuff I cannot think of
right now.

It is worth noting here that up until this point, this architecture
did not have a stack. Newcomers from other architectures are often
outraged at this, but it is quite clear that a hardware stack is
unnecessary to implement things like recursion and local variables. It
is also notable that the linkage stack introduced here is not used by
the IBM C/C++ compilers, and has been dismissed by their authors as
"Stack? - that's not a stack!". (In passing, contrary to popular
belief, the C language does not define a stack, but even if it did
there is no need for the underlying hardware to have one to implement
one in software.)

One notably warty addition is the special meaning of protection key 9.
There are a few others.

Post by Roger Bowler
6. Study the z/Architecture Principles of Operation to find out about
64 bit addressing, region tables, and hundreds upon hundreds of new
instructions. This mammoth size book mixes almost the whole 40 years
of evolution in its 1200 pages and I would not envy anyone who decides
to plunge into it as an introductory text.

I don't imagine there is anyone on the planet who knows even most of
the instruction opcodes, or even how to use many of them.

Tony H.

Martin T2..

2007-09-21 21:54:25 UTC

Tony,

... warty addition is the special meaning of protection key 9. <<

You got to see the implication of the use of it in VSE.

Because of the "warty"-style of this addition, CICS can only use
sub-system-storage proctection in partitions other than F4.

--
Martin
--
XML2PDF - the way to get all features of PDF into your documents
on mainframe or PC systems; more at http://www.pi-sysprog.de

halfmeg

2007-09-22 06:34:31 UTC

Post by Roger Bowler
What you have to remember is that you are looking at the result of
an evolutionary process spanning more than 40 years.

<snip>

Post by Roger Bowler
... many new methods have superseded old methods, but the old
methods have been retained so that existing programs do not have to
be rewritten (they do not even need to be recompiled).

They often don't even need to be relinked! There are binaries last
linked on OS/360 in 1969 that run on z/OS 1.8 today. Something
unmatched by any other architecture in history.
<snip>

If recompiled or relinked however, the program may no longer fit in
the same region size it ran in before recompilation. The compiler
which created it may have long been retired, unavailable and new
'reserve words' may trip up the source code with the new improved
compiler version. LE imposes it's own bloat upon seemingly simple
programs which never needed a monstrous 'shared' library before.

Phil - battling a virus war on a personal level

Roger Bowler

2007-09-22 12:52:32 UTC

... provides an introduction to the concepts of
virtualization and a virtualizable architecture, which S/370 is, and
370-XA and higher (and e.g. i386 and Power) are not.

This is an interesting observation. Would you care to expand? (I mean
the bit about 370-XA and higher, not about i386 and Power)

DAS pre-dates 370-XA and is part of the S/370 architecture. Somewhere
in my cellar I still have a supplement to the S/370 Principles of
Operation containing the updates describing the cross memory feature.
In S/370 mode DAS was supported by MVS/SP2 (subsequently renamed as
MVS/SP V1R2 to distinguish it from MVS/SP V2, better known as MVS/XA)
and MVS/SP V1R3.

Roger Bowler

Tony Harminc

2007-09-26 15:35:30 UTC

On 22/09/2007, Roger Bowler <rogerbowler-/E1597aS9LT10XsdtD+***@public.gmane.org> wrote:
[me]

... provides an introduction to the concepts of
virtualization and a virtualizable architecture, which S/370 is, and
370-XA and higher (and e.g. i386 and Power) are not.

This is an interesting observation. Would you care to expand? (I mean
the bit about 370-XA and higher, not about i386 and Power)

Well, I may (again) be wrong about the point in the evolution of the
architecture when this happened. S/370 arch is virtualizable in the
sense that it is possible to write a hypervisor that dispatches
virtual machines that perceive they are in supervisor state while they
are in real problem state. Unprivileged instructions execute on the
real iron with no added overhead (and no knowledge of the hypervisor),
but privileged instructions cause a real program check, and are then
handled by the hypervisor, which fixes things up so that the effects
within the virtual machine of the privileged instruction appear to
have been accomplished.

The key is that there is nothing that code in the virtual machine can
do to reliably discover that it is running in a virtual machine,
except via the architected interface of STIDP, and perhaps by playing
with the Diagnose instruction.

This is blatantly broken in z/Arch because of the existence of
unprivileged instructions like Extract PSW, but I believe it was
broken more subtly somewhere before z/Arch, perhaps by Extract Stacked
State, though this may be controllable. I think any level of the
architecture with access-registers is also non-virtualizable in a
practical if not theoretical sense, because the semi-privileged
instructions must be turned into fully privileged ones by the
hypervisor, and this in turn will make performance unacceptable.

Tony H.

peter_flass

2007-09-21 22:10:45 UTC

Interesting you mention this. I've been having a, ahem. "discussion"
in another group where I argue that the non-mainframe world isn't
making enough effort to maintain compatibility, and, in fact, don't
really have a clue how to go about this or even why they'd want to.
Thank you for an excellent example.

Post by Roger Bowler
[1] The episode which prompted me to give up serious development under
Linux was in 2000 when I resurrected a program which I had written
about 3 years earlier but which I had not run for at least 2 years. To
my dismay, it no longer worked. IIRC, it had been linked with glibc
version 1 but Linux had since moved on to glibc version 2. So it would
not even load. Nor would it recompile against glibc version 2 without
modification. Linux is what I would call a moving target. MVS in
general is not. You can still get by as a programmer even if you have
never heard of the new things that have been added since 1990. Whether
this is a good or bad thing, of course, depends on your point of view :-)

Harold Grovesteen

2007-09-20 08:52:25 UTC

Josef,

The reason prefixing must be used in a mult-CPU environment is that
information is saved with every interrupt. Without actually using
physcially different absolute locations, interrupts of the same type on
different CPU's using the same assigned storage locations, a slightly
later interrupt on one CPU could overlay the information supplied for
the interrupt by another CPU before the first CPU could have sufficient
time to process it, losing the first interrupt entirely. Unpredictable
and unpleasant results would follow. The OS would attempt to execute
the wrong SVC for a program. I/O's would mysteriously not complete.
Well, you get the picture. The OS starts to lose its mind.

Harold Grovesteen

Post by Ivan Warren
PREFIX is irrelevant when only 1 CPU is active and MUST be used in a
multi CPU environment.
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
<http://groups.yahoo.com/;_ylc=X3oDMTJjZjJnY21jBF9TAzk3MzU5NzE0BGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEc2VjA2Z0cgRzbGsDZ2ZwBHN0aW1lAzExOTAyMzU2MTQ->
Change settings via the Web
<http://groups.yahoo.com/group/hercules-390/join;_ylc=X3oDMTJlZm4xbnVtBF9TAzk3MzU5NzE0BGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEc2VjA2Z0cgRzbGsDc3RuZ3MEc3RpbWUDMTE5MDIzNTYxNA-->
(Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest
| Switch format to Traditional
Visit Your Group
<http://groups.yahoo.com/group/hercules-390;_ylc=X3oDMTJjZ21tcWcxBF9TAzk3MzU5NzE0BGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEc2VjA2Z0cgRzbGsDaHBmBHN0aW1lAzExOTAyMzU2MTQ->
| Yahoo! Groups Terms of Use <http://docs.yahoo.com/info/terms/> |
Recent Activity
*
7
New Members
<http://groups.yahoo.com/group/hercules-390/members;_ylc=X3oDMTJlZHA5cW9wBF9TAzk3MzU5NzE0BGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEc2VjA3Z0bARzbGsDdm1icnMEc3RpbWUDMTE5MDIzNTYxNA-->
Visit Your Group
<http://groups.yahoo.com/group/hercules-390;_ylc=X3oDMTJkbDducmg5BF9TAzk3MzU5NzE0BGdycElkAzM0MjA2NARncnBzcElkAzE3MDcyODE5NDIEc2VjA3Z0bARzbGsDdmdocARzdGltZQMxMTkwMjM1NjE0>
Yahoo! Finance
It's Now Personal
<http://us.ard.yahoo.com/SIG=12j1rngrl/M=493064.10729649.11333340.8674578/D=groups/S=1707281942:NC/Y=YAHOO/EXP=1190242814/A=4507179/R=0/SIG=12de4rskk/*http://us.rd.yahoo.com/evt=50284/*http://finance.yahoo.com/personal-finance>
Guides, news,
advice & more.
Endurance Zone
A Fitness Group
<http://us.ard.yahoo.com/SIG=12jm8akbd/M=493064.11135487.11710473.8674578/D=groups/S=1707281942:NC/Y=YAHOO/EXP=1190242814/A=4834085/R=0/SIG=11ikjqbtm/*http://sports.groups.yahoo.com/group/accelerade/>
about overall
better endurance.
Beauty & Fashion
on Yahoo! Groups
<http://us.ard.yahoo.com/SIG=12jr8u2fr/M=493064.11135489.11710475.8674578/D=groups/S=1707281942:NC/Y=YAHOO/EXP=1190242814/A=4776344/R=0/SIG=11neles1v/*http://advision.webevents.yahoo.com/beautyandfashion/>
Share style tips
and advice.
.

Roger Bowler

2007-09-19 22:19:18 UTC

Post by Josef Sipek
And I know interrupts will not be fun to deal with, but it needs to
be done.

You must surely have missed off an ironic smiley here?

Interrupt handling must be one of the nicest aspects of S/360/370/390/z
systems programming. The architecture is satisfyingly well designed,
it's not at all like interrupt handling on a PC.

Good luck.
Roger Bowler

Josef Sipek

2007-09-19 22:54:35 UTC

Post by Josef Sipek
And I know interrupts will not be fun to deal with, but it needs to
be done.

You must surely have missed off an ironic smiley here?

I wasn't being sarcastic.

Post by Roger Bowler
Interrupt handling must be one of the nicest aspects of S/360/370/390/z
systems programming. The architecture is satisfyingly well designed,
it's not at all like interrupt handling on a PC.

I have't looked at the way S/360/370/390/z do it, and I am sure it's orders
of magnitude better than the PC - but then again, just about anything is
better than the PC :)

Josef 'Jeff' Sipek.

--
You measure democracy by the freedom it gives its dissidents, not the
freedom it gives its assimilated conformists.
- Abbie Hoffman

Roger Bowler

2007-09-16 21:36:18 UTC

Post by Tim Pinkawa
Some of the discussions on the list over the past week have sparked
interest in trying to write something very basic that I can IPL
Hercules with.

I'm pleased to see some interest in this. It was exactly what I had in
mind in 1999 when I said "You will have to write the operating system
or standalone program yourself, unless you can manage to obtain a
license from IBM to run one of their operating systems on your PC"
- http://www.hercules-390.org/hercfaq.html#1.02

When I wrote those words 8 years ago, I did imagine that Hercules
might inspire a few people to write some kind of standalone program or
operating system, spurred on by the non-availability of IBM software
licenses for personal use. However it did not work out like that in
practice.

So I was delighted to read Josef Sipek's recent message describing his
experiments in this area
- http://tech.groups.yahoo.com/group/hercules-390/message/51518

Post by Tim Pinkawa
In the simplest terms, I believe I would need an assembler that
outputs plain object code, correct?

Well, the assembler outputs object deck format (80 byte card images),
which isn't exactly plain object code, but is usable as an IPL deck
for standalone programs if you stick a 3-card loader on the front of
it [1]

Post by Tim Pinkawa
Is there an easy (and free) way to
develop this on an x86 PC and test with Hercules or would I need to
use something like IFOX00 and transfer the object code back to my PC
to test?

One way would be to do the assemblies with IFOX00 on MVS 3.8 and punch
the output directly to a file on your PC, by coding PARM='DECK,NOLOAD'
(or is it NOOBJECT which replaced NOLOAD at some point) and by coding
a //SYSPUNCH DD UNIT=00D statement, where 00D is defined as a card
punch (00D 3525 /home/tim/ipldeck.ebcdic) No need for a separate
MVS-to-PC transfer. You could punch the 3-card loader to 00D in a
preceding IEBGENER step.

Alternatively, some time back Harry Wahl was talking about a method of
generating standalone object code from a C program on the PC, but I
never saw this thing in action.
- http://tech.groups.yahoo.com/group/hercules-390/message/42652

Regards,
Roger Bowler
Hercules "the people's mainframe"

[1] I think the 3 card loader can be found somewhere in SYS1.SAMPLIB
Lynn Wheeler has an article about it:
- http://www.garlic.com/~lynn/2007f.html#1

Josef Sipek

2007-09-16 21:46:13 UTC

Post by Tim Pinkawa
Some of the discussions on the list over the past week have sparked
interest in trying to write something very basic that I can IPL
Hercules with.

I'm pleased to see some interest in this. It was exactly what I had in
mind in 1999 when I said "You will have to write the operating system
or standalone program yourself, unless you can manage to obtain a
license from IBM to run one of their operating systems on your PC"
- http://www.hercules-390.org/hercfaq.html#1.02
When I wrote those words 8 years ago, I did imagine that Hercules
might inspire a few people to write some kind of standalone program or
operating system, spurred on by the non-availability of IBM software
licenses for personal use. However it did not work out like that in
practice.
So I was delighted to read Josef Sipek's recent message describing his
experiments in this area
- http://tech.groups.yahoo.com/group/hercules-390/message/51518

My intension is to have an LPAR/zVM like hypervisor. From the discussion
about SIE few days ago, it doesn't seem all that hard.

I suppose now would be a good time to fix up the one last problem I have
with the code (and give it a name), and release it so others can help out :)

I use assembly to get a usable state, and then it's C (compiled with gcc) to
do the kernel. There's no kernel at the moment, I'm still trying to make the
loader working.

Post by Roger Bowler
Well, the assembler outputs object deck format (80 byte card images),
which isn't exactly plain object code, but is usable as an IPL deck
for standalone programs if you stick a 3-card loader on the front of
it [1]

Oh? It has the PSW in the first 8 bytes, and then 2 CCWs?

Post by Roger Bowler
One way would be to do the assemblies with IFOX00 on MVS 3.8 and punch
the output directly to a file on your PC, by coding PARM='DECK,NOLOAD'
(or is it NOOBJECT which replaced NOLOAD at some point) and by coding
a //SYSPUNCH DD UNIT=00D statement, where 00D is defined as a card
punch (00D 3525 /home/tim/ipldeck.ebcdic) No need for a separate
MVS-to-PC transfer. You could punch the 3-card loader to 00D in a
preceding IEBGENER step.

I'm completely incompetent when it comes to MVS, so I develop on linux
running under hercules - it's a whole lot easier than cross compiling
things.

Josef 'Jeff' Sipek.

--
Research, n.:
Consider Columbus:
He didn't know where he was going.
When he got there he didn't know where he was.
When he got back he didn't know where he had been.
And he did it all on someone else's money.

kerravon86

2010-08-01 14:14:31 UTC

Post by Tim Pinkawa
Some of the discussions on the list over the past week have sparked
interest in trying to write something very basic that I can IPL
Hercules with.

I'm pleased to see some interest in this. It was exactly what I had in
mind in 1999 when I said "You will have to write the operating system
or standalone program yourself, unless you can manage to obtain a
license from IBM to run one of their operating systems on your PC"
- http://www.hercules-390.org/hercfaq.html#1.02
When I wrote those words 8 years ago, I did imagine that Hercules
might inspire a few people to write some kind of standalone program or
operating system, spurred on by the non-availability of IBM software
licenses for personal use. However it did not work out like that in
practice.

Better late than never?

I've just uploaded pdos00.199, which is a bootable
3390 disk containing PDOS/370. There's a 31-bit
version available elsewhere as well.

Main code consists of ...

500 lines of C ...

http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/s370/pdos.c?view=markup

300 lines of assembler ...

http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/s370/pdossup.asm?view=markup

Other code to support stand-alone programs is in
PDPCLIB.

If anyone would like to alter the design etc before
it gets stuck in stone, now's the time. :-)

BFN. Paul.

22:40:33 * MSG FROM HERCULES: Welcome to PDOS!!!
22:40:33 * MSG FROM HERCULES: IPL device is 1b9
22:40:33 * MSG FROM HERCULES: PCOMM should reside on cylinder 2, head 0 of IPL device
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 24
22:40:33 * MSG FROM HERCULES: SVC code is 64
22:40:33 * MSG FROM HERCULES: SVC code is 27
22:40:33 * MSG FROM HERCULES: SVC code is 22
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 24
22:40:33 * MSG FROM HERCULES: SVC code is 64
22:40:33 * MSG FROM HERCULES: SVC code is 27
22:40:33 * MSG FROM HERCULES: SVC code is 22
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 24
22:40:33 * MSG FROM HERCULES: SVC code is 64
22:40:33 * MSG FROM HERCULES: SVC code is 27
22:40:33 * MSG FROM HERCULES: SVC code is 22
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: welcome to pcomm
22:40:33 * MSG FROM HERCULES: argc = 3
22:40:33 * MSG FROM HERCULES: arg 0 is <>
22:40:33 * MSG FROM HERCULES: arg 1 is <Hi>
22:40:33 * MSG FROM HERCULES: arg 2 is <There>
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 20
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 20
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 20
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 3
22:40:33 * MSG FROM HERCULES: return from PCOMM is 5

Mike Stramba

2010-08-01 14:56:35 UTC

Ok, I IPL'd it .... now what?

10:53:43 * MSG FROM HERCULES: PDOS should reside on cylinder 1, head 0 of IPL
10:53:43 * MSG FROM HERCULES: IPL device is 100
10:53:43 * MSG FROM HERCULES: Welcome to PDOS!!!
10:53:43 * MSG FROM HERCULES: IPL device is 100
10:53:43 * MSG FROM HERCULES: PCOMM should reside on cylinder 2, head 0 of IPL
10:53:43 * MSG FROM HERCULES: SVC code is 120
10:53:43 * MSG FROM HERCULES: SVC code is 120
10:53:43 * MSG FROM HERCULES: SVC code is 10
10:53:43 * MSG FROM HERCULES: SVC code is 120
10:53:43 * MSG FROM HERCULES: SVC code is 24
10:53:43 * MSG FROM HERCULES: SVC code is 64
10:53:43 * MSG FROM HERCULES: SVC code is 27 V
.......

I tried !foo and .foo .... get SCP not receiving cmds

Post by kerravon86

Post by Tim Pinkawa
Some of the discussions on the list over the past week have sparked
interest in trying to write something very basic that I can IPL
Hercules with.

I'm pleased to see some interest in this. It was exactly what I had in
mind in 1999 when I said "You will have to write the operating system
or standalone program yourself, unless you can manage to obtain a
license from IBM to run one of their operating systems on your PC"
- http://www.hercules-390.org/hercfaq.html#1.02
When I wrote those words 8 years ago, I did imagine that Hercules
might inspire a few people to write some kind of standalone program or
operating system, spurred on by the non-availability of IBM software
licenses for personal use. However it did not work out like that in
practice.

Better late than never?
I've just uploaded pdos00.199, which is a bootable
3390 disk containing PDOS/370. There's a 31-bit
version available elsewhere as well.
Main code consists of ...
500 lines of C ...
http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/s370/pdos.c?view=markup
300 lines of assembler ...
http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/s370/pdossup.asm?view=markup
Other code to support stand-alone programs is in
PDPCLIB.
If anyone would like to alter the design etc before
it gets stuck in stone, now's the time. :-)
BFN. Paul.
22:40:33 * MSG FROM HERCULES: Welcome to PDOS!!!
22:40:33 * MSG FROM HERCULES: IPL device is 1b9
22:40:33 * MSG FROM HERCULES: PCOMM should reside on cylinder 2, head 0 of IPL device
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 24
22:40:33 * MSG FROM HERCULES: SVC code is 64
22:40:33 * MSG FROM HERCULES: SVC code is 27
22:40:33 * MSG FROM HERCULES: SVC code is 22
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 24
22:40:33 * MSG FROM HERCULES: SVC code is 64
22:40:33 * MSG FROM HERCULES: SVC code is 27
22:40:33 * MSG FROM HERCULES: SVC code is 22
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 24
22:40:33 * MSG FROM HERCULES: SVC code is 64
22:40:33 * MSG FROM HERCULES: SVC code is 27
22:40:33 * MSG FROM HERCULES: SVC code is 22
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: welcome to pcomm
22:40:33 * MSG FROM HERCULES: argc = 3
22:40:33 * MSG FROM HERCULES: arg 0 is <>
22:40:33 * MSG FROM HERCULES: arg 1 is <Hi>
22:40:33 * MSG FROM HERCULES: arg 2 is <There>
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 20
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 20
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 20
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 3
22:40:33 * MSG FROM HERCULES: return from PCOMM is 5

kerravon86

2010-08-01 15:15:41 UTC

Post by Mike Stramba
Ok, I IPL'd it .... now what?
10:53:43 * MSG FROM HERCULES: PDOS should reside on cylinder 1, head 0 of IPL
10:53:43 * MSG FROM HERCULES: IPL device is 100
10:53:43 * MSG FROM HERCULES: Welcome to PDOS!!!
10:53:43 * MSG FROM HERCULES: IPL device is 100

What is your device 100? I tested with this:

01b9 3390 dasd/pdos00.199

It's only designed to work with a 3390.

Post by Mike Stramba
10:53:43 * MSG FROM HERCULES: PCOMM should reside on cylinder 2, head 0 of IPL
10:53:43 * MSG FROM HERCULES: SVC code is 120
10:53:43 * MSG FROM HERCULES: SVC code is 120
10:53:43 * MSG FROM HERCULES: SVC code is 10
10:53:43 * MSG FROM HERCULES: SVC code is 120
10:53:43 * MSG FROM HERCULES: SVC code is 24
10:53:43 * MSG FROM HERCULES: SVC code is 64
10:53:43 * MSG FROM HERCULES: SVC code is 27 V
.......

I'm unsure whether the above is all you got,
and you're reporting a bug, or whether it
completed as expected. If it ends successfully,
it has a wait state of x'444'.

Post by Mike Stramba
I tried !foo and .foo .... get SCP not receiving cmds

It doesn't do any more than run an MVS executable
(with caveats) and then end. It doesn't speak to
a console yet, if that was your expectation.

That is next thing on the cards though, unless
there is some restructure required.

BFN. Paul.

Post by Mike Stramba

Post by kerravon86

Post by Tim Pinkawa
Some of the discussions on the list over the past week have sparked
interest in trying to write something very basic that I can IPL
Hercules with.

I'm pleased to see some interest in this. It was exactly what I had in
mind in 1999 when I said "You will have to write the operating system
or standalone program yourself, unless you can manage to obtain a
license from IBM to run one of their operating systems on your PC"
- http://www.hercules-390.org/hercfaq.html#1.02
When I wrote those words 8 years ago, I did imagine that Hercules
might inspire a few people to write some kind of standalone program or
operating system, spurred on by the non-availability of IBM software
licenses for personal use. However it did not work out like that in
practice.

Better late than never?
I've just uploaded pdos00.199, which is a bootable
3390 disk containing PDOS/370. There's a 31-bit
version available elsewhere as well.
Main code consists of ...
500 lines of C ...
http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/s370/pdos.c?view=markup
300 lines of assembler ...
http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/s370/pdossup.asm?view=markup
Other code to support stand-alone programs is in
PDPCLIB.
If anyone would like to alter the design etc before
it gets stuck in stone, now's the time. :-)
BFN. Paul.
22:40:33 * MSG FROM HERCULES: Welcome to PDOS!!!
22:40:33 * MSG FROM HERCULES: IPL device is 1b9
22:40:33 * MSG FROM HERCULES: PCOMM should reside on cylinder 2, head 0 of IPL device
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 24
22:40:33 * MSG FROM HERCULES: SVC code is 64
22:40:33 * MSG FROM HERCULES: SVC code is 27
22:40:33 * MSG FROM HERCULES: SVC code is 22
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 24
22:40:33 * MSG FROM HERCULES: SVC code is 64
22:40:33 * MSG FROM HERCULES: SVC code is 27
22:40:33 * MSG FROM HERCULES: SVC code is 22
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 24
22:40:33 * MSG FROM HERCULES: SVC code is 64
22:40:33 * MSG FROM HERCULES: SVC code is 27
22:40:33 * MSG FROM HERCULES: SVC code is 22
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: welcome to pcomm
22:40:33 * MSG FROM HERCULES: argc = 3
22:40:33 * MSG FROM HERCULES: arg 0 is <>
22:40:33 * MSG FROM HERCULES: arg 1 is <Hi>
22:40:33 * MSG FROM HERCULES: arg 2 is <There>
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 20
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 20
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 20
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 10
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 120
22:40:33 * MSG FROM HERCULES: SVC code is 3
22:40:33 * MSG FROM HERCULES: return from PCOMM is 5

Roger Bowler

2007-09-16 21:57:15 UTC

Rafael Pereira has some interesting stuff about standalone loaders:

http://perso.wanadoo.es/rptv2005/en/index.html

Regards,
Roger Bowler

vmdave9

2007-09-16 23:24:20 UTC

Tim,

for a very good and easy to understand introduction on how
to develop stand alone S/390 programs, take a look at Rafa
Tercero's web site at:

http://perso.wanadoo.es/rptv2005/en/index.html

He has examples of both a simple stand alone loader (which
can be used to load other stand alone programs) and a stand
alone game of tic-tac-toe. They work on both in a Hercules
or real hardware environment, as well as a guest of VM. Yes,
you too, can bring up tic-tac-toe in an LPAR on your z9
box....:-)

Hope this helps.

Ivan Warren

2007-09-16 23:11:33 UTC

.. RESEND.. BECAUSE Yahoo Groups ate up the last copy ...

Post by Tim Pinkawa
Some of the discussions on the list over the past week have sparked
interest in trying to write something very basic that I can IPL
Hercules with.
In the simplest terms, I believe I would need an assembler that
outputs plain object code, correct? Is there an easy (and free) way to
develop this on an x86 PC and test with Hercules or would I need to
use something like IFOX00 and transfer the object code back to my PC
to test?
I've never really done anything like this before so I apologize for
the dumb questions. :)
Tim

The only dumb questions are the ones you don't ask right ?

Anyway.. I've always found the easiest way to build IPL programs is with
VM (I'm a VM guy, so this may explain that).. And usually I do this
using tapes which allows me to test my IPL'able programs directly within
VM or "natively" in hercules. Also, VM has a nice little file (DMKBSL
aka 3CARD LOADER S2) that you can prepend to a simple[1] assembler
output deck.. This little 240 bytes utility will load your text deck (no
matter how long it is) into memory and jump into it.

Considering you can also IPL card decks, and since the internal
structure of card decks is as simple as it can be, you may also elect to
do this from the host (the architecture of the host is irrelevant
here).. although you are still going something to convert the program to
IPL by itself into S/370-S/390-z/Arch code (this all depends on the
language you inted to use).. But eventually.. somehow.. you are going to
need to do a bit of assembler if you want to do I/O & such.

Now .. building the IPL record (the first 24 bytes of the first block on
the device to IPL) is easy.. (just a PSW and 2 CCWs).. and can be done
from the host. The rest.. probably needs a pass through IFOX00 (or some
uncanny magic !)

--Ivan

[1] The text deck must be simple : No ESD and no RLD (which are ignored)
and only the TXT and END cards are used. The 'END' card must have the
location of the start of the program.. So it usually looks something like :

FOO CSECT *
ORG *+20000
START DS 0H
... Your program ...
END START

Ivan Warren

2007-09-16 21:40:51 UTC

peter_flass

2007-09-17 11:18:06 UTC

In _Operating Sytems_ Madnick and Donavan describe a message passing
OS for S/360, with complete source. Many years ago I inputted the
source, and there's a copy here in Files as "Madnick.zip". By the
time I inputted it, the 360 had been replaced by the 370 and I had to
change a bit of code that assumed 2K pages to 4K. At this remove I
can't remember which version I uploaded, but the changes were minor in
any case.

To run the OS under VM I wrote my own "3-card loader" in Files as
"ipl.zip". This version requires VM to determine the memory size, but
is otherwise pure stand-alone. It will (IIRC) directly load a TEXT
(object) deck generated by the assembler. You just assemble the
program with 'ORG 0' (or no ORG).

Madnick and Donavan should be available from ABEBooks or Amazon if
yo're interested.

Ian S. Worthington

2007-09-18 19:59:18 UTC

I know it works on Flex, at least under VM. No reason to suspect native
wouldnt work. IIRC zTPF would *need* VM to get QDIO support as Hercules can't
emulate an OSA Express card. You should be able to get a copy of ACP from
somewhere though and play with that instead should the fancy take you.

i

------ Original Message ------
Received: Tue, 18 Sep 2007 07:45:54 PM BST
From: Andre Rosenthal <Andre_rosenthal-***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Subject: [hercules-390] Availability of TPF (either 2 or 4) under Hercules?

Post by Andre Rosenthal
Yall
I just added myself to this list so pardon if this has been already asked. I

spent many moons under the TPF OS and am wondering if anyone has ever heard of
a port onto Hercules.

Post by Andre Rosenthal
Best regards, Andre Rosenthal

Andre Rosenthal

2007-09-18 21:17:30 UTC

however I do not even know where one goes to get a copy of ACP or ALCS... Since z/tpf is already released I thought it would be fun to find the TPF 2.x or even the TPF 4.1 in download form.

Anyone knows where these bits may live?
Best regards, Andre Rosenthal

To: hercules-390-hHKSG33Tihig7M29m/***@public.gmane.org: IanWorthington-***@public.gmane.org: Tue, 18 Sep 2007 20:59:18 +0100Subject: Re: [hercules-390] Availability of TPF (either 2 or 4) under Hercules?

I know it works on Flex, at least under VM. No reason to suspect nativewouldnt work. IIRC zTPF would *need* VM to get QDIO support as Hercules can'temulate an OSA Express card. You should be able to get a copy of ACP fromsomewhere though and play with that instead should the fancy take you.i------ Original Message ------Received: Tue, 18 Sep 2007 07:45:54 PM BSTFrom: Andre Rosenthal <Andre_rosenthal-***@public.gmane.org>To: <hercules-390-***@public.gmane.org>Subject: [hercules-390] Availability of TPF (either 2 or 4) under Hercules?> Yall> > I just added myself to this list so pardon if this has been already asked. Ispent many moons under the TPF OS and am wondering if anyone has ever heard ofa port onto Hercules.> > Best regards, Andre Rosenthal

[Non-text portions of this message have been removed]

Mike Schwab

2007-09-18 22:01:43 UTC

http://en.wikipedia.org/wiki/Airlines_Control_Program
http://www.blackbeard.com/tpf/tpfhist.htm

Post by Ian S. Worthington
I know it works on Flex, at least under VM. No reason to suspect native
wouldnt work. IIRC zTPF would *need* VM to get QDIO support as Hercules can't
emulate an OSA Express card. You should be able to get a copy of ACP from
somewhere though and play with that instead should the fancy take you.
i

--
Mike A Schwab, Springfield IL USA http://geocities.com/maschwab/ for
software links

Peter Sylvester

2007-09-20 15:50:49 UTC

Does any have access to the the book from W.T Batten

Understanding the IBM 360 and 370 Computers,
With Machine Language Programming
(ISBN: 0139360964)

I remember that there are some nice example standalone programs in it
like a stand alone dump on printer and others.

30 years ago I tried some on a real machine. Was nice to
understand the architecture at the real low level, and not just
inside an operating system.

[Non-text portions of this message have been removed]

Josef Sipek

2007-09-20 18:05:16 UTC

Post by Peter Sylvester
Does any have access to the the book from W.T Batten
Understanding the IBM 360 and 370 Computers,
With Machine Language Programming
(ISBN: 0139360964)

My university library seems to have a copy.

Post by Peter Sylvester
I remember that there are some nice example standalone programs in it
like a stand alone dump on printer and others.
30 years ago I tried some on a real machine. Was nice to
understand the architecture at the real low level, and not just
inside an operating system.

Nice. I'll go and check it out later today :)

Josef 'Jeff' Sipek.

--
A computer without Microsoft is like chocolate cake without mustard.

Josef Sipek

2007-09-20 18:48:18 UTC

Post by Peter Sylvester
Does any have access to the the book from W.T Batten
Understanding the IBM 360 and 370 Computers,
With Machine Language Programming
(ISBN: 0139360964)

My university library seems to have a copy.

Gah! False alarm. They tossed it but didn't update their database fully. :-/

Josef 'Jeff' Sipek.

--
You measure democracy by the freedom it gives its dissidents, not the
freedom it gives its assimilated conformists.
- Abbie Hoffman

Mike Bell

2007-09-20 18:58:32 UTC

there are several copies listed on amazon.com

Mike

-----Original Message-----
From: hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] On
Behalf Of Josef Sipek
Sent: Thursday, September 20, 2007 1:48 PM
To: hercules-390-***@public.gmane.org
Subject: Re: [hercules-390] OS Design for Hercules

Post by Peter Sylvester
Does any have access to the the book from W.T Batten
Understanding the IBM 360 and 370 Computers,
With Machine Language Programming
(ISBN: 0139360964)

My university library seems to have a copy.

Gah! False alarm. They tossed it but didn't update their database fully. :-/

Josef 'Jeff' Sipek.

--
You measure democracy by the freedom it gives its dissidents, not the
freedom it gives its assimilated conformists.
- Abbie Hoffman

Harold Grovesteen

2007-09-21 02:49:36 UTC

What are you typing? When I search on amazon.com all I get is one
listing with "unavailalbe."

Harold Grovesteen

Post by Mike Bell
there are several copies listed on amazon.com
Mike
-----Original Message-----
Behalf Of Josef Sipek
Sent: Thursday, September 20, 2007 1:48 PM
Subject: Re: [hercules-390] OS Design for Hercules

Post by Peter Sylvester
Does any have access to the the book from W.T Batten
Understanding the IBM 360 and 370 Computers,
With Machine Language Programming
(ISBN: 0139360964)

My university library seems to have a copy.

Gah! False alarm. They tossed it but didn't update their database fully. :-/
Josef 'Jeff' Sipek.

Fish

2007-09-21 07:57:22 UTC

(reply reformatted, since I absolutely LOATHE top-posting and people
who don't trim their posts...)

(below retained for context / instructional purposes)

Post by Harold Grovesteen

Post by Mike Bell

Post by Peter Sylvester
Does any have access to the the book from W.T Batten
Understanding the IBM 360 and 370 Computers,
With Machine Language Programming
(ISBN: 0139360964)

My university library seems to have a copy.

Gah! False alarm. They tossed it but didn't update their
database fully. :-/

there are several copies listed on amazon.com
Mike

What are you typing? When I search on amazon.com all I get
is one listing with "unavailalbe."

Try:

http://www.amazon.co.uk/Understanding-360-370-Computers-Programming/dp
/0139360964

Or:

http://s1.amazon.ca/exec/varzea/sdp/sai-condition/0139360964/058-44131
79-4473433?_encoding=UTF8&coliid=&qid=&sr=&colid=

It's not Amazon.com, but there's also:

http://www.bookfinder4u.com/detail/0471886572.html

Basically I just did a Google for: "ISBN: 0139360964". <shrug>

- --
"Fish" (David B. Trout) - fish(at)infidels.org
Fight Spam! Join CAUCE! <http://www.cauce.org/>
(Any HTML email received will be deleted unread)
PGP key fingerprints:
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

Fish

2007-09-21 08:25:28 UTC

Post by Fish
(reply reformatted, since I absolutely LOATHE top-posting
and people who don't trim their posts...)

[..]

FYI: that isn't meant as a harsh complaint to you or anyone else,
Harold! (just in case any of you thought I was in a bitchy mood or
something (which I'm not!)). It was only meant as a friendly reminder
to all concerned, that's all.

My apologies ahead of time if my [perhaps poor?] choice of words (use
of the word "LOATHE") offends/upsets anyone since that was not my
intent.

- --
"Fish" (David B. Trout) - fish(at)infidels.org
Fight Spam! Join CAUCE! <http://www.cauce.org/>
(Any HTML email received will be deleted unread)
PGP key fingerprints:
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

Harold Grovesteen

2007-09-21 14:09:27 UTC

Unfortunately, whatever you did to reformat the message, Netscape will
not allow bottom posting. I run into that problem alot with the Yahoo
group emails. Sometimes I can not even edit in-line.

I searched many times on Amazon and got nothing. Having the ISBN must
have helped, which I did not have. Also, the amounts came up in pounds
so maybe Amazon limited my searches to the US. Who knows?

Anyway, I ordered a copy from alibris as someone else suggested.

Harold

BTW, it probably isn't healthy to loathe that many people in the world.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(reply reformatted, since I absolutely LOATHE top-posting and people
who don't trim their posts...)
(below retained for context / instructional purposes)

Post by Harold Grovesteen

Post by Mike Bell

Post by Peter Sylvester
Does any have access to the the book from W.T Batten
Understanding the IBM 360 and 370 Computers,
With Machine Language Programming
(ISBN: 0139360964)

My university library seems to have a copy.

Gah! False alarm. They tossed it but didn't update their
database fully. :-/

there are several copies listed on amazon.com
Mike

What are you typing? When I search on amazon.com all I get
is one listing with "unavailalbe."

http://www.amazon.co.uk/Understanding-360-370-Computers-Programming/dp
/0139360964
http://s1.amazon.ca/exec/varzea/sdp/sai-condition/0139360964/058-44131
79-4473433?_encoding=UTF8&coliid=&qid=&sr=&colid=
http://www.bookfinder4u.com/detail/0471886572.html
Basically I just did a Google for: "ISBN: 0139360964". <shrug>
- --
"Fish" (David B. Trout) - fish(at)infidels.org
Fight Spam! Join CAUCE! <http://www.cauce.org/>
(Any HTML email received will be deleted unread)
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBRvN5Ykj11/TE7j4qEQL9YgCdHLzwFuVem0zxLNJWCvthzDucJHcAoI3o
3N6CwsNx5G3mbLVbYCKlH8vl
=yaiK
-----END PGP SIGNATURE-----
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links

Harold Grovesteen

2007-09-21 02:39:48 UTC

That book doesn't seem to be available even used on Amazon. When it
came out and I got a copy of it, it really helped me to understand how
all of this worked. The new generation of mainframers could no doubt
use this book.

Harold Grovesteen

Post by Peter Sylvester
Does any have access to the the book from W.T Batten
Understanding the IBM 360 and 370 Computers,
With Machine Language Programming
(ISBN: 0139360964)
I remember that there are some nice example standalone programs in it
like a stand alone dump on printer and others.
30 years ago I tried some on a real machine. Was nice to
understand the architecture at the real low level, and not just
inside an operating system.

[Non-text portions of this message have been removed]

zenith89

2007-09-21 06:12:03 UTC

That book doesn't seem to be available even used on Amazon....

FYI, I found 4 copies listed on Alibris.com.

peter_flass

2007-09-21 22:15:12 UTC

Post by Harold Grovesteen
That book doesn't seem to be available even used on Amazon. When it
came out and I got a copy of it, it really helped me to understand how
all of this worked. The new generation of mainframers could no doubt
use this book.
Harold Grovesteen

Post by Peter Sylvester
Does any have access to the the book from W.T Batten
Understanding the IBM 360 and 370 Computers,
With Machine Language Programming
(ISBN: 0139360964)

ABE Books has a copy, but they want $66! Any good mainframe
programming book appears to be expensive.

dave

2007-09-16 22:06:35 UTC