Discussion:
Z arch I/O programming info
(too old to reply)
mstramba2000
2010-04-15 15:02:23 UTC
Permalink
I'm trying to get up to speed with Z/Arch I/O programming, I have Z-Arch Principles-Operation, and ABC of Z/oS Sys Programming (Vol 10 seems to be relevant).

Are there any other redbooks /etc a.k.a. "Channel programmers's guide" or something similar ?

I've tried to start with a "bare bones" "Hello World" to a 3215 :
but am getting no output, and nothing stored from the STSCH.

I 'hand loaded' the code into hercules using the script command,
then did a psw cmwp=C, psw ia=2000, start.

Do I need to setup some other control regs, or have to IPL, or
some other intialization?

LG R1,SUBID
SSCH ORBW1
STSCH SCIB


SCIB DC 12F'0'


SUBID DC F'0'
DC X'0'
DC X'1'
DC X'0'
DC X'9'


ORBW1 DS 0D
DC F'0'
DC F'0'
DC X'00'
DC AL3(CCWWRTG)


I also found this site, which has some good code examples :

http://www.josefsipek.net/projects/hvf/

"HVF operating system
HVF aims to be a hypervisor OS for z/Architecture systems.

It is currently in a very heavy development, and large portions are not yet implemented.

The initial development was done with Hercules, an open source emulator (supporting almost everything z/Architecture has to offer), but since I've gotten a z/VM 5.2 account (thank you Dave Jones), more and more testing and debugging happens on a real mainframe. This makes development easier, and forces me to make sure that it actually works on real hardware :)"
Ivan Warren
2010-04-15 15:21:30 UTC
Permalink
Post by mstramba2000
I'm trying to get up to speed with Z/Arch I/O programming, I have Z-Arch Principles-Operation, and ABC of Z/oS Sys Programming (Vol 10 seems to be relevant).
Are there any other redbooks /etc a.k.a. "Channel programmers's guide" or something similar ?
but am getting no output, and nothing stored from the STSCH.
There is something you need to do 1st..

All subchannels (except for the IPL device if an IPL is issued) are in a
*disabled* state upon a system reset (which implies an I/O reset which
disables the subchannels). In a disabled state, a subchannel won't
accept SSCH and will not produce interrupts. A POR (Power On Reset) has
the same effect (all subchannels are disabled).

It is therefore necessary to 1st issue something like :
...
L 1,MYSSID (you must determine this 1st - see below)
STSCH MYSCHIB Store SCHIB
OI MYSCHIB+5,X'80' (turn E bit on in PMCW portion of the SCHIB)
MSCH MYSCHIB Modify Subchannel with altered SCHIB
...
MYSCHIB DS 12F

Now.. The Subsystem ID (GPR1 for I/O instruction is NOT the device
number.. The device number can be determined during the STSCH
instruction (bytes @ +6 and +7 in the SCHIB) - and a SSID always has bit
16 set to 1. (so X'00010000' is a valid SSID, but X'00000000' is not).

See chapters 14 and 15 of the z/Arch POO.

--Ivan


[Non-text portions of this message have been removed]
Mike Stramba
2010-04-15 16:03:27 UTC
Permalink
Ivan,

Thanks !

I'll work on the stuff you posted.

On page 14-1 :
"When the multiple-subchannel set (MSS) facility is
installed, the format of the subsystem-identification
word is as follows:"

Is MSS implemented in Hecules 3.07 ?

If so, is the default for it to be enabled ? ... is there a config
setting for it?

Mike
Post by Ivan Warren
Post by mstramba2000
I'm trying to get up to speed with Z/Arch I/O programming, I have Z-Arch
Principles-Operation, and ABC of Z/oS Sys Programming (Vol 10 seems to be
relevant).
Are there any other redbooks /etc a.k.a. "Channel programmers's guide" or
something similar ?
but am getting no output, and nothing stored from the STSCH.
There is something you need to do 1st..
All subchannels (except for the IPL device if an IPL is issued) are in a
*disabled* state upon a system reset (which implies an I/O reset which
disables the subchannels). In a disabled state, a subchannel won't
accept SSCH and will not produce interrupts. A POR (Power On Reset) has
the same effect (all subchannels are disabled).
...
L 1,MYSSID (you must determine this 1st - see below)
STSCH MYSCHIB Store SCHIB
OI MYSCHIB+5,X'80' (turn E bit on in PMCW portion of the SCHIB)
MSCH MYSCHIB Modify Subchannel with altered SCHIB
...
MYSCHIB DS 12F
Now.. The Subsystem ID (GPR1 for I/O instruction is NOT the device
number.. The device number can be determined during the STSCH
16 set to 1. (so X'00010000' is a valid SSID, but X'00000000' is not).
See chapters 14 and 15 of the z/Arch POO.
--Ivan
[Non-text portions of this message have been removed]
Ivan Warren
2010-04-15 16:20:12 UTC
Permalink
Post by Mike Stramba
"When the multiple-subchannel set (MSS) facility is
installed, the format of the subsystem-identification
word is as follows:"
Is MSS implemented in Hecules 3.07 ?
MSS has been implemented for quite some time.

As a matter of fact, the *FULL* definition of a device (as per a config
statement or an "attach" command) is :

n:xxxx where 'n' is the subchannel set identification (n defaults to 0
if it is not specified).

Bits 13 and 14 (or 45 & 46 on a 64 bit system) indicate the subchannel
set identification in the subsystem identification word.

The Subchannel set identification and the subchannel number - and bit
15/47 set to 1 give an SSID.

This is fully supported in hercules.

So,

0009 3215
is the same as
0:0009 3215
but
1:0009 3215 is a different device

(Note that the number following subchannel set identification is a
*DEVICE NUMBER* - Not a subchannel number). In hercules (for the time
being), subchannels are numbered in the order they are encountered in
the configuration on each subchannel set. Therefore, if the device
configuration portion of your hercules config has :

...
0009 3215
001F 3270
...

Then Device 0009 will be subchannel ID 0 (that is SSID 00010000), and
device 001F will have a subchannel ID of 1 (00010001).

If you have

....
0:0009 3215
1:0009 3270
....
Then device 0:0009 will be subchannel 0 on SS 0 (that is SSID 00010000)
and 1:0009 will be subchannel 0 on SS1 (that is SSID 00030000)

--Ivan


[Non-text portions of this message have been removed]
Mike Stramba
2010-04-15 16:44:15 UTC
Permalink
Ivan,

Thanks again !

(One of) the other "loose ends" is the idea of channel paths.

How are they handled in Hercules ?

Mike
Post by Ivan Warren
Post by Mike Stramba
"When the multiple-subchannel set (MSS) facility is
installed, the format of the subsystem-identification
word is as follows:"
Is MSS implemented in Hecules 3.07 ?
MSS has been implemented for quite some time.
As a matter of fact, the *FULL* definition of a device (as per a config
n:xxxx where 'n' is the subchannel set identification (n defaults to 0
if it is not specified).
Bits 13 and 14 (or 45 & 46 on a 64 bit system) indicate the subchannel
set identification in the subsystem identification word.
The Subchannel set identification and the subchannel number - and bit
15/47 set to 1 give an SSID.
This is fully supported in hercules.
So,
0009 3215
is the same as
0:0009 3215
but
1:0009 3215 is a different device
(Note that the number following subchannel set identification is a
*DEVICE NUMBER* - Not a subchannel number). In hercules (for the time
being), subchannels are numbered in the order they are encountered in
the configuration on each subchannel set. Therefore, if the device
...
0009 3215
001F 3270
...
Then Device 0009 will be subchannel ID 0 (that is SSID 00010000), and
device 001F will have a subchannel ID of 1 (00010001).
If you have
....
0:0009 3215
1:0009 3270
....
Then device 0:0009 will be subchannel 0 on SS 0 (that is SSID 00010000)
and 1:0009 will be subchannel 0 on SS1 (that is SSID 00030000)
--Ivan
[Non-text portions of this message have been removed]
Ivan Warren
2010-04-15 18:28:57 UTC
Permalink
Post by Mike Stramba
Ivan,
Thanks again !
(One of) the other "loose ends" is the idea of channel paths.
How are they handled in Hercules ?
Mike
The notion of "Channel Path" is totally artificial under hercules
because there is no actual "channel" involved.

Effectively, all devices are actually operating under their own channel
path (which is in effect a combination of locks, conditions and control
blocks). More accurately, you could say that each device has its own
control unit and is attached to its own private channel path.

However, as seen by a program running under hercules, each device is
seen as being accessible by a single Channel Path. The Channel Path ID
is identical to the 1st 2 digits of the device number (hence, device
X'6790' would be seen as being on CHPID X'67'). Each device has a single
Channel Path (as seen in the PAM/POM fields in the SCHIB)

Providing more than 1 "emulated" channel path makes no sense in the
current implementation (because a channel path is never "busy").
Multiple channel path only make sense if a channel path can fail or if a
channel path can become too busy to service an I/O request - for example
when servicing a burst data transfer.

--Ivan


[Non-text portions of this message have been removed]
Mike Stramba
2011-08-31 06:26:11 UTC
Permalink
Hi guys,

I'm "revisiting" this experiment, and trying to get it working under
the z/VM eval system.

Where would I find the sub channel ID for a VM's console ?

I'm guessing the answer might be in a z/VM system programmer manual ?
... in maybe a system call or macro?

I'm now looking for the manual(s) to look for the info

thx
Post by Ivan Warren
Post by mstramba2000
I'm trying to get up to speed with Z/Arch I/O programming, I have Z-Arch
Principles-Operation, and ABC of Z/oS Sys Programming (Vol 10 seems to be
relevant).
Are there any other redbooks /etc a.k.a. "Channel programmers's guide" or
something similar ?
but am getting no output, and nothing stored from the STSCH.
There is something you need to do 1st..
All subchannels (except for the IPL device if an IPL is issued) are in a
*disabled* state upon a system reset (which implies an I/O reset which
disables the subchannels). In a disabled state, a subchannel won't
accept SSCH and will not produce interrupts. A POR (Power On Reset) has
the same effect (all subchannels are disabled).
...
L 1,MYSSID (you must determine this 1st - see below)
STSCH MYSCHIB Store SCHIB
OI MYSCHIB+5,X'80' (turn E bit on in PMCW portion of the SCHIB)
MSCH MYSCHIB Modify Subchannel with altered SCHIB
...
MYSCHIB DS 12F
Now.. The Subsystem ID (GPR1 for I/O instruction is NOT the device
number.. The device number can be determined during the STSCH
16 set to 1. (so X'00010000' is a valid SSID, but X'00000000' is not).
See chapters 14 and 15 of the z/Arch POO.
--Ivan
[Non-text portions of this message have been removed]
Harold Grovesteen
2011-08-31 09:27:24 UTC
Permalink
You can determine the device number from a VM diagnose. There are a
couple of options there I think. Check the CP manual.

For the SCHID, I found there is no option other than looping through the
valid schid's and doing a STSCH. Look into the SCHIB for the device
number you determined from the DIAGNOSE and when they match you found
it. Start with SCHID X'00010000' and increment by one. You are at the
end of the devices when STSCH returns CC==3. You will have to enable it
when you find it as you have in the code below.

Harold Grovesteen
Post by Mike Stramba
Hi guys,
I'm "revisiting" this experiment, and trying to get it working under
the z/VM eval system.
Where would I find the sub channel ID for a VM's console ?
I'm guessing the answer might be in a z/VM system programmer manual ?
... in maybe a system call or macro?
I'm now looking for the manual(s) to look for the info
thx
Post by Ivan Warren
Post by mstramba2000
I'm trying to get up to speed with Z/Arch I/O programming, I have Z-Arch
Principles-Operation, and ABC of Z/oS Sys Programming (Vol 10 seems to be
relevant).
Are there any other redbooks /etc a.k.a. "Channel programmers's guide" or
something similar ?
but am getting no output, and nothing stored from the STSCH.
There is something you need to do 1st..
All subchannels (except for the IPL device if an IPL is issued) are in a
*disabled* state upon a system reset (which implies an I/O reset which
disables the subchannels). In a disabled state, a subchannel won't
accept SSCH and will not produce interrupts. A POR (Power On Reset) has
the same effect (all subchannels are disabled).
...
L 1,MYSSID (you must determine this 1st - see below)
STSCH MYSCHIB Store SCHIB
OI MYSCHIB+5,X'80' (turn E bit on in PMCW portion of the SCHIB)
MSCH MYSCHIB Modify Subchannel with altered SCHIB
...
MYSCHIB DS 12F
Now.. The Subsystem ID (GPR1 for I/O instruction is NOT the device
number.. The device number can be determined during the STSCH
16 set to 1. (so X'00010000' is a valid SSID, but X'00000000' is not).
See chapters 14 and 15 of the z/Arch POO.
--Ivan
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
Ivan Warren
2011-08-31 09:34:30 UTC
Permalink
Use DIAG 24 (X'84xy0024) with Rx set to ffffffff on entry. On return, Rx
will indicate the device number of the VM console. You still need to
scan all SSIDs to determine the SSID of the device which matches.
Something like :

L 2,=X'ffffffff'
DC X'84100024'
L 1,=X'00010000'
LOOPSCAN DS 0H
STSCH SCHIB
BNZ NOCONS - NOTE - If you happen to have 65535*4 devices but no VM
console, then a program interrupt will occur on STSCH
CLM 2,B'0011',SCHIB+2
BZ CONSFOUND
LA 2,1(2)
B LOOPSCAN
CONSFOUND 0H
... SSID of console in R1... SCHIB contains the Subchannel Information
block for the console, and a MSCH is in order here !
...
NOCONS DS 0H
... No console...
Post by Mike Stramba
Hi guys,
I'm "revisiting" this experiment, and trying to get it working under
the z/VM eval system.
Where would I find the sub channel ID for a VM's console ?
I'm guessing the answer might be in a z/VM system programmer manual ?
... in maybe a system call or macro?
I'm now looking for the manual(s) to look for the info
thx
Post by Ivan Warren
Post by mstramba2000
I'm trying to get up to speed with Z/Arch I/O programming, I have Z-Arch
Principles-Operation, and ABC of Z/oS Sys Programming (Vol 10 seems to be
relevant).
Are there any other redbooks /etc a.k.a. "Channel programmers's guide" or
something similar ?
but am getting no output, and nothing stored from the STSCH.
There is something you need to do 1st..
All subchannels (except for the IPL device if an IPL is issued) are in a
*disabled* state upon a system reset (which implies an I/O reset which
disables the subchannels). In a disabled state, a subchannel won't
accept SSCH and will not produce interrupts. A POR (Power On Reset) has
the same effect (all subchannels are disabled).
...
L 1,MYSSID (you must determine this 1st - see below)
STSCH MYSCHIB Store SCHIB
OI MYSCHIB+5,X'80' (turn E bit on in PMCW portion of the SCHIB)
MSCH MYSCHIB Modify Subchannel with altered SCHIB
...
MYSCHIB DS 12F
Now.. The Subsystem ID (GPR1 for I/O instruction is NOT the device
number.. The device number can be determined during the STSCH
16 set to 1. (so X'00010000' is a valid SSID, but X'00000000' is not).
See chapters 14 and 15 of the z/Arch POO.
--Ivan
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
[Non-text portions of this message have been removed]
Ivan Warren
2011-08-31 09:37:30 UTC
Permalink
Post by Ivan Warren
Use DIAG 24 (X'84xy0024) with Rx set to ffffffff on entry. On return, Rx
will indicate the device number of the VM console. You still need to
scan all SSIDs to determine the SSID of the device which matches.
L 2,=X'ffffffff'
DC X'84100024'
L 1,=X'00010000'
LOOPSCAN DS 0H
STSCH SCHIB
BNZ NOCONS - NOTE - If you happen to have 65535*4 devices but no VM
console, then a program interrupt will occur on STSCH
CLM 2,B'0011',SCHIB+2
BZ CONSFOUND
LA 2,1(2)
Correction : Should be LA 1,1(1)
Post by Ivan Warren
B LOOPSCAN
CONSFOUND 0H
... SSID of console in R1... SCHIB contains the Subchannel Information
block for the console, and a MSCH is in order here !
...
NOCONS DS 0H
... No console...
[Non-text portions of this message have been removed]
Ivan Warren
2011-08-31 11:47:33 UTC
Permalink
Post by Ivan Warren
Post by Ivan Warren
Use DIAG 24 (X'84xy0024) with Rx set to ffffffff on entry. On return, Rx
will indicate the device number of the VM console. You still need to
scan all SSIDs to determine the SSID of the device which matches.
L 2,=X'ffffffff'
DC X'84100024'
Grrr... and also

DC X'83200024' ! can't seem to do assembly anymore ! That's DIAG 2,0,X'24'
I Want GPR2 to hold -1 on entry, and the console device address on exit !
Post by Ivan Warren
Post by Ivan Warren
L 1,=X'00010000'
LOOPSCAN DS 0H
STSCH SCHIB
BNZ NOCONS - NOTE - If you happen to have 65535*4 devices but no VM
console, then a program interrupt will occur on STSCH
CLM 2,B'0011',SCHIB+2
BZ CONSFOUND
LA 2,1(2)
Correction : Should be LA 1,1(1)
Post by Ivan Warren
B LOOPSCAN
CONSFOUND 0H
... SSID of console in R1... SCHIB contains the Subchannel Information
block for the console, and a MSCH is in order here !
...
NOCONS DS 0H
... No console...
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
[Non-text portions of this message have been removed]

Gerhard Postpischil
2010-04-15 18:47:13 UTC
Permalink
Post by mstramba2000
Do I need to setup some other control regs, or have to IPL, or
some other intialization?
LG R1,SUBID
SSCH ORBW1
STSCH SCIB
The last time I worked on a z machine, it IPLed in 31-bit mode.
If you're doing a reset or something similar, that might also be
true, so to be on the safe side you should switch to 64 bit mode
before using LG.


Gerhard Postpischil
Bradford, VT
Mike Stramba
2010-04-15 19:24:10 UTC
Permalink
Doesn't 24/31/64 mode only apply to addresses?
(page 3-6 P.O.O)

I haven't tried IPL'ing in Z/arch mode yet, but from a "cold start",
LG is working (loading 64 bits) .. using 24 bit addressing. 24bit
addressing should (??) work for these miniscule ~20 line programs I'm
running.
Post by Gerhard Postpischil
Post by mstramba2000
Do I need to setup some other control regs, or have to IPL, or
some other intialization?
LG R1,SUBID
SSCH ORBW1
STSCH SCIB
The last time I worked on a z machine, it IPLed in 31-bit mode.
If you're doing a reset or something similar, that might also be
true, so to be on the safe side you should switch to 64 bit mode
before using LG.
Gerhard Postpischil
Bradford, VT
j***@public.gmane.org
2010-04-15 21:35:03 UTC
Permalink
Post by Mike Stramba
Doesn't 24/31/64 mode only apply to addresses?
(page 3-6 P.O.O)
I haven't tried IPL'ing in Z/arch mode yet, but from a "cold start",
LG is working (loading 64 bits) .. using 24 bit addressing. 24bit
addressing should (??) work for these miniscule ~20 line programs I'm
running.
z always IPLs in 390 architecture mode. This mode gives you two addressing
modes (24 and 31 bits) - controlled via the PSW bit 32.

You can issue a SIGP to switch to z architecture mode. Once that's done,
you have 3 addressing modes to choose from (24, 31, and 64 bits) - also
controlled by the PSW BA and EA bits (bits 31 and 32).

Note that once you switch to z architecture mode, your PSW format changes a
bit - from an 8-byte PSW to a 16-byte PSW. Also, while in 390 arch mode,
the ESA/390 POP applies. (Well, I'm sure that Ivan will point out a whole
slew of differences, but the basic architecture is just like a regular 390.)

Jeff.
Post by Mike Stramba
Post by Gerhard Postpischil
Post by mstramba2000
Do I need to setup some other control regs, or have to IPL, or
some other intialization?
LG R1,SUBID
SSCH ORBW1
STSCH SCIB
The last time I worked on a z machine, it IPLed in 31-bit mode.
If you're doing a reset or something similar, that might also be
true, so to be on the safe side you should switch to 64 bit mode
before using LG.
Gerhard Postpischil
Bradford, VT
--
We have joy, we have fun, we have Linux on a Sun...
Mike Stramba
2010-04-15 23:47:46 UTC
Permalink
Ok I'm still missing something.

Still no output, zero CC after running Ivan's code.

I wonder if it's the ORB ?

I only initialized the address field, left everything else 0.

ORBW1 DC F'0'
DC F'0'
DC X'00'
DC AL3(CCWWRTG)
Post by j***@public.gmane.org
Post by Mike Stramba
Doesn't 24/31/64 mode only apply to addresses?
(page 3-6 P.O.O)
I haven't tried IPL'ing in Z/arch mode yet, but from a "cold start",
LG is working (loading 64 bits) .. using 24 bit addressing. 24bit
addressing should (??) work for these miniscule ~20 line programs I'm
running.
z always IPLs in 390 architecture mode. This mode gives you two addressing
modes (24 and 31 bits) - controlled via the PSW bit 32.
You can issue a SIGP to switch to z architecture mode. Once that's done,
you have 3 addressing modes to choose from (24, 31, and 64 bits) - also
controlled by the PSW BA and EA bits (bits 31 and 32).
Note that once you switch to z architecture mode, your PSW format changes a
bit - from an 8-byte PSW to a 16-byte PSW. Also, while in 390 arch mode,
the ESA/390 POP applies. (Well, I'm sure that Ivan will point out a whole
slew of differences, but the basic architecture is just like a regular 390.)
Jeff.
Post by Mike Stramba
Post by Gerhard Postpischil
Post by mstramba2000
Do I need to setup some other control regs, or have to IPL, or
some other intialization?
LG R1,SUBID
SSCH ORBW1
STSCH SCIB
The last time I worked on a z machine, it IPLed in 31-bit mode.
If you're doing a reset or something similar, that might also be
true, so to be on the safe side you should switch to 64 bit mode
before using LG.
Gerhard Postpischil
Bradford, VT
--
We have joy, we have fun, we have Linux on a Sun...
j***@public.gmane.org
2010-04-16 00:30:50 UTC
Permalink
Post by Mike Stramba
Ok I'm still missing something.
Still no output, zero CC after running Ivan's code.
I wonder if it's the ORB ?
I only initialized the address field, left everything else 0.
ORBW1 DC F'0'
DC F'0'
DC X'00'
DC AL3(CCWWRTG)
The LPM must have at least one path enabled. Using X'FF' is the simplest
way (i.e., enable all 8 paths). Of course, you might want to flip the CCW
Format bit.

Jeff.
--
The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers.
- Bill Gates, The Road Ahead, pg. 265
Mike Stramba
2010-04-16 01:12:49 UTC
Permalink
Jeff,

Thanks, that did the trick, whoopee ! ... I printed something to a
'teletetype' / telnet terminal ;) !

Now to try * reading* , then on to either the fearsome DASD or the 3270 ;)

Mike
Post by j***@public.gmane.org
Post by Mike Stramba
Ok I'm still missing something.
Still no output, zero CC after running Ivan's code.
I wonder if it's the ORB ?
I only initialized the address field, left everything else 0.
ORBW1 DC F'0'
DC F'0'
DC X'00'
DC AL3(CCWWRTG)
The LPM must have at least one path enabled. Using X'FF' is the simplest
way (i.e., enable all 8 paths). Of course, you might want to flip the CCW
Format bit.
Jeff.
--
The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers.
- Bill Gates, The Road Ahead, pg. 265
j***@public.gmane.org
2010-04-16 01:20:39 UTC
Permalink
Post by Mike Stramba
Jeff,
Thanks, that did the trick, whoopee ! ... I printed something to a
'teletetype' / telnet terminal ;) !
Great!
Post by Mike Stramba
Now to try * reading*
Reading from a 3215 is equally trivial.
Post by Mike Stramba
then on to either the fearsome DASD or the 3270 ;)
Those get a bit more complicated. With DASDs, the channel program consists
of several CCWs (which ones exactly depends on whether you're using a FBA or
a ECKD DASD), and with 3270 channel programs, the data itself needs to
contain some magic (described by GA23-0059-07: 3270 Information Display
System) that gets interpreted by the terminal (well, I suppose it's the CU).

Jeff.
--
Don't drink and derive. Alcohol and algebra don't mix.
laddiehanus
2010-04-16 00:44:35 UTC
Permalink
Have you enabled the subchannel
STSCH DEVSCHIB
OI DEVSCHIB+5,X'80' Enable the subchannel
MSCH DEVSCHIB Update the subchannel

And then doing a test subchannel to get the IRB to see whats going on

Laddie Hanus
Post by Mike Stramba
Ok I'm still missing something.
Still no output, zero CC after running Ivan's code.
I wonder if it's the ORB ?
I only initialized the address field, left everything else 0.
ORBW1 DC F'0'
DC F'0'
DC X'00'
DC AL3(CCWWRTG)
Post by j***@public.gmane.org
Post by Mike Stramba
Doesn't 24/31/64 mode only apply to addresses?
(page 3-6 P.O.O)
I haven't tried IPL'ing in Z/arch mode yet, but from a "cold start",
LG is working (loading 64 bits) .. using 24 bit addressing. 24bit
addressing should (??) work for these miniscule ~20 line programs I'm
running.
z always IPLs in 390 architecture mode. This mode gives you two addressing
modes (24 and 31 bits) - controlled via the PSW bit 32.
You can issue a SIGP to switch to z architecture mode. Once that's done,
you have 3 addressing modes to choose from (24, 31, and 64 bits) - also
controlled by the PSW BA and EA bits (bits 31 and 32).
Note that once you switch to z architecture mode, your PSW format changes a
bit - from an 8-byte PSW to a 16-byte PSW. Also, while in 390 arch mode,
the ESA/390 POP applies. (Well, I'm sure that Ivan will point out a whole
slew of differences, but the basic architecture is just like a regular 390.)
Jeff.
Post by Mike Stramba
Post by Gerhard Postpischil
Post by mstramba2000
Do I need to setup some other control regs, or have to IPL, or
some other intialization?
LG R1,SUBID
SSCH ORBW1
STSCH SCIB
The last time I worked on a z machine, it IPLed in 31-bit mode.
If you're doing a reset or something similar, that might also be
true, so to be on the safe side you should switch to 64 bit mode
before using LG.
Gerhard Postpischil
Bradford, VT
--
We have joy, we have fun, we have Linux on a Sun...
Gerhard Postpischil
2010-04-16 01:51:50 UTC
Permalink
Post by Mike Stramba
Doesn't 24/31/64 mode only apply to addresses?
(page 3-6 P.O.O)
I haven't tried IPL'ing in Z/arch mode yet, but from a "cold start",
LG is working (loading 64 bits) .. using 24 bit addressing. 24bit
addressing should (??) work for these miniscule ~20 line programs I'm
running.
You're correct, as I wasn't thinking straight, and was thinking
effective address where you had a device address.




Gerhard Postpischil
Bradford, VT
Harold Grovesteen
2010-04-16 14:09:02 UTC
Permalink
The Hercules LPAR will be in the current architecture mode when
instructions start to execute if there has not been an IPL. So, if your
configuration says ARCHMODE ESAME, then you are already in
z/Architecture mode. IPL will actually change the mode to ESA/390 and
in that case you will need to issue a SIGP instruction to subsequently
enter z/Architecture.

If you elect to start execution using a restart interrupt, without an
IPL and the system is already in z/Architecture mode, the z/Architecture
restart PSW will be loaded, not the ESA/390 restart PSW that is located
at assigned storage location 0.

Harold Grovesteen
Post by Mike Stramba
Doesn't 24/31/64 mode only apply to addresses?
(page 3-6 P.O.O)
I haven't tried IPL'ing in Z/arch mode yet, but from a "cold start",
LG is working (loading 64 bits) .. using 24 bit addressing. 24bit
addressing should (??) work for these miniscule ~20 line programs I'm
running.
Post by Gerhard Postpischil
Post by mstramba2000
Do I need to setup some other control regs, or have to IPL, or
some other intialization?
LG R1,SUBID
SSCH ORBW1
STSCH SCIB
The last time I worked on a z machine, it IPLed in 31-bit mode.
If you're doing a reset or something similar, that might also be
true, so to be on the safe side you should switch to 64 bit mode
before using LG.
Gerhard Postpischil
Bradford, VT
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
Mike Stramba
2010-04-16 15:02:15 UTC
Permalink
I haven't used SIGP yet, code 1 would seem to be the simpler option ?

What would code 2 be used for ?
--------------
"Set Architecture: The contents of bit positions
56-63 of the parameter register are used as a code
specifying an architectural mode to which all CPUs in
the configuration are to be set: code 0 specifies the
ESA/390 mode, and codes 1 and 2 specify the
z/Architecture mode.

Code 1 specifies that, for each
of all CPUs in the configuration, the current ESA/390
PSW is to be transformed to a z/Architecture PSW.

Code 2 specifies that the PSW of the CPU executing
SIGNAL PROCESSOR is to be transformed to a
z/Architecture PSW and that, for each of all other
CPUs in the configuration, the PSW is to be set with
the value of the captured-z/Architecture-PSW register
for that CPU. The setting of the PSW with the
value of the captured-z/Architecture-PSW register
will restore the PSW that existed when the CPU was
last in the z/Architecture mode, provided that the
captured-z/Architecture-PSW register has not been
set to all zeros by a reset.
-------------------------------------------
Post by Harold Grovesteen
The Hercules LPAR will be in the current architecture mode when
instructions start to execute if there has not been an IPL. So, if your
configuration says ARCHMODE ESAME, then you are already in
z/Architecture mode. IPL will actually change the mode to ESA/390 and
in that case you will need to issue a SIGP instruction to subsequently
enter z/Architecture.
If you elect to start execution using a restart interrupt, without an
IPL and the system is already in z/Architecture mode, the z/Architecture
restart PSW will be loaded, not the ESA/390 restart PSW that is located
at assigned storage location 0.
Harold Grovesteen
Post by Mike Stramba
Doesn't 24/31/64 mode only apply to addresses?
(page 3-6 P.O.O)
I haven't tried IPL'ing in Z/arch mode yet, but from a "cold start",
LG is working (loading 64 bits) .. using 24 bit addressing. 24bit
addressing should (??) work for these miniscule ~20 line programs I'm
running.
Post by Gerhard Postpischil
Post by mstramba2000
Do I need to setup some other control regs, or have to IPL, or
some other intialization?
LG R1,SUBID
SSCH ORBW1
STSCH SCIB
The last time I worked on a z machine, it IPLed in 31-bit mode.
If you're doing a reset or something similar, that might also be
true, so to be on the safe side you should switch to 64 bit mode
before using LG.
Gerhard Postpischil
Bradford, VT
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
Mike Stramba
2010-04-17 13:57:44 UTC
Permalink
For some reason, I'm only getting output to the 3215 the first time the channel
program runs.

No other output is seen when I repeat either the SSCH instruction, or the
entire sequence of instructions. (LOOP1 / LOOPALL)

The SCSW is showing Channel-end and Device-end.

The CRW has the ancillary report (bit 8) set though :

("indicates that a malfunction of a system component has
occurred that was recognized previously or which
has affected the activity of multiple channel-subsystem
facilities.")

The ERC of the CRW is showing 04 (Installed parameters initialized).

Mike

LOOPALL L R1,SUBID024
STSCH SCHIB0
OI SCHIB0+5,X'80' ENABLE CHANNEL
MSCH SCHIB0
LOOP! SSCH ORBW0 START SUBCHANNEL
STCRW CRW
STSCH SCHIB
L R2,DELAY0
DELAYLP BCT R2,DELAYLP
B LOOP1
* B LOOPALL
CRW DC F'0'

SUBID DC F'0' CPU00320
SUBID24 DC X'0' CPU00330
DC X'1' CPU00340
DC X'0' CPU00350
DC X'0' CPU00360

ORBW0 DC F'0'
DC X'0000FF00' SET ALL LPM TRUE
DC X'00'
DC AL3(CCWWRT0)

WRITECR EQU 9

CCWWRT0 CCW WRITECR,MSG0,'0',MSG0LEN
MSG0 DC C'COMMAND: '
MSG0LEN EQU *-MSG1
Post by Mike Stramba
I haven't used SIGP yet, code 1 would seem to be the simpler option ?
What would code 2 be used for ?
--------------
"Set Architecture: The contents of bit positions
56-63 of the parameter register are used as a code
specifying an architectural mode to which all CPUs in
the configuration are to be set: code 0 specifies the
ESA/390 mode, and codes 1 and 2 specify the
z/Architecture mode.
Code 1 specifies that, for each
of all CPUs in the configuration, the current ESA/390
PSW is to be transformed to a z/Architecture PSW.
Code 2 specifies that the PSW of the CPU executing
SIGNAL PROCESSOR is to be transformed to a
z/Architecture PSW and that, for each of all other
CPUs in the configuration, the PSW is to be set with
the value of the captured-z/Architecture-PSW register
for that CPU. The setting of the PSW with the
value of the captured-z/Architecture-PSW register
will restore the PSW that existed when the CPU was
last in the z/Architecture mode, provided that the
captured-z/Architecture-PSW register has not been
set to all zeros by a reset.
-------------------------------------------
Post by Harold Grovesteen
The Hercules LPAR will be in the current architecture mode when
instructions start to execute if there has not been an IPL. So, if your
configuration says ARCHMODE ESAME, then you are already in
z/Architecture mode. IPL will actually change the mode to ESA/390 and
in that case you will need to issue a SIGP instruction to subsequently
enter z/Architecture.
If you elect to start execution using a restart interrupt, without an
IPL and the system is already in z/Architecture mode, the z/Architecture
restart PSW will be loaded, not the ESA/390 restart PSW that is located
at assigned storage location 0.
Harold Grovesteen
Post by Mike Stramba
Doesn't 24/31/64 mode only apply to addresses?
(page 3-6 P.O.O)
I haven't tried IPL'ing in Z/arch mode yet, but from a "cold start",
LG is working (loading 64 bits) .. using 24 bit addressing. 24bit
addressing should (??) work for these miniscule ~20 line programs I'm
running.
Post by Gerhard Postpischil
Post by mstramba2000
Do I need to setup some other control regs, or have to IPL, or
some other intialization?
LG R1,SUBID
SSCH ORBW1
STSCH SCIB
The last time I worked on a z machine, it IPLed in 31-bit mode.
If you're doing a reset or something similar, that might also be
true, so to be on the safe side you should switch to 64 bit mode
before using LG.
Gerhard Postpischil
Bradford, VT
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
laddiehanus
2010-04-17 15:25:22 UTC
Permalink
You need to do a TSCH to clear the status pending. If you get cc=1 you need to reissue the tsch until you get cc=0 (I think I got the cc's right, I always use a interrupt handler)

Laddie Hanus
Post by Mike Stramba
For some reason, I'm only getting output to the 3215 the first time the channel
program runs.
No other output is seen when I repeat either the SSCH instruction, or the
entire sequence of instructions. (LOOP1 / LOOPALL)
The SCSW is showing Channel-end and Device-end.
("indicates that a malfunction of a system component has
occurred that was recognized previously or which
has affected the activity of multiple channel-subsystem
facilities.")
The ERC of the CRW is showing 04 (Installed parameters initialized).
Mike
LOOPALL L R1,SUBID024
STSCH SCHIB0
OI SCHIB0+5,X'80' ENABLE CHANNEL
MSCH SCHIB0
LOOP! SSCH ORBW0 START SUBCHANNEL
STCRW CRW
STSCH SCHIB
L R2,DELAY0
DELAYLP BCT R2,DELAYLP
B LOOP1
* B LOOPALL
CRW DC F'0'
SUBID DC F'0' CPU00320
SUBID24 DC X'0' CPU00330
DC X'1' CPU00340
DC X'0' CPU00350
DC X'0' CPU00360
ORBW0 DC F'0'
DC X'0000FF00' SET ALL LPM TRUE
DC X'00'
DC AL3(CCWWRT0)
WRITECR EQU 9
CCWWRT0 CCW WRITECR,MSG0,'0',MSG0LEN
MSG0 DC C'COMMAND: '
MSG0LEN EQU *-MSG1
Mike Stramba
2010-04-17 15:55:08 UTC
Permalink
Laddie,

Thanks !

That did the trick .. will have to read more on 'status pending'.

Mike
Post by laddiehanus
You need to do a TSCH to clear the status pending. If you get cc=1 you need
to reissue the tsch until you get cc=0 (I think I got the cc's right, I
always use a interrupt handler)
Laddie Hanus
Post by Mike Stramba
For some reason, I'm only getting output to the 3215 the first time the channel
program runs.
No other output is seen when I repeat either the SSCH instruction, or the
entire sequence of instructions. (LOOP1 / LOOPALL)
The SCSW is showing Channel-end and Device-end.
("indicates that a malfunction of a system component has
occurred that was recognized previously or which
has affected the activity of multiple channel-subsystem
facilities.")
The ERC of the CRW is showing 04 (Installed parameters initialized).
Mike
LOOPALL L R1,SUBID024
STSCH SCHIB0
OI SCHIB0+5,X'80' ENABLE CHANNEL
MSCH SCHIB0
LOOP! SSCH ORBW0 START SUBCHANNEL
STCRW CRW
STSCH SCHIB
L R2,DELAY0
DELAYLP BCT R2,DELAYLP
B LOOP1
* B LOOPALL
CRW DC F'0'
SUBID DC F'0'
CPU00320
SUBID24 DC X'0'
CPU00330
DC X'1'
CPU00340
DC X'0'
CPU00350
DC X'0'
CPU00360
ORBW0 DC F'0'
DC X'0000FF00' SET ALL LPM TRUE
DC X'00'
DC AL3(CCWWRT0)
WRITECR EQU 9
CCWWRT0 CCW WRITECR,MSG0,'0',MSG0LEN
MSG0 DC C'COMMAND: '
MSG0LEN EQU *-MSG1
PeterH
2010-04-17 16:00:55 UTC
Permalink
Post by laddiehanus
You need to do a TSCH to clear the status pending. If you get cc=1
you need to reissue the tsch until you get cc=0 (I think I got the
cc's right, I always use a interrupt handler)
The channel processor takes most of the I/O processing overhead off
of the control program. The channel subsystem also facilitates
dynamically assigned UCBs, while preserving the traditional CUU
external device identification method, while actually substituting
its own method, the channel path ID.

Basically, the channel processor returns either "good" or "bad" to
the control program.

If "bad", then the control unit and/or the channel processor has/have
already done everything it/they can to ensure a good outcome, but it/
they failed to do so, and any recovery procedures by the control
program will be hopeless.
Ivan Warren
2010-04-17 15:33:51 UTC
Permalink
Post by Mike Stramba
For some reason, I'm only getting output to the 3215 the first time the channel
program runs.
No other output is seen when I repeat either the SSCH instruction, or the
entire sequence of instructions. (LOOP1 / LOOPALL)
Your program isn't dequeuing the SCSW off the subchannel (you should
issue a TSCH / Test Subchannel) until you get a CC=0 (IRB Stored, device
not status pending). right now, your subchannel remains 'status pending'
- and thus you cannot issue any I/O.

As a matter of fact, you should probably do the test *BEFORE* you issue
the I/O !

You are also not testing the results of the SSCH (anything else than
CC=0 indicates a problem).

You shouldn't have to worry about the CRW. You are usually only
interested in the CRW upon receiving a machine check (which could
indicate I/O reconfiguration).

So how about something like.. (quite crude, but should probably work)

LOOPALL L R1,SUBID024
STSCH SCHIB0
BNZ IOFAIL
OI SCHIB0+5,X'80' ENABLE CHANNEL
MSCH SCHIB0
BNZ IOFAIL
LOOP1 DS 0H
TSCH MYIRB
BC 4,LOOP1 retry on CC=1
* should check the SCSW though
* for CE, DE, ATTN.. or Unit Check
BC 1,IOFAIL CC=3
SSCH ORBW0 START SUBCHANNEL
BC 14,LOOP1 CC=0, CC=1 or CC=2 (although CC=2 shouldn't
occur here)
* CC = 3 here
IOFAIL DS 0H
...
...


Of course, that's not the most efficient use... You should setup a new
I/O PSW, Load a I/O enabled WAIT PSW, process the interrupt and then
proceed to the next I/O when everything is cleared out.

--Ivan


[Non-text portions of this message have been removed]
Continue reading on narkive:
Loading...