We have two servers because of execs who are over-keen on M&A. I am supposed to somehow weld them together so users only need set one port. We are going to write a minimal test-bed using BPX and see how it goes. Server 1 does file transfer and server 2 runs ISPF sessions using CEA technology, so they are very different beasts best kept far apart.
Robin -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Crayford Sent: 20 March 2015 19:49 To: [email protected] Subject: Re: Problems with takesocket in another ASID On 20/03/2015 8:02 PM, Robin Atwood wrote: > 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. I don't think option 1 is a starter. You've got two TCP/IP servers for some reason so writing C wrappers doesn't make any sense. But then again I don't understand your architecture. Why do you have two servers? I would need to understand the use cases before I can give an opinion. If you need to write the listener in C why not just use threads which are serviced by assembler routines for the use cases where you need to use assembler rather than passing socket descriptors to seperate address spaces? > 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.z >> o >> 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%3BM >>> a 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/GlobalSubscriptionManagementEmailFoot >>> e >>> 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 ---------------------------------------------------------------------- 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
