Hi Michael, The key point to a concurrent server is that once a socket has been obtained in the maintask, that this is the socket used for all TYPE=ACCEPT calls from then on. So the S= parameter should just keep pointing to the same halfword in your storage. Never change this value. Just leave it alone. Note that the socket number comes back in the RETCODE field from TYPE=SOCKET. This field is a fullword. You should just save the low order halfword for use later in your TYPE=BIND, TYPE=LISTEN and TYPE=ACCEPT calls.
I suggest you use http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D490/3.3.12.1 ?SHELF=f1a1bkc0&DT=20100609053923 for reference. Quite clearly it says that NAME= on the TYPE=ACCEPT is an output parameter. Its use is to tell you who just connected to your server. You can do whatever you wish with this information but you don't have to do anything if you don't want to. Here are some hints vis-à-vis EZASMI socket programming: -- Be sure you have specified APITYPE=3 on the INTIAPI call and LEAVE ALL SOCKETS AS BLOCKING (the default). You will be substituting asynchronous execution for non-blocking sockets. -- Always move a fresh TYPE=L form of EZASMI to your work area before each call. Then point to this area with your TYPE=(E,xxxxx) call. Have a separate area for each EZASMI macro. Don't ask me why this is important, but my experience says do this. Easy enough to do. -- As with the MF=L, have a separate 104 byte area for each asynchronous call. Note that since you are using APITYPE=3, you must include the ECB= on all EZASMI calls when the manual says you can. TCP/IP doesn't let you mix and match synchronous and asynchronous macro invocations. -- As soon as each asynchronous EZASMI macro completes, clear the 104 byte ECB area to zeros and handle the completing event. -- When a TYPE=ACCEPT completes and RETCODE is > 0, save this value because you are going to use it in your next macro which will be TYPE=GIVESOCKET. Be careful because RETCODE from TYPE=ACCEPT is a fullword and you only want the low order halfword for TYPE=GIVESOCKET and TYPE=CLOSE -- Once you have given this new socket to a subtask, you will issue a TYPE=CLOSE specifying this socket number. -- Now you can re-issue the TYPE=ACCEPT again using the exact same S= area that you used the first time. Since the accept is asynchronous you won't "hang" in it, but the ECB won't be posted until another connection comes in from the network. Hence your STIMERM. I would not have your STIMERM exit post the same ECB that TCP/IP is going to post. A different ECB and a WAIT on an ECBLIST is the way to do it. I do this all the time so I know it works. Hope at least some of this helps. I may think of some more things that I want to say and I'll post these later. I'm assuming there is some reason you need to be authorized because you said that you used TESTAUTH for debugging. Be careful: TCP/IP validates your storage areas against the TCBPKF field (which will always be 8 upon entry to your program). It should validate these areas against the protect key you are in at the time of issuing the EZASMI macro, but it doesn't. So if you enter key 0, be sure you set TCBPKF to zero before issuing TYPE=INITAPI. Andy Coburn -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Micheal Butz Sent: Sunday, April 01, 2012 12:58 PM To: [email protected] Subject: Debugging EZASMI Hi, I am trying to debug a TCP/IP server as a template I am using the following flow chart from a document by Tony Thigpen http://dinomasters.com/coolstuff/2004EZA.pdf My Client is a Windows MFC C++ program I have multiple connections going as per the document The accept macro I have coded to accept the connection Does not have any value for the second parameter to the socket name, the doc says this a input parameter ">>__EZASMI__TYPE=ACCEPT__,S__=__ _number___ __,NAME__=__ _address__ _____> S Input parameter. A value or the address of a halfword binary number specifying the descriptor of the socket from which the connection is accepted" For the first connection Select and subsequent Accept work and I am able to have a subtask do the work read/write On the second connection the Accept hangs TCP/IP does not post the ECB I have been debugging the Assembler started task under TSO TESTAUTH I have also coded a STIMERM exit to POST the TCP/IP ecb however when code reaches the STIMERM exit I get abend 138 which according to the doc is totally off base (having to do with global resource serialization So in summation I have 2 questions . Using the document flow below for action 4 would the accept macro in this case need a value for the socket . Would anyone have a idea would I would be getting a abend code 138 at entry to the STIMERM exit thanks ---------------------------------------------------------------------- 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
