开云体育

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Matthew Wilson
Sent: Friday, November 25, 2022 4:13 AM
To: [email protected]
Subject: [H390-MVS] How to wait indefinitely for a read on CTC device?

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