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/
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. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
