|
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
|
Hi Matthew,
Being the author of the Hercules CTCE device supporting real CTCA's (even Ficon CTCA's), I must however admit that I've never written any programs performing communications using CTCA's, and I do not know how to do that. Not under MVS - z/OS or VM - z/VM. All I ever tested were these operating systems using CTCE CTCA's, including VTAM (MPC and non-MPC), RSCS CTCA links, NJE links, z/VM SSI ISFC links, MVS GRS connections, and even z/OS XCF links (like for Base Sysplex). The CTCA channel programs I've thus come across, seem mighty complex to me, but they all appeared to be working fine. There is even automatic recovery after some TCP/IP hiccups, most of the times.
Sorry that I am unable to help you further, but I hope you find support from others who know how to do the things you want to achieve.
Cheers,
Peter
|
Hello Matthew, Many years ago I contacted Shelby Beach who uses CTC in their DDT debug tool. In the reader part of the tool a CCW is issued using a C3 command code with a data length of 1. No sure what this does but it may be a solution to your problem, or just a red herring :-) ?FYI Have you a copy of the CTC manual? IBM System/370 Special Feature
Description: Channel-to-Channel Adapter?which can be found on bitsavers.
Hope this is of some use !
Regards,
Martin.
|
This reference may be useful for the C3 code etc
Regards,
Tom Bottomley
toggle quoted message
Show quoted text
Hello Matthew,
Many years ago I contacted Shelby Beach who uses CTC in their DDT debug tool. In the reader part of the tool a CCW is issued using a C3 command code with a data length of 1. No sure what this does but it may be a solution to your problem, or just a red herring
:-) ?FYI Have you a copy of the CTC manual? IBM System/370 Special Feature
Description: Channel-to-Channel Adapter?which can be found on bitsavers.
Hope this is of some use !
Regards,
Martin.
-- Regards, Tom [UK]
|
[...] This reference may be useful for the C3 code etc
channel-channel-ctc-adapters Wow. I didn't know a CTC device hexadecimal CCW opcode could be registered as a trademark! Really, IBM?! :) -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
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
|
Bob, I have copies of the files from most of the MVS groups but I won¡¯t be able to access them for a week. Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Bob Polmanter
Sent: 25 November 2022 20:42
To: [email protected]
Subject: Re: [H390-MVS] How to wait indefinitely for a read on CTC device?? 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
|
When doing communications, I used to use a Twait or Waitt macro. I don't remember which. Either way it waited on multiple ecb's. That way of I wanted to end the program I just post the correct ecb and it did clean up and went to EOJ.
toggle quoted message
Show quoted text
-----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
|
On 11.25.2022 08:09, Martin Taylor via groups.io wrote: Many years ago I contacted Shelby Beach who uses CTC in their DDT debug
tool. In the reader part of the tool a CCW is issued using a C3 command
code with a data length of 1. No sure what this does but it may be a
solution to your problem, or just a red herring :-) ?FYI Have you a
copy of the CTC manual *IBM System/370 Special Feature* *Description:
Channel-to-Channel Adapter* which can be found on bitsavers. Ah, interesting. C3 is a no-op, but it has a side-effect of disabling compatibility mode on the adapter, putting it into extended mode. Extended mode, among other things, looks like it enables some additional status bits and generates -- and requires handling of -- an attention interrupt when a command is first received from the other side. The attention interrupt is interesting in that it sounds like that aligns with Bob's message about waiting on the interrupt... Thanks, Matthew
|
Hi Bob, Thank you for your extensive reply. On 11.25.2022 12:42, Bob Polmanter wrote: 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. Off-list, Rene Ferland sent me a file he found from one of the old Yahoo files sections, CTCAMAIN.VS1.txt. I'm not sure if this was your code, but from what I can see from a brief scroll through it, it does match much of what you describe from your notes. 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. Yes, I think waiting for the attention interruption is the correct approach. Alas, I couldn't find a way for programs running under MVS to easily wait for an attention on a device... 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. ...and it sounds like I couldn't find a way because MVS doesn't make it easy! ? 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. This definitely gets into areas I haven't touched before... lots of quality time reading through more PDFs on Bitsavers looks to be in my future. I think you've given me the information I need to navigate through learning all the right pieces to accomplish what I want. 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. The code you provided from your notes looks similar to code in the file Rene found (attached to this message), so I think it should give me a good example. Thank you again for your extensive reply. I'll have to leave my delay/sense-polling in place for now while I learn enough to make sense of some of these details, but this does appear to be the answer. Thanks, Matthew
|
Hi Matthew,
Yes, this is the program!?? Thanks Rene for locating it and making it available.?? I sure thought it was an MVS version though.? Still, odds are this would run on MVS with little to no changes.
After reviewing the code, some things you should know.? This was run on VS1 running as a guest of VM/370.? Hence the DIAG08 subroutine and the CP commands that it issues; you can ignore all that stuff.? I did recall correctly about the system providing the SCB data, the command code byte that was issued by the other side.? It is in the UCB, and I can see this code checking to see if the other side issued a read or a write CCW.? This version doesn't answer the question of the type of POST; in the VS1 code I cheated by turning off the wait bit in the RB.? I don't that that would fly in MVS.
You should also know that the "other side" of this program was a virtual machine running CMS.? The CMS application would communicate with this CTCA code via a 'virtual CTCA'.? If you're not familiar with VM, a virtual CTCA is a software implementation of real CTCA hardware, and it acts and functions just like a real one and you drive it exactly the same way.
This code was a prototype for an idea to enable a CMS user to read a PDS or delete a dataset or issue a message to the console; the request would be sent over CTC to VS1 and the actual work was done on the VS1 side.? Unfortunately, all of that extra stuff muddies the waters for want you really want in order to pick out the CTC portions of the code.
I still feel like I have an MVS CTCA program around somewhere; if I find it I'll be sure to make it available.
Regards,
Bob
|
Hi Bob, On 11.25.2022 15:12, Bob Polmanter wrote: Yes, this is the program!?? Thanks Rene for locating it and making it
available.?? I sure thought it was an MVS version though.? Still, odds
are this would run on MVS with little to no changes.
After reviewing the code, some things you should know.? This was run on
VS1 running as a guest of VM/370.? Hence the DIAG08 subroutine and the
CP commands that it issues; you can ignore all that stuff. Yep, I saw the DIAG08 and thought... aha! This must have been VS1 running under VM! You should also know that the "other side" of this program was a
virtual machine running CMS.? The CMS application would communicate
with this CTCA code via a 'virtual CTCA'.? If you're not familiar with
VM, a virtual CTCA is a software implementation of real CTCA hardware,
and it acts and functions just like a real one and you drive it exactly
the same way. In a way, that's somewhat like what I'm prototyping. While I've done MVS<->MVS/Hercules<->Hercules to do some initial programming to make sure I understand the basics of writing CTCA code, the project I'm working on is MVS in Hercules on one side, but an application I'm running on my host system on the other side. I've read through Hercules' CTC implementation enough to piece together the struct that's serialized and sent over the wire, the handshake protocol in Spinhawk-and-later, etc., so I have a program written in Go running on my computer which sends a command to my program running under MVS and receives data back from the MVS program and displays it. Same approach that Shelby's MVSDDT tool (which of course has been invaluable in debugging my usually-broken assembler code!) uses from what I can tell, but using the "CTCE" support instead of the original CTCT. Working to demonstrate the possibilities of client/server programming against servers running inside MVS that work all the way back with Hercules 3.13 that's included as a binary package in some Linux distros (although 3.13 and Spinhawk-and-later made changes/improvements to the CTC code, so I have accounted for the differences on my side to support 3.13 through SDL-Hyperion). I still feel like I have an MVS CTCA program around somewhere; if I
find it I'll be sure to make it available. If you happen to find it I'm sure it'd be helpful, but otherwise you've given me plenty to try to find a path through. Thanks! -Matthew
|
So i've been following this thread with some curiosity ... Looking at the CTCA for S/370 (the one that would've been used with MVS 3.8J) ...
It seems you need to do an SIO on the receiving side (channel Y) to clear the mandatory attention interrupt generated by the first command from the sending (channel X) side. Also, have a look at "operation sequences" on pp 7-8...? They seem to indicated synchronous operation of the adapter (write on channel x must be accompanied by read on channel Y)...
Joe
On Fri, Nov 25, 2022 at 4:32 PM Matthew Wilson < mwilson@...> wrote: Hi Bob,
Thank you for your extensive reply.
On 11.25.2022 12:42, Bob Polmanter wrote:
>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 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.
Off-list, Rene Ferland sent me a file he found from one of the old Yahoo
files sections, CTCAMAIN.VS1.txt. I'm not sure if this was your code,
but from what I can see from a brief scroll through it, it does match
much of what you describe from your notes.
>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.
Yes, I think waiting for the attention interruption is the correct
approach. Alas, I couldn't find a way for programs running under MVS to
easily wait for an attention on a device...
>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.
...and it sounds like I couldn't find a way because MVS doesn't make it
easy!
>? 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.
This definitely gets into areas I haven't touched before... lots of
quality time reading through more PDFs on Bitsavers looks to be in my
future. I think you've given me the information I need to navigate
through learning all the right pieces to accomplish what I want.
>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.
The code you provided from your notes looks similar to code in the file
Rene found (attached to this message), so I think it should give me a
good example.
Thank you again for your extensive reply. I'll have to leave my
delay/sense-polling in place for now while I learn enough to make sense
of some of these details, but this does appear to be the answer.
Thanks,
Matthew
|
Hi Joe, On 11.25.2022 18:33, Joe Monk wrote: So i've been following this thread with some curiosity ... Looking at the
CTCA for S/370 (the one that would've been used with MVS 3.8J) ...
[image: image.png]
It seems you need to do an SIO on the receiving side (channel Y) to clear
the mandatory attention interrupt generated by the first command from the
sending (channel X) side. Also, have a look at "operation sequences" on pp
7-8... They seem to indicated synchronous operation of the adapter (write
on channel x must be accompanied by read on channel Y)... Yep... as for the SIO, that's taken care of my MVS itself. I can't exactly run an SIO instruction directly from a problem state program, but I'm successfully communicating over the CTCA from my code by running channel programs with EXCP. And yes, the operations do need to be "in sync" on both sides or things go downhill very quickly. Until I get the interruption-detection stuff working, I'm faking it with my SENSE+delay loop. The SENSE command is one command you can run on the CTCA *without* a matching command on the other side of the link, BUT if the other side of the link sends a CONTROL command, the SENSE command ends up satisfying it. So you can end up doing either a simple "CONTROL + WRITE" with a SENSE on the other side to detect when to read, or "CONTROL + READ" if you want to SENSE on the other side to determine when to do your write. The SENSE command is special in that it doesn't affect the CTCA state unless there's a command pending for it to read. Yep the old doc from '72 has been critical. The Hercules source code also references a newer CTC Adapter doc that I was able to find in BookManager format that has more details about the state of the adapters on each end of a connection (section 2.13 in SA22-7203-00 or section 2.13 in SA22-7203-00). Thanks, Matthew
|
Hi Bob,
I appreciated much your post. Even if I was doing a lot of EXCP programming over the years I could learn something new in this area.
I'm currently working on an MVS Front-End Application that runs in Windows and communicates via IP to an MVS 3.8 that is running under Hercules. For the discussed topic I found another simple way of getting around. In the Assembler Server program that runs in MVS I need to know if the peer (The front-end program in Windows) is ready to communicate. So I check if the peer has initialized a 'Read' operation. I can check this by repeatedly (every 5 seconds) issuing a Sense command to the CTC. If the 'other' side has issued a read I get a x'02' response with means that the peer has issued a read and is read to communicate. To overcome running in timeouts with outstanding reads I send an 'Alive' packet every 5 seconds when there is no other useful activity.?
Now some consideration about communicating with a program running in Windows that uses IP and 'plays' the role of a peer to the Hercules emulation that transfers the request to another side over IP. In the MVS Assembler program I'm running on a 'real' device and can of course use any CCW commands that are acceptable for CTC's. On the other hand in the Windows side I have no possibility to? issue real CCW command like Sense. I can only send or receive data over IP. In a case where you communicate to a real CTC peer you can do it with only one MVS device address for an exchange in both directions. But since in Windows I can do only send and receives without the possibility to 'see' if the peer is in a Read or whatever state you need to use two MVS device addresses. Over one address you send (Write Command x'01') to the Windows program and on the other address your receive (Read Command x'02') messages from Windows. It seems that the same approach has been used in the MVS-DDT tool but the source code is not available to see how it was really done. Anyway so far it works fine.?
As soon as I'm finished with my 'exercise' and corrected the last bugs I can gladly publish the source code here. Watch this space....
|
You might find this guide handy ...
Joe
Hi Bob,
I appreciated much your post. Even if I was doing a lot of EXCP programming over the years I could learn something new in this area.
I'm currently working on an MVS Front-End Application that runs in Windows and communicates via IP to an MVS 3.8 that is running under Hercules. For the discussed topic I found another simple way of getting around. In the Assembler Server program that runs in MVS I need to know if the peer (The front-end program in Windows) is ready to communicate. So I check if the peer has initialized a 'Read' operation. I can check this by repeatedly (every 5 seconds) issuing a Sense command to the CTC. If the 'other' side has issued a read I get a x'02' response with means that the peer has issued a read and is read to communicate. To overcome running in timeouts with outstanding reads I send an 'Alive' packet every 5 seconds when there is no other useful activity.?
Now some consideration about communicating with a program running in Windows that uses IP and 'plays' the role of a peer to the Hercules emulation that transfers the request to another side over IP. In the MVS Assembler program I'm running on a 'real' device and can of course use any CCW commands that are acceptable for CTC's. On the other hand in the Windows side I have no possibility to? issue real CCW command like Sense. I can only send or receive data over IP. In a case where you communicate to a real CTC peer you can do it with only one MVS device address for an exchange in both directions. But since in Windows I can do only send and receives without the possibility to 'see' if the peer is in a Read or whatever state you need to use two MVS device addresses. Over one address you send (Write Command x'01') to the Windows program and on the other address your receive (Read Command x'02') messages from Windows. It seems that the same approach has been used in the MVS-DDT tool but the source code is not available to see how it was really done. Anyway so far it works fine.?
As soon as I'm finished with my 'exercise' and corrected the last bugs I can gladly publish the source code here. Watch this space....
|
Sorry for the noise ... wrong link in the other mail.
Joe
Hi Bob,
I appreciated much your post. Even if I was doing a lot of EXCP programming over the years I could learn something new in this area.
I'm currently working on an MVS Front-End Application that runs in Windows and communicates via IP to an MVS 3.8 that is running under Hercules. For the discussed topic I found another simple way of getting around. In the Assembler Server program that runs in MVS I need to know if the peer (The front-end program in Windows) is ready to communicate. So I check if the peer has initialized a 'Read' operation. I can check this by repeatedly (every 5 seconds) issuing a Sense command to the CTC. If the 'other' side has issued a read I get a x'02' response with means that the peer has issued a read and is read to communicate. To overcome running in timeouts with outstanding reads I send an 'Alive' packet every 5 seconds when there is no other useful activity.?
Now some consideration about communicating with a program running in Windows that uses IP and 'plays' the role of a peer to the Hercules emulation that transfers the request to another side over IP. In the MVS Assembler program I'm running on a 'real' device and can of course use any CCW commands that are acceptable for CTC's. On the other hand in the Windows side I have no possibility to? issue real CCW command like Sense. I can only send or receive data over IP. In a case where you communicate to a real CTC peer you can do it with only one MVS device address for an exchange in both directions. But since in Windows I can do only send and receives without the possibility to 'see' if the peer is in a Read or whatever state you need to use two MVS device addresses. Over one address you send (Write Command x'01') to the Windows program and on the other address your receive (Read Command x'02') messages from Windows. It seems that the same approach has been used in the MVS-DDT tool but the source code is not available to see how it was really done. Anyway so far it works fine.?
As soon as I'm finished with my 'exercise' and corrected the last bugs I can gladly publish the source code here. Watch this space....
|
Hi Silvio,
You might consider using two CTC devices in your application (rereading your post it seems you may have come to that conclusion as well).? Each CTC would operate in one direction only.? So for example, from the MVS side one CTC would only be used for issuing writes, and the other CTC would only be used for issuing reads.? Correspondingly on the Windows side, it would be the opposite.? The CTC that MVS is only writing to would be read-only for Windows, and the CTC that MVS is only reading from would be write-only for Windows.
In this way, you do not need to worry about a direction change and there is no need to issue any sense or control CCWs from either side.
This technique is used in more advanced operating systems, in VTAM for one example, using a pair of CTCs to communicate with another VTAM host.?? MVS DDT also uses two CTCs but I do not know for certain that DDT is in fact using this technique.
Regards,
Bob
|
Good thinking...except that VTAM, at least at the version 3 level, does not use a pair of CTCAs for a given honey. One is all it uses for bidirectional communications.
On Mon, Feb 20, 2023 at 10:41 AM Bob Polmanter < wably@...> wrote: Hi Silvio,
You might consider using two CTC devices in your application (rereading your post it seems you may have come to that conclusion as well).? Each CTC would operate in one direction only.? So for example, from the MVS side one CTC would only be used for issuing writes, and the other CTC would only be used for issuing reads.? Correspondingly on the Windows side, it would be the opposite.? The CTC that MVS is only writing to would be read-only for Windows, and the CTC that MVS is only reading from would be write-only for Windows.
In this way, you do not need to worry about a direction change and there is no need to issue any sense or control CCWs from either side.
This technique is used in more advanced operating systems, in VTAM for one example, using a pair of CTCs to communicate with another VTAM host.?? MVS DDT also uses two CTCs but I do not know for certain that DDT is in fact using this technique.
Regards,
Bob
|
"a given honey"??! What kind of a typo is that? What I meant to say is that it only uses one CTC connection for bidirectional communications with another host.
On Mon, Feb 20, 2023 at 11:31 AM Jay Maynard via <jaymaynard= [email protected]> wrote: Good thinking...except that VTAM, at least at the version 3 level, does not use a pair of CTCAs for a given honey. One is all it uses for bidirectional communications.
On Mon, Feb 20, 2023 at 10:41 AM Bob Polmanter < wably@...> wrote: Hi Silvio,
You might consider using two CTC devices in your application (rereading your post it seems you may have come to that conclusion as well).? Each CTC would operate in one direction only.? So for example, from the MVS side one CTC would only be used for issuing writes, and the other CTC would only be used for issuing reads.? Correspondingly on the Windows side, it would be the opposite.? The CTC that MVS is only writing to would be read-only for Windows, and the CTC that MVS is only reading from would be write-only for Windows.
In this way, you do not need to worry about a direction change and there is no need to issue any sense or control CCWs from either side.
This technique is used in more advanced operating systems, in VTAM for one example, using a pair of CTCs to communicate with another VTAM host.?? MVS DDT also uses two CTCs but I do not know for certain that DDT is in fact using this technique.
Regards,
Bob
--
|
Peter Jansen
Silvio Losa