> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Rob Scott > Sent: Thursday, April 15, 2010 1:48 PM > To: [email protected] > Subject: Re: Internal (program) start of an STC - MGCRE vs. ASCRE > > ASCRE also has an option to have an exit taken when the > started address space terminates which can aid > communication/sync between your main STC and the aux STCs. > > Do you really need an ASID for each function? - Why not use a > TCB within the same STC ? > > > Rob Scott
This is "sort of" like the ftp client. When a client connects to ftp on z/OS, the ftp daemon fork()s another address space to do the function. What I am intending is similar. When a users does a "logon" to my application from a UNIX desktop, that will communicate to z/OS via TCPIP. This will be via a "personal daemon" (so to speak) or a "disconnected process". This will start an address space __for that user__ using z/OS UNIX BPX1SEC to establish an RACF environment. All futher communication will be between the "personal daemon" on the client and this specific STC. If another user does a "logon", it will start another STC. The "personal daemon" on the client talks to the "personal STC" on the mainframe. The user on the client talks to the "personal daemon" using AF_UNIX sockets. So the client talks to the "personal daemon" which talks to the z/OS "personal STC", which will then use ATTACH or POSIX threads (whichever I go with) to do the client function. This "multiplexes" th! e, possibly multiple, client requests over a single socket to a single STC. There is one thread which manages the socket and does all the thread starting of the client function as well as the TCPIP I/O. A very weird design. And I've likely not described it well as my thoughts are only beginning to jell as to how I do this. It would be something like: client>zos_login zos_id zos_user zos_password # connects to inetd or a server STC which starts another STC. # this STC uses BPX1SEC to change its racf identity to the one on the # command line. This is a "personal STC". # zos_login forks and "daemonizes" itself for this user. # it also sets up a AF_UNIX socket for communications. client>zos_function ... # this uses the AF_UNIX socket to talk to the "personal daemon". # the "personal daemon" starts POSIX thread for this function. # this POSIX thread talks to the initial thread to do its IP communictions # to the "personal STC". This thread does all the functions needed other than # TCPIP communications, which is done via the "personal daemon". I know I'm likely not saying this well at all. It's all very vague in my mind as to how to design it. This is for my own, personal, learning. It is unlikely to ever actually be written on the z/OS system. I am writing the UNIX code at home, on my own time. I will test it with by doing some sort of emulation of what I want the z/OS system to do. -- 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
