Discussion:
S/370 Channel 0 and/or select CCW considerations
(too old to reply)
the_thom
2008-03-13 18:37:49 UTC
Permalink
Hello all,

I'm posting this as a result of a conversation I was having with
Kevin Leonard while we were trying to debug some issues with DOS/VS
VTAM devices on channel 0 of a DOS/VS machine running under VM a few
weeks back. These errors were only occuring under VM/370.

It took me a while to realize the issue was with a select command on
a block multiplexor channel. Once I realized that, the problem was
elementary.

I was content with moving the terminal devices to another channel,
but Kevin went on a tear to understand the discrepancy better.
The VM STIDC simulation doesn't just return what's in the
virtual channel block as the channel type. It will do that
as a last resort, but first it goes through an elaborate
search trying to find a dedicated device or minidisk on
the virtual channel. For the first one it finds, it takes
the STIDC response stored at IPL time from the associated
real channel block, and uses that to build the virtual
STIDC response. There's a hack that checks to ensure that
block multiplexer isn't returned for a virtual selector
channel, but nothing special is done to ensure byte
multiplexer.
If VM finds a device on virtual channel 0 that maps to
a dedicated device on real channel 0, he will return the
IPL-time STIDC response for real channel 0. That's
probably what's happening in our test cases.
Hercules always returns block multiplexer in response to
STIDC regardless of the channel. There isn't anything like
a Hercules IODF. A case could be made that according to the
Principles of Operation, Hercules should be returning byte
multiplexer for channel 0 if the system is operating in
System/370 mode, but that's not how it currently works.
So when VM returns the type of virtual channel 0 to DOS/VS,
what it passes back is the type of real channel 0 as returned
by Hercules, which is block multiplexer.
I bring this up not as a complaint, just something I think is worth
some general discussion.

There is also a discrepancy between Hercules' select command
simulation and VM/370's. The select command doesn't take an address,
so Hercules ignores it. Appearently, VM/370 actually tries to
validate an address if it is provided (it really shouldn't, but it
does). This was the real culprit behind the issues I was having. MVS
does not give an address, so terminals on channel 0 work without
issue. DOS/VS gives a *virtual* address, which Hercules ignores
(which is technically the right thing to do), but VM/370 attempts to
validate, resulting in a channel program check being generated by VM.

Since the select command is a case of Hercules doing the right
thing, and VM/370 doing the wrong thing, this is merely being
brought up as an interesting phenomenon.

As far as I'm concerned, the select command can just as well be left
alone since it's VM that's doing it wrong. The channel 0 issue is
one I wonder about.

Whether the channel 0 behavior is worth changing is probably a
judgement best left to the person who last had their fingers in that
code, so I'm simply describing the issue and seeing what comes of it.

--Thom Rounds
Ivan Warren
2008-03-13 19:55:44 UTC
Permalink
Post by the_thom
I bring this up not as a complaint, just something I think is worth
some general discussion.
There is also a discrepancy between Hercules' select command
simulation and VM/370's. The select command doesn't take an address,
so Hercules ignores it. Appearently, VM/370 actually tries to
validate an address if it is provided (it really shouldn't, but it
does). This was the real culprit behind the issues I was having. MVS
does not give an address, so terminals on channel 0 work without
issue. DOS/VS gives a *virtual* address, which Hercules ignores
(which is technically the right thing to do), but VM/370 attempts to
validate, resulting in a channel program check being generated by VM.
That's odd.. all the local non-sna 3174 'Select' commands (0B, 1B, 2B,
3B and 4B) are described in / GA23-0218-11 /as immediate commands - so
whatever data is given in the CCW should be silently ignored by VM
(actually, you HAVE to give it at least 1 byte - otherwise you get a
channel program check because you're not allowed a length of 0 in a CCW
- except for TIC). I'm a little confused as to what this has to do with
the Channel 0 type confusion.. See below.
Post by the_thom
Since the select command is a case of Hercules doing the right
thing, and VM/370 doing the wrong thing, this is merely being
brought up as an interesting phenomenon.
As far as I'm concerned, the select command can just as well be left
alone since it's VM that's doing it wrong. The channel 0 issue is
one I wonder about.
Whether the channel 0 behavior is worth changing is probably a
judgement best left to the person who last had their fingers in that
code, so I'm simply describing the issue and seeing what comes of it.
Ok.. Now that's something that needs to be worked out. I *did* find the
S/370 POP reference stating that channel 0 is a Byte Multiplexor (Page
192, Paragraph 2 in GA22-7000-4). I do not think there should be any arm
in doing the "Right Thing"[1] here. (that will only affect S/370 since
STIDC only exists in S/370). Accordingly, I've changed the source code
to return Byte Multiplex (X'01' @ 168) when STIDC is done against channel 0.

Note that "in reality", all hercules 'channels' (even though hercules
has very little concepts about channels) actually operate in Byte
Multiplexing mode with non-burst operations all the time (and CR0 Bit 0
is always blissfully ignored[2]). That is, I/O operations are always
accepted as long as the "device" can accept it (read : we also do not
emulate shared CUs).

--Ivan

[1] The "Right Thing" being doing what the relevant POP or IBM manual says.

[2] Honoring CR0/0, emulating Selector mode operations and Shared CUs
operation is one of those things that need rework in the I/O subsystem.
It's a lot of work though !
Dave Wade
2008-03-13 20:02:56 UTC
Permalink
How does the DEFINE CHANNELS command affect this?



-----Original Message-----
From: hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] On
Behalf Of Ivan Warren
Sent: 13 March 2008 19:56
To: hercules-390-***@public.gmane.org
Subject: Re: [hercules-390] S/370 Channel 0 and/or select CCW considerations
Post by the_thom
I bring this up not as a complaint, just something I think is worth
some general discussion.
There is also a discrepancy between Hercules' select command
simulation and VM/370's. The select command doesn't take an address,
so Hercules ignores it. Appearently, VM/370 actually tries to
validate an address if it is provided (it really shouldn't, but it
does). This was the real culprit behind the issues I was having. MVS
does not give an address, so terminals on channel 0 work without
issue. DOS/VS gives a *virtual* address, which Hercules ignores
(which is technically the right thing to do), but VM/370 attempts to
validate, resulting in a channel program check being generated by VM.
That's odd.. all the local non-sna 3174 'Select' commands (0B, 1B, 2B,
3B and 4B) are described in / GA23-0218-11 /as immediate commands - so
whatever data is given in the CCW should be silently ignored by VM
(actually, you HAVE to give it at least 1 byte - otherwise you get a
channel program check because you're not allowed a length of 0 in a CCW
- except for TIC). I'm a little confused as to what this has to do with
the Channel 0 type confusion.. See below.
Post by the_thom
Since the select command is a case of Hercules doing the right
thing, and VM/370 doing the wrong thing, this is merely being
brought up as an interesting phenomenon.
As far as I'm concerned, the select command can just as well be left
alone since it's VM that's doing it wrong. The channel 0 issue is
one I wonder about.
Whether the channel 0 behavior is worth changing is probably a
judgement best left to the person who last had their fingers in that
code, so I'm simply describing the issue and seeing what comes of it.
Ok.. Now that's something that needs to be worked out. I *did* find the
S/370 POP reference stating that channel 0 is a Byte Multiplexor (Page
192, Paragraph 2 in GA22-7000-4). I do not think there should be any arm
in doing the "Right Thing"[1] here. (that will only affect S/370 since
STIDC only exists in S/370). Accordingly, I've changed the source code
to return Byte Multiplex (X'01' @ 168) when STIDC is done against channel 0.

Note that "in reality", all hercules 'channels' (even though hercules
has very little concepts about channels) actually operate in Byte
Multiplexing mode with non-burst operations all the time (and CR0 Bit 0
is always blissfully ignored[2]). That is, I/O operations are always
accepted as long as the "device" can accept it (read : we also do not
emulate shared CUs).

--Ivan

[1] The "Right Thing" being doing what the relevant POP or IBM manual says.

[2] Honoring CR0/0, emulating Selector mode operations and Shared CUs
operation is one of those things that need rework in the I/O subsystem.
It's a lot of work though !





[Non-text portions of this message have been removed]
Ivan Warren
2008-03-13 20:05:02 UTC
Permalink
Post by Dave Wade
How does the DEFINE CHANNELS command affect this?
IIRC, VM's "CP DEF CHAN [SEL|BMX]" only affects channels that are >0..
Channel 0 is always emulated as a byte multiplexor.. Channels >0 are
emulated according to "DEF CHAN"..

--Ivan
the_thom
2008-03-13 21:01:13 UTC
Permalink
Post by Ivan Warren
That's odd.. all the local non-sna 3174 'Select' commands (0B, 1B, 2B,
3B and 4B) are described in / GA23-0218-11 /as immediate commands - so
whatever data is given in the CCW should be silently ignored by VM
(actually, you HAVE to give it at least 1 byte - otherwise you get a
channel program check because you're not allowed a length of 0 in a CCW
- except for TIC). I'm a little confused as to what this has to do with
the Channel 0 type confusion.. See below.
There's no direct link, it just so happens that both differences in
behavior were discovered at the same time.

They're two seperate items. You are correct that the data provided
in the CCW *should* be silently ignored by VM. For whatever reason,
it's not. This is not something that needs to be addressed in
Hercules per se, but since I've seen a few threads float around in
the last few months regarding behavioral differences between VM and
Hercules, I figured it was worth an FYI.

So, as far as the select command is concerned, I vote for "don't fix
what ain't broke", unless anyone feels the need for an optional "VM
affinity" or some such thing in S/370 mode. Some may argue that
Hercules in S/370 mode should behave like VM did, even though it's
obvious that VM/370 did not follow the 3270 CD w/r/t the select
command.

I don't feel the select command should be changed, as it would break
almost everyone's DOS/VS systems not running under VM, and would
violate the 3270 spec (even though the authors of VM didn't seem to
mind doing that).
Post by Ivan Warren
Post by the_thom
Whether the channel 0 behavior is worth changing is probably a
judgement best left to the person who last had their fingers in that
code, so I'm simply describing the issue and seeing what comes of it.
Ok.. Now that's something that needs to be worked out. I *did*
find the
Post by Ivan Warren
S/370 POP reference stating that channel 0 is a Byte Multiplexor (Page
192, Paragraph 2 in GA22-7000-4). I do not think there should be any arm
in doing the "Right Thing"[1] here. (that will only affect S/370 since
STIDC only exists in S/370). Accordingly, I've changed the source code
Has this been checked in? I'd be curious to test that against my
DOSVS and MVS guests under VM. Part of the issue was VM's decisions
based on the result of STIDC against channel 0.

I recall there were various and sundry gotchas with given
combinations of devices on channel 0 in the real world, which is why
I approached the subject somewhat cautiously.

--Thom
Kevin Leonard
2008-03-14 01:50:28 UTC
Permalink
Post by Ivan Warren
That's odd.. all the local non-sna 3174 'Select' commands (0B, 1B, 2B,
3B and 4B) are described in / GA23-0218-11 /as immediate commands - so
whatever data is given in the CCW should be silently ignored by VM
(actually, you HAVE to give it at least 1 byte - otherwise you get a
channel program check because you're not allowed a length of 0 in a CCW
- except for TIC).
For a format 0 CCW, you need a non-zero length, right? That
doesn't require a non-zero data address.
Post by Ivan Warren
I'm a little confused as to what this has to do with
the Channel 0 type confusion
DOS/VS VTAM won't insert the select if the target 3270 device
isn't on a block multiplexor channel. So if Thom's channel 0
devices looked to be on a byte multiplexor channel (as he thought
they were), the opportunity for VM's (incorrect) validation of the
bad CCW data address wouldn't have occurred. The error would still
happen if the target 3270 was on channel 1+ and DEFINE CHANNELS was
set to BMX, but the user can prevent that by defining channels 1+ as
SEL. There's no way the user can specify what channel type should
be returned for channel 0.
Post by Ivan Warren
IIRC, VM's "CP DEF CHAN [SEL|BMX]" only affects channels that
are >0.. Channel 0 is always emulated as a byte multiplexor..
Channels >0 are emulated according to "DEF CHAN"..
That's correct, mostly. If I read the algorithm in DMKPRV right,
VM will always ensure that if virtual channel 1+ is defined as
selector, the STIDC response won't be block multiplexor. Nothing
is done to prevent a returned response of byte multiplexor, if
that's the value obtained from the real STIDC response used to
build the virtual STIDC response. And it looks like DEFINE
CHANNELS BMX won't force a response of block multiplexor if the
real STIDC response says selector.
--
Kevin
Ivan Warren
2008-03-14 02:48:17 UTC
Permalink
Post by Kevin Leonard
Post by Ivan Warren
That's odd.. all the local non-sna 3174 'Select' commands (0B, 1B, 2B,
3B and 4B) are described in / GA23-0218-11 /as immediate commands - so
whatever data is given in the CCW should be silently ignored by VM
(actually, you HAVE to give it at least 1 byte - otherwise you get a
channel program check because you're not allowed a length of 0 in a CCW
- except for TIC).
For a format 0 CCW, you need a non-zero length, right? That
doesn't require a non-zero data address.
It doesn't matter.. An address in a CCW is an address (0 is just as good
as an address for a CCW than any other value (otherwise IPL wouldn't
work !)).. Since the SELxxx CCW codes are immediate commands, the
address pointed to by the CCW is irrelevant. When an immediate CCW is
issued to a control unit, Channel end is presented before the control
unit requests any data from the channel (that's the actual definition of
an 'immediate' command), therefore, the channel never attempts to read
from storage - and consequently - even if the CCW points to a
non-existing location in storage or is read protected, an I/O with a CCW
containing a code for an immediate command should never fail with a CCW
data fetching error (protection or addressing).

BTW, That's why an immediate command should always have SILI on (in
S/370.. Post XA, if the Suppress ILI feature is installed and requested
in the ORB (or is it via MSCH) that's not necessary)... That's because
there will ALWAYS be a residual count for Format 0 CCWs when the CCW is
an immediate command.

Now, in hercules, we had to implement a special "immediate" command
table for each emulated device to instruct the channel code to not
attempt pre-fetching data from storage when a write or ctrl-write type
immediate op is issued (immediate commands are always odd anyways). This
is actually a kludge because - ideally - it is the control unit that
should be determining when data (and what amount) should be fetched from
storage and NOT the channel code. This also leads to a very subtle
deviation in the emulation from the standard (when, for example, a data
block crosses a page boundary - with a fetch error on the second part..
In the real word, if the amount requested by the control unit doesn't
make the write I/O cross that page boundary, the I/O will succeed.. In
hercules it will fail because it will attempt to fetch the entire block
beforehand *EXCEPT* for immediate commands).
Post by Kevin Leonard
Post by Ivan Warren
I'm a little confused as to what this has to do with
the Channel 0 type confusion
DOS/VS VTAM won't insert the select if the target 3270 device
isn't on a block multiplexor channel. So if Thom's channel 0
devices looked to be on a byte multiplexor channel (as he thought
they were), the opportunity for VM's (incorrect) validation of the
bad CCW data address wouldn't have occurred. The error would still
happen if the target 3270 was on channel 1+ and DEFINE CHANNELS was
set to BMX, but the user can prevent that by defining channels 1+ as
SEL. There's no way the user can specify what channel type should
be returned for channel 0.
Ok.. gotcha..Makes sense actually (the SELxxx operations are only
relevant on BMX channels - since they are intended to allow the CU to
get prepared for the next operation without tying up a BMX subchannel..
On Byte Multiplex, it's irrelevant (because I think a 3x74 never does
bursts).. and you usually wouldn't put a 3x74 on a selector channel (or
only by itself - at which point the SELxxx I/O is moot since the CU only
has a single subchannel anyway)).

The real question is : Why does VM present a channel program check ?
Ok.. let's try to get this right.. IIRC, when VM is given an address
that is incorrect (for example, when the data is passed virtual
addressable storage, it tries to put some invalid address in the *real*
CCW.. And *maybe* it is using funky IDAWs to do that (for example when
there is 16MB of real storage - at which point there is no
non-addressable storage for the channel).. It's possible then that we
may be interpreting the CCW address too soon in some situation.. Or
maybe it makes the CCW point to some key protected storage (and sets the
CAW key to some mismatching value) and then transform any resulting
Channel Protection Check to a Channel Program Check.

I'd like to know - in the situation you mention - if VM is making ANY
attempt at sending the I/O to the device.. A hercules CCW trace on the
device would be most helpful ! If we are seeing ANY Channel fetch error
on ANY immediate command - then something needs fixing !
Post by Kevin Leonard
Post by Ivan Warren
IIRC, VM's "CP DEF CHAN [SEL|BMX]" only affects channels that
are >0.. Channel 0 is always emulated as a byte multiplexor..
Channels >0 are emulated according to "DEF CHAN"..
That's correct, mostly. If I read the algorithm in DMKPRV right,
VM will always ensure that if virtual channel 1+ is defined as
selector, the STIDC response won't be block multiplexor. Nothing
is done to prevent a returned response of byte multiplexor, if
that's the value obtained from the real STIDC response used to
build the virtual STIDC response. And it looks like DEFINE
CHANNELS BMX won't force a response of block multiplexor if the
real STIDC response says selector.
I'm still a little confused about VM's mapping of virtual channel 0 to
real channel 0 based on real STIDC response.. But I'll have to trust you
on that.. (Hey.. what if there are NO devices on channel 0.. Or if there
are only virtual devices on virtual channel 0..).

Oh BTW.. Latest CVS has real channel 0 return Byte Multiplex (Location
168=01) on STIDC now..(assuming there IS a channel 0 ! If there are no
devices in the X'000'-X'0FF' range, STIDC returns CC=3.

--Ivan
the_thom
2008-03-14 19:01:34 UTC
Permalink
Post by Ivan Warren
I'd like to know - in the situation you mention - if VM is making ANY
attempt at sending the I/O to the device.. A hercules CCW trace on the
device would be most helpful ! If we are seeing ANY Channel fetch error
on ANY immediate command - then something needs fixing !
That's a good question. I don't know if the select was ever
propagated beyond VM. I would have to go back and reproduce the
problem with the CCW trace turned on. Since that machine is not
networked (and nowhere near this one), it will take me some time to
turn that around.

Kevin took the extra step of testing this on a DOS/VS system running
directly under Hercules - no error. The bogus address was silently
ignored, just like all the specs say it should be.

Having said all that: we all agree that Hercules is doing what the
370 and 3270 specs say should be done in this instance, and that VM
is *not*. If there were a broad issue with immediate commands in
Hercules, I would think they would have manifested themselves long
before this.
Post by Ivan Warren
I'm still a little confused about VM's mapping of virtual channel 0 to
real channel 0 based on real STIDC response.. But I'll have to
trust you
Post by Ivan Warren
on that.. (Hey.. what if there are NO devices on channel 0.. Or if there
are only virtual devices on virtual channel 0..).
Also a good question, but since it was almost universal (in S/370
days) to put unit record devices on real channel 0 (especially if
one was building a new system from the distribution tapes), an
unpopulated real channel 0 was probably a rarity.
Post by Ivan Warren
Oh BTW.. Latest CVS has real channel 0 return Byte Multiplex
(Location
Post by Ivan Warren
168=01) on STIDC now..(assuming there IS a channel 0 ! If there are no
devices in the X'000'-X'0FF' range, STIDC returns CC=3.
Great. I'll see if I can't get you a CCW trace on the failed select,
then I'll pull down the code from CVS and take another pass at it.

Again, this won't be a very quick turnaround, but hopefully I'll
have some results for you over the weekend.

--Thom
Ivan Warren
2008-03-14 19:34:43 UTC
Permalink
Post by the_thom
Post by Ivan Warren
I'd like to know - in the situation you mention - if VM is making
ANY
Post by Ivan Warren
attempt at sending the I/O to the device.. A hercules CCW trace on
the
Post by Ivan Warren
device would be most helpful ! If we are seeing ANY Channel fetch
error
Post by Ivan Warren
on ANY immediate command - then something needs fixing !
That's a good question. I don't know if the select was ever
propagated beyond VM. I would have to go back and reproduce the
problem with the CCW trace turned on. Since that machine is not
networked (and nowhere near this one), it will take me some time to
turn that around.
Kevin took the extra step of testing this on a DOS/VS system running
directly under Hercules - no error. The bogus address was silently
ignored, just like all the specs say it should be.
Having said all that: we all agree that Hercules is doing what the
370 and 3270 specs say should be done in this instance, and that VM
is *not*. If there were a broad issue with immediate commands in
Hercules, I would think they would have manifested themselves long
before this.
I'm not 100% sure that hercules isn't somehow guilty. When a virtual
machines issues an I/O to a dedicated device, CP has no other choice
than to transmit that I/O to that device... Even if the I/O looks bogus.
Of course, CP will perform some transformation to the CCW - at least
because it needs to translate a virtual machine's virtual addresses to
real addresses, eventually turning a straight CCW into one with some
Indirect Data..

.. thinking out loud here ..

As I was saying, I am a little curious about how it does that when the
virtual machine specifies a CCW data address that is beyond addressable
storage AND CP has a full 16MB of storage.. It's possible it uses IDAs
to do that too (specifying bogus addresses in the IDAs since IDAs can
address a full 31 or 32 address space). For example, if the virtual
machine has 8MB, but CP has 16MB.. and the guest issues a CCW with
address X'FFFFFF'.. clearly this is beyond virtual addressable storage
right ? But CP can't do the same (because X'FFFFFF' is a valid CCW data
address for CP - and you DO NOT want a virtual machine to access storage
that clearly doesn't belong to it - plus you want the channel program
check to be reported if the CCW code wasn't an immediate command after all).

What I am suspecting is that when VM does this (in order to allow the
channel to report the bogus address fetch if it applies) - then it does
throw hercules off.. DOS/VS won't have that issue because it doesn't use
any sophisticated technique there (the SELxxx CCWs will be issued with a
simple addressing (no IDAs) and hercules copes with that gracefully).

If this proves to be correct, there are probably other areas that need
to be checked (I haven't looked, but what I am suspecting is that the
channel code is inspecting the validity of the IDAWs in the IDAL even if
it is not necessary).

I'll wait for your trace further check this out..

Thanks,

--Ivan
Gerhard Postpischil
2008-03-14 20:26:34 UTC
Permalink
Post by Ivan Warren
If this proves to be correct, there are probably other areas that need
to be checked (I haven't looked, but what I am suspecting is that the
channel code is inspecting the validity of the IDAWs in the IDAL even if
it is not necessary).
It gets hairier than that - I can issue a chain of CCWs with
invalid addresses, bad opcodes, zero lengths, etc., yet have the
request execute correctly, providing an earlier CCW has the PCI
flag and corrects the problems in time. This could work fine for
a native system, but fail under VM. If I recall, there is
special code to handle MVS PCI Fetch, but that code just
replaces or appends CCWs, with never an invalid one present.

Gerhard Postpischil
Bradford, VT
pfg504
2008-03-26 00:12:10 UTC
Permalink
For the VM testing, is hercules running with or without assists turned on? The assists were
used to translate addresses. If they are on, would you turn them off and rerun the test?

Assists: E608, E609, E604, E60C, E60F

Second, what type of device is being used as specified in DMKRIO? Some CCW validation is
done at the devtype level.

Which Version, Release, etc. of VM are you using?

Question: In 370 mode, does storage loop around on 16M machines for both I/O and
instructions?

Paul
Post by Ivan Warren
Post by the_thom
Post by Ivan Warren
I'd like to know - in the situation you mention - if VM is making
ANY
Post by Ivan Warren
attempt at sending the I/O to the device.. A hercules CCW trace on
the
Post by Ivan Warren
device would be most helpful ! If we are seeing ANY Channel fetch
error
Post by Ivan Warren
on ANY immediate command - then something needs fixing !
That's a good question. I don't know if the select was ever
propagated beyond VM. I would have to go back and reproduce the
problem with the CCW trace turned on. Since that machine is not
networked (and nowhere near this one), it will take me some time to
turn that around.
Kevin took the extra step of testing this on a DOS/VS system running
directly under Hercules - no error. The bogus address was silently
ignored, just like all the specs say it should be.
Having said all that: we all agree that Hercules is doing what the
370 and 3270 specs say should be done in this instance, and that VM
is *not*. If there were a broad issue with immediate commands in
Hercules, I would think they would have manifested themselves long
before this.
I'm not 100% sure that hercules isn't somehow guilty. When a virtual
machines issues an I/O to a dedicated device, CP has no other choice
than to transmit that I/O to that device... Even if the I/O looks bogus.
Of course, CP will perform some transformation to the CCW - at least
because it needs to translate a virtual machine's virtual addresses to
real addresses, eventually turning a straight CCW into one with some
Indirect Data..
.. thinking out loud here ..
As I was saying, I am a little curious about how it does that when the
virtual machine specifies a CCW data address that is beyond addressable
storage AND CP has a full 16MB of storage.. It's possible it uses IDAs
to do that too (specifying bogus addresses in the IDAs since IDAs can
address a full 31 or 32 address space). For example, if the virtual
machine has 8MB, but CP has 16MB.. and the guest issues a CCW with
address X'FFFFFF'.. clearly this is beyond virtual addressable storage
right ? But CP can't do the same (because X'FFFFFF' is a valid CCW data
address for CP - and you DO NOT want a virtual machine to access storage
that clearly doesn't belong to it - plus you want the channel program
check to be reported if the CCW code wasn't an immediate command after all).
What I am suspecting is that when VM does this (in order to allow the
channel to report the bogus address fetch if it applies) - then it does
throw hercules off.. DOS/VS won't have that issue because it doesn't use
any sophisticated technique there (the SELxxx CCWs will be issued with a
simple addressing (no IDAs) and hercules copes with that gracefully).
If this proves to be correct, there are probably other areas that need
to be checked (I haven't looked, but what I am suspecting is that the
channel code is inspecting the validity of the IDAWs in the IDAL even if
it is not necessary).
I'll wait for your trace further check this out..
Thanks,
--Ivan
pfg504
2008-03-26 01:09:32 UTC
Permalink
One more question: Is the IO being done to the virtual CONS or to a dedicate/attached
virtual device?

IO to a "SPECIAL" device, a SPOOLED device or the VIRTUAL console behaves differently
that to an attached device.

Some validation is done to CCW chains against the devtype specified in DMKRIO. Defining
a device as unsupported minimizes checks.

Paul
Post by pfg504
For the VM testing, is hercules running with or without assists turned on? The assists were
used to translate addresses. If they are on, would you turn them off and rerun the test?
Assists: E608, E609, E604, E60C, E60F
Second, what type of device is being used as specified in DMKRIO? Some CCW validation is
done at the devtype level.
Which Version, Release, etc. of VM are you using?
Question: In 370 mode, does storage loop around on 16M machines for both I/O and
instructions?
Paul
Post by Ivan Warren
Post by the_thom
Post by Ivan Warren
I'd like to know - in the situation you mention - if VM is making
ANY
Post by Ivan Warren
attempt at sending the I/O to the device.. A hercules CCW trace on
the
Post by Ivan Warren
device would be most helpful ! If we are seeing ANY Channel fetch
error
Post by Ivan Warren
on ANY immediate command - then something needs fixing !
That's a good question. I don't know if the select was ever
propagated beyond VM. I would have to go back and reproduce the
problem with the CCW trace turned on. Since that machine is not
networked (and nowhere near this one), it will take me some time to
turn that around.
Kevin took the extra step of testing this on a DOS/VS system running
directly under Hercules - no error. The bogus address was silently
ignored, just like all the specs say it should be.
Having said all that: we all agree that Hercules is doing what the
370 and 3270 specs say should be done in this instance, and that VM
is *not*. If there were a broad issue with immediate commands in
Hercules, I would think they would have manifested themselves long
before this.
I'm not 100% sure that hercules isn't somehow guilty. When a virtual
machines issues an I/O to a dedicated device, CP has no other choice
than to transmit that I/O to that device... Even if the I/O looks bogus.
Of course, CP will perform some transformation to the CCW - at least
because it needs to translate a virtual machine's virtual addresses to
real addresses, eventually turning a straight CCW into one with some
Indirect Data..
.. thinking out loud here ..
As I was saying, I am a little curious about how it does that when the
virtual machine specifies a CCW data address that is beyond addressable
storage AND CP has a full 16MB of storage.. It's possible it uses IDAs
to do that too (specifying bogus addresses in the IDAs since IDAs can
address a full 31 or 32 address space). For example, if the virtual
machine has 8MB, but CP has 16MB.. and the guest issues a CCW with
address X'FFFFFF'.. clearly this is beyond virtual addressable storage
right ? But CP can't do the same (because X'FFFFFF' is a valid CCW data
address for CP - and you DO NOT want a virtual machine to access storage
that clearly doesn't belong to it - plus you want the channel program
check to be reported if the CCW code wasn't an immediate command after all).
What I am suspecting is that when VM does this (in order to allow the
channel to report the bogus address fetch if it applies) - then it does
throw hercules off.. DOS/VS won't have that issue because it doesn't use
any sophisticated technique there (the SELxxx CCWs will be issued with a
simple addressing (no IDAs) and hercules copes with that gracefully).
If this proves to be correct, there are probably other areas that need
to be checked (I haven't looked, but what I am suspecting is that the
channel code is inspecting the validity of the IDAWs in the IDAL even if
it is not necessary).
I'll wait for your trace further check this out..
Thanks,
--Ivan
pfg504
2008-03-28 22:07:43 UTC
Permalink
Post by Ivan Warren
Post by the_thom
Post by Ivan Warren
I'd like to know - in the situation you mention - if VM is making
ANY
Post by Ivan Warren
attempt at sending the I/O to the device.. A hercules CCW trace on
the
Post by Ivan Warren
device would be most helpful ! If we are seeing ANY Channel fetch
error
Post by Ivan Warren
on ANY immediate command - then something needs fixing !
====
If VM detects an error prior to execution, then no I/O is performed. VM definition of errors
is not directly related to the hardware. The goal was operating environment integrity and
speed. It is possible that if a particular CCW is not valid for a specific device, then a UC
could be generated without trying the operation.

Using a dedicated device that is GEN'ed as unsupported provided a method to skip device
dependent command checking.

====

====
Post by Ivan Warren
Post by the_thom
That's a good question. I don't know if the select was ever
propagated beyond VM. I would have to go back and reproduce the
problem with the CCW trace turned on. Since that machine is not
networked (and nowhere near this one), it will take me some time to
turn that around.
Kevin took the extra step of testing this on a DOS/VS system running
directly under Hercules - no error. The bogus address was silently
ignored, just like all the specs say it should be.
Having said all that: we all agree that Hercules is doing what the
370 and 3270 specs say should be done in this instance, and that VM
is *not*. If there were a broad issue with immediate commands in
Hercules, I would think they would have manifested themselves long
before this.
=====
VM and HERCULES are not the same thing and should not be compared in that manner. A
user logged on to a VM OS will have an environment that is LIKE what the POO prescribes
and does not necessarily match the REAL hard it is being hosted on.

That would defeat the idea of virtual. So, Channel ZERO will be a BYTE mode channel,
channels > zero can be either SEL/BMX depending on a directory entry (VM/370 R6) or a
DEFINE CHANNEL command.

By default all channels other than ZERO for VM/370 R6 guests are SEL. The DEFINE
CHANNEL makes all > ZERO BLOCK MUX.

======
Post by Ivan Warren
I'm not 100% sure that hercules isn't somehow guilty. When a virtual
machines issues an I/O to a dedicated device, CP has no other choice
than to transmit that I/O to that device... Even if the I/O looks bogus.
Of course, CP will perform some transformation to the CCW - at least
because it needs to translate a virtual machine's virtual addresses to
real addresses, eventually turning a straight CCW into one with some
Indirect Data..
.. thinking out loud here ..
==============
Take a look at the Section in the POO/POP called ADDRESS WRAPAROUND. It occurs in
both 24 bit and 31 bit mode at the top end of storage. ADDRESS X'FFFFFF' is NOT beyond
the range of a 24-bit PSW with 16 M Main Storage.
==============
Post by Ivan Warren
As I was saying, I am a little curious about how it does that when the
virtual machine specifies a CCW data address that is beyond addressable
storage AND CP has a full 16MB of storage.. It's possible it uses IDAs
to do that too (specifying bogus addresses in the IDAs since IDAs can
address a full 31 or 32 address space). For example, if the virtual
machine has 8MB, but CP has 16MB.. and the guest issues a CCW with
address X'FFFFFF'.. clearly this is beyond virtual addressable storage
right ? But CP can't do the same (because X'FFFFFF' is a valid CCW data
address for CP - and you DO NOT want a virtual machine to access storage
that clearly doesn't belong to it - plus you want the channel program
check to be reported if the CCW code wasn't an immediate command after all).
What I am suspecting is that when VM does this (in order to allow the
channel to report the bogus address fetch if it applies) - then it does
throw hercules off.. DOS/VS won't have that issue because it doesn't use
any sophisticated technique there (the SELxxx CCWs will be issued with a
simple addressing (no IDAs) and hercules copes with that gracefully).
If this proves to be correct, there are probably other areas that need
to be checked (I haven't looked, but what I am suspecting is that the
channel code is inspecting the validity of the IDAWs in the IDAL even if
it is not necessary).
I'll wait for your trace further check this out..
Thanks,
--Ivan
Kevin Leonard
2008-03-15 01:54:04 UTC
Permalink
IIRC, when VM is given an address that is incorrect (for example,
when the data is passed virtual addressable storage, it tries to
put some invalid address in the *real* CCW.. And *maybe* it is
using funky IDAWs to do that (for example when there is 16MB of
real storage - at which point there is no non-addressable storage
for the channel)
You have a wonderful memory. Here's the result of a potentially
interesting trace.

With DOS/VS running directly under Hercules, no VM,
a Hercules trace of the bad channel program looks like
this:

HHCCP066I DEV00C0: attention
HHCCP049I 00C0:Stat=8000 Count=0000 CCW=000000
HHCCP048I 00C0:CCW=0BE74034 60000001
HHCCP075I 00C0:Stat=0C00 Count=0001
HHCCP048I 00C0:CCW=06058034 80000024=>00000000 00000000 00000000
00000000 ................
HHCCP075I 00C0:Stat=0C40 Count=0018 =>7D40C611 C5E9A396 93A38597
00000000 ' F.EZtoltep....
HHCCP049I 00C0:Stat=0C40 Count=0018 CCW=058018

Under VM, I enter the "toltep" command. The Hercules trace
shows the attention:

HHCCP066I DEV00C0: attention
HHCCP049I 00C0:Stat=8000 Count=0000 CCW=000000

The next Hercules trace entry shows a select command,
but it's really strange:

HHCCP048I 00C0:CCW=0B000000 63000001=>000C0000 0000080C 00000000
00F43000 .............4..
HHCCP049I 00C0:Stat=0020 Count=0119 CCW=FA2E10

It is Hercules returning the channel program check. I
missed that the first time through. The data address in
the CCW is zero, but CCW flags CC+SLI+suspend are on, as
well as the last bit, which according to the POP I'm looking
at should be zero (that's probably enough right there for
the channel program check). Also the residual count is
huge. And the CCW address FA2E10 is outside the bounds
of the virtual machine, real machine size being 2M.

At this point, VM trace of SIO and I/O in the guest machine
shows the SIO pointing at the defective select:

I/O 00E67C SIO 9C002000 GRAF 00C0 CC 0 GRAF 00C0 CAW 4005B008
D T5B008.90
05B000 80000060 00E71E20 0BE74034 60000001 46 *...-.X...X .-...*
05B010 0605B034 80000024 0805B060 00E74060 *...........-.X -*
05B020 08012002 10004000 00000000 00000000 *...... .........*
05B030 00000000 00000000 00000000 00000000 *................*
05B040 TO 05B050 SUPPRESSED LINE(S) SAME AS ABOVE .....
05B050 00000000 00000000 80000060 00E71E20 *...........-.X..*
05B060 0605B070 80000040 0805B0B8 00E740B8 *....... .....X .*
05B070 00000000 00000000 00000000 00000000 *................*
05B080 TO 05B0A0 SUPPRESSED LINE(S) SAME AS ABOVE .....

and then it reflects the channel program check:

*** 006748 I/O 00C0 ==> 000BBE CSW 0020

DOS displays the I/O error message on the console:

5C55I 3270 LOCAL ERROR N0C0 , 0C0 , 04 , 0BE7403460000001 , 0020
, 00
(Hey.. what if there are NO devices on channel 0.. Or if there
are only virtual devices on virtual channel 0..).
Then DMKPRV falls through to what must have been the
original code before it was "improved" to give back
real channel STIDC information: it returns the channel
type defined in the virtual channel block.
--
Kevin
the_thom
2008-03-15 15:24:29 UTC
Permalink
Post by Kevin Leonard
It is Hercules returning the channel program check. I
missed that the first time through. The data address in
the CCW is zero, but CCW flags CC+SLI+suspend are on, as
well as the last bit, which according to the POP I'm looking
at should be zero (that's probably enough right there for
the channel program check). Also the residual count is
huge. And the CCW address FA2E10 is outside the bounds
of the virtual machine, real machine size being 2M.
Strange, I seem to recall you weren't having the same issues I was
when running DOS/VS directly under Hercules a few weeks back (namely
the channel program check). Has something changed?

Either way, it sounds like we've come back around to DOS/VS VTAM
being just plain broken. I wonder which would be easier: porting the
local device handlers over from MVS, or just doing the whole damn
package at once. I haven't studied your modified netsol to see what
needed fixing to correctly compile for DOS. The VTAM shipped with
MVS has many more APARs listed, so it's been through a lot more QA
than what's on DOS. I guess we can return to email for that
conversation.

Ivan, thanks for the STIDC change. I'll test that on my system and
let you know the results.

--Thom
Kevin Leonard
2008-03-15 19:21:58 UTC
Permalink
Post by the_thom
Strange, I seem to recall you weren't having the same issues I was
when running DOS/VS directly under Hercules a few weeks back (namely
the channel program check).
I'm not. But the invalid data address in the select CCW
is there. Hercules is ignoring it, which I think is the
correct behavior.
Post by the_thom
Either way, it sounds like we've come back around to DOS/VS VTAM
being just plain broken.
I don't know what the PTF status of the DOS/VS system is.
It may be at the base R34 level. The MVS code we've got
has had a lot of PTFs installed on top of the R3.8 base.

This particular error is occurring in ISTPIECA (ISTPICCA),
the local 3270 attention handler. After the channel type
test determines that the target 3270 is on a block, it sets
a pointer to the select CCW and calls a subroutine CPBUILD
to complete the channel program. CPBUILD tests whether a
prefix CCW has been supplied by its caller. If so, the
supplied prefix CCW is moved to the first slot in the LDB,
and as the comments say, "COMMON LDB FIELDS ARE FILLED IN".
The address of the first LDB buffer area is set in the
prefix CCW, without checking to see if the command is
one that shouldn't have a data area address.

When the channel program has been built, SVC 49 is called
to schedule the channel program for execution. ISTPIEXL
(ISTPICXL), 3270 channel program initiation, loops
translating CCW data area virtual addresses to real
addresses. It does not, however, translate the data
address if the command is either select (X'0B') or
erase all unprotected (X'0F'), neither of which
transfers data between the channel and main storage.
Thus the virtual address in the select is left
unmodified.
--
Kevin
Kevin Leonard
2008-03-21 20:47:26 UTC
Permalink
Some additional details about what's happening with the
error that VM returns in response to a select issued to
a local 3270 by DOS/VS VTAM.

Oversimplifying DMKCCW: VM decides that the select
CCW data address should be validated. Validation
fails because the address is not real to the guest.
Control is transferred to label CCWBAD4. At CCWBAD4,
VM attempts to construct a real channel program that
will induce a real channel program check, which will
subsequently be reflected back to the guest operating
system as a virtual channel program check. There are
two scenarios.

(1) If the real storage size of the machine VM is running
in (Hercules MAINSIZE) is less than 16 MB, CCWBAD4 inserts
the real storage size into the real CCW as the data address.
If MAINSIZE is 14 (hex X'E00000'), this results in the real
select CCW passed to Hercules looking like:

0BE00000 60000001

DMKCCW expects this channel program to fail. But because
Hercules doesn't validate the data address for a CCW that
doesn't transfer data, the operation completes successfully.

(2) If the real storage size is equal to 16 MB (Hercules
MAINSIZE 16), just setting the data address equal to the
real storage size isn't enough to generate a channel
program check. So CCWBAD4 turns on bits 38 and 39 (now
SUSPEND and MIDA) in the real CCW:

OI RCWFLAG,3 SET CCW INVALID FOR 16 MEG

The real CCW data address is set to zero (a residue of storing
the real storage size into the data address: X'000000' is the
three low-order bytes of X'01000000'). The resulting real CCW
is:

0B000000 63000001

Code in channel.c returns channel program check if MIDA is set
and the MIDAW feature is not present:

/* Channel program check if MIDAW not installed */ /*@MW*/
if (flags & CCW_FLAGS_MIDAW) /*@MW*/
{
chanstat = CSW_PROGC;
break;
}
Post by Ivan Warren
As I was saying, I am a little curious about how it does that
when the virtual machine specifies a CCW data address that is
beyond addressable storage AND CP has a full 16MB of storage..
It's possible it uses IDAs to do that too (specifying bogus
addresses in the IDAs since IDAs can address a full 31 or 32
address space). For example, if the virtual machine has 8MB,
but CP has 16MB.. and the guest issues a CCW with address
X'FFFFFF'.. clearly this is beyond virtual addressable storage
right ? But CP can't do the same (because X'FFFFFF' is a valid
CCW data address for CP - and you DO NOT want a virtual machine
to access storage that clearly doesn't belong to it - plus you
want the channel program check to be reported if the CCW code
wasn't an immediate command after all).
When VM R6 was written, both SUSPEND and MIDA were invalid
flag bits in the CCW. VM isn't trying to use the MIDAW
feature; it's assuming that turning on what is now the MIDA
CCW flag bit would force channel program check. Hercules
appears to be providing the desired result.
--
Kevin
Ivan Warren
2008-03-21 22:34:50 UTC
Permalink
Post by Kevin Leonard
0B000000 63000001
I'm just very curious to see how another S/370 system would react to
this. There is a slight ambiguity in GA22-7000 that would eventually
make it possible for this CCW to still be valid. The POP doesn't specify
whether CCW format validation (especially bits 38 & 39) is performed
*before* or *after* the I/O is initiated.

Unfortunatelly, S/370 systems are a rare thing to find nowadays..

--Ivan
jim s
2008-03-22 07:36:20 UTC
Permalink
Ivan Warren wrote:

<snip>
Post by Ivan Warren
Unfortunatelly, S/370 systems are a rare thing to find nowadays..
9370/20 and 9370/30 or do these have to be actual 370's to have
relevance here? Both of the ones I know of have real channels, as in
bus / tag, and are not the P/370's or P/390's

Jim
Peter
2008-03-22 07:55:32 UTC
Permalink
Post by jim s
9370/20 and 9370/30 or do these have to be actual 370's to have
relevance here? Both of the ones I know of have real channels, as in
bus / tag, and are not the P/370's or P/390's
Parallel (bus/tag) and serial (ESCON).
Ivan Warren
2008-03-22 12:47:00 UTC
Permalink
Post by jim s
<snip>
Post by Ivan Warren
Unfortunatelly, S/370 systems are a rare thing to find nowadays..
9370/20 and 9370/30 or do these have to be actual 370's to have
relevance here? Both of the ones I know of have real channels, as in
bus / tag, and are not the P/370's or P/390's
Jim
Any S/370 capable IBM built machine is fine (this includes S/370s, 303x,
43xx, 308x, 3090, 9370, P/370 and P|R/390 - no "real" channel
required).. Also, any XA/ESA machine (non z/Arch machines) running VM/XA
or VM/ESA would do too (but not z/VM since it doesn't support S/370
virtual machines).

--Ivan
Dave Wade
2008-03-22 13:52:54 UTC
Permalink
Ivan,

Even I have , at least for a while, access to a VM/ESA machine,

Dave.



-----Original Message-----
From: hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] On
Behalf Of Ivan Warren
Sent: 22 March 2008 12:47
To: hercules-390-***@public.gmane.org
Subject: Re: [hercules-390] Re: S/370 Channel 0 and/or select CCW
considerations
Post by jim s
<snip>
Post by Ivan Warren
Unfortunatelly, S/370 systems are a rare thing to find nowadays..
9370/20 and 9370/30 or do these have to be actual 370's to have
relevance here? Both of the ones I know of have real channels, as in
bus / tag, and are not the P/370's or P/390's
Jim
Any S/370 capable IBM built machine is fine (this includes S/370s, 303x,
43xx, 308x, 3090, 9370, P/370 and P|R/390 - no "real" channel
required).. Also, any XA/ESA machine (non z/Arch machines) running VM/XA
or VM/ESA would do too (but not z/VM since it doesn't support S/370
virtual machines).

--Ivan





[Non-text portions of this message have been removed]
Kevin Leonard
2008-03-22 22:52:33 UTC
Permalink
Post by Ivan Warren
Post by Kevin Leonard
0B000000 63000001
I'm just very curious to see how another S/370 system would
react to this. There is a slight ambiguity in GA22-7000 that
would eventually make it possible for this CCW to still be
valid. The POP doesn't specify whether CCW format validation
(especially bits 38 & 39) is performed *before* or *after*
the I/O is initiated.
Looking at GA72-7000-8 dated October 1981. This level of the
manual defines bit 38 as the SUSPEND flag, with revision bars
next to the paragraph defining it. It goes on to say:

* Bit position 39 of every CCW other than one specifying
* transfer in channel must contain zero. Otherwise,
* a program-check condition is generated. When the
* first CCW designated by the CAW does not contain
* zero in bit position 39, the I/O operation is not
* initiated, and the status portion of the CSW with
* the program-check indication is stored during
* execution of START I/O or START I/O FAST RELEASE
* being executed as START I/O. Detection of this
* condition during data chaining causes the I/O
* device to be signaled to conclude the operation.
* When the absence of these zeros is detected during
* command chaining or subsequent to the execution of
* START I/O FAST RELEASE, the new operation is not
* initiated, and an interruption condition is generated.

I read that as saying that if the first CCW has bit 39
on, the SIO fails with CC=1 and CSW indicating channel
program check. If the first CCW is OK but the second or
subsequent CCW has bit 39 on, the SIO completes with CC=0
and a CSW indicating channel program check is presented
during a subsequent interrupt.

This doesn't appear to be what Hercules is doing. It looks
like the SIO completes successfully even though the first
CCW has bit 39 on, and the channel program check occurs
in a subsequent interrupt. Here's a script to issue a
SIO with the invalid select as the first CCW. I turned
on bit 39 but left bit 38 off:

# Issue defective select to 3270 0C1 and wait for I/O interrupt
archmode S/370
sysreset
r 00=0000000000000400 # Restart new PSW
r 28=000200000000DEAD # Program new PSW
r 78=000200000000AAAA # I/O new PSW
r 48=00000440 # CAW
r 400=411000C1 # R1 = device address 0C1
r 404=9C001000 # SIO 0(R1)
r 408=82000438 # LPSW ENWAIT load enabled wait PSW
r 430=000200000000BEEF # WAITPSW disabled wait PSW
r 438=FE0200000000FFFF # ENWAIT enabled wait PSW
r 440=0B00000061000001 # CCW 1 = select with bit 39 set to 1
r 448=0600048020000008 # CCW 2 = read
r 480=EEEEEEEEEEEEEEEE # Input area
s+
restart

Running this produces:

PSW=00000000 00000400 INST=411000C1 LA 1,193(0,0)
PSW=00000000 00000404 INST=9C001000 SIO 0(1)
HHCCP048I 00C1:CCW=0B000000 61000001=>00000000 00000400
PSW=00000000 80000408 INST=82000438 LPSW 1080(0)
HHCCP043I Wait state PSW loaded: PSW=FE020000 8000FFFF
HHCCP049I 00C1:Stat=0020 Count=0000 CCW=000448
HHCCP044I I/O interrupt code=00C1 CSW=00000448 00200000
HHCCP043I Wait state PSW loaded: PSW=00020000 8000AAAA
HHCCP011I CPU0000: Disabled wait state
PSW=00020000 8000AAAA
--
Kevin
Ivan Warren
2008-03-23 02:23:22 UTC
Permalink
Post by Kevin Leonard
Looking at GA72-7000-8 dated October 1981. This level of the
manual defines bit 38 as the SUSPEND flag, with revision bars
* Bit position 39 of every CCW other than one specifying
* transfer in channel must contain zero. Otherwise,
* a program-check condition is generated. When the
* first CCW designated by the CAW does not contain
* zero in bit position 39, the I/O operation is not
* initiated, and the status portion of the CSW with
* the program-check indication is stored during
* execution of START I/O or START I/O FAST RELEASE
* being executed as START I/O. Detection of this
* condition during data chaining causes the I/O
* device to be signaled to conclude the operation.
* When the absence of these zeros is detected during
* command chaining or subsequent to the execution of
* START I/O FAST RELEASE, the new operation is not
* initiated, and an interruption condition is generated.
Gotcha.. the one I was looking at was .. hmm.. quite outdated ! (still
leaves the question of HOW IN THE WORLD can CP emulate an immediate I/O
CCW to a device with an invalid address field when there is 16MB of real
storage)..
Post by Kevin Leonard
I read that as saying that if the first CCW has bit 39
on, the SIO fails with CC=1 and CSW indicating channel
program check. If the first CCW is OK but the second or
subsequent CCW has bit 39 on, the SIO completes with CC=0
and a CSW indicating channel program check is presented
during a subsequent interrupt.
This doesn't appear to be what Hercules is doing. It looks
like the SIO completes successfully even though the first
CCW has bit 39 on, and the channel program check occurs
in a subsequent interrupt. Here's a script to issue a
SIO with the invalid select as the first CCW. I turned
I know.. same thing happens when issuing an I/O to a device that is not
ready.. For most I/Os this should also result in the CSW getting stored
at I/O initiation time (the CSW is returned right after device
selection) and thus should return CC=1 for SIO (or for SIOF when SIOF is
issued as SIO.. basically, hercules always executes SIO as SIOF (which
is *wrong*)).

This will need to get addressed eventually !

--Ivan
the_thom
2008-03-23 16:54:28 UTC
Permalink
Post by Ivan Warren
Gotcha.. the one I was looking at was .. hmm.. quite outdated ! (still
leaves the question of HOW IN THE WORLD can CP emulate an
immediate I/O
Post by Ivan Warren
CCW to a device with an invalid address field when there is 16MB of real
storage)..
In my case, the CCW is being generated by DOS/VS in a virtual
machine with less than 16MB of storage.

It's in range for VM, but not for the guest (at least, not in range
of "real" storage, the address was in DOS/VS *virtual* address
space, beyond the "real" address space of the virtual machine DOS/VS
is running in).

Basically, you are in a maze of twisty little passages, all alike.

--Thom
Ivan Warren
2008-03-23 23:44:32 UTC
Permalink
Post by the_thom
In my case, the CCW is being generated by DOS/VS in a virtual
machine with less than 16MB of storage.
That was the corollary to my statement.

It seems odd there is no way for a hypervisor to emulate for a virtual
machine the behavior of issuing a CCW specifying an address that is
beyond *virtual* addressable storage when there is no *REAL*
non-addressable storage on the real machine and the CCW specifies an
immediate I/O code (and CP doesn't or cannot know whether the I/O is
immediate or not short of issuing it).

I was starting to believe that specifying both bits 38 & 39 to 1 in a
CCW would have somehow triggered a non-documented behavior of the S/370
architecture which would only have triggered a CPC upon the CU
requesting data from the channel (thus allowing a program to trigger a
CPC only on non-immediate CCWs when there is 16MB of storage in the
config). This seems to not be the case since the S/370 POP that Kevin
mentions seems to explicitly prohibit this. (note that issuing an I/O
with a correctly formatted CCW specifying an immediate I/O but a
non-addressable storage address still shouldn't lead to a CPC.. That's
specifically covered in various paragraphs in the POP).

--Ivan
the_thom
2008-03-24 22:37:15 UTC
Permalink
Post by Ivan Warren
Post by the_thom
In my case, the CCW is being generated by DOS/VS in a virtual
machine with less than 16MB of storage.
That was the corollary to my statement.
It seems odd there is no way for a hypervisor to emulate for a
virtual
Post by Ivan Warren
machine the behavior of issuing a CCW specifying an address that is
beyond *virtual* addressable storage when there is no *REAL*
non-addressable storage on the real machine and the CCW specifies an
immediate I/O code (and CP doesn't or cannot know whether the I/O is
immediate or not short of issuing it).
For CP to accommodate a CCW that specifies an address that is only
valid within the virtual space *of the guest OS* would require CP to
have direct knowledge of that guest OS's paging activities. Real
hardware can't do that, so there's no reason to expect an emulator
(which is all VM really is) to be able to.

It would also require VM to validate the addresses in *every* CCW,
including immediate commands, which we all agree (and the POP
states) it's not supposed to be doing. CP isn't generating the CCW,
it's merely passing it along.

Maybe we're discussing two different things, but I don't see
anything mysterious about it.

--Thom
Ivan Warren
2008-03-25 06:45:13 UTC
Permalink
Post by the_thom
For CP to accommodate a CCW that specifies an address that is only
valid within the virtual space *of the guest OS* would require CP to
have direct knowledge of that guest OS's paging activities. Real
hardware can't do that, so there's no reason to expect an emulator
(which is all VM really is) to be able to.
It would also require VM to validate the addresses in *every* CCW,
including immediate commands, which we all agree (and the POP
states) it's not supposed to be doing. CP isn't generating the CCW,
it's merely passing it along.
Oh.. Let me tell you that CP *DOES* validate each and every CCW that it
is being presented by a virtual machine. That's because CP *has* to
translate CCW addresses from the host virtual address ones (the ones
that appear absolute to the guest) to 1st level absolute addresses (the
ones that can be used for I/O) - among other things.

Whether the virtual machine has its own virtual addressing is irrelevant
because addresses in CCWs are always absolute (but if it weren't the
case, it wouldn't really matter because CP *DOES* know of a virtual
machine's 2nd level DAT table - otherwise it wouldn't be able to emulate
DAT for that virtual machine - using shadow tables).

And no.. CP doesn't "pass along" the CCWs.. it issues it's own modified
version (sometime the CCW issued by CP has *NOTHING* to do with the CCW
issued by the virtual machine..) - and sometimes it doesn't even issue
any real I/O at all (for example : a coupled virtual CTC).

The only case when CP doesn't translate a CCW is when the virtual
machine is a V=R VM, the device is dedicated and the virtual machine has
CCWNOTRANS ON set.

On more modern versions of VM, it is possible for a virtual machine
(with the appropriate CP directory option set) to issue *real* CCWs
directly using a Diagnose instruction (which provides facilities to lock
and map pages, unlock pages and issue I/Os to dedicated devices). (for
VM/SP, this is "DIAG 98".. This is only available using a CP directory
statement because it inherently gives the very potent capability for a
virtual machine to read & write *REAL* host storage - akin to a class C
virtual machine).

Because it is somewhat heavy on CP to do all that translating, there is
also a couple of CP Assist E6xx instructions that will aid CP in
translating CCWs (not implemented under hercules).

Example 1 :
A VM Issues
CCW X'0B',X'1000',X'20',1 to a dedicated 3270.
CP will have to look up the virtual machine's X'1000' address to
determine the real page frame (PTRAN BRING,TYPE=DEFER).. If the
resulting page is, say, X'80E000' then CP issues
CCW X'0B',X'80E000',X'20',1

Example 2 :
A VM Issues
CCW X'0B',X'F00000',X'20',1 to a dedicated 3270 and the VM only has
2MB of virtual storage (and no DCSS loaded at that address)
CP Will look up the page and determine it is outside the VM's address
space. VM/370 R6 will then determine it's own storage size and if it has
less than 16MB it will issue the CCW with a storage address that is
outside the real addressable space. If it has 16MB, then there is no way
to do that, so it issues a CCW with bits 38 & 39 set to force a CPC.
(and that's the problem we are seeing : a CPC is generated *regardless*
of whether the I/O is immediate or not).

Example 3 :
A VM Issues
CCW X'02',X'F00000',X'20',1 to a virtual reader
CP will look up the page and determine it is outside the VM's address
space. Since it is a virtual device, CP knows it is NOT an immediate I/O
(X'01' would be a request to read a card). Assuming the virtual reader
is ready, it will queue a virtual I/O interrupt to the virtual machine
with a CSW specifying a CPC *without having issued any real I/O*. If the
reader is not ready, a CSW is made pending at SIO time (SIO CC=1) with a
CSW containing UC only. If the CCW is valid (including the address), the
*actual* CCW issued (if necessary) will be one to fetch a page from a CP
owned volume's spool space that contains the spool file that is
available for that virtual reader.

--Ivan
Tony Harminc
2008-03-25 16:13:44 UTC
Permalink
Post by Ivan Warren
A VM Issues
CCW X'0B',X'F00000',X'20',1 to a dedicated 3270 and the VM only has
2MB of virtual storage (and no DCSS loaded at that address)
CP Will look up the page and determine it is outside the VM's address
space. VM/370 R6 will then determine it's own storage size and if it has
less than 16MB it will issue the CCW with a storage address that is
outside the real addressable space. If it has 16MB, then there is no way
to do that, so it issues a CCW with bits 38 & 39 set to force a CPC.
(and that's the problem we are seeing : a CPC is generated *regardless*
of whether the I/O is immediate or not).
A VM Issues
CCW X'02',X'F00000',X'20',1 to a virtual reader
CP will look up the page and determine it is outside the VM's address
space. Since it is a virtual device, CP knows it is NOT an immediate I/O
(X'01' would be a request to read a card). Assuming the virtual reader
is ready, it will queue a virtual I/O interrupt to the virtual machine
with a CSW specifying a CPC *without having issued any real I/O*.
[snip]

I'm missing just one little bit here... Why is it that CP can't treat
example 2 like example 3? Why does it have to issue a real I/O that is
crafted to fail, rather than just making up the CPC on its own? Is it
because CP doesn't know the characteristics of the real device if it's
ATTACHed, or doesn't want to have to understand such details for even
supported device types? Or is it done so as to leave the real I/O
system (channel, device, etc.) in a correct state for subsequent
operations such as sense? Or something else...?

Tony H.
pfg504
2008-03-28 22:38:02 UTC
Permalink
Post by Tony Harminc
Post by Ivan Warren
A VM Issues
CCW X'0B',X'F00000',X'20',1 to a dedicated 3270 and the VM only has
2MB of virtual storage (and no DCSS loaded at that address)
CP Will look up the page and determine it is outside the VM's address
space. VM/370 R6 will then determine it's own storage size and if it has
less than 16MB it will issue the CCW with a storage address that is
outside the real addressable space. If it has 16MB, then there is no way
to do that, so it issues a CCW with bits 38 & 39 set to force a CPC.
(and that's the problem we are seeing : a CPC is generated *regardless*
of whether the I/O is immediate or not).
A VM Issues
CCW X'02',X'F00000',X'20',1 to a virtual reader
CP will look up the page and determine it is outside the VM's address
space. Since it is a virtual device, CP knows it is NOT an immediate I/O
(X'01' would be a request to read a card). Assuming the virtual reader
is ready, it will queue a virtual I/O interrupt to the virtual machine
with a CSW specifying a CPC *without having issued any real I/O*.
[snip]
=== Are you implying that this is the SPOOLED Virtual Reader.
=== Virtual UR is a very special case because of the Spooler.
Post by Tony Harminc
I'm missing just one little bit here... Why is it that CP can't treat
example 2 like example 3? Why does it have to issue a real I/O that is
crafted to fail, rather than just making up the CPC on its own? Is it
because CP doesn't know the characteristics of the real device if it's
ATTACHed, or doesn't want to have to understand such details for even
supported device types? Or is it done so as to leave the real I/O
system (channel, device, etc.) in a correct state for subsequent
operations such as sense? Or something else...?
Tony H.
the_thom
2008-03-25 20:35:57 UTC
Permalink
Post by Ivan Warren
Oh.. Let me tell you that CP *DOES* validate each and every CCW that it
is being presented by a virtual machine. That's because CP *has* to
translate CCW addresses from the host virtual address ones (the ones
that appear absolute to the guest) to 1st level absolute addresses (the
ones that can be used for I/O) - among other things.
Yes, I understand that. But we've all agreed that the trouble is
being caused by VM validating an address it's not supposed to care
about (in the case of the select command).
Post by Ivan Warren
Whether the virtual machine has its own virtual addressing is
irrelevant
Post by Ivan Warren
because addresses in CCWs are always absolute (but if it weren't the
case, it wouldn't really matter because CP *DOES* know of a
virtual
Post by Ivan Warren
machine's 2nd level DAT table - otherwise it wouldn't be able to emulate
DAT for that virtual machine - using shadow tables).
If that were true in this case, this problem would never have
occurred. The problem with the address in the select CCW is that it
was virtual within DOS/VS, beyond the 4M storage size of the DOS/VS
virtual machine.

I'm not aware of VM/370 emulating second-level DAT tables at all (in
fact, it seems mutually-exclusive to have reserved pages as an
option in a system which could just do the paging for you in that
case), I seem to recall that functionality came along later in VM's
life.

It's all moot, anyway. The problem is with VM, so there's no need
for us to debate *what* the problem with VM actually is. It's
interesting, but doesn't add anything to the Hercules project.
Ivan Warren
2008-03-26 11:25:26 UTC
Permalink
Post by Ivan Warren
because addresses in CCWs are always absolute (but if it weren't
the
Post by Ivan Warren
case, it wouldn't really matter because CP *DOES* know of a
virtual
Post by Ivan Warren
machine's 2nd level DAT table - otherwise it wouldn't be able to
emulate
Post by Ivan Warren
DAT for that virtual machine - using shadow tables).
If that were true in this case, this problem would never have
occurred. The problem with the address in the select CCW is that it
was virtual within DOS/VS, beyond the 4M storage size of the DOS/VS
virtual machine.
That doesn't matter. The address specified in a CCW is always an
absolute address. However, the storage reference by the address in a CCW
when the I/O is in immediate command should not be fetched (and thus
should not generate a CPC).
I'm not aware of VM/370 emulating second-level DAT tables at all (in
fact, it seems mutually-exclusive to have reserved pages as an
option in a system which could just do the paging for you in that
case), I seem to recall that functionality came along later in VM's
life.
VM/370 emulates DAT in a virtual machine, otherwise you wouldn't be able
to run DOS/VS or any other operating system using DAT in a virtual machine
It's all moot, anyway. The problem is with VM, so there's no need
for us to debate *what* the problem with VM actually is. It's
interesting, but doesn't add anything to the Hercules project.
It's not moot if DOS/VS running on an IBM built system could run with
less than 16MB of virtual storage under VM/370 R6 and the real system
had 16MB with 3270 devices attached to an address > X'0FF' with SET
CHANNEL BMX in effect (in which case it indicates an error exists in the
hercules emulation code).

--Ivan
Lindy Mayfield
2008-03-26 11:55:41 UTC
Permalink
What am I doing wrong here? I have DASD files (on Windows) that I have
DASDINIT as 3390-27 (zlib compressed) yet the actual file is going over
2GB. It will actually expand to over 4GB but when that happens I get a
ton of "over 4 gig" messages to the Herc console and the DASD becomes
corrupted.



My understanding was that the files would be split up and numbered
sequentially and not go over 2GB.



Lindy



[Non-text portions of this message have been removed]
Peter Vels
2008-03-26 12:05:33 UTC
Permalink
Post by Lindy Mayfield
What am I doing wrong here? I have DASD files (on Windows) that I have
DASDINIT as 3390-27 (zlib compressed) yet the actual file is going over
2GB. It will actually expand to over 4GB but when that happens I get a
ton of "over 4 gig" messages to the Herc console and the DASD becomes
corrupted.
My understanding was that the files would be split up and numbered
sequentially and not go over 2GB.
Lindy
Working as designed - see http://www.hercules-390.org/hercload.html

You said you're creating compressed DASD (CCKD). The multiple file stuff is
for CKD (non-compressed DASD).

Peter


[Non-text portions of this message have been removed]
Lindy Mayfield
2008-03-26 12:46:36 UTC
Permalink
Thanks again, Peter. (-:



To be honest, I had that page open and right in front of me. I had
scanned down below where it says "Volumes exceeding 2GB" and under
examples my eyes hit the -bz2 option.



I just tried to read it carefully and I still haven't seen where it says
that, but I totally trust you are correct.





________________________________

From: hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org]
On Behalf Of Peter Vels
Sent: 26. maaliskuuta 2008 14:06
To: hercules-390-***@public.gmane.org
Subject: Re: [hercules-390] DASD going over 2GB
What am I doing wrong here? I have DASD files (on Windows) that I have
DASDINIT as 3390-27 (zlib compressed) yet the actual file is going over
2GB. It will actually expand to over 4GB but when that happens I get a
ton of "over 4 gig" messages to the Herc console and the DASD becomes
corrupted.
My understanding was that the files would be split up and numbered
sequentially and not go over 2GB.
Lindy
Working as designed - see http://www.hercules-390.org/hercload.html
<http://www.hercules-390.org/hercload.html>

You said you're creating compressed DASD (CCKD). The multiple file stuff
is
for CKD (non-compressed DASD).

Peter





[Non-text portions of this message have been removed]
Peter Vels
2008-03-27 10:18:59 UTC
Permalink
...I just tried to read it carefully and I still haven't seen where it
says
that, but I totally trust you are correct.
It says "For CKD volumes which exceed 2GB...". but you are not creating a
CKD volume. You are creating a CCKD volume. Big difference. I agree that
the restriction is only implied by the web page, but it still seems to be
the case.

Peter


[Non-text portions of this message have been removed]
the_thom
2008-03-26 16:27:06 UTC
Permalink
Post by Ivan Warren
Post by the_thom
The problem with the address in the select CCW is that it
was virtual within DOS/VS, beyond the 4M storage size of the
DOS/VS
Post by Ivan Warren
Post by the_thom
virtual machine.
That doesn't matter. The address specified in a CCW is always an
absolute address.
It's *supposed* to be, yes. The CCW that VTAM put in the select CCW
was not. That address had not been translated to any address that
would have been "absolute" to DOS/VS's point of view.

I'm not making this up.
Post by Ivan Warren
However, the storage reference by the address in a CCW
when the I/O is in immediate command should not be fetched (and thus
should not generate a CPC).
Absolutely right.
Post by Ivan Warren
It's not moot if DOS/VS running on an IBM built system could run with
less than 16MB of virtual storage under VM/370 R6 and the real
system
Post by Ivan Warren
had 16MB with 3270 devices attached to an address > X'0FF' with SET
CHANNEL BMX in effect (in which case it indicates an error exists in the
hercules emulation code).
My point is that not only was VM/370 broken, DOS/VS VTAM was also
broken. The address VTAM put in the CCW was bogus, period. It should
have been an absolute address (to DOS/VS's point of view), but it
wasn't (no matter how much you disagree with me on that).

Moot or not, this conversation is chasing its own tail. I've done my
part, I found the error and reported it. Kevin gave you the traces
you wanted. You changed channel 0 to byte multiplexor (thanks
again), but there's nothing more I can contribute to this.

--Thom
Ivan Warren
2008-03-26 17:39:16 UTC
Permalink
Post by the_thom
It's *supposed* to be, yes. The CCW that VTAM put in the select CCW
was not. That address had not been translated to any address that
would have been "absolute" to DOS/VS's point of view.
I'm not making this up.
It's irrelevant ! The storage address in a CCW is always absolute (the
fact that this address happens to be a "virtual" address in the program
doesn't make it a virtual address in a CCW). The fact that DOS/VS' VTAM
uses an address that is outside it's addressable space should be
irrelevant since the CCW I/O code is for an immediate command (but it is
causing a problem when VM/370 is running with 16MB).
Post by the_thom
My point is that not only was VM/370 broken, DOS/VS VTAM was also
broken. The address VTAM put in the CCW was bogus, period. It should
have been an absolute address (to DOS/VS's point of view), but it
wasn't (no matter how much you disagree with me on that).
I disagree. Neither are broken. Although DOS/VS VTAM is specifying an
address in the CCW that is outside the addressable range, it shouldn't
cause a CPC because the select I/O is an immediate command. VM/370 isn't
broken either because, when it has less than 16MB it correctly specifies
an address that is also outside it's addressable range. When it has
16MB, it is possible that there are no other options for VM/370 than to
specify this ill formatted CCW which leads to a CPC on the hosting layer
(regardless of whether the I/O is immediate or not and THAT is the
problem - and I shall repeat myself again - it may either be a hercules
bug or a S/370 architecture limitation - but in neither case is it a
DOS/VS VTAM bug nor a VM/370 bug) - the point is that if anything is
broken, it's hercules.
Post by the_thom
Moot or not, this conversation is chasing its own tail. I've done my
part, I found the error and reported it. Kevin gave you the traces
you wanted. You changed channel 0 to byte multiplexor (thanks
again), but there's nothing more I can contribute to this.
You managed to circumvent your specific problem (DOS/VS using VTAM under
VM/370 with 16MB of real storage and less than 16MB of virtual storage
and 3270 devices attached to channel 0), which is fine, but you managed
to uncover a possible problem in hercules. However, the solution here
(having hercules now correctly report channel 0 as a byte multiplexor)
only addresses 3270 graphics devices attached to channel 0. If the 3270
is attached to another 'virtual' channel and SET CHAN BMX is in effect,
the problem will rise again (because DOS/VS VTAM will again attempt to
issue a SELECT CCW with an out of range storage address - which I repeat
again is a perfectly VALID thing to do). Your solution here then is to
either give 15MB to VM/370 (instead of 16MB) or to give your DOS/VS
virtual machine 16MB or to define channels as SEL (but this may lead to
other issues such as not permitting some I/Os to overlap) or to restrict
VTAM devices to channel 0 (the 2 latter cases driving DOS/VS VTAM not to
issue the problematic (despite perfectly *VALID*) Select CCW).

The fact that you are not willing or unable to help any further is fine
by me - but it doesn't mean I personally have to end my search on this -
and request help from others - because I still believe there is a
possible *BUG* in hercules. The only way to find out if this is a
hercules bug or an inherent limitation of the S/370 architecture for
virtualization using VM/370 would be to have VM/370 run on another
hardware (preferably IBM built) with at least 16MB of real storage and
to see how it behaves in that case. If this case shows that issuing an
immediate command I/O with a storage address in the CCW outside the
virtual machine's addressable storage address range doesn't yield a CPC,
then something needs to be done in hercules to correct the situation so
that hercules behaves like a reference implementation of the S/370
architecture.

--Ivan
the_thom
2008-03-26 20:42:50 UTC
Permalink
Post by Ivan Warren
The fact that you are not willing or unable to help any further is fine
by me - but it doesn't mean I personally have to end my search on this -
and request help from others - because I still believe there is a
possible *BUG* in hercules.
Never said you should, all I'm saying is that my ability to contribute
much further is diminshed at this point for various reasons. That's
all.

I'm sure you'll get to the bottom of it. Thanks again for what you've
done so far.

--Thom
pfg504
2008-03-27 16:11:05 UTC
Permalink
Thom,

You have stated that VM is BROKEN. This is the second time I have asked for specific
information to determine if this is the case.

The original request was:

For the VM testing, is hercules running with or without assists turned on? The
assists were used to translate addresses. If they are on, would you turn them off and rerun
the test?

Assists: E608, E609, E604, E60C, E60F

Second, what type of device is being used as specified in DMKRIO? Some CCW
validation is done at the devtype level.

Which Version, Release, etc. of VM are you using?
Is the IO being done to the virtual CONS or to a dedicate/attached virtual device?

IO to a "SPECIAL" device, a SPOOLED device or the VIRTUAL console behaves
differently that to an attached device.

Some validation is done to CCW chains against the devtype specified in DMKRIO.
Defining a device as unsupported minimizes checks.
----

Other considerations, the version/service level of VM/370 that we have made available
was in production shops for several years and in several shops running DOS and OS. I can
not fine any reported error by a IBM customer with these symptoms.

At this point declarations of a failure within VM, DOS or HERCULES must be scrutinized,
researched and proven. All the stubborn bantering back and forth is not productive.

As the current care taker of VM/370 multipack distribution, I asked specific questions to
try and assist you in resolving your issue. They were ignored. NO DUMP - NO PROBLEM.

VM/370 is not a emulation or a simulator. It is a multi-user operating system that
provides a 360/370 environment that can support executing an guest OS, CMS or other
standalone programs while maintaining isolation of each of the guests environments. It is
not constrained by the "Principles of Operation". In order to maintain integrity of the
running environment, additional constrains are in place.

Hercules is an emulator. Not every IBM machine in each generation behaved exactly the
same. Although the POO/POP defines a lot of rules, it also left up to interpretation and in
some cases, never defined several behaviors.

HERCULES is probably the closest thing that matches the POO/POP completely. IBM never
implement hardware that support all of the functions of each class of machine. That is one
of the reasons CONTROL Registers are in the architecture.

When you specify a machine type in the configuration file, such as 4381. This does not
mean that Hercules is running as a 4381. It is just used as the returned results in a STIDP
instruction. However, the OS will respond differently, especially MVT/MFT and MVS
because they have specific code that was table driven that affects scheduling, dispatching
and recovery.

You have the source to HERCULES and VM/370, Have you looked into solving the problem
yourself and sharing your results group?

Paul
the_thom
2008-03-27 17:02:25 UTC
Permalink
Post by pfg504
Thom,
You have stated that VM is BROKEN. This is the second time I have asked for specific
information to determine if this is the case.
I'm very sorry, but I didn't *see* your initial request. No need to
take that tone, but I'll answer your questions anyway.
Post by pfg504
For the VM testing, is hercules running with or without assists turned on? The
assists were used to translate addresses. If they are on, would you turn them off and rerun
the test?
Assists: E608, E609, E604, E60C, E60F
The assists were not explicitly set either way. Whatever the
default, that's what the settings were.
Post by pfg504
Second, what type of device is being used as specified in DMKRIO? Some CCW
validation is done at the devtype level.
I don't have the machine networked to this one, so I can't just copy-
and-paste the entry. The device is defined in DMKRIO as a 3277 on a
3272.
Post by pfg504
Which Version, Release, etc. of VM are you using?
VM/370 R6L0. Built from the distribution tapes.
Post by pfg504
Is the IO being done to the virtual CONS or to a
dedicate/attached virtual device?

VTAM only works with graf devices, not the VM console. This was
originally discovered on an attached graf, reproduced on a dialled
graf. Wasn't tested with a dedicated graf.
Post by pfg504
As the current care taker of VM/370 multipack distribution, I
asked specific questions to
Post by pfg504
try and assist you in resolving your issue. They were ignored. NO DUMP - NO PROBLEM.
STOP SHOUTING. This isn't *your* distribution, it's a system I built
from tape. Your questions weren't "ignored", they simply *weren't
seen*.

If you go back and read the thread from the beginning, you'll not
only find most of the answers you demanded, you'll also see that I'm
not looking for *any* help with VM.
Post by pfg504
You have the source to HERCULES and VM/370, Have you looked into solving the problem
yourself and sharing your results group?
I started to, but I have a life outside of Hercules, and don't have
the time to devote to that. I'm sorry if that pisses you off, but
it's a fact of life.

If you have any more questions, feel free to ask; but please don't
get all wrapped around the axles if I miss the post or don't respond
*immediately*. I don't have the time to devote to this that I had a
few months ago.

--Thom
t***@public.gmane.org
2008-03-27 17:47:27 UTC
Permalink
Hello, all

I'm new in this group. I used to work as a programmer in IBM Uruguay
(that's South America) for a 1401, and later in the university (same
country) as a systems programmer. At that time, in the seventies, we had a
360/44 with an incredible 128K main memory :-)

We used two OS's: at first IBM's own PS/44, and later Purdue University'
MFT/44, which was a simple multitasking OS based on PS/44, mainly with a
reader and printer spooler. We had the sources for both OSes then, but they
are lost now. I wonder if someone in this list has or knows about these.

The machine originally lacked the decimal instruction set. We programmed it
in Fortran G and BAL and I also istalled Algol, but it was never used
(except by me, that is) Later, somebody decided to teach COBOL and we had
to upgrade to the decimal instruction set. Sadly, when installed, we
discovered that the decimal instruction set was emulated and hence very
slow. But we could install 2314 disks and run DOS/360, which made available
COBOL for the students and PL/I for some of us programmers.

Later I changed to DEC PDP8's, 11's and Vaxes and still later to Unix.
However, thanks to Hercules I'm remembering my long gone IBM days!

I have read somewhere that the /44 doesn't run on Hercules, is that true?
It was a nice and very fast scientific machine...

Cheers
Tom Sobota
Madrid, Spain
pfg504
2008-03-27 20:02:08 UTC
Permalink
Thanks for the information;

First, please download the VMDIST.ZIP from http://homepage.mac.com/WebObjects/FileSharing.woa/56/wo/rHIahkT7B1d1clxo.1/2.2.
1.2.26.31.97.2.35.0.1.1.1?user=pfg504&fpath=VM-
370%20for%20Hercules:VM370R6&templatefn=FileSharing3.html

or: http://homepage.mac.com/pfg504/Menu2.html

There are several hundred fixes included in this system all are important and it has been a
very stable system.

The default for ECPSVM should be off, but just in case, please include ECPSVM NO in the
configuration file.

The VMDIST system has several enhancements that are documented on the 093 and 094
MAINT minidisks.

Regarding the tone:
I want to reinforce that several people devote hundreds of hours for free to make all of
these components work as best that we can. We are not obligated to do any thing to
support the community, it is our choice and desire to do so. Keep this in mind when
seeking help.

The average person support this effort has more than 30 years of systems programming
experience and we want to share this with the community. It is often a very thankless endeavor and I have zero tolerance for any counter-productive communication.

I am certain that Ivan has study the I/O area very carefully and would appreciate any help
in identifying and solving problems. On IBM machines I/O is almost as complex as the
entire rest of the machine.

It is very difficult to tell what each of our specialities are because our biographies or
resumes are generally not posted, so I am guessing that most people are going to assume
that the skill set is similar to their own. This is probably a bad idea.

For example, you would not know that my VM experience goes back to 1970, or that I
managed an IBM mainframe CPU development group while working for Dr. Gene Amdahl,
or that I was an VM developer and specialist at Amdahl Corp. developing VM/PE and
providing customer support in the Amdahl Eastern Support Center while at the same time
developing and supporting Zenith Z90 PCs as a remote service device for Amdahl V6-V8
processors.

Any way, we are more than happy to help, but, treat us kindly...


Paul
Post by pfg504
Post by pfg504
Thom,
You have stated that VM is BROKEN. This is the second time I have
asked for specific
Post by pfg504
information to determine if this is the case.
I'm very sorry, but I didn't *see* your initial request. No need to
take that tone, but I'll answer your questions anyway.
Post by pfg504
For the VM testing, is hercules running with or without assists
turned on? The
Post by pfg504
assists were used to translate addresses. If they are on, would
you turn them off and rerun
Post by pfg504
the test?
Assists: E608, E609, E604, E60C, E60F
The assists were not explicitly set either way. Whatever the
default, that's what the settings were.
Post by pfg504
Second, what type of device is being used as specified in DMKRIO?
Some CCW
Post by pfg504
validation is done at the devtype level.
I don't have the machine networked to this one, so I can't just copy-
and-paste the entry. The device is defined in DMKRIO as a 3277 on a
3272.
Post by pfg504
Which Version, Release, etc. of VM are you using?
VM/370 R6L0. Built from the distribution tapes.
Post by pfg504
Is the IO being done to the virtual CONS or to a
dedicate/attached virtual device?
VTAM only works with graf devices, not the VM console. This was
originally discovered on an attached graf, reproduced on a dialled
graf. Wasn't tested with a dedicated graf.
Post by pfg504
As the current care taker of VM/370 multipack distribution, I
asked specific questions to
Post by pfg504
try and assist you in resolving your issue. They were ignored. NO
DUMP - NO PROBLEM.
STOP SHOUTING. This isn't *your* distribution, it's a system I built
from tape. Your questions weren't "ignored", they simply *weren't
seen*.
If you go back and read the thread from the beginning, you'll not
only find most of the answers you demanded, you'll also see that I'm
not looking for *any* help with VM.
Post by pfg504
You have the source to HERCULES and VM/370, Have you looked into
solving the problem
Post by pfg504
yourself and sharing your results group?
I started to, but I have a life outside of Hercules, and don't have
the time to devote to that. I'm sorry if that pisses you off, but
it's a fact of life.
If you have any more questions, feel free to ask; but please don't
get all wrapped around the axles if I miss the post or don't respond
*immediately*. I don't have the time to devote to this that I had a
few months ago.
--Thom
the_thom
2008-03-27 23:12:29 UTC
Permalink
Post by pfg504
Thanks for the information;
My pleasure.
Post by pfg504
First, please download the VMDIST.ZIP from
(...)
I have Andy's 4-pack distro and migrated some of the fixes over to
my own nucleus, as well as many others that have surfaced over the
years. In fact, I have those volumes mounted, but still use my
original nucleus because I like knowing exactly what I'm running.

Please understand it will take me some time to turn any of this
around (if I can do so at all). I had a lot more time on my hands
when I started all this than I have now. Don't expect immediate
results.
Post by pfg504
I want to reinforce that several people devote hundreds of hours for free to make all of
these components work as best that we can. We are not obligated to do any thing to
support the community, it is our choice and desire to do so. Keep this in mind when
seeking help.
Again, I *really* think you should read the thread from the
beginning (before Ivan and I went off on a tangent). I was not (and
still am not) seeking help. My reason for starting this thread was
to *document* an observed behavioral discrepancy between Hercules
and VM/370, and leave its resolution to anyone who gave a damn about
it. I was not seeking help, hostility, or anyone's resume'.

You are correct that you are not obligated to help anyone. Please
bear in mind that works *both* ways when getting upset that I didn't
provide you with the information you wanted exactly when you wanted
it. My time is money, too; and I have no more of an obligation than
you.

I resolved the problem myself by doing what we always did in the 370
era: if a device gave you fits on channel 0, you moved it to another
channel. If the problem went away, you mentioned it to IBM and got
back to work.

Kevin Leonard has put a lot of effort into tracking this down, and I
see he just responded with the information you want.

Thank you, and enjoy your day.

--Thom
Gregg C Levine
2008-03-28 03:40:10 UTC
Permalink
Hello!
I agree. I applaud Paul's abilities, and yes even your advice, Paul. The one
thing we can ill afford to do is to waste time in insulting each other.

I should also mention that any time all of you wish to study this problem
properly, since it concerns VM, we can take it over to the Hercules-390 VM
group.

And of course I manage it.

By the way Paul I am currently downloading the unnumbered VM file from your
site. Do I need to grab the other two, those with numbers?
--
Gregg C Levine hansolofalcon-XfrvlLN1Pqtfpb/***@public.gmane.org
"The Force will be with you always." Obi-Wan Kenobi
 
Post by Dave Wade
-----Original Message-----
On
Post by Dave Wade
Behalf Of pfg504
Sent: Thursday, March 27, 2008 4:02 PM
Subject: [hercules-390] Re: S/370 Channel 0 and/or select CCW
considerations
Post by Dave Wade
Thanks for the information;
First, please download the VMDIST.ZIP from
http://homepage.mac.com/WebObjects/FileSharing.woa/56/wo/rHIahkT7B1d1clxo.1/
2.2.
Post by Dave Wade
1.2.26.31.97.2.35.0.1.1.1?user=pfg504&fpath=VM-
370%20for%20Hercules:VM370R6&templatefn=FileSharing3.html
or: http://homepage.mac.com/pfg504/Menu2.html
There are several hundred fixes included in this system all are important and it has been a
very stable system.
The default for ECPSVM should be off, but just in case, please include ECPSVM NO in the
configuration file.
The VMDIST system has several enhancements that are documented on the 093 and 094
MAINT minidisks.
I want to reinforce that several people devote hundreds of hours for free to make all of
these components work as best that we can. We are not obligated to do any thing to
support the community, it is our choice and desire to do so. Keep this in mind when
seeking help.
The average person support this effort has more than 30 years of systems programming
experience and we want to share this with the community. It is often a
very thankless
Post by Dave Wade
endeavor and I have zero tolerance for any counter-productive
communication.
Post by Dave Wade
I am certain that Ivan has study the I/O area very carefully and would appreciate any help
in identifying and solving problems. On IBM machines I/O is almost as complex as the
entire rest of the machine.
It is very difficult to tell what each of our specialities are because our biographies or
resumes are generally not posted, so I am guessing that most people are going to assume
that the skill set is similar to their own. This is probably a bad idea.
For example, you would not know that my VM experience goes back to 1970, or that I
managed an IBM mainframe CPU development group while working for Dr. Gene Amdahl,
or that I was an VM developer and specialist at Amdahl Corp. developing VM/PE and
providing customer support in the Amdahl Eastern Support Center while at the same time
developing and supporting Zenith Z90 PCs as a remote service device for Amdahl V6-V8
processors.
Any way, we are more than happy to help, but, treat us kindly...
Paul
Post by pfg504
Post by pfg504
Thom,
You have stated that VM is BROKEN. This is the second time I have
asked for specific
Post by pfg504
information to determine if this is the case.
I'm very sorry, but I didn't *see* your initial request. No need to
take that tone, but I'll answer your questions anyway.
Post by pfg504
For the VM testing, is hercules running with or without assists
turned on? The
Post by pfg504
assists were used to translate addresses. If they are on, would
you turn them off and rerun
Post by pfg504
the test?
Assists: E608, E609, E604, E60C, E60F
The assists were not explicitly set either way. Whatever the
default, that's what the settings were.
Post by pfg504
Second, what type of device is being used as specified in DMKRIO?
Some CCW
Post by pfg504
validation is done at the devtype level.
I don't have the machine networked to this one, so I can't just copy-
and-paste the entry. The device is defined in DMKRIO as a 3277 on a
3272.
Post by pfg504
Which Version, Release, etc. of VM are you using?
VM/370 R6L0. Built from the distribution tapes.
Post by pfg504
Is the IO being done to the virtual CONS or to a
dedicate/attached virtual device?
VTAM only works with graf devices, not the VM console. This was
originally discovered on an attached graf, reproduced on a dialled
graf. Wasn't tested with a dedicated graf.
Post by pfg504
As the current care taker of VM/370 multipack distribution, I
asked specific questions to
Post by pfg504
try and assist you in resolving your issue. They were ignored. NO
DUMP - NO PROBLEM.
STOP SHOUTING. This isn't *your* distribution, it's a system I built
from tape. Your questions weren't "ignored", they simply *weren't
seen*.
If you go back and read the thread from the beginning, you'll not
only find most of the answers you demanded, you'll also see that I'm
not looking for *any* help with VM.
Post by pfg504
You have the source to HERCULES and VM/370, Have you looked into
solving the problem
Post by pfg504
yourself and sharing your results group?
I started to, but I have a life outside of Hercules, and don't have
the time to devote to that. I'm sorry if that pisses you off, but
it's a fact of life.
If you have any more questions, feel free to ask; but please don't
get all wrapped around the axles if I miss the post or don't respond
*immediately*. I don't have the time to devote to this that I had a
few months ago.
--Thom
pfg504
2008-03-28 05:32:24 UTC
Permalink
I trying to migrate the working copies of my changes/fixes over to source forge so that I
don't loose them in a disaster. I have several more changes in the pipe, a lot a
experimental in nature.

Any way, I am always looking for help. DIAG 58 FULL SCREEN READ and CMS EDF would be
nice to get completed.

Paul
Post by Gregg C Levine
Hello!
I agree. I applaud Paul's abilities, and yes even your advice, Paul. The one
thing we can ill afford to do is to waste time in insulting each other.
I should also mention that any time all of you wish to study this problem
properly, since it concerns VM, we can take it over to the Hercules-390 VM
group.
And of course I manage it.
By the way Paul I am currently downloading the unnumbered VM file from your
site. Do I need to grab the other two, those with numbers?
--
"The Force will be with you always." Obi-Wan Kenobi
ᅵ
Post by Dave Wade
-----Original Message-----
On
Post by Dave Wade
Behalf Of pfg504
Sent: Thursday, March 27, 2008 4:02 PM
Subject: [hercules-390] Re: S/370 Channel 0 and/or select CCW
considerations
Post by Dave Wade
Thanks for the information;
First, please download the VMDIST.ZIP from
http://homepage.mac.com/WebObjects/FileSharing.woa/56/wo/rHIahkT7B1d1clxo.1/
2.2.
Post by Dave Wade
1.2.26.31.97.2.35.0.1.1.1?user=pfg504&fpath=VM-
370%20for%20Hercules:VM370R6&templatefn=FileSharing3.html
or: http://homepage.mac.com/pfg504/Menu2.html
There are several hundred fixes included in this system all are important
and it has been a
Post by Dave Wade
very stable system.
The default for ECPSVM should be off, but just in case, please include
ECPSVM NO in the
Post by Dave Wade
configuration file.
The VMDIST system has several enhancements that are documented on the 093
and 094
Post by Dave Wade
MAINT minidisks.
I want to reinforce that several people devote hundreds of hours for free
to make all of
Post by Dave Wade
these components work as best that we can. We are not obligated to do any
thing to
Post by Dave Wade
support the community, it is our choice and desire to do so. Keep this in
mind when
Post by Dave Wade
seeking help.
The average person support this effort has more than 30 years of systems
programming
Post by Dave Wade
experience and we want to share this with the community. It is often a
very thankless
Post by Dave Wade
endeavor and I have zero tolerance for any counter-productive
communication.
Post by Dave Wade
I am certain that Ivan has study the I/O area very carefully and would
appreciate any help
Post by Dave Wade
in identifying and solving problems. On IBM machines I/O is almost as
complex as the
Post by Dave Wade
entire rest of the machine.
It is very difficult to tell what each of our specialities are because our
biographies or
Post by Dave Wade
resumes are generally not posted, so I am guessing that most people are
going to assume
Post by Dave Wade
that the skill set is similar to their own. This is probably a bad idea.
For example, you would not know that my VM experience goes back to 1970,
or that I
Post by Dave Wade
managed an IBM mainframe CPU development group while working for Dr. Gene
Amdahl,
Post by Dave Wade
or that I was an VM developer and specialist at Amdahl Corp. developing
VM/PE and
Post by Dave Wade
providing customer support in the Amdahl Eastern Support Center while at
the same time
Post by Dave Wade
developing and supporting Zenith Z90 PCs as a remote service device for
Amdahl V6-V8
Post by Dave Wade
processors.
Any way, we are more than happy to help, but, treat us kindly...
Paul
Post by pfg504
Post by pfg504
Thom,
You have stated that VM is BROKEN. This is the second time I have
asked for specific
Post by pfg504
information to determine if this is the case.
I'm very sorry, but I didn't *see* your initial request. No need to
take that tone, but I'll answer your questions anyway.
Post by pfg504
For the VM testing, is hercules running with or without assists
turned on? The
Post by pfg504
assists were used to translate addresses. If they are on, would
you turn them off and rerun
Post by pfg504
the test?
Assists: E608, E609, E604, E60C, E60F
The assists were not explicitly set either way. Whatever the
default, that's what the settings were.
Post by pfg504
Second, what type of device is being used as specified in DMKRIO?
Some CCW
Post by pfg504
validation is done at the devtype level.
I don't have the machine networked to this one, so I can't just copy-
and-paste the entry. The device is defined in DMKRIO as a 3277 on a
3272.
Post by pfg504
Which Version, Release, etc. of VM are you using?
VM/370 R6L0. Built from the distribution tapes.
Post by pfg504
Is the IO being done to the virtual CONS or to a
dedicate/attached virtual device?
VTAM only works with graf devices, not the VM console. This was
originally discovered on an attached graf, reproduced on a dialled
graf. Wasn't tested with a dedicated graf.
Post by pfg504
As the current care taker of VM/370 multipack distribution, I
asked specific questions to
Post by pfg504
try and assist you in resolving your issue. They were ignored. NO
DUMP - NO PROBLEM.
STOP SHOUTING. This isn't *your* distribution, it's a system I built
from tape. Your questions weren't "ignored", they simply *weren't
seen*.
If you go back and read the thread from the beginning, you'll not
only find most of the answers you demanded, you'll also see that I'm
not looking for *any* help with VM.
Post by pfg504
You have the source to HERCULES and VM/370, Have you looked into
solving the problem
Post by pfg504
yourself and sharing your results group?
I started to, but I have a life outside of Hercules, and don't have
the time to devote to that. I'm sorry if that pisses you off, but
it's a fact of life.
If you have any more questions, feel free to ask; but please don't
get all wrapped around the axles if I miss the post or don't respond
*immediately*. I don't have the time to devote to this that I had a
few months ago.
--Thom
the_thom
2008-03-28 05:54:23 UTC
Permalink
Post by Gregg C Levine
Hello!
I agree. I applaud Paul's abilities, and yes even your advice,
Paul. The one
Post by Gregg C Levine
thing we can ill afford to do is to waste time in insulting each other.
Okay, this has gone far enough, and it's gotten to the point of
*STUPIDITY*. I now remember why I got *out* of the mainframe biz all
those years ago.

Ivan: the debate I got into with you was pointless. I wasn't even
*trying* to get into a debate with you, but that's what happened.
I'll take the blame for that, okay? It was pointless, it was stupid,
but it happened, and it's DONE now.

Gregg: I respect your opinion, but at *no* point (before this post)
have I allowed myself to sink to the level of insults, nor do I feel
that any other protagonist to the preceeding discussion has done the
same. I resent the implication that *any* of us have. What's
happened here is a misunderstanding, but HAS NOT reduced itself to
something so personal and petty as insults by *anyone* before now.

What has happened here is Ivan and I violently agreeing on a few
points, and disagreeing on ancillary points. From there, Paul jumped
in, a bit (read: a lot) late to the party.

Paul: please read the thread from the beginning, and you'll see that
my only intent to starting this thread was to document what I
observed.

You guys can figure this out for yourselves from this point on. I
didn't deliver the message just to be the guy that got shot.

Good luck.

--Thom
pfg504
2008-03-28 23:27:22 UTC
Permalink
I did read every one of the e-mails prior to answering you the first time.

It appears that all of this is as a result of using e-mails and not holding a true
conversation. We can not see or hear any expressions that would moderate the words, so
we have not choice to be read the words and make a best guess at what the intent was.

It can also be very frustrating at times when our points are not gotten understood.

It can also be problematic when you write to one person, but you have another 1000 eyes
looking and responding.

What I saw in particular, was statements of absolutes. I am not sure if that was the intent
or if you were trying to convey that it does not make sense to you.

I guess that is probably an area that programmers, especially systems programmers, deal
poorly with. Our environment is usually 1s & 0s, black & white or right and wrong, not a
whole lot in between.

Paul

---
Graduate of the John Wayne School of Humility
"Never apologize ..., it is a sign of weakness"
---

Just kidding...
Post by Gregg C Levine
Post by Gregg C Levine
Hello!
I agree. I applaud Paul's abilities, and yes even your advice,
Paul. The one
Post by Gregg C Levine
thing we can ill afford to do is to waste time in insulting each
other.
Okay, this has gone far enough, and it's gotten to the point of
*STUPIDITY*. I now remember why I got *out* of the mainframe biz all
those years ago.
Ivan: the debate I got into with you was pointless. I wasn't even
*trying* to get into a debate with you, but that's what happened.
I'll take the blame for that, okay? It was pointless, it was stupid,
but it happened, and it's DONE now.
Gregg: I respect your opinion, but at *no* point (before this post)
have I allowed myself to sink to the level of insults, nor do I feel
that any other protagonist to the preceeding discussion has done the
same. I resent the implication that *any* of us have. What's
happened here is a misunderstanding, but HAS NOT reduced itself to
something so personal and petty as insults by *anyone* before now.
What has happened here is Ivan and I violently agreeing on a few
points, and disagreeing on ancillary points. From there, Paul jumped
in, a bit (read: a lot) late to the party.
Paul: please read the thread from the beginning, and you'll see that
my only intent to starting this thread was to document what I
observed.
You guys can figure this out for yourselves from this point on. I
didn't deliver the message just to be the guy that got shot.
Good luck.
--Thom
Kevin Leonard
2008-03-27 21:16:19 UTC
Permalink
Paul:

Thanks for your response. I meant to respond to this
earlier, but when I looked for it I couldn't find it.
(No, really, I did.....)
Post by pfg504
For the VM testing, is hercules running with or without
assists turned on? The assists were used to translate
addresses. If they are on, would you turn them off and
rerun the test?
Tested the select containing an invalid data address both
with and without assist turned on. The result was the same
in both cases: if CP real storage is less than 16 MB, the
real CCW data address contains the real machine size; if
real storage is equal to 16 MB, the data address is zeroes
and bits 38 and 39 are on. With assist enabled, the "ecpsvm
level" command reports:

ecpsvm level
HHCEV011I ECPS:VM Command processor invoked
HHCEV016I Current reported ECPS:VM Level is 20
HHCEV011I ECPS:VM Command processor complete
Post by pfg504
Second, what type of device is being used as specified
in DMKRIO? Some CCW validation is done at the devtype
level.
The device is defined as a 3277:

RDEVICE ADDRESS=(0C0,32),DEVTYPE=3277

The TN3270 session is operating in Model 2 mode, 24 lines
and 80 columns.
Post by pfg504
Which Version, Release, etc. of VM are you using?
VM identifies itself at IPL as:

VM/370 Version 06 Level 00 PLC 0029 HRC V03/PFG; 06/03/06 20:18:52

I have rebuilt the CP nucleus to take the SYSIPL macro
out of DMKSYS, so it's not exactly the five pack system
as shipped.
Post by pfg504
Is the IO being done to the virtual CONS or to a dedicate/attached virtual device?
The target 3277 device is attached to the virtual machine
using a CP ATTACH command.
Post by pfg504
Some validation is done to CCW chains against the devtype
specified in DMKRIO. Defining a device as unsupported
minimizes checks.
This is true. That may not be practical, though, for a
3277 device whose normal status is ENABLE.

Looking at DMKCCW, what appears to be happening to the
select is this:

DMKCCW decides what kind of validation is required for the
CCW based on a combination of device group and CCW command.
The "groups" don't exactly match the VM device class, and
are defined internally in DMKCCW, thus:

DASDTBL CCTBL DASD,12,18 TABLE FOR NON-DEDICATED DASD DEVICES:
DEDDTBL CCTBL DEDD,12,18 TABLE FOR DEDICATED DASD DEVICES:
TAPETBL CCTBL TAPE,12,09 TABLE FOR TAPE DEVICES:
TERMTBL CCTBL TERM,12,09 TABLE FOR TERMINAL-CLASS DEVICES:
SDLCTBL CCTBL SDLC,12,09 TABLE FOR ICA-SDLC
DIALTBL CCTBL DIAL,12,09 TABLE FOR "DIALED LINE" DEVICES:
OTHRTBL CCTBL OTHR,12,09 TABLE FOR ALL OTHER DEVICES:
CONSTBL CCTBL CONS,12,09 TABLE FOR DEDICATED 3210 CONSOLES
MSCTBL CCTBL MSC,12,09 TABLE FOR PORTS ON 3851 MSS

Expansion of the CCTBL macro creates a vector table of
16 validation routines. DMKCCW masks the first four bits
of the command code, and uses the last four bits to select
the validation routine from among those defined for the
group. When DMKCCW determines which group a device falls
into, in the code immediately following the DMKCCWTR
label, local 3270 devices end up in the "OTHER" group.
The local 3270 select X'0B' results in a branch to the
validation routine OTHRXB. OTHRXB checks for the special
case of a X'5B' command to a 1287. For any other case it
branches to the general CCW validation routine CCWGENRL.

Oversimplifying CCWGENRL: LRA is done to translate the
virtual CCW data area address to a real address. (In
fact, the CCW data address has to be an absolute address,
but VM comments tend to say "real".) The LRA fails
because the virtual address is invalid, it doesn't
map to a real address currently in storage. CCWGENRL
then calls DMKPTRAN to translate the virtual data
address. This fails because the address is not within
the guest's virtual memory. When the DMKPTRAN call
fails, CCWGENRL branches to the error routine CCWBAD4.

At CCWBAD4, DMKCCW has decided that the data address is
invalid, and attempts to construct a real channel program
that will induce a channel program check. If the real
storage size of the machine VM is running in (Hercules
MAINSIZE) is less than 16 MB, CCWBAD4 inserts the real
storage size into the real CCW as the data address.
DMKCCW expects that to force the channel program to fail,
by specifying an address of maximum installed storage + 1.
But because Hercules doesn't validate the data address for
a CCW that doesn't transfer data, no failure occurs.
Assuming that MAINSIZE is defined as 14 (X'E000000' bytes),
a Hercules CCW trace shows:

HHCCP048I 00C1:CCW=0BE00000 60000001

and the channel program completes successfully. As
I read the Principles of Operation, what Hercules is
doing is the correct behavior.

If the real storage size is equal to 16 MB, CCWBAD4
knows that just setting the data address equal to the
real storage size isn't enough to generate a channel
program failure. So CCWBAD4 turns on bits 38 and 39
in the real channel program:

OI RCWFLAG,3 SET CCW INVALID FOR 16 MEG

The real CCW data address is set to zero (a residue of
storing the real storage size into the data address:
X'000000' is the three low-order bytes of X'01000000').
Hercules CCW trace shows:

HHCCP048I 00C1:CCW=0B000000 63000001=>000C0000 0000080C 00000000 00F43000

Hercules fails the I/O with channel program check because
the MIDA flag (bit 39) is on in an environment that doesn't
support MIDAW:

HHCCP049I 00C1:Stat=0020 Count=0000 CCW=FA17A8

Again, as I read it, Hercules is doing the correct thing
by failing the I/O. As Ivan pointed out, Hercules is
treating the SIO as though it was a SIOF, but that's
not really important here. Ultimately this I/O should
fail, and Hercules fails it.

DMKCCW doesn't always validate the CCW data address. Tape
control requests that don't transfer data are recognized
as special. For example, X'x7' tape commands (rewind,
erase gap, backspace record, forward space record) don't
end up at CCWGENRL, where the data address gets validated.
Instead they branch to CLEARADD, where the CCW data
address isn't validated:

* TAPEX7 = "CONTROL" COMMANDS WITH THE LAST 4 BITS = 7:
* ADDRESS IN CCW IRRELEVANT - NO DATA TRANSFER OCCURS
* (BUT ANY EXISTING SENSE BYTES ARE CLEARED)
TAPEX7 EQU CLEARADD CONTROL - ADDRESS IS IRRELEVANT

CLEARADD DS 0H ADDRESS IS IRRELEVANT AND/OR SKIP FLAG IS SET
* LEAVE VIRTUAL ADDRESS (AS IS) IN THE CCW, BUT
L R2,FFS -1 INTO R2 FOR BENEFIT OF PROTECTION-CHECKING

Here's a Hercules CCW trace of a rewind X'07' to tape
device 580, issued from a 4 MB virtual machine. I put
an invalid data address X'FEFEFE' in the CCW. DMKCCW
left it there in the real CCW, and the rewind completes
successfully:

HHCCP048I 0580:CCW=07FEFEFE 20000001=>00000000 00000000 00000000 00000000
HHCCP075I 0580:Stat=0C00 Count=0001
HHCCP049I 0580:Stat=0C00 Count=0001 CCW=FA01E8
Post by pfg504
Other considerations, the version/service level of VM/370
that we have made available was in production shops for
several years and in several shops running DOS and OS. I
can not fine any reported error by a IBM customer with
these symptoms.
It takes a specific combination of circumstances to
produce the situation: DOS/VS must be running as a
guest under VM, the VTAM 3270 device has to be on a
virtual channel that gets identified by VM as a block
multiplexor channel, the real machine size has to be
16 MB, the DOS/VS virtual machine size has to be less
than DOS virtual storage. Something may have been
reported and we're no longer able to see it. IBM's
removal of RETAIN items prior to OS/390 makes it
impossible to know for sure whether anybody encountered
this.
--
Kevin
pfg504
2008-03-28 22:39:47 UTC
Permalink
Post by Ivan Warren
Post by Ivan Warren
Oh.. Let me tell you that CP *DOES* validate each and every CCW
that it
Post by Ivan Warren
is being presented by a virtual machine. That's because CP *has*
to
Post by Ivan Warren
translate CCW addresses from the host virtual address ones (the
ones
Post by Ivan Warren
that appear absolute to the guest) to 1st level absolute addresses
(the
Post by Ivan Warren
ones that can be used for I/O) - among other things.
Yes, I understand that. But we've all agreed that the trouble is
being caused by VM validating an address it's not supposed to care
about (in the case of the select command).
Post by Ivan Warren
Whether the virtual machine has its own virtual addressing is
irrelevant
Post by Ivan Warren
because addresses in CCWs are always absolute (but if it weren't
the
Post by Ivan Warren
case, it wouldn't really matter because CP *DOES* know of a
virtual
Post by Ivan Warren
machine's 2nd level DAT table - otherwise it wouldn't be able to
emulate
Post by Ivan Warren
DAT for that virtual machine - using shadow tables).
If that were true in this case, this problem would never have
occurred. The problem with the address in the select CCW is that it
was virtual within DOS/VS, beyond the 4M storage size of the DOS/VS
virtual machine.
I'm not aware of VM/370 emulating second-level DAT tables at all (in
fact, it seems mutually-exclusive to have reserved pages as an
option in a system which could just do the paging for you in that
case), I seem to recall that functionality came along later in VM's
life.
It's all moot, anyway. The problem is with VM, so there's no need
for us to debate *what* the problem with VM actually is. It's
interesting, but doesn't add anything to the Hercules project.
==== This was the statement that I have a problem with.
pfg504
2008-03-28 22:33:44 UTC
Permalink
Post by Ivan Warren
Post by the_thom
For CP to accommodate a CCW that specifies an address that is only
valid within the virtual space *of the guest OS* would require CP to
have direct knowledge of that guest OS's paging activities. Real
hardware can't do that, so there's no reason to expect an emulator
(which is all VM really is) to be able to.
It would also require VM to validate the addresses in *every* CCW,
including immediate commands, which we all agree (and the POP
states) it's not supposed to be doing. CP isn't generating the CCW,
it's merely passing it along.
Oh.. Let me tell you that CP *DOES* validate each and every CCW that it
is being presented by a virtual machine. That's because CP *has* to
translate CCW addresses from the host virtual address ones (the ones
that appear absolute to the guest) to 1st level absolute addresses (the
ones that can be used for I/O) - among other things.
Whether the virtual machine has its own virtual addressing is irrelevant
because addresses in CCWs are always absolute (but if it weren't the
case, it wouldn't really matter because CP *DOES* know of a virtual
machine's 2nd level DAT table - otherwise it wouldn't be able to emulate
DAT for that virtual machine - using shadow tables).
And no.. CP doesn't "pass along" the CCWs.. it issues it's own modified
version (sometime the CCW issued by CP has *NOTHING* to do with the CCW
issued by the virtual machine..) - and sometimes it doesn't even issue
any real I/O at all (for example : a coupled virtual CTC).
The only case when CP doesn't translate a CCW is when the virtual
machine is a V=R VM, the device is dedicated and the virtual machine has
CCWNOTRANS ON set.
On more modern versions of VM, it is possible for a virtual machine
(with the appropriate CP directory option set) to issue *real* CCWs
directly using a Diagnose instruction (which provides facilities to lock
and map pages, unlock pages and issue I/Os to dedicated devices). (for
VM/SP, this is "DIAG 98".. This is only available using a CP directory
statement because it inherently gives the very potent capability for a
virtual machine to read & write *REAL* host storage - akin to a class C
virtual machine).
Because it is somewhat heavy on CP to do all that translating, there is
also a couple of CP Assist E6xx instructions that will aid CP in
translating CCWs (not implemented under hercules).
=== DITTO
Post by Ivan Warren
A VM Issues
CCW X'0B',X'1000',X'20',1 to a dedicated 3270.
CP will have to look up the virtual machine's X'1000' address to
determine the real page frame (PTRAN BRING,TYPE=DEFER).. If the
resulting page is, say, X'80E000' then CP issues
CCW X'0B',X'80E000',X'20',1
A VM Issues
CCW X'0B',X'F00000',X'20',1 to a dedicated 3270 and the VM only has
2MB of virtual storage (and no DCSS loaded at that address)
CP Will look up the page and determine it is outside the VM's address
space. VM/370 R6 will then determine it's own storage size and if it has
less than 16MB it will issue the CCW with a storage address that is
outside the real addressable space. If it has 16MB, then there is no way
to do that, so it issues a CCW with bits 38 & 39 set to force a CPC.
(and that's the problem we are seeing : a CPC is generated *regardless*
of whether the I/O is immediate or not).
A VM Issues
CCW X'02',X'F00000',X'20',1 to a virtual reader
CP will look up the page and determine it is outside the VM's address
space. Since it is a virtual device, CP knows it is NOT an immediate I/O
(X'01' would be a request to read a card). Assuming the virtual reader
is ready, it will queue a virtual I/O interrupt to the virtual machine
with a CSW specifying a CPC *without having issued any real I/O*. If the
reader is not ready, a CSW is made pending at SIO time (SIO CC=1) with a
CSW containing UC only. If the CCW is valid (including the address), the
*actual* CCW issued (if necessary) will be one to fetch a page from a CP
owned volume's spool space that contains the spool file that is
available for that virtual reader.
--Ivan
pfg504
2008-03-28 22:32:27 UTC
Permalink
Post by Ivan Warren
Post by the_thom
In my case, the CCW is being generated by DOS/VS in a virtual
machine with less than 16MB of storage.
That was the corollary to my statement.
It seems odd there is no way for a hypervisor to emulate for a
virtual
Post by Ivan Warren
machine the behavior of issuing a CCW specifying an address that
is
Post by Ivan Warren
beyond *virtual* addressable storage when there is no *REAL*
non-addressable storage on the real machine and the CCW specifies
an
Post by Ivan Warren
immediate I/O code (and CP doesn't or cannot know whether the I/O
is
Post by Ivan Warren
immediate or not short of issuing it).
For CP to accommodate a CCW that specifies an address that is only
valid within the virtual space *of the guest OS* would require CP to
have direct knowledge of that guest OS's paging activities. Real
hardware can't do that, so there's no reason to expect an emulator
(which is all VM really is) to be able to.
== IT DOES because GUEST INTEGRITY is first priority. NOT the POP.
== VM is not an emulator or a simulator. It is a hyper-visor managing/sharing s/370 resources.
== It validates and alters to some extent the CCWs. Addresses are changed for example. In later versions CCW
sorting occurred to improve performance. (DASD I/O would be sorted from low CCHHR to HIGH

== VM it self in not running in translate mode as does MVS. Storage address (except for a V=R guest) in CCWs
are always translated to a Real Address. Page boundaries are validated. Page crossings a validated. Assists were provided to improve these processes.
It would also require VM to validate the addresses in *every* CCW,
including immediate commands, which we all agree (and the POP
states) it's not supposed to be doing. CP isn't generating the CCW,
it's merely passing it along.
Maybe we're discussing two different things, but I don't see
anything mysterious about it.
--Thom
Kevin Leonard
2008-03-24 18:00:43 UTC
Permalink
Post by Ivan Warren
same thing happens when issuing an I/O to a device that
is not ready.. For most I/Os this should also result in
the CSW getting stored at I/O initiation time (the CSW
is returned right after device selection) and thus should
return CC=1 for SIO (or for SIOF when SIOF is issued as SIO..
basically, hercules always executes SIO as SIOF
Understood. That explains the behavior we're seeing.
Post by Ivan Warren
note that issuing an I/O with a correctly formatted CCW
specifying an immediate I/O but a non-addressable storage
address still shouldn't lead to a CPC
The way I'm understanding it, the select CCW data address
shouldn't be validated. Hercules is handling that correctly,
and VM isn't. Right?
--
Kevin
pfg504
2008-03-28 22:21:23 UTC
Permalink
Post by Ivan Warren
Post by Kevin Leonard
Looking at GA72-7000-8 dated October 1981. This level of the
manual defines bit 38 as the SUSPEND flag, with revision bars
* Bit position 39 of every CCW other than one specifying
* transfer in channel must contain zero. Otherwise,
* a program-check condition is generated. When the
* first CCW designated by the CAW does not contain
* zero in bit position 39, the I/O operation is not
* initiated, and the status portion of the CSW with
* the program-check indication is stored during
* execution of START I/O or START I/O FAST RELEASE
* being executed as START I/O. Detection of this
* condition during data chaining causes the I/O
* device to be signaled to conclude the operation.
* When the absence of these zeros is detected during
* command chaining or subsequent to the execution of
* START I/O FAST RELEASE, the new operation is not
* initiated, and an interruption condition is generated.
Gotcha.. the one I was looking at was .. hmm.. quite outdated ! (still
leaves the question of HOW IN THE WORLD can CP emulate an immediate I/O
CCW to a device with an invalid address field when there is 16MB of real
storage)..
==== X'FFFFFF' is valid in a 16M real machine 24-bit psw. It wraps to page 0.
Post by Ivan Warren
Post by Kevin Leonard
I read that as saying that if the first CCW has bit 39
on, the SIO fails with CC=1 and CSW indicating channel
program check. If the first CCW is OK but the second or
subsequent CCW has bit 39 on, the SIO completes with CC=0
and a CSW indicating channel program check is presented
during a subsequent interrupt.
This doesn't appear to be what Hercules is doing. It looks
like the SIO completes successfully even though the first
CCW has bit 39 on, and the channel program check occurs
in a subsequent interrupt. Here's a script to issue a
SIO with the invalid select as the first CCW. I turned
I know.. same thing happens when issuing an I/O to a device that is not
ready.. For most I/Os this should also result in the CSW getting stored
at I/O initiation time (the CSW is returned right after device
selection) and thus should return CC=1 for SIO (or for SIOF when SIOF is
issued as SIO.. basically, hercules always executes SIO as SIOF (which
is *wrong*)).
This will need to get addressed eventually !
--Ivan
pfg504
2008-03-28 22:19:54 UTC
Permalink
Post by Kevin Leonard
Post by Ivan Warren
Post by Kevin Leonard
0B000000 63000001
I'm just very curious to see how another S/370 system would
react to this. There is a slight ambiguity in GA22-7000 that
would eventually make it possible for this CCW to still be
valid. The POP doesn't specify whether CCW format validation
(especially bits 38 & 39) is performed *before* or *after*
the I/O is initiated.
Looking at GA72-7000-8 dated October 1981. This level of the
manual defines bit 38 as the SUSPEND flag, with revision bars
====
As late as June '97, SA22-7201-04 has a similar comment, but includes fmt-1 ccw bit 15.
(for XA I/O)
====
Post by Kevin Leonard
* Bit position 39 of every CCW other than one specifying
* transfer in channel must contain zero. Otherwise,
* a program-check condition is generated. When the
* first CCW designated by the CAW does not contain
* zero in bit position 39, the I/O operation is not
* initiated, and the status portion of the CSW with
* the program-check indication is stored during
* execution of START I/O or START I/O FAST RELEASE
* being executed as START I/O. Detection of this
* condition during data chaining causes the I/O
* device to be signaled to conclude the operation.
* When the absence of these zeros is detected during
* command chaining or subsequent to the execution of
* START I/O FAST RELEASE, the new operation is not
* initiated, and an interruption condition is generated.
I read that as saying that if the first CCW has bit 39
on, the SIO fails with CC=1 and CSW indicating channel
program check. If the first CCW is OK but the second or
subsequent CCW has bit 39 on, the SIO completes with CC=0
and a CSW indicating channel program check is presented
during a subsequent interrupt.
This doesn't appear to be what Hercules is doing. It looks
like the SIO completes successfully even though the first
CCW has bit 39 on, and the channel program check occurs
in a subsequent interrupt. Here's a script to issue a
SIO with the invalid select as the first CCW. I turned
# Issue defective select to 3270 0C1 and wait for I/O interrupt
archmode S/370
sysreset
r 00=0000000000000400 # Restart new PSW
r 28=000200000000DEAD # Program new PSW
r 78=000200000000AAAA # I/O new PSW
r 48=00000440 # CAW
r 400=411000C1 # R1 = device address 0C1
r 404=9C001000 # SIO 0(R1)
r 408=82000438 # LPSW ENWAIT load enabled wait PSW
r 430=000200000000BEEF # WAITPSW disabled wait PSW
r 438=FE0200000000FFFF # ENWAIT enabled wait PSW
r 440=0B00000061000001 # CCW 1 = select with bit 39 set to 1
r 448=0600048020000008 # CCW 2 = read
r 480=EEEEEEEEEEEEEEEE # Input area
s+
restart
PSW=00000000 00000400 INST=411000C1 LA 1,193(0,0)
PSW=00000000 00000404 INST=9C001000 SIO 0(1)
HHCCP048I 00C1:CCW=0B000000 61000001=>00000000 00000400
PSW=00000000 80000408 INST=82000438 LPSW 1080(0)
HHCCP043I Wait state PSW loaded: PSW=FE020000 8000FFFF
HHCCP049I 00C1:Stat=0020 Count=0000 CCW=000448
HHCCP044I I/O interrupt code=00C1 CSW=00000448 00200000
HHCCP043I Wait state PSW loaded: PSW=00020000 8000AAAA
HHCCP011I CPU0000: Disabled wait state
PSW=00020000 8000AAAA
--
Kevin
Ivan Warren
2008-03-15 15:41:38 UTC
Permalink
Post by Kevin Leonard
I/O 00E67C SIO 9C002000 GRAF 00C0 CC 0 GRAF 00C0 CAW 4005B008
D T5B008.90
05B000 80000060 00E71E20 0BE74034 60000001 46 *...-.X...X .-...*
Is E74034 within our outside the virtual machine's address space ?

Thanks,

--Ivan
Kevin Leonard
2008-03-15 19:10:03 UTC
Permalink
Post by Ivan Warren
Post by Kevin Leonard
I/O 00E67C SIO 9C002000 GRAF 00C0 CC 0 GRAF 00C0 CAW 4005B008
D T5B008.90
05B000 80000060 00E71E20 0BE74034 60000001 46 *...-.X...X .-...*
Is E74034 within our outside the virtual machine's address space ?
No. It's a valid virtual address, but not a valid real address:

CP D E74034
HEXLOC E74034 EXCEEDS STORAGE
CP Q V STOR
STORAGE = 02048K

So I redefined the virtual machine storage size to make it a valid
address. That eliminates the channel program check.

CP DEF STOR 15M

Integrating the Hercules trace and the VM I/O trace:

* toltep command issued from 0c0
HHCCP066I DEV00C0: attention
HHCCP049I 00C0:Stat=8000 Count=0000 CCW=000000
* *** 002490 I/O 00C0 ==> 000BBE CSW 8000
* I/O 00E13E TCH 9F002000 GRAF 00C0 CC 0

Here's the bad select. Flags are CC+SLI, residual count is 1,
the byte after flags which should be reserved has X'80':

HHCCP048I 00C0:CCW=0BDED034 60800001=>00000000 00000000 00000000
00000000 ................
HHCCP075I 00C0:Stat=0C00 Count=0001

Data address in the Hercules trace doesn't match the data address
in the virtual select CCW:

I/O 00E67C SIO 9C002000 GRAF 00C0 CC 0 GRAF 00C0 CAW 40058008
CP D T58008.90
058000 80000060 00E71E20 0BE74034 60000001 46 *...-.X...X .-...*
058010 06058034 80000024 08058060 00E74060 *...........-.X -*
058020 08012002 10004000 00000000 00000000 *...... .........*
058030 00000000 7D40C611 C5E9A396 93A38597 *....' F.EZ......*
058040 00000000 00000000 00000000 00000000 *................*
058050 00000000 00000000 80000060 00E71E20 *...........-.X..*
058060 06058070 80000040 080580B8 00E740B8 *....... .....X .*
058070 00000000 00000000 00000000 00000000 *................*
058080 TO 0580A0 SUPPRESSED LINE(S) SAME AS ABOVE .....

The virtual data address is a valid real address:

CP D E74034
E74034 00000000

as is the real data address:

CP D DED034
DED034 00000000
--
Kevin
pfg504
2008-03-28 22:47:22 UTC
Permalink
If you are up to trying something:

1) define storage under 16m
2) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should fail
A) define storage at 16M
B) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should work with the data involved being the last double word of storage
-- and the first double word of storage.


Paul
Post by Kevin Leonard
Post by Ivan Warren
Post by Kevin Leonard
I/O 00E67C SIO 9C002000 GRAF 00C0 CC 0 GRAF 00C0 CAW 4005B008
D T5B008.90
05B000 80000060 00E71E20 0BE74034 60000001 46 *...-.X...X
.-...*
Post by Ivan Warren
Is E74034 within our outside the virtual machine's address space ?
CP D E74034
HEXLOC E74034 EXCEEDS STORAGE
CP Q V STOR
STORAGE = 02048K
So I redefined the virtual machine storage size to make it a valid
address. That eliminates the channel program check.
CP DEF STOR 15M
* toltep command issued from 0c0
HHCCP066I DEV00C0: attention
HHCCP049I 00C0:Stat=8000 Count=0000 CCW=000000
* *** 002490 I/O 00C0 ==> 000BBE CSW 8000
* I/O 00E13E TCH 9F002000 GRAF 00C0 CC 0
Here's the bad select. Flags are CC+SLI, residual count is 1,
HHCCP048I 00C0:CCW=0BDED034 60800001=>00000000 00000000 00000000
00000000 ................
HHCCP075I 00C0:Stat=0C00 Count=0001
Data address in the Hercules trace doesn't match the data address
I/O 00E67C SIO 9C002000 GRAF 00C0 CC 0 GRAF 00C0 CAW 40058008
CP D T58008.90
058000 80000060 00E71E20 0BE74034 60000001 46 *...-.X...X .-...*
058010 06058034 80000024 08058060 00E74060 *...........-.X -*
058020 08012002 10004000 00000000 00000000 *...... .........*
058030 00000000 7D40C611 C5E9A396 93A38597 *....' F.EZ......*
058040 00000000 00000000 00000000 00000000 *................*
058050 00000000 00000000 80000060 00E71E20 *...........-.X..*
058060 06058070 80000040 080580B8 00E740B8 *....... .....X .*
058070 00000000 00000000 00000000 00000000 *................*
058080 TO 0580A0 SUPPRESSED LINE(S) SAME AS ABOVE .....
CP D E74034
E74034 00000000
CP D DED034
DED034 00000000
--
Kevin
Tony Harminc
2008-03-28 22:58:02 UTC
Permalink
Post by pfg504
1) define storage under 16m
2) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should fail
A) define storage at 16M
B) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should work with the data involved being the last double word of storage
-- and the first double word of storage.
What am I missing? Surely channel-generated addresses do not wrap?

Tony H.
pfg504
2008-03-28 23:07:35 UTC
Permalink
Post by Tony Harminc
Post by pfg504
1) define storage under 16m
2) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should fail
A) define storage at 16M
B) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should work with the data involved being the last double word of storage
-- and the first double word of storage.
What am I missing? Surely channel-generated addresses do not wrap?
Tony H.
According to the ESA POP I am reading, it should generate an I/O Program Check.

I was hoping that we could validate it since it would be a common practice to share the
code that handles main storage addressing. If we substituted a move in the above
example it should certainly work.

I am not sure what would happen if a CCW chain started at address FFFFF0 and wrapped
back to 000000. The same POP implies that it should also work.

These are real addresses.


Paul
Kevin Leonard
2008-03-29 03:33:48 UTC
Permalink
Post by pfg504
1) define storage under 16m
2) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should fail
A) define storage at 16M
B) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should work with the data involved being the last double word of storage
-- and the first double word of storage.
OK. Working on it.

Question: on point (2), do you mean absolute address
X'FFFFF0' (should fail because the starting address
can't be accessed), or the top of storage minus X'10'
(should fail because the 32 byte data length won't
wrap at the end of storage)?
--
Kevin
pfg504
2008-03-29 04:16:49 UTC
Permalink
The starting address for 2 should fail because it is out of range. I wanted to make sure
that nothing gets written to page 0.

'B' should fail if Hercules or VM is working correctly. The storage wraparound occurs only
when the CPU is accessing storage.

What I am not sure is what happens if a CCW chain is at x'FFFFF0' with chaining turned on
and a second CCW at address x'000000'. The POP implies that it should be valid.

MVC would get an address exception in the 1st case, but succeed in the second case.

Paul
Post by pfg504
Post by pfg504
1) define storage under 16m
2) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should fail
A) define storage at 16M
B) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should work with the data involved being the last double
word of storage
Post by pfg504
-- and the first double word of storage.
OK. Working on it.
Question: on point (2), do you mean absolute address
X'FFFFF0' (should fail because the starting address
can't be accessed), or the top of storage minus X'10'
(should fail because the 32 byte data length won't
wrap at the end of storage)?
--
Kevin
Kevin Leonard
2008-03-29 05:23:20 UTC
Permalink
Post by pfg504
The starting address for 2 should fail because it is
out of range. I wanted to make sure that nothing gets
written to page 0.
Using write CCWs to a virtual printer, I tried the case
of writing from a data area that starts at storage
size minus 16 bytes for a length of 32, with storage
defined to be 14 MB. The SIO gets CC=1 (CSW stored)
with CSW status 0020 (channel program check). No data
is written to the printer.
Post by pfg504
'B' should fail if Hercules or VM is working correctly.
The storage wraparound occurs only when the CPU is accessing
storage.
If I did it right, it didn't fail. SIO gets CC=0,
subsequent interrupt returns CSW status 0C00. The
printed output shows one record:

<--TEST OUTPUT-- © ------->

The first 16 characters were at X'FFFFF0', the next
eight (unprintable) characters are the restart new
PSW at location 0, the last eight characters I moved
into the restart old PSW at location X'000008' before
issuing the SIO.

I'm looking at the System/360 Principles of Operation
A22-6832-7. In describing the main storage area
associated with an I/O operation, it says:

"Storage addresses do not wrap around to location 0
unless the system has the maximum addressable storage
(16,777,216 bytes). When the maximum addressable
storage is provided, location 0 follows location
16,777,215, and on reading backward, location
16,777,215 follows location 0." So maybe what
I'm seeing is the right result.
Post by pfg504
What I am not sure is what happens if a CCW chain
is at x'FFFFF0' with chaining turned on and a
second CCW at address x'000000'.
It appears to work, at least with a spooled printer
and 16 MB of storage under VM. I put a write CCW
at X'FFFFF8' (the last eight bytes of storage) with
command chaining on, moved another write CCW to
location zero with command chaining on, and a no-op
CCW to location 8. SIO got CC=0, subsequent interrupt
had CSW status 0C00. Two records were printed:

<-------TEST OUTPUT 1---------->
<-------TEST OUTPUT 2---------->

The first record was written by the CCW at X'FFFFF8',
and the second by the CCW at X'000000'.

It would probably be good to repeat the tests using
a real printer as opposed to a VM-simulated spooled
unit record device.

Bedtime for now...
--
Kevin
Ivan Warren
2008-03-29 09:19:23 UTC
Permalink
Post by pfg504
1) define storage under 16m
2) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should fail
A) define storage at 16M
B) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should work with the data involved being the last double word of storage
-- and the first double word of storage.
1,2 - Defnitely
A,B - Possibly - but not 100% sure !

I had to look up at z/Arch POP.. It does state that an I/O initiated
with a format 0 CCW is subject to 24 bit address wraparound for channel
storage addressing without IDAWS or MIDAWS - so - for compatibility
reasons, I would tend to believe that an I/O issued from a S/370 CPU
(which is always a format 0 CCW) should also wrap around from 2^24-1 to
0.. However, when IDAWs are concerned, it seems they *MAY* not wrap
(SA22-7832-6 specified a 31 bit wrap for Format 1 IDAWs in Format 0
CCWs[1]) - which may include the case of a S/370 configuration with more
than 16MB. I am therefore not certain whether a S/370 configuration with
an address approaching the 16MB line specified in an IDAW will wrap or
CPC (when the CU fetches said storage of course).

The underlying problem is that the "wrapping" behavior is inherently a
CPU based mechanism (especially in XA and beyond which control wrapping
with a PSW bit(s)) - something a channel has very little or no knowledge
about. In S/370 - things get more complicated when the configuration has
storage in excess of 16MB (which may be used, up to 64MB, for AE) - at
which point I am not certain as to what the proper behavior should be in
case of S/370 (especially if IDAWs are involved). GA22-7000-4 is a bit
fuzzy about this (it does state in the "storage" section in all
paragraphs whether CPU, Channels or both are involved in each storage
accesses behavior or mechanism *except* when they talk about 24 bits
wraparounds !)

So, as a precaution I would say 'may or may not wrap' or 'may or may not
yield a CPC' (because it may be related to a channel implementation and
not a CPU implementation). Of course, GA22-7000-4 is NOT very specific
here.. In all "storage" chapter paragraphs, they mention whether CPU,
Channel or both are involved *EXCEPT* for the address wraparound paragraph !

--Ivan

[1] On AE capable machines, this may provide an convenient way to
perform I/O on the 2^24-2^26-1 range of storage addresses - in which
case wrapping may NOT be involved.
Greg Smith
2008-03-29 13:18:46 UTC
Permalink
Post by Ivan Warren
Post by pfg504
1) define storage under 16m
2) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should fail
A) define storage at 16M
B) build a ccw to read or write from X'FFFFF0' for 32 bytes
-- This should work with the data involved being the last double word of storage
-- and the first double word of storage.
1,2 - Defnitely
A,B - Possibly - but not 100% sure !
For ccw fetch, from looking at the code in channel.c, ccwaddr is type
U32 and we do not have any code looking for a wrap. We only look to see
if it goes beyond dev->mainlim (sysblk.mainsize-1) or sysblk.addrlimval
(set by the SAL instruction). Also it looks like sysblk.mainsize can be
any number as long as we can obtain the storage. That is, you can
specify `mainsize 512' in hercules.cnf then ipl s/370.

Likewise for the data. In channel.c copy_iobuf there is no code
checking for wraparound.

Personally, I think anyone who writes a channel program using address
wraparound should get what they get ;-)

Greg
Ivan Warren
2008-03-29 15:10:08 UTC
Permalink
Post by Greg Smith
Likewise for the data. In channel.c copy_iobuf there is no code
checking for wraparound.
Personally, I think anyone who writes a channel program using address
wraparound should get what they get ;-)
You know this architecture is notorious from preventing people from
shooting themselves (too much) in the foot !

the "Good Book" GA22-7000-4 says on page 14 :

"Storage addressing wraps around from the maximum byte address,
16,7777,215, to 0. Information may be located partially in the last and
partially in the first location of storage and is processed without
special indication of crossing the maximum address boundary"

Like I was saying earlier, it doesn't specify whether this applies to
CPU, Channel or both.

And there is also the issue of X'xC' CCWs which may reach below 0 !

Although the CAW is itself real address, the storage address designated
by the CAW is an absolute address and so are the storage addresses
designated by the CCWs. Consequently, CCW fetching during command and
data chaining also needs to be checked (for addressability and key
storage protection).

Now.. I obviously misread SA22-7832 ! Hopefully, the z/Arch POP is *way*
more specific ! Figure 3-2 at page Storage 3-7 and 3-8 show this :

For a channel program with format-0 CCWs:
Successive CCWs A P24
Successive IDAWs A P24
Successive MIDAWs A P24
Successive bytes of I/O data (without IDAWs and MIDAWs) A P24
Successive bytes of I/O data (with format-1 IDAWs) A P31
Successive bytes of I/O data (with format-2 IDAWs) A P64
Successive bytes of I/O data (with MIDAWs) A P64
For a channel program with format-1 CCWs:
Successive CCWs A P31
Successive IDAWs A P31
Successive MIDAWs A P31
Successive bytes of I/O data (without IDAWs and MIDAWs) A P31
Successive bytes of I/O data (with format-1 IDAWs) A P31
Successive bytes of I/O data (with format-2 IDAWs) A P64
Successive bytes of I/O data (with MIDAWs) A P64

(here the A is for Absolute and Pxx indicates the limit at which a CPC
will occur (and not were it will wrap)) :

P24 An I/O program-check condition is recognized when the address
exceeds 2^24 - 1 or is decremented below zero.
P31 An I/O program-check condition is recognized when the address
exceeds 2^31 - 1 or is decremented below zero.
P64 An I/O program-check condition is recognized when the address
exceeds 2^64 - 1 or is decremented below zero.

So for S/370 I think (if the configuration has >16MB) we should either
wrap or CPC - but we shouldn't allow access the storage above 16MB
without IDAWs. For ESA/390 and z/Arch we should just follow the rule book.

I would therefore tend to think we could CPC on any described boundary
crossing in S/370.

--Ivan
pfg504
2008-03-29 18:17:20 UTC
Permalink
If the memory is at the address modes limit (24, or 31) then access should definiately
wrap.

Again, I remember a circumvention with LASP that some flavor of MVS used. Setting a base
register to a real address in the last page of the real address space the accesses that
wrapped around to page zero, bypassed LASP.

The ESA/390 POP indicates that all should wrap when the machine storage is 16M for 24
bit and 2G for 31-bit mode.

See: SA22-7201-4 page 3-5.

Maybe we should pick a POP for various modes and stick to it since there are either
differences or clarifications made in each successive version. It is hard to determine which
are which.

Paul
Post by Ivan Warren
Post by Greg Smith
Likewise for the data. In channel.c copy_iobuf there is no code
checking for wraparound.
Personally, I think anyone who writes a channel program using address
wraparound should get what they get ;-)
You know this architecture is notorious from preventing people from
shooting themselves (too much) in the foot !
"Storage addressing wraps around from the maximum byte address,
16,7777,215, to 0. Information may be located partially in the last and
partially in the first location of storage and is processed without
special indication of crossing the maximum address boundary"
Like I was saying earlier, it doesn't specify whether this applies to
CPU, Channel or both.
And there is also the issue of X'xC' CCWs which may reach below 0 !
Although the CAW is itself real address, the storage address designated
by the CAW is an absolute address and so are the storage addresses
designated by the CCWs. Consequently, CCW fetching during command and
data chaining also needs to be checked (for addressability and key
storage protection).
Now.. I obviously misread SA22-7832 ! Hopefully, the z/Arch POP is *way*
Successive CCWs A P24
Successive IDAWs A P24
Successive MIDAWs A P24
Successive bytes of I/O data (without IDAWs and MIDAWs) A P24
Successive bytes of I/O data (with format-1 IDAWs) A P31
Successive bytes of I/O data (with format-2 IDAWs) A P64
Successive bytes of I/O data (with MIDAWs) A P64
Successive CCWs A P31
Successive IDAWs A P31
Successive MIDAWs A P31
Successive bytes of I/O data (without IDAWs and MIDAWs) A P31
Successive bytes of I/O data (with format-1 IDAWs) A P31
Successive bytes of I/O data (with format-2 IDAWs) A P64
Successive bytes of I/O data (with MIDAWs) A P64
(here the A is for Absolute and Pxx indicates the limit at which a CPC
P24 An I/O program-check condition is recognized when the address
exceeds 2^24 - 1 or is decremented below zero.
P31 An I/O program-check condition is recognized when the address
exceeds 2^31 - 1 or is decremented below zero.
P64 An I/O program-check condition is recognized when the address
exceeds 2^64 - 1 or is decremented below zero.
So for S/370 I think (if the configuration has >16MB) we should either
wrap or CPC - but we shouldn't allow access the storage above 16MB
without IDAWs. For ESA/390 and z/Arch we should just follow the rule book.
I would therefore tend to think we could CPC on any described boundary
crossing in S/370.
--Ivan
pfg504
2008-03-29 23:47:10 UTC
Permalink
I think this is the correct approach. IBM has gotten more specific as the Architecture has
improved. Improving to content on the manuals.

SA22-7201-4 (ESA/390 POP) dedicates the first paragraph to state what address
generation is and it includes the CPU and CHANNEL SUBSYSTEM.



The second paragraph goes on to state what is being done with address generation:

WHEN, DURING THE GENERATION OF THE ADDRESS, AN ADDRESS IS OBTAINED THAT
EXCEEDS THE VALUE ALLOWED FOR THE ADDRESS SIZE (2^24-1 or 2^31-1), ONE OF THE
FOLLOWING TWO ACTIONS IS TAKEN:

1) THE CARRY OUT OF THE HIGH-ORDER BIT POSITION OF THE ADDRESS IS IGNORED.
THIS HANDLING OF AN ADDRESS OF EXCESSIVE SSIZE IS CALLED WRAPAROUND.
2) AN INTERRUPTION CONDITION IS RECOGNIZED

THE EFFECT OF WRAPAROUND IS TO MAKE AN ADDRESS SPACE APPEAR CIRCULAR; THAT
IS, ADDRESS 0 APPEARS TO FOLLOW THE MAXIMUM ALLOWABLE ADDRESS. ADDRESS
ARITHMETIC AND WRAPAROUND OCCUR BEFORE TRANSFORMATION, IF ANY, OF THE
ADDRESS BY DAT OR PREFIXING.

...
...
...

FOR CHANNEL-PROGRAM EXECUTION, WHEN THE GENERATED ADDRESS EXCEEDS THE
VALUE FOR THE ADDRESS SIZE (OR, FOR THE READ-BACKWARD COMMAND IS
DECREMENTED BELOW 0), AN I/O PROGRAM-CHECK CONDITION IS RECOGNIZED.

Between paragraphs in the book, IBM appears to contradict themselves. Or it is just
written really bad.

Items 1 and 2 do not necessary apply to both CPU and CHANNEL SUBSYSTEM. Item 1 could
be for the CPU and item 2 for the CHANNEL SUBSYSTEM when channel program execution
is occurring.

I hope Z-Arch is more clear about this. Let's pick the Z-Arch version and retrofit it
downward.


Paul
Post by Ivan Warren
Post by Greg Smith
Likewise for the data. In channel.c copy_iobuf there is no code
checking for wraparound.
Personally, I think anyone who writes a channel program using address
wraparound should get what they get ;-)
You know this architecture is notorious from preventing people from
shooting themselves (too much) in the foot !
"Storage addressing wraps around from the maximum byte address,
16,7777,215, to 0. Information may be located partially in the last and
partially in the first location of storage and is processed without
special indication of crossing the maximum address boundary"
Like I was saying earlier, it doesn't specify whether this applies to
CPU, Channel or both.
And there is also the issue of X'xC' CCWs which may reach below 0 !
Although the CAW is itself real address, the storage address designated
by the CAW is an absolute address and so are the storage addresses
designated by the CCWs. Consequently, CCW fetching during command and
data chaining also needs to be checked (for addressability and key
storage protection).
Now.. I obviously misread SA22-7832 ! Hopefully, the z/Arch POP is *way*
Successive CCWs A P24
Successive IDAWs A P24
Successive MIDAWs A P24
Successive bytes of I/O data (without IDAWs and MIDAWs) A P24
Successive bytes of I/O data (with format-1 IDAWs) A P31
Successive bytes of I/O data (with format-2 IDAWs) A P64
Successive bytes of I/O data (with MIDAWs) A P64
Successive CCWs A P31
Successive IDAWs A P31
Successive MIDAWs A P31
Successive bytes of I/O data (without IDAWs and MIDAWs) A P31
Successive bytes of I/O data (with format-1 IDAWs) A P31
Successive bytes of I/O data (with format-2 IDAWs) A P64
Successive bytes of I/O data (with MIDAWs) A P64
(here the A is for Absolute and Pxx indicates the limit at which a CPC
P24 An I/O program-check condition is recognized when the address
exceeds 2^24 - 1 or is decremented below zero.
P31 An I/O program-check condition is recognized when the address
exceeds 2^31 - 1 or is decremented below zero.
P64 An I/O program-check condition is recognized when the address
exceeds 2^64 - 1 or is decremented below zero.
So for S/370 I think (if the configuration has >16MB) we should either
wrap or CPC - but we shouldn't allow access the storage above 16MB
without IDAWs. For ESA/390 and z/Arch we should just follow the rule book.
I would therefore tend to think we could CPC on any described boundary
crossing in S/370.
--Ivan
Kevin Leonard
2008-03-29 20:55:59 UTC
Permalink
Post by Greg Smith
For ccw fetch, from looking at the code in channel.c,
ccwaddr is type U32 and we do not have any code looking
for a wrap. We only look to see if it goes beyond
dev->mainlim (sysblk.mainsize-1) or sysblk.addrlimval
(set by the SAL instruction). Also it looks like
sysblk.mainsize can be any number as long as we can
obtain the storage. That is, you can specify
`mainsize 512' in hercules.cnf then ipl s/370.
Likewise for the data. In channel.c copy_iobuf there
is no code checking for wraparound.
Testing directly under Hercules (no VM) in S/370 mode:

(1) With MAINSIZE less than 16MB, attempt to write
32 bytes starting at MAINSIZE minus 16 gets channel
program check.

(2) With MAINSIZE equal to 16MB, attempt to write
32 bytes starting at MAINSIZE minus 16 gets channel
program check. There is no attempt to wrap.

(3) With MAINSIZE greater than 16MB (I set it to 32MB),
attempt to write 32 bytes starting at MAINSIZE minus 16
is successful. The 32 bytes written are X'FFFFF0' through
X'100000F' (that is, 16 bytes beyond the line):

restart
HHCPN038I Restart key depressed
PSW=00000000 00000400 INST=4110000F LA 1,15(0,0)
PSW=00000000 00000404 INST=9C001000 SIO 0(1)
HHCCP048I 000F:CCW=09FFFFF0 00000020=>C8C5D3D3 D6606060 60606060
6060604E HELLO----------+
HHCCP075I 000F:Stat=0C00 Count=0000
PSW=00000000 80000408 INST=47800418 BC 8,1048(0,0)
PSW=00000000 80000418 INST=82000458 LPSW 1112(0)
HHCCP043I Wait state PSW loaded: PSW=FE020000 8000FFFF
HHCCP049I 000F:Stat=0C00 Count=0000 CCW=000468
HHCCP044I I/O interrupt code=000F CSW=00000468 0C000000
HHCCP043I Wait state PSW loaded: PSW=00020000 8000AAAA
HHCCP011I CPU0000: Disabled wait state
-------- PSW=00020000 8000AAAA
r FFFFF0
R:00FFFFF0:K:06=C8C5D3D3 D6606060 60606060 6060604E HELLO----------+
R:01000000:K:06=C1C6E3C5 D940F1F6 D4C26060 6060606E AFTER 16MB----->
R:01000010:K:06=00000000 00000000 00000000 00000000 ................
R:01000020:K:06=00000000 00000000 00000000 00000000 ................

and the output written to 00F is:

HELLO----------+AFTER 16MB----->
--
Kevin
Greg Smith
2008-03-29 22:12:52 UTC
Permalink
Post by Kevin Leonard
(1) With MAINSIZE less than 16MB, attempt to write
32 bytes starting at MAINSIZE minus 16 gets channel
program check.
(2) With MAINSIZE equal to 16MB, attempt to write
32 bytes starting at MAINSIZE minus 16 gets channel
program check. There is no attempt to wrap.
(3) With MAINSIZE greater than 16MB (I set it to 32MB),
attempt to write 32 bytes starting at MAINSIZE minus 16
is successful. The 32 bytes written are X'FFFFF0' through
X'100000F' (that is, 16 bytes beyond the line)
Looks like I read the code correctly.

My point is: should we add complication to the code for each execution
of a ccw to fix a problem that doesn't occur for any sane operating
system in order to more precisely conform to the `good book'?

Kevin, I jumped in here late. What was the original problem? Was it
s370 vm trying to cause a device error but was getting the wrong csw set
because it set the midaw bit in the flags when mainsize was 16M?

Greg
Gerhard Postpischil
2008-03-30 01:01:18 UTC
Permalink
Post by Greg Smith
My point is: should we add complication to the code for each execution
of a ccw to fix a problem that doesn't occur for any sane operating
system in order to more precisely conform to the `good book'?
I've never run into an actual case where wrapping is necessary
(or desirable?). So IMHO this should be a documentation change <g>

Gerhard Postpischil
Bradford, VT
Kevin Leonard
2008-03-30 02:46:05 UTC
Permalink
Post by Greg Smith
My point is: should we add complication to the
code for each execution of a ccw to fix a problem
that doesn't occur for any sane operating system
in order to more precisely conform to the `good
book'?
That has the potential to be a religious issue, and
people can with good will and good intentions argue
passionately on both sides of the question. My strong
preference is to avoid as much as possible getting
lost in a dispute that would generate a maximum of
anger with a minimum of practical results. I'm not
entirely sure how to do that. Some ground rules for
considering subjects of this type do suggest themselves,
though:

o Everybody's informed opinion on Hercules community
issues is welcomed and valued, as long as the discourse
remains civil, friendly and respectful.

o No one will ever be entirely satisfied with every
decision, no matter what is decided. But whatever
is decided should probably make enough sense that a
consensus of regular Hercules users understand why
it was decided that way.

o Ultimately, Hercules is Roger's creation, and if
it comes down to it, the final word belongs to him.
And the rest of us support his right to the final say
even if we disagree with any particular decision.
Knowing Roger, and knowing Hercules users, that's
unlikely to happen often.

OK, those are the rules, now here's the game, or at
least my take on it....

There's a point at which the cost of absolute
authenticity outweighs the benefit of precise
conformity to a standard, particularly when the
authenticity being sought is with regard to
something that will be encountered rarely if ever
in the "real" world of, as you put it, sane
operating systems. That said, I think we should
explore what it would take to implement a feature
before we rule out doing it. It may be possible
to implement wraparound so that performance
overhead is insignificant in the ordinary case
where wraparound doesn't occur. If it's not
possible, then we don't do it, and document the
fact in the architectural features implementation
list.

A consideration before any discussion about what
should be implemented is to figure out exactly
what "authentic" behavior actually is. The S/360
POP seems to insist pretty clearly on wraparound.
The ESA/390 documentation that Paul posted suggests
alternatives. "Correct" behavior would have to be
determined.

One possibility I see from the ESA/390 stuff, if
wraparound is too expensive, is to force channel
program error whenever an address exceeds the
architectural limit. This would have the advantage
of consistent behavior no matter what MAINSIZE is
defined to be. Instead of CHADDRCHK() testing
mainlim, it could test the smaller of mainlim and
architectural limit, the value of which would be set
during initialization.
Post by Greg Smith
Kevin, I jumped in here late. What was the original
problem? Was it s370 vm trying to cause a device error
but was getting the wrong csw set because it set the midaw
bit in the flags when mainsize was 16M?
Here's the original problem:

http://tech.groups.yahoo.com/group/hercules-390/message/53481

I'll try to summarize. If I miss something, Thom
and Paul and Ivan will I hope supply it.

The original problem was a channel program check
that occurred on a local 3277 DOS/VS VTAM device
when DOS/VS was running as a VM guest, but didn't
happen when DOS/VS was running native. A 3277
select command X'0B' was failing with channel
program check. The failing CCW had an "invalid" data
address (it turned out to be an untranslated virtual
address in DOS/VS virtual storage). We found that a
lot of things all have to happen to get the error:

(1) DOS/VS has to be running under VM;

(2) The 3277 has to be on a channel that VM has
identified in a virtual STIDC response as a block
multiplexor channel;

(3) The VM system has to have an RMSIZE of 16 MB;

(4) The DOS/VS guest machine storage size has to be
smaller than the virtual address in the select CCW.

What I see -- and Paul, Thom and Ivan will correct
me if I miss something -- is that VM has decided to
validate the select CCW's data address, and when the
validation fails, it deliberately builds a real CCW
that it intends to be invalid. If VM's real storage
size is less than 16 MB, the real storage size is set
as the data address, which should produce a channel
program check because last_installed_byte + 1 is an
invalid address. Hercules doesn't validate the select
data address, so in this case the select doesn't fail.
If VM real storage is 16 MB, there's no way to force a
program check with an invalid address because in a 16
MB machine all addresses are valid. So in this case,
VM turns on CCW bits 38 and 39 (undefined at the time
VM R6 was written, now SUSPEND and MIDA) to generate a
program check due to CCW format error. Hercules finds
the MIDA bit on in an environment that doesn't support
MIDAW and returns channel program check.

(As Ivan noted, the fact that Hercules is actually
simulating SIOF rather than SIO causes the error to be
presented as an interrupt rather than in response to
the SIO, but that's a whole separate discussion.)

Discussions have considered whether the original
cause is VTAM setting a data address for a control
command that doesn't need one (but that shouldn't
make any difference); whether VM should be forcing
channel program check for the select CCW's bad
address (VM R6 makes decisions about whether to
validate the data address based on device type
and command, but it doesn't seem to know about
3270 selects).

--
Kevin
pfg504
2008-03-30 02:57:14 UTC
Permalink
One small note:

We have had discussions about sticking to the POP/POO without deviation and now we
have a discussion to deviate from the POP/POO.

No OS is sane that just are.

Paul
Post by Kevin Leonard
Post by Greg Smith
My point is: should we add complication to the
code for each execution of a ccw to fix a problem
that doesn't occur for any sane operating system
in order to more precisely conform to the `good
book'?
That has the potential to be a religious issue, and
people can with good will and good intentions argue
passionately on both sides of the question. My strong
preference is to avoid as much as possible getting
lost in a dispute that would generate a maximum of
anger with a minimum of practical results. I'm not
entirely sure how to do that. Some ground rules for
considering subjects of this type do suggest themselves,
o Everybody's informed opinion on Hercules community
issues is welcomed and valued, as long as the discourse
remains civil, friendly and respectful.
o No one will ever be entirely satisfied with every
decision, no matter what is decided. But whatever
is decided should probably make enough sense that a
consensus of regular Hercules users understand why
it was decided that way.
o Ultimately, Hercules is Roger's creation, and if
it comes down to it, the final word belongs to him.
And the rest of us support his right to the final say
even if we disagree with any particular decision.
Knowing Roger, and knowing Hercules users, that's
unlikely to happen often.
OK, those are the rules, now here's the game, or at
least my take on it....
There's a point at which the cost of absolute
authenticity outweighs the benefit of precise
conformity to a standard, particularly when the
authenticity being sought is with regard to
something that will be encountered rarely if ever
in the "real" world of, as you put it, sane
operating systems. That said, I think we should
explore what it would take to implement a feature
before we rule out doing it. It may be possible
to implement wraparound so that performance
overhead is insignificant in the ordinary case
where wraparound doesn't occur. If it's not
possible, then we don't do it, and document the
fact in the architectural features implementation
list.
A consideration before any discussion about what
should be implemented is to figure out exactly
what "authentic" behavior actually is. The S/360
POP seems to insist pretty clearly on wraparound.
The ESA/390 documentation that Paul posted suggests
alternatives. "Correct" behavior would have to be
determined.
One possibility I see from the ESA/390 stuff, if
wraparound is too expensive, is to force channel
program error whenever an address exceeds the
architectural limit. This would have the advantage
of consistent behavior no matter what MAINSIZE is
defined to be. Instead of CHADDRCHK() testing
mainlim, it could test the smaller of mainlim and
architectural limit, the value of which would be set
during initialization.
Post by Greg Smith
Kevin, I jumped in here late. What was the original
problem? Was it s370 vm trying to cause a device error
but was getting the wrong csw set because it set the midaw
bit in the flags when mainsize was 16M?
http://tech.groups.yahoo.com/group/hercules-390/message/53481
I'll try to summarize. If I miss something, Thom
and Paul and Ivan will I hope supply it.
The original problem was a channel program check
that occurred on a local 3277 DOS/VS VTAM device
when DOS/VS was running as a VM guest, but didn't
happen when DOS/VS was running native. A 3277
select command X'0B' was failing with channel
program check. The failing CCW had an "invalid" data
address (it turned out to be an untranslated virtual
address in DOS/VS virtual storage). We found that a
(1) DOS/VS has to be running under VM;
(2) The 3277 has to be on a channel that VM has
identified in a virtual STIDC response as a block
multiplexor channel;
(3) The VM system has to have an RMSIZE of 16 MB;
(4) The DOS/VS guest machine storage size has to be
smaller than the virtual address in the select CCW.
What I see -- and Paul, Thom and Ivan will correct
me if I miss something -- is that VM has decided to
validate the select CCW's data address, and when the
validation fails, it deliberately builds a real CCW
that it intends to be invalid. If VM's real storage
size is less than 16 MB, the real storage size is set
as the data address, which should produce a channel
program check because last_installed_byte + 1 is an
invalid address. Hercules doesn't validate the select
data address, so in this case the select doesn't fail.
If VM real storage is 16 MB, there's no way to force a
program check with an invalid address because in a 16
MB machine all addresses are valid. So in this case,
VM turns on CCW bits 38 and 39 (undefined at the time
VM R6 was written, now SUSPEND and MIDA) to generate a
program check due to CCW format error. Hercules finds
the MIDA bit on in an environment that doesn't support
MIDAW and returns channel program check.
(As Ivan noted, the fact that Hercules is actually
simulating SIOF rather than SIO causes the error to be
presented as an interrupt rather than in response to
the SIO, but that's a whole separate discussion.)
Discussions have considered whether the original
cause is VTAM setting a data address for a control
command that doesn't need one (but that shouldn't
make any difference); whether VM should be forcing
channel program check for the select CCW's bad
address (VM R6 makes decisions about whether to
validate the data address based on device type
and command, but it doesn't seem to know about
3270 selects).
--
Kevin
Ivan Warren
2008-03-15 17:11:45 UTC
Permalink
Post by Kevin Leonard
HHCCP048I 00C0:CCW=0B000000 63000001=>000C0000 0000080C 00000000
00F43000 .............4..
HHCCP049I 00C0:Stat=0020 Count=0119 CCW=FA2E10
Ah ah ! That is quite interesting !

Ok.. I tried to dig information in the S/370 POP I could find (the
September 1975 edition I got from bitsavers) and there are a couple of
notes of interest here :

Page 234 (almost entire page).. At the end of the Program Check
description it states the following :

<excerpt>
Detection of the program-check condition during the initiation of an
operation causes execution of the operation to be suppressed. When the
condition is detected after the device has been started, the device is
signaled to conclude the operation *the next time it requests or offers
data*. The program check condition causes command chaining to be suppressed
</excerpt>
(emphasis mine).

Of course, I would suspect that this condition (invalid CCW format)
should be detected at initiation time but IT DOESN'T say so anywhere.

And the CSW sure doesn't look right either !

--Ivan
PeterH5322
2008-03-14 04:10:52 UTC
Permalink
Post by Ivan Warren
Ok.. Now that's something that needs to be worked out. I *did* find the
S/370 POP reference stating that channel 0 is a Byte Multiplexor (Page
192, Paragraph 2 in GA22-7000-4). I do not think there should be any arm
in doing the "Right Thing"[1] here. (that will only affect S/370 since
STIDC only exists in S/370). Accordingly, I've changed the source code
On a Model 155, Chs. 0 and 4 could be byte multiplexors, so Ch. 0 is not
the only possible myte multiplexor (and on an Amdahl, any channel could
be any of: 2660 Selector Channel, 2870 Byte Multiplexor Channel, or 2880
Block multiplexor Channel, as the customer requested).

And, at least for the 2870 byte multiplexor channel (Models 65, 75, 165,
168 and others others, and their Amdahl emulations) such a byte
multiplxor may have selector subchannels, with which to connect burst
devices, such as tape drives, etcetera.
Ivan Warren
2008-03-14 04:36:19 UTC
Permalink
Post by PeterH5322
Post by Ivan Warren
Ok.. Now that's something that needs to be worked out. I *did* find the
S/370 POP reference stating that channel 0 is a Byte Multiplexor (Page
192, Paragraph 2 in GA22-7000-4). I do not think there should be any arm
in doing the "Right Thing"[1] here. (that will only affect S/370 since
STIDC only exists in S/370). Accordingly, I've changed the source code
On a Model 155, Chs. 0 and 4 could be byte multiplexors, so Ch. 0 is not
the only possible myte multiplexor (and on an Amdahl, any channel could
be any of: 2660 Selector Channel, 2870 Byte Multiplexor Channel, or 2880
Block multiplexor Channel, as the customer requested).
And, at least for the 2870 byte multiplexor channel (Models 65, 75, 165,
168 and others others, and their Amdahl emulations) such a byte
multiplxor may have selector subchannels, with which to connect burst
devices, such as tape drives, etcetera.
Right.. Same for a 4381 which could have channel 5 configured as either
a Block or Byte Multiplexor

But.. it's not the point !

The only *mandatory* specification (from the POP) is that Channel 0 be a
Byte Multiplexor.. Other channels are model dependent (and on the
hercules 'model', for the time being, it's block multiplexor for the rest).

Now.. as I said, if people are REALLY interested in having this
configurable, then it shouldn't be overly hard to do. Something like :

CHANNELS [CSID0/]M|B|S[,M|B|S][,...] [CSID1/M|B|S[,...]]

With CSIDn being the Channel Set ID
Each of M(Multiplexor), B(Block MPX), S(Selector) representing
consecutive channels
With the remaining being the same as the last entry..

For example :

CHANNELS 0/M,B,B,S,B 1/M,S,B

would have Channel 0 on Channel set 0 as a byte multiplexor, Channels
1,2,4 and up on CS 0 as block multiplexors and channel 3 as a selector
and Channel 0 on CS 1 as a byte mpx, Channel 1 on CS 1 as a sel and
Channels 2 and up on CS 1 as block multiplexors..

Again, for S/370 this (for the time being) would only affect the STIDC
results, not the ACTUAL operations on the channel.

--Ivan
Gerhard Postpischil
2008-03-14 05:17:23 UTC
Permalink
Post by Ivan Warren
Right.. Same for a 4381 which could have channel 5 configured as either
a Block or Byte Multiplexor
Are you sure? I seem to recall the 4341 and 4381 as having four
channels per set, which made our second byte multiplexer channel
4 (we had regular unit record gear on 0, and an NCR/Comten
3695 on 4).
Post by Ivan Warren
But.. it's not the point !
Right, unless someone really simulates pre-XA behavior
Post by Ivan Warren
CHANNELS [CSID0/]M|B|S[,M|B|S][,...] [CSID1/M|B|S[,...]]
If it's not too much work, and has a sensible default, it would
be nice to have.

Gerhard Postpischil
Bradford, VT
Ivan Warren
2008-03-14 05:29:12 UTC
Permalink
Post by Gerhard Postpischil
Post by Ivan Warren
Right.. Same for a 4381 which could have channel 5 configured as either
a Block or Byte Multiplexor
Are you sure? I seem to recall the 4341 and 4381 as having four
channels per set, which made our second byte multiplexer channel
4 (we had regular unit record gear on 0, and an NCR/Comten
3695 on 4).
My 4381 P03 had 6 channels per channel set and 2 channel sets.. All this
is entirely model dependent !
Post by Gerhard Postpischil
Post by Ivan Warren
But.. it's not the point !
Right, unless someone really simulates pre-XA behavior
The only "constant" is channel 0 being a Byte Multiplexor. From the 115
up to a 3090 Mod 600 running in S/370 mode (with its possible 6*16
channels - or was it 6*32 ?) we certainly had a load of different
channel configurations (think about the 9370 which could even run
WITHOUT having a real bus-tag channel)..
Post by Gerhard Postpischil
Post by Ivan Warren
CHANNELS [CSID0/]M|B|S[,M|B|S][,...] [CSID1/M|B|S[,...]]
If it's not too much work, and has a sensible default, it would
be nice to have.
Sensible default would probably be channel 0 of each channel set as a
Byte MPX and the rest as Block MPX

--Ivan
PeterH5322
2008-03-14 21:04:21 UTC
Permalink
Post by Gerhard Postpischil
If I recall, there is
special code to handle MVS PCI Fetch, but that code just
replaces or appends CCWs, with never an invalid one present.
PCI Fetch (MVT, and later) is a very special case, for which a permanent
"dispensation" was given for its "disabled bit spin".

The channel programs are rigidly specified, and it works natively, as
well as under VM.

If a deviation from the specification was made, it likely wouldn't work
under VM.

The MVS version isn't substantially different, and as with MVT it depends
upon the disabled bit spin to ensure that the entire Control/RLD record
was read before the contents of that record were utilized to perform
asynchronous relocation, or, if there was no RLD data, the control
portion was used to reinitialize the channel program for the next text
record to be read.

Immediately thereafter, the NOP is changed to a TIC, and the C.P.
continues until it ends.


(Stanford U. came up with SLAC Fetch for MVT, which may have influenced
the design of MVS' PCI Fetch ... early MVT did the relocation in Fetch's
mainline, by a WAIT/POST mechanism ... SLAC moved this to the PCI
appendage ... MVS moved this to the DIE exit).
Loading...