OS Design for Hercules

[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

[Josef Sipek]

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

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

> 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 ;)

> 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.

> 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.

[Roger Bowler]

--- In hercules-390@..., Tim Pinkawa wrote:
> 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

> 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]

> 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]

On Sun, Sep 16, 2007 at 05:19:00PM -0400, Josef Sipek wrote:

> On Sun, Sep 16, 2007 at 02:33:23PM -0500, Tim Pinkawa wrote:
> ...
>
> Shhh...don't tell anyone, but I'm writing an OS ;)
>
> > 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 ;)
>
> > 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.

 
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]

Tim Pinkawa wrote:

> 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

[Josef Sipek]

On Sun, Sep 16, 2007 at 09:36:18PM -0000, Roger Bowler wrote:

> --- In hercules-390@..., Tim Pinkawa wrote:
> > 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.

> 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?

> 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.

[Ivan Warren]

Josef Sipek wrote:

> 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 :)
>
>  

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

[Roger Bowler]

Rafael Pereira has some interesting stuff about standalone loaders:

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

Regards,
Roger Bowler

[Dave Jones-9]

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.

----- Original Message Follows -----
From: "Tim Pinkawa" <timpinkawa@...>
To: hercules-390@...
Subject: [hercules-390] OS Design for Hercules
Date: Sun, 16 Sep 2007 14:33:23 -0500

> 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
>

[Ivan Warren]

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

Tim Pinkawa wrote:

> 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

[Josef Sipek]

On Sun, Sep 16, 2007 at 11:52:00PM +0200, Ivan Warren wrote:

> Josef Sipek wrote:
> > 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 :)
> >
> >  
> 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? ;)

> 2) Does binutil's 'as' support control instructions ? (SSCH, LCTL, etc..)

Haven't tried it.

> 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)

[Dave Jones-9]

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.

[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

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

[Ivan Warren]

Tim Pinkawa wrote:
> CCW2:
> 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

[Josef Sipek]

On Sun, Sep 16, 2007 at 09:06:27PM -0500, Tim Pinkawa wrote:

> 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.

> 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.

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

> 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.

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
        ^

> 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.

> 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.

> 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.

[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.

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

[Tim Pinkawa]

On 9/16/07, Josef Sipek <jsipek@...> wrote:
> 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

[Mike Schwab]

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@...> wrote:
>
<deleted>

>  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

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

[royfusa1946]

--- In hercules-390@..., Josef Sipek <jsipek@...> wrote:

>
> On Sun, Sep 16, 2007 at 09:06:27PM -0500, Tim Pinkawa wrote:
> > 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.
>
> > 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.
>
> The 80000018 is address 0x18, with 31-bit addressing. The 360 was

the one
> with only 24-bit addressing, right? That should work.
>
> > 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.
>
> 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
>         ^
>
> > 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.
>
> > 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.
>
> > 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]

Tim Pinkawa wrote:

> On 9/16/07, Josef Sipek <jsipek@...> wrote:
>  
>> 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.
>>    
>
>
> 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?
>  

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.

> 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.