Hi Matthew,
I've done a lot of CCW programming of CTC devices over the years but unfortunately for this case the vast majority of it was in a VM environment.? In a virtual machine, I could write my own interrupt handlers and issue the CCWs using SIO and have 100% control over the device.? However, I did do some work with CTC adapters under MVS and VS1, using EXCP and WAIT but it wasn't anything meaningful; its sole purpose was to prove that I could get it to work.? And I did.
I originally posted the MVS-based CTC program on the H390-MVS group when it was still under the control of Yahoo Groups.? It was in the file section and it had a name like CTCASAMP.TXT or CTCAMVS.TXT or something like that.? For some reason, that post did not get migrated over here to groups.io in this forum or in the other MVS Turnkey forum.? Further, I cannot seem to find it here on my TK4 system.? I honestly don't know what happened to it.? Actually, I think I did this when I was still using TK3 long ago and so it might be there, if I still have that stuff.? It has been a long while.
However, I did find some 'CTC Notes' in my files, and I do recall some things that I discovered while trying to get those adapters to work on MVS, and combined with what I know of how CTCAs work in general, I think I can get you pointed in the right direction.
First of all, you don't want to issue a READ command and have it pending. Instead, you just want to have the device's DCB opened and everything initialized and ready to go, then just WAIT.? The ECB isn't tied to the device or the DCB; this is just one of your own ECBs. ? When the other side writes to the CTC, an attention interruption will be raised on the opposite side.? This attention will drive an interrupt handler and then it can post the WAIT.
After the WAIT is posted, your code can now issue the READ. It should be completed very quickly and you'll get a CSW with CE+DE if you chain the READ CCW with a NO-OP? X'03' CCW.? After that operation is completed you are free to go back and wait again, or attempt to write something to send back.? The other side would also be waiting for the next action and if you did write something back then the other side would also receive an attention and do a post and then issue READ.? I hope that makes sense.? But the main point is, you don't issue a read until you get an attention.
After receiving an attention, you could (optionally) issue a "Sense Command Byte" CCW (X'14'), to see what command the other side used to initiate the attention.? It could have issued a write.? Or it could have issued a Control CCW.? You can use the results of sense command byte (SCB) to determine how you want to handle the attention.? But something tickles my memory that in MVS the SCB value is placed into the UCB and you can examine that after the attention, thereby avoiding the extra hassle of issuing another EXCP to do the Sense Command Byte operation.? See below in the notes about UCB+23.
Ok with all of that laid out, here is the ugly part.? MVS? (and VS1 before it), do not present the attention to the application program.? Even though you have a DCB opened to the DDNAME with UNIT=xxx for the CTCA device, MVS won't give you the attention.? So what to do?? Turns out, you must establish the attention routine yourself.? I don't know if there is some official "MVS-way" of doing this, such as with IO appendages or some system macro that I don't know about (but I doubt it), so what I did was set up the attention routine myself.
The attention routine should be treated like an asynchronous exit.? It needs to be in page-fixed storage.? The exit gets control directly from the system i/o interrupt handler and it is treated as a subroutine of the interrupt handler.? You set up a base register quickly, examine the CSW in the IOB if you need to, and POST your ECB.? Then exit using BR 14.
What I can't remember is if I did a regular POST or if I did a 'branch entry to POST'.? I think it was branch entry though, because I doubt the system interruption handler would tolerate an SVC execution due to a regular POST.
To page-fix the storage for the exit, you could GETMAIN some storage in subpool 245 and move your exit code into that storage area.? What I did (because this wasnt anything serious) was just use ADDRSPC=REAL on the EXEC PGM=? JCL statement along with a small REGION size like 64K or whatever to make the program? run in fixed real storage that way.
Now there is one other problem to solve and this is where my notes come in.? The system doesn't know about your exit routine or how to locate it.? You have to tell it, manually.? Basically, you stuff the address of of a one word parameter list that contains the address of the entry point of your exit directly into the CTC's UCB.? To do all of this (to set the parm list exit address in the UCB and to use SP 245 storage) you need to be APF-authorized and both of these functions need storage key 0 access.? Here is what my notes say about getting the exit address set into the UCB:
???????? OPEN? (CTCA)
*
???????? MODESET KEY=ZERO,MODE=SUP
???????? LA??? R5,CTCAATTN????????? POINT TO ATTN EXIT PARM LIST
???????? L???? R6,CTCA+44????????????? GET DEB ADDRESS FROM DCB
???????? L???? R6,32(,R6)????????????? GET UCB ADDR FOR CTCA FROM DEB
???????? LA??? R6,0(,R6)?????????????? CLEAR THE HIGH ORDER BYTE R6
???????? ST??? R5,24(,R6)????????????? PUT PARM LIST ADDR IN UCB
CTCA???? DCB?? DDNAME=CTCA500,MACRF=(E),DSORG=PS
CTCAATTN DC? A(ATTNRTN)???? PARMLIST POINTS TO ATTN EXIT
.
.
ATTNRTN? DS? 0H
????????????????? BALR? R3,0
????????????????? USING *,R3
* UCB addr is in R7, can examine CSW or sense data in UCB
* UCB sense command code is at UCB+23
* UCB CSW status is at UCB+28
?????????????????? BR?? R14
I hope this helps you get started.? If there is way to access the old Yahoo group files that might be an option.? Feel free to ask questions if needed.? Good luck.
Regards,
Bob
