When writing my initial message (see below), I had application programmers in
mind, which code in a higher level language such as PL/1, COBOL or C, and have
limited or no knowlegde of ASSEMBLER and machine instructions. For them,
it is not very common to get abends in system service calls, because they call
routines of the underlying runtime system instead, which is built by IBM and
hopefully well tested. So they will probably get return codes from these
library routines and no abends.
If occasionally they use installation specific ASSEMBLER subprograms to use
system services which are unusual for higher level languages, there will
probably be some responsible person for these subprograms. So again there is no
need to locate errors in system related routines.
I agree, it never hurts to train people. But unfortunately, management always
wants to pay as little as possible for education reasons. So you have to find
some economical mid way, and in my opinion this could be: teach the HLL
programmers the chaining of the save areas, the way to find the error position
in the source, and the way to look up the variables, static or auto. This will
be of real help to these persons.
Am Mit, 20 Nov 2002 schrieben Sie:
> Weeeeeeeeeeeeeeeeeeeeell maybe. I suppose "it depends".
> There are certainly applications for which you probably are never
> going to see anything other than a simple abend in mainline code,
> but those kind of problems almost always get debugged long before
> they blow up in production.
> For code that's had time to bake, you're more likely to have abends
> in system service calls. If your game plan depends on looking at
> R13 at the time of the abend and working your way backwards, you're
> often going to be disappointed (and plain bamboozled) when R13 at
> the time of the error is not pointing to anything remotely related
> to your application.
> The SDWA is your friend and even then you may not be able to figure
> it out unless you know a bit more about the environment your code
> runs in. IMHO it never hurts to train people.
> > In my opinion, this is kind of "nice to know", but it is only
> > of limited use
> > for application programmers. Why do you want to look at all
> > these control
> > blocks, TCBs, SRBs, RTM work areas and so on ?
> > Most important for the application programmer is: finding the modules,
> > finding the variables (most often by using the addresses of
> > the save area
> > trace). And: associating PSW or return adresses with offsets
> > of the abending
> > module (which is often not easy, too). So in my opinion, the
> > only relevant
> > control blocks for appl programmers are: save areas (of
> > course), CDE, XTLST (to
> > locate the modules), TIOT and maybe the control blocks which
> > show up allocated
> > memory in the subpools.