It would be nice if BPX1ATM had something analogous to SHSPL= (or at least SZERO=YES), but you could code a work-around where the child posts the parent (or whoever the subpool owner is) to free the storage. Or if the parent could just free the storage after returning from BPX1WAT.
In article <000301d189b0$69a845a0$3cf8d0e0$@gmail.com> you wrote: > It seems I am not out of the woods yet. :( The kludge with BPX1MSD allowed > me to start more than one subtask as > POSIX(ON) and the server seemed to work flawlessly. The only problem came at > shutdown when the listener tried to > detach the worker task and got an abend 23E-08: TCB is not a subtask of the > caller. Of course, it was until it got turned > into a process by the SSL calls, or something similar. So I tried replacing > the ATTACH macro with a call to BPX1ATM and > removed the calls to BPX1MSD. Everything came up and seemed to be working > until I executed a transaction that > caused another (ATTACHed) subtask to do some PCs to another address-space. > The cross-memory part worked as usual > but when it was finished and the subtask attempted to release the storage > used, it got 378-14: storage not owned by > task. I seem to be plagued by problems of identity! This happens whether or > not any SSL calls have been made. Are there any known problems using PC > instructions and POSIX programs together? I am not sure how to proceed from > here, the BPX1MSD kludge seems to be the best solution if I can suppress the > abend in the ESTAE or something. > Thanks > Robin > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Don Poitras > Sent: 22 March 2016 19:01 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Linking C module with SSL > BPX1ATM returns the process id. You then use BPX1WAT to wait for the > process(es) to end. > In article <000301d18413$756bf730$6043e590$@gmail.com> you wrote: > > Using BPX1ATM it's not clear to me how you know if the subtask terminates. > > The ATTACH macro has an ECB and an exit routine available. > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of David Crayford > > Sent: 21 March 2016 20:13 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Linking C module with SSL > > I'm happy I've got you working but as I said it's a circumvention. > > Dons solution is the way to go. > > > On 21 Mar 2016, at 8:05 PM, Robin Atwood <abend...@gmail.com> wrote: > > > > > > I first tried David's suggestion of using BPX1MSD (because that was > > > quite > > > painless) and it worked! Each of my modules has a #pragma > > > runops(POSIX(ON)) and a call to BPX1MSD in their initialisation > > > routine. They are started one at a time and they all now come up and > > > the gsk calls still work. So, for the time being, I am back in business. > > > > > > Thanks > > > Robin > > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Poitras > > > Sent: 21 March 2016 18:35 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Linking C module with SSL > > > > > > It's for attaching a program as a new process. To z/OS, it just > > > looks like a new TCB that's a daughter of the caller. You can still > > > pass it an ECB and it can run POSIX(ON). I really think this is all > > > you need to do to get what you want. > > > > > > In article <001f01d18352$51d38a70$f57a9f50$@gmail.com> you wrote: > > >> Thanks for the suggestion. Looking at the doc BPX1ATM seems to be > > >> for attaching a TCB to a process, which is not our situation. We > > >> need to attach a TCB to a TCB and pass the new TCB an ECB in the usual > way. > > >> However, I will bear it in mind! > > > > > >> Thanks > > >> Robin > > > > > >> -----Original Message----- > > >> From: IBM Mainframe Discussion List > > >> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Poitras > > >> Sent: 18 March 2016 20:49 > > >> To: IBM-MAIN@LISTSERV.UA.EDU > > >> Subject: Re: Linking C module with SSL > > > > > >> Try using BPX1ATM (attach_execmvs) rather than ATTACH. > > > > > >> In article <000301d1810e$c20b22d0$46216870$@gmail.com> you wrote: > > >>> We have a lot of HLASM and XL/C modules doing > > >>> attach/wait/post/detach. The > > >> problem seems to be that the POSIX(ON) is not inherited by an > > >> attached subtask. Recoding to use threads and semaphores would > > >> effectively be rewriting the server - I'll think I'll leave that > > >> for the > > next generation! > > >> It's a bit poor that IBM's SSL implementation does not properly > > >> support traditional MVS programs; it's a part of TCP/IP, after all. > > >> I tried experimenting with BPX1SDD (set_dub_default) to make TCB's > > >> processes and threads but I still got the EDC5167I. > > > > > >>> Thanks > > >>> Robin > > > > > >>> -----Original Message----- > > >>> From: IBM Mainframe Discussion List > > >>> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford > > >>> Sent: 17 March 2016 21:18 > > >>> To: IBM-MAIN@LISTSERV.UA.EDU > > >>> Subject: Re: Linking C module with SSL > > > > > >>>> On 17/03/2016 10:05 PM, Robin Atwood wrote: > > >>>> Now I have hit the problem I thought might be lurking. The module > > >>>> I > > >> fixed before with the POSIX(ON) pragma is the listener. It attaches > > >> a number of worker tasks it givesockets an incoming session to. > > >> When the worker does its takesocket it must then do a > > >> gsk_secure_socket_open() to start the SSL handshake. This failed > > >> with a EDC5167I so I added the > > > POSIX(ON) pragma. > > >> Restarting, the STC immediately failed in a call to BPX1MSS, > > >> rc=156, rsn= 0D070201, which means: > > > > > >>> I take it you are attaching your subtasks using MVS services. That > > >>> won't > > >> happen if you use pthreads. > > > > > >>>> JRAlreadySigSetUp: BPX1MSS found the process already set up for > > >>>> signals > > >>>> Action: Only one task can be set up for signals at any one time. > > >>>> Issue the signal unset (BPX1MSD) service on the task that did the > > >>>> last setup and then reissue this service. > > >>>> > > >>>> So it seems I can only have POSIX(ON) in one TCB? That's a bit of > > >>>> a showstopper. :( > > >>>> > > >>>> Thanks > > >>>> Robin > > >>>> > > >>>> -----Original Message----- > > >>>> From: IBM Mainframe Discussion List > > >>>> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills > > >>>> Sent: 14 March 2016 21:24 > > >>>> To: IBM-MAIN@LISTSERV.UA.EDU > > >>>> Subject: Re: Linking C module with SSL > > >>>> > > >>>> Yup ... > > >>>> > > >>>> Be aware that changing to POSIX(ON) will introduce other subtle > > >>>> changes > > >> in behavior. For example, fopen()'s decision on what is a legacy > > >> dataset and what is a UNIX file changes. I was surprised to see > > >> that DD:SYSPRINT was now the name of a new UNIX file and happily > > >> created it > > > under /u/! Really. > > >>>> > > >>>>> Is this telling me SSL can only be used under USS? > > >>>> Yes, but realize that USS is z/OS, and you can have a program > > >>>> that runs > > >> from conventional JCL and looks externally like it could have been > > >> written in 1970 that in fact "runs under USS." > > >>>> > > >>>> Charles > > >>>> > > >>>> -----Original Message----- > > >>>> From: IBM Mainframe Discussion List > > >>>> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robin Atwood > > >>>> Sent: Monday, March 14, 2016 2:40 AM > > >>>> To: IBM-MAIN@LISTSERV.UA.EDU > > >>>> Subject: Re: Linking C module with SSL > > >>>> > > >>>> Thanks. I had just spotted Charles's post back in 2012 with the > > >>>> same problem and used a pragma. Now the init function fails with > > >>>> 202 (KEYRING OPEN ERROR) but that looks like an admin problem. :) -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637 Cary, NC 27513 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
