Thanks for the mention Rob.
WRT this religions war over whether to use system abends vs. user
abends, I'm agnostic. My own personal preference is to use a
contrived 0C1 (which is what my dead traps are that Rob mentioned),
but it ain't worth a hill of beans to argue about.
However, not that my #DIE macro has been mentioned, I would like to add this.
One minor convenience of #DIE, in addition to those mentioned by
RScott, is that it can generate a conditional branch ahead of the
X'00DEAD' code, thereby making execution of the "dead trap" optional. Example:
LTR R1,R1
#DIE NP,'ILLOGICAL IF R1 IS NOT POSITIVE'
z/XDC's internal code has *thousands* of #DIE traps scattered
throughout its logic. Yet, problem reports resulting from those traps
occur only a couple of times a year.
The purpose of the #DIE traps is to arrest illogical conditions
before that can seed a failure that occurs a million instructions
later. They are used within z/XDC's logic where the perceived
likelihood of the illogical condition is low or "nonexistent". i.e.
in places where it is not worth the effort to write a more polite handler.
The result of my use of #DIE traps is that when an "impossible"
condition does arise, my having trapped it early makes creating a fix
considerably easier. Sometimes I can produce and publish a fix within
only a day or two or sometimes even within an hour or two!
One good application for dead traps is to verify the critical details
of an interface to some outside support routine (especially
undocumented interfaces). If an API changes in an unexpected way, it
generally is good to know about that sooner than later.
One example of where I got bit by that is with IBM's TPUT service. A
couple of decades ago, they added some new return codes. I was using
a branch vector to react to the various return codes, so the new one
caused execution to blow past the vector entirely. There were several
lessons learned from that. One was to use dead traps to vcheck what
was returned.
The #DIE macro is available to anyone for free in a MACLIB.ZIP file
located at
<http://www.colesoft.com/Downloads/downloads_utilities.html>http://www.colesoft.com/Downloads/downloads_utilities.html
Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
At 2/13/2012 06:32 AM, Rob Scott wrote:
I have always liked Dave Cole's approach in z/XDC here - he supplies
a "#DIE" macro that places X'00DEAD' in the code followed by
identification bytes that indicate where in the code the #DIE was
and optional comments
Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Martin Truebner
Sent: 13 February 2012 11:21
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: VarIabLe DD names in VSAM
Thomas (or should I say "amateur in asm" ;-)
The idea is to produce something that is easy recognisable as "done
on purpose" and not to muddy the water more for this "unexpected"
situation.
I for example always have a EX *,* (or an equivalent if there is no
base covering it) after a EXEC CICS RETURN.
It must work- but hey, I have seen horses dying in front of
drugstores (German saying)
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more
at http://www.picapcpu.de
