Chris, Removing the specific names is a good suggestion for debugging this problem - although personally I would put them back in again for "production" or GA.
As for the "musts" in my posts - I believe that if the optional NAME/TASK values are used then they *must* tally correctly as I outlined - you can of course omit them if you so wish. If removing the names does not fix the problem, we are not going to get too much further without seeing the actual EZASMI statements that Giovanni has used. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] http://www.rs.com/portfolio/mxi/ -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chris Mason Sent: 16 June 2006 09:30 To: [email protected] Subject: Re: Writing a Listener and receive the takesocket in other address space Rob and Giovanni, I've been watching this thread unravel. A dozen or so years ago when I was teaching myself C and socket programming I paraphrased the samples in the what is now the "z/OS Communications Server IP Sockets API Guide and Reference" manual. This included the 3 programs in what is now Appendix A of the manual, "Multitasking C socket sample program". This covers how to use getclientid(), givesocket() and takesocket(). Those are my credentials for jumping in. Incidentally, my rewrite of the programs worked just fine so I must have done it correctly. The samples use the C "Multitasking Facility" (MTF) calls so at first I thought it was not possible to have the programs "taking" the socket run in a different address space. However, the description of the givesocket() call specifically mentions running in another address space - actually it's more mentions running in the same address space as being special. Straight away however, there's a testing suggestion which is not to specify the address space at all in the clientid structure name field used in the givesocket() call so that any address space can "take" the socket. This description of the givesocket() call indicates that the subtaskname field should be blank. I realise that you are using EZASMI macros in assembler rather than the C calls and structures but I would expect the API to operate in much the same way with the same rules. Thus the field you call TASK I presume corresponds to the subtaskname field and I see from an earlier post that you set a name here. Could this be a problem? I also appreciate that you talk about changing the program from using a subtask so you've had something working already. Having mentioned the assembler interface I took a look at the descriptions there in order to see if they were much different. In essence they are not although, unlike with the C descriptions, there is talk of setting the subtask fields, although again, they can be left blank. So why run before you can walk? Why not remove all these unnecessary name checks while you are testing? Set the CLIENTID structure fields blank - except for 2 in the DOMAIN field for AF_INET, of course - for the GIVESOCKET macro. Now all you need to do is provide that correct DOMAIN, correct address space NAME and a blank TASK name in the CLIENTID structure used by the TAKESOCKET macro together with the correct socket number and it should work. Incidentally, Rob, the manual doesn't seem to agree with all the "musts" in your second post in this thread. Chris Mason ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
