|
Jay,
Yes true.? But ACF/VTAM 4 and above supports multiple CTC connections in pairs. No reason not to use the same approach at the TK4 level if you are in control of reading/writing to the hardware.
Regards,
Bob
|
Hi Matthew,
I suspect MIH is causing this - Missing Interrupt Handler - however, it may not be that but something similar
??.
I'm not sure if the command format will be the same on your MVS but:
D IOS,MIH,TIME=CTC is what I last used to diagnode issues on CTC's
After that you will need to look at the doc for your MVS to find out how to extend it
I also recall that the time can only be mm:ss , i.e. not Hours.
example from my running system
? - 16.13.18 ? ? ? ? ? D IOS,MIH,TIME=CTC? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?IOS086I 16.13.18 MIH TIME(S) ? ? ? ? FRAME LAST ? F ? ? ?E ? SYS=TOMB? ?
? CTC =03:00. ??
00- 16.15.10 ? ? ? ? ? D IOS,MIH ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?IOS086I 16.15.10 MIH AND IOT TIMES ? FRAME LAST ? F ? ? ?E ? SYS=TOMB ?
? MOUNTMSG = ?NO, ? ? ? ? HALT=00:05, MNTS=03:00, UREC=03:00, ? ? ? ? ?
? DASD=00:15, TAPE=03:00, GRAF=03:00, CTC =03:00, COMM=03:00, ? ? ? ? ?
? CHAR=03:00, IOTDASD=00:00, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? US01=00:30 UDEV=0300, 0301, 0302, 0310, 0A80, 0A81, 0A82, 0A83, ? ? ?
? ? ? ? ? ? ? ? ? 0A84, 0A85, 0A86, 0A87, 0A88, 0A89, 0A8A, 0A8B, ? ? ?
? ? ? ? ? ? ? ? ? 0A8C, 0A8D, 0A8E, 0A8F, 0A90, 0A91, 0A92, 0A93, ? ? ?
? ? ? ? ? ? ? ? ? 0A94, 0A95, 0A96, 0A97, 0A98, 0A99, 0A9A, 0A9B, ? ? ?
? ? ? ? ? ? ? ? ? 0A9C, 0A9D, 0A9E. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
vague memory of values are in?IECIOSxx ?
ref:?MVS?Initialization
and Tuning Reference?manual
? ? ? ? ? ? ? ? ? ??
Hope this helps,
Regards
Tom Bottomley? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
toggle quoted message
Show quoted text
Hello,
I am on MVS 3.8, writing assembler code that reads from a CTC adapter. I
will be running a "server" started task that should wait indefinitely
for a command from the "client" program on the other end of the CTC
link.
I'm having trouble finding the right way to wait indefinitely for the
other side to send data.
I'm using the EXCP macro to execute my channel program (just a simple
read command) on the CTC device. I do the EXCP, then I use the WAIT
macro on the associated ECB.
When the sender doesn't send anything, the WAIT ends after 1 minute and
the completion code in the high order byte of the ECB is 0x41. If I run
EXCP and WAIT again, the WAIT *immediately* returns and the high order
byte of the ECB is 0x48.
See the attached CTCREAD.0.txt for a job that demonstrates this.
That's not the behavior I want. Ideally I could WAIT, hit the 1 minute
timeout waiting for data, then just issue the READ again and WAIT
another minute. (Or just not timeout at all, in a perfect world.) I can
loop until I get a non-timeout completion. (Although...I suspect this
isn't quite right; I get an "IEA000I 502,IOE,02,9000,..." message on the
console for the timeout, which I wouldn't want accumulating every minute
over time.)
Alternatively, if I close the CTC DCB and open it again before the next
EXCP/WAIT, there's another one minute pause before timing out again.
This is closer to the desired behavior... but I feel like CLOSEing and
OPENing the CTC device each time through the "wait indefinitely for the
other side to send data" loop is wrong. (And I also suspect that the
read side sending the "read" command state to the other side of the link
every time when it's not actually issuing corresponding writes each time
will lead to problems.)
See the attached CTCREAD.1.txt for a job that demonstrates this
close/open approach. This suggests to me that there's some state I
should be able to clear to get the EXCP to really wait another minute
before timing out, without actually having to close and re-open the CTC
DCB.
The best approach I've been able to come up with so far is to not do a
READ in my "wait" loop, but to do a SENSE CCW on the CTC adapter. On the
sending side, I issue a CONTROL command through the CTC adapter before
doing the WRITE. On my receiving side, I put the EXCP that runs the
SENSE CCW in a loop with a 250ms pause (using STIMER macro). So if the
SENSE doesn't see the CONTROL command from the other side, I sleep for
250ms and check again. Once the SENSE gets the CONTROL command from the
other side, I can run the READ CCW and get data back.
This, so far, is the closest I've come to an ideal solution because it
doesn't cause any IO exceptions, either in my program or on the MVS
console.
However, I don't quite like it because I want to be able to use the WAIT
macro on an ECB list that include the CTC "read" wait along with some
other events. And with the 250ms spin loop, if the other side of the
link writes data 50ms into the loop iteration, it's unfortunate to delay
activity the remaining 200ms, and seeing the CPU time of the job slowly
increase over time while doing nothing due to the loop is...not
aesthetically pleasing.
SO... MY QUESTION... what is the correct way in MVS 3.8 to wait on
reading data from a CTC adapter that may come right away or may not come
for hours? Especially in the context of wanting that to be one of
several ECBs I'm waiting on with the WAIT ECBLIST=... form of the WAIT
macro?
Thank you,
Matthew
-- Regards, Tom [UK]
|
Hi all,
IECIOSxx doesn't exist on MVS 3.8. The MIH is hard coded to primary
of 3 minutes, and secondary of 15 seconds, if I remember correctly.
It can be changed with a zap, but it is for all devices, not a
single type.
The best way I have found is to do a SENSE OTHER, WAIT loop and when
you get an I/O command from the other side, then you can process it.
Basically polling for something to do.
I worked at a company in the 80's and 90's and we wrote server code
to do exactly this.
Thanks,
Dennis
On 5/18/23 11:32, Tom Bottomley wrote:
toggle quoted message
Show quoted text
Hi Matthew,
I suspect MIH is causing this - Missing Interrupt Handler -
however, it may not be that but something similar
??.
I'm not sure if the command format will be the same on your MVS
but:
D IOS,MIH,TIME=CTC is what I last used to diagnode issues on
CTC's
After that you will need to look at the doc for your MVS to find
out how to extend it
I also recall that the time can only be mm:ss , i.e. not Hours.
example from my running system
? - 16.13.18 ? ? ? ? ? D IOS,MIH,TIME=CTC? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ?
?IOS086I 16.13.18 MIH
TIME(S) ? ? ? ? FRAME LAST ? F ? ? ?E ? SYS=TOMB? ?
? CTC =03:00. ??
00-
16.15.10 ? ? ? ? ? D IOS,MIH ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?
?IOS086I 16.15.10 MIH AND IOT
TIMES ? FRAME LAST ? F ? ? ?E ? SYS=TOMB ?
? MOUNTMSG = ?NO, ? ? ? ?
HALT=00:05, MNTS=03:00, UREC=03:00, ? ? ? ? ?
? DASD=00:15, TAPE=03:00,
GRAF=03:00, CTC =03:00, COMM=03:00, ? ? ? ? ?
? CHAR=03:00, IOTDASD=00:00, ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? US01=00:30 UDEV=0300, 0301,
0302, 0310, 0A80, 0A81, 0A82, 0A83, ? ? ?
? ? ? ? ? ? ? ? ? 0A84, 0A85,
0A86, 0A87, 0A88, 0A89, 0A8A, 0A8B, ? ? ?
? ? ? ? ? ? ? ? ? 0A8C, 0A8D,
0A8E, 0A8F, 0A90, 0A91, 0A92, 0A93, ? ? ?
? ? ? ? ? ? ? ? ? 0A94, 0A95,
0A96, 0A97, 0A98, 0A99, 0A9A, 0A9B, ? ? ?
? ? ? ? ? ? ? ? ? 0A9C, 0A9D,
0A9E. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?
vague memory of values are in?IECIOSxx ?
ref:?MVS?Initialization and Tuning Reference?manual
? ? ? ? ? ? ? ? ? ??
Hope this helps,
Regards
Tom Bottomley? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
Hello,
I am on MVS 3.8, writing assembler code that reads from a
CTC adapter. I
will be running a "server" started task that should wait
indefinitely
for a command from the "client" program on the other end
of the CTC
link.
I'm having trouble finding the right way to wait
indefinitely for the
other side to send data.
I'm using the EXCP macro to execute my channel program
(just a simple
read command) on the CTC device. I do the EXCP, then I use
the WAIT
macro on the associated ECB.
When the sender doesn't send anything, the WAIT ends after
1 minute and
the completion code in the high order byte of the ECB is
0x41. If I run
EXCP and WAIT again, the WAIT *immediately* returns and
the high order
byte of the ECB is 0x48.
See the attached CTCREAD.0.txt for a job that demonstrates
this.
That's not the behavior I want. Ideally I could WAIT, hit
the 1 minute
timeout waiting for data, then just issue the READ again
and WAIT
another minute. (Or just not timeout at all, in a perfect
world.) I can
loop until I get a non-timeout completion. (Although...I
suspect this
isn't quite right; I get an "IEA000I 502,IOE,02,9000,..."
message on the
console for the timeout, which I wouldn't want
accumulating every minute
over time.)
Alternatively, if I close the CTC DCB and open it again
before the next
EXCP/WAIT, there's another one minute pause before timing
out again.
This is closer to the desired behavior... but I feel like
CLOSEing and
OPENing the CTC device each time through the "wait
indefinitely for the
other side to send data" loop is wrong. (And I also
suspect that the
read side sending the "read" command state to the other
side of the link
every time when it's not actually issuing corresponding
writes each time
will lead to problems.)
See the attached CTCREAD.1.txt for a job that demonstrates
this
close/open approach. This suggests to me that there's some
state I
should be able to clear to get the EXCP to really wait
another minute
before timing out, without actually having to close and
re-open the CTC
DCB.
The best approach I've been able to come up with so far is
to not do a
READ in my "wait" loop, but to do a SENSE CCW on the CTC
adapter. On the
sending side, I issue a CONTROL command through the CTC
adapter before
doing the WRITE. On my receiving side, I put the EXCP that
runs the
SENSE CCW in a loop with a 250ms pause (using STIMER
macro). So if the
SENSE doesn't see the CONTROL command from the other side,
I sleep for
250ms and check again. Once the SENSE gets the CONTROL
command from the
other side, I can run the READ CCW and get data back.
This, so far, is the closest I've come to an ideal
solution because it
doesn't cause any IO exceptions, either in my program or
on the MVS
console.
However, I don't quite like it because I want to be able
to use the WAIT
macro on an ECB list that include the CTC "read" wait
along with some
other events. And with the 250ms spin loop, if the other
side of the
link writes data 50ms into the loop iteration, it's
unfortunate to delay
activity the remaining 200ms, and seeing the CPU time of
the job slowly
increase over time while doing nothing due to the loop
is...not
aesthetically pleasing.
SO... MY QUESTION... what is the correct way in MVS 3.8 to
wait on
reading data from a CTC adapter that may come right away
or may not come
for hours? Especially in the context of wanting that to be
one of
several ECBs I'm waiting on with the WAIT ECBLIST=... form
of the WAIT
macro?
Thank you,
Matthew
--
Regards,
Tom
[UK]
|
Dear Dennis,
?
The classical way would be to handle the Attention Interrupt that is generated when the ‘other’ side issues a command. There is an index in the UCB (UCBATI) to an attention table.
The CTC Attention handling is module IECTCATN. You can find the source in MVSSRC.SYS102.F19 on MVS 3.8. I hope this helps to find a way to avoid the Sense approach.
?
Regards
Silvio
?
?
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Dennis Stone
Sent: Thursday, 18 May 2023 18:26
To: [email protected]
Subject: Re: [H390-MVS] How to wait indefinitely for a read on CTC device?
?
Hi all,
IECIOSxx doesn't exist on MVS 3.8. The MIH is hard coded to primary of 3 minutes, and secondary of 15 seconds, if I remember correctly. It can be changed with a zap, but it is for all devices, not a single type.
The best way I have found is to do a SENSE OTHER, WAIT loop and when you get an I/O command from the other side, then you can process it. Basically polling for something to do.
I worked at a company in the 80's and 90's and we wrote server code to do exactly this.
Thanks,
Dennis
On 5/18/23 11:32, Tom Bottomley wrote:
I suspect MIH is causing this - Missing Interrupt Handler - however, it may not be that but something similar
??.
I'm not sure if the command format will be the same on your MVS but:
D IOS,MIH,TIME=CTC is what I last used to diagnode issues on CTC's
After that you will need to look at the doc for your MVS to find out how to extend it
I also recall that the time can only be mm:ss , i.e. not Hours.
example from my running system
? - 16.13.18 ? ? ? ? ? D IOS,MIH,TIME=CTC? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?IOS086I 16.13.18 MIH TIME(S) ? ? ? ? FRAME LAST ? F ? ? ?E ? SYS=TOMB? ?
00- 16.15.10 ? ? ? ? ? D IOS,MIH ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?IOS086I 16.15.10 MIH AND IOT TIMES ? FRAME LAST ? F ? ? ?E ? SYS=TOMB ?
? MOUNTMSG = ?NO, ? ? ? ? HALT=00:05, MNTS=03:00, UREC=03:00, ? ? ? ? ?
? DASD=00:15, TAPE=03:00, GRAF=03:00, CTC =03:00, COMM=03:00, ? ? ? ? ?
? CHAR=03:00, IOTDASD=00:00, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? US01=00:30 UDEV=0300, 0301, 0302, 0310, 0A80, 0A81, 0A82, 0A83, ? ? ?
? ? ? ? ? ? ? ? ? 0A84, 0A85, 0A86, 0A87, 0A88, 0A89, 0A8A, 0A8B, ? ? ?
? ? ? ? ? ? ? ? ? 0A8C, 0A8D, 0A8E, 0A8F, 0A90, 0A91, 0A92, 0A93, ? ? ?
? ? ? ? ? ? ? ? ? 0A94, 0A95, 0A96, 0A97, 0A98, 0A99, 0A9A, 0A9B, ? ? ?
? ? ? ? ? ? ? ? ? 0A9C, 0A9D, 0A9E. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
vague memory of values are in?IECIOSxx ?
ref:?MVS?Initialization
and Tuning Reference?manual
Tom Bottomley? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
Hello,
I am on MVS 3.8, writing assembler code that reads from a CTC adapter. I
will be running a "server" started task that should wait indefinitely
for a command from the "client" program on the other end of the CTC
link.
I'm having trouble finding the right way to wait indefinitely for the
other side to send data.
I'm using the EXCP macro to execute my channel program (just a simple
read command) on the CTC device. I do the EXCP, then I use the WAIT
macro on the associated ECB.
When the sender doesn't send anything, the WAIT ends after 1 minute and
the completion code in the high order byte of the ECB is 0x41. If I run
EXCP and WAIT again, the WAIT *immediately* returns and the high order
byte of the ECB is 0x48.
See the attached CTCREAD.0.txt for a job that demonstrates this.
That's not the behavior I want. Ideally I could WAIT, hit the 1 minute
timeout waiting for data, then just issue the READ again and WAIT
another minute. (Or just not timeout at all, in a perfect world.) I can
loop until I get a non-timeout completion. (Although...I suspect this
isn't quite right; I get an "IEA000I 502,IOE,02,9000,..." message on the
console for the timeout, which I wouldn't want accumulating every minute
over time.)
Alternatively, if I close the CTC DCB and open it again before the next
EXCP/WAIT, there's another one minute pause before timing out again.
This is closer to the desired behavior... but I feel like CLOSEing and
OPENing the CTC device each time through the "wait indefinitely for the
other side to send data" loop is wrong. (And I also suspect that the
read side sending the "read" command state to the other side of the link
every time when it's not actually issuing corresponding writes each time
will lead to problems.)
See the attached CTCREAD.1.txt for a job that demonstrates this
close/open approach. This suggests to me that there's some state I
should be able to clear to get the EXCP to really wait another minute
before timing out, without actually having to close and re-open the CTC
DCB.
The best approach I've been able to come up with so far is to not do a
READ in my "wait" loop, but to do a SENSE CCW on the CTC adapter. On the
sending side, I issue a CONTROL command through the CTC adapter before
doing the WRITE. On my receiving side, I put the EXCP that runs the
SENSE CCW in a loop with a 250ms pause (using STIMER macro). So if the
SENSE doesn't see the CONTROL command from the other side, I sleep for
250ms and check again. Once the SENSE gets the CONTROL command from the
other side, I can run the READ CCW and get data back.
This, so far, is the closest I've come to an ideal solution because it
doesn't cause any IO exceptions, either in my program or on the MVS
console.
However, I don't quite like it because I want to be able to use the WAIT
macro on an ECB list that include the CTC "read" wait along with some
other events. And with the 250ms spin loop, if the other side of the
link writes data 50ms into the loop iteration, it's unfortunate to delay
activity the remaining 200ms, and seeing the CPU time of the job slowly
increase over time while doing nothing due to the loop is...not
aesthetically pleasing.
SO... MY QUESTION... what is the correct way in MVS 3.8 to wait on
reading data from a CTC adapter that may come right away or may not come
for hours? Especially in the context of wanting that to be one of
several ECBs I'm waiting on with the WAIT ECBLIST=... form of the WAIT
macro?
Thank you,
Matthew
--
Regards,
Tom
[UK]
?
|
Silvio Losa