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.zos.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%3BMatches
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/GlobalSubscriptionManagementEmailFooter_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
