I don't grok why server 2 needs to be assembler. CEA services are
callable services so can be called in a HLL. If I were writing your
server I would write it all in C where the listener spawns a client
using spawn()
passing a socket descriptor that then acts like an ISPF server. I'm sure
that's how z/OSMF does it.
On 20/03/2015 9:43 PM, Robin Atwood wrote:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
