On 12/9/2011 11:10 AM, Edward Jaffe wrote:
On 12/9/2011 9:07 AM, Steve Comstock wrote:
Right, so I would argue that the GET approach is more 'traditional'
than the 'traditional approach' you describe: it's been around longer.
I should have said 'typical'. The flaws introduced by older 1960s-era designs
have been corrected in modern implementations. It's practically impossible to
find a modern-era service that handles a simple 'end-of-data' condition using an
out-of-line branch, and with good reason.
You set up a deliberate disonance when you use the word 'arbitrary';
there need be nothing arbitrary about the routine jumped to for an
EODAD occurrence: it should be well planned and naturally take the
control flow to the next part of the logic.
When DCBEODAD was designed, stacks were not used. In modern code, an out-of-line
branch risks a situation where one or more stack frames do not get unwound. This
is exactly the sort of thing that would be flagged by tools that look for
problematic programming that violates good architectural and coding practices,
such as those from 'Cast Software' that are getting so much press lately--having
found Java to be the most problematic language and COBOL the least in a study
involving 745 applications from 160 companies in nearly a dozen industries which
totaled 365 million lines of code.
http://www.computerworlduk.com/news/applications/3323819/java-apps-have-most-flaws-cobol-apps-least-study-finds/
Well, the kind of code you write is designed to interface
deeply with the system (for example, you have mentioned
that your company's main product is designed to be eligible
for zIIP (or is it zAAP) execution).
For application programming (granted: there are precious few
applications written in Assembler these days, except by
software product developers), I actually disdain using the
linkage stack, for these reasons:
1. BAKR / PR are included in Chapter 10 of the POO: Control
Instructions, not Chapter 7, General Instructions; they
are semiprivileged instructions
I realize many application programmers use this convention
because it's easy, but I think the easy way is not always
the best way, depending on circumstances
2. Performance can be very slow (granted, if you only do BAKR
on entry, it's not a big deal; but calling lots of subroutines
that all use BAKR can hurt performance)
3. Save area chains may not be available or meaningful for
debugging situations (note Robert Ngan's recent post on
this very list)
4. It is possible to get a stack full exception, which few
application programmers want to deal with (again, see
Robert Ngan's recent post)
Actually, the EODAD (and other DCB exit routines) might be more
closely compared to exception routines in languages such as
Java: event-driven routines that get control specifically when
some event occurs. Event handlers, if you will. Which is more
'modern'? Which is 'better'? As you know, the answer is always
'it depends'.
Such 'event handlers' are usually designed to deal with the stack frame issue I
mentioned above, just as ESTAE is aware of the System z hardware linkage stack.
DCBEODAD does no such thing.
Stack frame issues are not really relevant if you don't
use the linkage stack; users of classic linkages simply
don't have that problem.
And I would disagree with your assertion that such event handlers
'are usually designed to deal with the stack frame issue'. Typically
event handlers deal with exceptions such as end of file, file not
found, data format exception, and so on. See:
http://www.trainersfriend.com/General_content/Book_site.htm
the third paper, "Introduction to Java in z/OS", pages 428-445
for an exhaustive list of Java exceptions
So while I agree with your assertions for code that must interface
with some z/OS internals, I don't think the 'typical' Assembler
application program is harmed by not using the linkage stack and
by using any of the various DCB exits as I suggested earlier.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
[email protected]
http://www.phoenixsoftware.com/
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
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 tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
