That's a thought. I guess I could then also shut down properly by using an ESTAE to trap abends. Or ATTACH'ing the user's program for even more isolation from them. Makes my system "more difficult" to use and not as "intuitive" to most programmers.
-- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [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 > -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] On Behalf Of Binyamin Dissen > Sent: Thursday, March 17, 2011 3:54 PM > To: [email protected] > Subject: Re: "how to" - designing an infrastructure > > Much simpler to have the JCL invoke your program passing the > name of the > client program as a parm. > > On Thu, 17 Mar 2011 15:28:54 -0500 "McKown, John" > <[email protected]> wrote: > > :>This is a "how to" type question for a z/OS application > infrastructure that I'm considering designing. That means the > code is not special in way. Runs key 8, non-APF authorized, > does not require LE but needs to be usable in an LE > environment. Not asking much am I? It is to simplify doing > some I/O for HLASM programmers. Now, I know that to be > "complete", it would need to be able to set up things like a > RESMGR and other ways to shutdown gracefully if the > application ABENDs or even just terminates with an SVC 3. I'm > going to ignore that for now. I'll suffer some efficiency > decrease by using unblocked, unbuffered I/O for the files. It > is supposed to be for low I/O activity files, not reports or > master files. > :> > :>The code should initialize itself upon the first call. OK, > this is not really too hard. It should shut itself down when > the jobstep TCB terminates, but not before. Hum, a bit > harder. What I'm thinking of doing is having the > initialization code do TCB chain chasing to find the JSTCB > (easy), then grab the TCBFSA and replace the saved R14 in the > first save area with my shutdown code (while saving the > original R14). So if the first RB on the JSTCB terminates by > doing a BR R14 (like with a RETURN), then my shutdown code > would get control. I think this is reasonable. What do the > wise old ones here me (I'm an old one, but not so wise). > :> > :>Another difficult part is efficiency. I want my routines to > be "dynamic" in that I don't want them to be linked (bound) > into the user's application. But I don't want the overhead of > a lot of LINK invocations. Now, I guess this means that I > could have a stub bound to the user's code. My macros would > vector to the stub which would do a LOAD if necessary, then > do a BASSM to actually go to my code (in order to be > AMODE/RMODE agnostic). Again, does this sound reasonable? > :> > :>I plan to "anchor" things using a home address space level > name token. I plan to write the code to be pure (non-self > modifying), and threadsafe. This is definitely at the leading > edge of my talents. Or maybe a bit beyond. > :> > :>Am I missing something already? > :> > :>John McKown > :>Systems Engineer IV > :>IT > :> > :>Administrative Services Group > :> > :>HealthMarkets(r) > :> > :>9151 Boulevard 26 * N. Richland Hills * TX 76010 > :>(817) 255-3225 phone * > :>[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 > > -- > Binyamin Dissen <[email protected]> > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > >
