BPX1ATM returns the process id. You then use BPX1WAT to wait for the process(es) to end.
In article <[email protected]> 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:[email protected]] On > Behalf Of David Crayford > Sent: 21 March 2016 20:13 > To: [email protected] > 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 <[email protected]> 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:[email protected]] > > On Behalf Of Don Poitras > > Sent: 21 March 2016 18:35 > > To: [email protected] > > 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 <[email protected]> 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:[email protected]] > >> On Behalf Of Don Poitras > >> Sent: 18 March 2016 20:49 > >> To: [email protected] > >> Subject: Re: Linking C module with SSL > > > >> Try using BPX1ATM (attach_execmvs) rather than ATTACH. > > > >> In article <[email protected]> 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:[email protected]] On Behalf Of David Crayford > >>> Sent: 17 March 2016 21:18 > >>> To: [email protected] > >>> 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:[email protected]] On Behalf Of Charles Mills > >>>> Sent: 14 March 2016 21:24 > >>>> To: [email protected] > >>>> 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:[email protected]] On Behalf Of Robin Atwood > >>>> Sent: Monday, March 14, 2016 2:40 AM > >>>> To: [email protected] > >>>> 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 > >> [email protected] (919) 531-5637 Cary, NC 27513 -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive [email protected] (919) 531-5637 Cary, NC 27513 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
