David - Thank you very much, your explanation has been most helpful. So my choices are: 1. Code a lot of wrappers so the C code can call the EZASMI macros 2. Change the ASM code to use BPX* calls
The amount of coding is probably about the same but choice 2 is preferable because we have a lot more customers using server 1. Thanks again! Robin -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Crayford Sent: 20 March 2015 17:22 To: [email protected] Subject: Re: Problems with takesocket in another ASID In the documentation for BPX1TAK it says: "The takesocket callable service used to be an MVS™ TCP/IP API, and was added to the z/OS UNIX callable services to allow migration of applications to a single library." The macro interface may seem attractive to assembler programmers because it's familiar. The USS callable services may be a little bit trickier to get your head around but I would always prefer them. The C/C++ runtime time is built on top of BPX* services so mixing C/C++ and assembler is never a problem. There is also lots of extra goodies in there like messages queues, mutexes etc. On 20/03/2015 6:01 PM, David Crayford wrote: > > > On 20/03/2015 4:31 PM, Robin Atwood wrote: >> We have done some digging into this problem. The crux is that server >> 1 (which we now want to do all the >> listening) is written in XL/C and server 2 (to which we want to pass >> certain sessions) is written in HLASM using EZASMI macros. I wrote a >> simple C program to do the >> takesocket() and that worked fine. This leads us to believe that the >> two socket libraries are incompatible. We took a component trace of >> TCPIP while attempting the givesocket/takesocket and what was >> conspicuous was that only the EZASMI socket calls had entries; there >> was no sign of the C givesocket. > > We had a similar problem with one of our products integrating into the > IMS connect address space. Our product was using EZASMI and IMS > connect was using z/OS UNIX systems services sockets. We replaced > EZASMI with BPX* services and it solved the issue. > >> So is the only solution to recode one of the servers so they are both >> in the same language or is there a simpler way to make them >> interoperate? I asked on IBMTCP-L and didn't get a response, so maybe >> one of you guys has some experience with this. It seems strange >> because normally in the IBM world you can write different modules in >> different languages and they work together seamlessly. Not with >> sockets, apparently. > > It's nothing to do with lanauges, it's the APIs that are inconsistent. > Change you assembler to use BPX1TAK > http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zo > s.r13.bpxb100/tak.htm > and you should be good to go. > There are lots of other reasons one might prefer USS such as AIO etc. > >> >> TIA >> Robin >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] >> On Behalf Of Rob Scott >> Sent: 11 March 2015 21:29 >> To: [email protected] >> Subject: Re: Problems with takesocket in another ASID >> >> I do not believe that you can use non-character data in the NAME or >> TASK values in GIVE/TAKESOCKET. >> >> Try using a test program with a single subtask with a known value - >> eg "TEST0001" >> >> Also ensure that the DOMAIN value is correct in your CLIENT structure >> is correct (for both give and take) and that the INITAPI calls are >> using the correct values. >> >> Rob Scott >> Lead Developer >> Rocket Software >> 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA >> Tel: +1.781.684.2305 >> Email: [email protected] >> Web: www.rocketsoftware.com >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] >> On Behalf Of Robin Atwood >> Sent: 11 March 2015 08:18 >> To: [email protected] >> Subject: Problems with takesocket in another ASID >> >> I searched the archives and found a very similar problem to mine in >> the thread >> https://listserv.ua.edu/cgi-bin/wa?A2=ind0606&L=IBM-MAIN&P=R34295&I=- >> 3&X=D02C315241E55CCC48&Y=abend922%40gmail.com&d=No+Match%3BMatch%3BMa >> tches back in 2006 and ably answered by Rob Scott. I seem to have a >> very similar problem. I am trying to convert a very ancient C module >> which listens for incoming connections and hands them off to a >> subtask in the same ASID. Now I want to handover the socket to >> another ASID so, following the above thread and the Sockets API >> manual, I changed the task name in the listener's client id to the >> jobname of the worker ASID and set the subtask name to blanks. I have >> also issued a >> getclientid() and set the task/subtask names in a system-wide >> Name/Token pair. In the worker ASID, which is written in assembler, I >> have picked up the N/T pair and inserted the value into a client id >> and issued takesocket(). The socket number is communicated via the >> code in a cross-memory post which wakes up the worker. Every time I >> get errno=113 (EBADF). I have tried setting the subtask name in the >> givesocket() to that used in the worker's INITAPI, but no difference. >> The client id from the listener looks like this: >> >> TAU0200I 13:35:12.736 Socket 1 received from MFADEV >> TAU0015I 13:39:06.296 Before call TAKESOCKET >> Address Offset Word 1 Word 2 Word 3 Word 4 Word 5 >> Word 6 Word 7 Word 8 * Storage Content * >> 1EA41614 00000000 00000002 D4C6C1C4 C5E54040 00000081 7F4E7D00 >> 00000000 00000000 00000000 *....MFADEV ...a"+'.............* >> 1EA41634 00000020 00000000 00000000 *......... * >> TAU0065I 13:43:21.612 After Call TAKESOCKET RC : FFFFFFFF >> ERRNO : 00000071 >> >> The task name is the jobname but the subtask name is binary. Is this >> acceptable? I tried zeroing it out but that didn’t help; setting it >> to blanks produced errno=121 (illegal argument). I seem to be doing >> what's described in the manual but it just won't work. Any pointers >> as to what I have missed? >> >> TIA >> Robin >> >> --------------------------------------------------------------------- >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO >> IBM-MAIN ================================ Rocket Software, Inc. and >> subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ >> +1 781.577.4321 Unsubscribe From Commercial Email – >> [email protected] Manage Your Subscription Preferences - >> http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFoote >> r_SubscriptionCenter.html >> Privacy Policy - >> http://www.rocketsoftware.com/company/legal/privacy-policy >> ================================ >> >> This communication and any attachments may contain confidential >> information of Rocket Software, Inc. All unauthorized use, disclosure >> or distribution is prohibited. If you are not the intended recipient, >> please notify Rocket Software immediately and destroy all copies of >> this communication. Thank you. >> >> --------------------------------------------------------------------- >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO >> IBM-MAIN >> >> --------------------------------------------------------------------- >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO >> IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
