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.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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
