>>I don't think I can use a single STC because I want the STC to service >>multiple users, each with their own RACF security environment (different z/OS >>RACF ids).
This is possible within z/OS and exactly why the TCBSENV field exists. Rob Scott Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of McKown, John Sent: 16 April 2010 13:40 To: [email protected] Subject: Re: Internal (program) start of an STC - MGCRE vs. ASCRE > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Hunkeler Peter (KIUP 4) > Sent: Friday, April 16, 2010 1:32 AM > To: [email protected] > Subject: Re: Internal (program) start of an STC - MGCRE vs. ASCRE > > I admit I'm haven't completely understood what you want to do, but.... > > o Why bother writing a listener by yourself if you can > take advantage of inetd. From what I understood, it > does what you need: Start a new process for each new > "login". Yes inetd does that. So why bother to "roll my own"? Because I believe that some reactionary shops don't like z/OS UNIX System Services and I'm considering pandering to them. I know that I'm the only sysprog here who has any knowledge of, or liking for, UNIX stuff. The others mutter under their breaths when confronted with it. For instance, they hate having a config file in /etc instead of SYS1.PARMLIB or some other PDS and complain bitterly about "idiot designers" who use UNIX services or files. If I use inetd, then my application must be a UNIX application - residing in a UNIX subdirectory and not a "legacy" application, residing in a PDS[E]. Again, pandering to the "anti UNIX" forces. Fully using UNIX would make this much easier to write. > > o Why do you need another fork() of your "login process" > and have it daemonize itself? Do you really need two > *independent* processes for each client that has logged > in? This is on the "client" end. The user enters a "logon" command to establish communications to the z/OS system. Once validated, I want a non-terminal process active to talk to the z/OS process. That is why I "daemonize" on the client. In order to free up and be independant of the shell command. I am probably using the wrong terminology. And I don't want a single process for all users, but a separate process for each user which is initiated by the "logon" command. > > Taking up your "ftp picture": > the "ftp client" process started by the ftpd is not a > daemon as I understand it. It is simply one end of > the ftp connection. True. My poor choice of description. > > o I thought that AF_UNIX is for connections *within" a > single instance of UNIX. Would you need this to > communicate between the two server side processes? Between two client side (desktop) processes. The client "login" command fork()s after validation in order to not tie up the command prompt as well as be independant of it (like running something "nohup command &" is "detached" from the command line, kinda, sorta). This process becomes a "communications channel" to the process, which was started from inetd or my own "listener", running on z/OS system. Now, I need a way to talk from another client command to this "communications channel" "daemon". I will use AF_UNIX to talk from the "command line command" to the "personal daemon", which is simply a relay to the z/OS process. I fear that I'm still not making sense, but it's because I can't think of the proper terminology. What I'm trying to avoid is starting another z/OS address space for each client command. I don't think I can use a single STC because I want the STC to service multiple users, each with their own RACF security environment (different z/OS RACF ids). > > -- > Peter Hunkeler > CREDIT SUISSE AG If I ever get something really designed, I may be able to better explain what I'm trying to do. For now, I was just wanting to know which technique to use: ASCRE or MGCRE START if I write my own "listener" instead of using inetd. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
