On 3/17/2011 2:28 PM, McKown, John 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.
I'm guessing this is related to the earlier thread about putting out simple debugging messages using some mechanism instead of WTO, is that right? I'm curious as to why you want to "simplify doing some I/O for HLASM programmers". Why not teach them the fundamentals of DCB, OPEN, CLOSE, PUT, even SYNAD with a user abend code? I mean they are Assembler programmers, right? This should be part of their kit. In our intro to Assembler class we don't teach WTO, we teach basic save area linkages and fundamental IO concepts. That and more fits into day one. So how much harder is it to suggest they provide an extra output file for debugging messages? [I also like Kirk's suggestion of using a call to bpx1wrt for this purpose.]
Now, I know that to be "complete", it would needto be able to set up things like a RESMGR and other ways toshutdown 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.
So your HLASM programmers will need to know CALL? Or are you building in some macro that does a CALL under the covers?
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).
OK, so this _is_ more than just debugging messages. But it seems an awful lot like "LE-lite", but it has to be able to run under LE.
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?
Relative to what? I must admit I'm completely in the dark as to the purpose of this "z/OS application infrastructure", so it's hard to say. How about some clues: is it batch? run under TSO? CICS? IMS? z/OS UNIX? HTTP server?
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?
Just some more information about what problem you're trying to solve. Or maybe that would "give away the store"?
John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r)
-- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our new tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html
