On 12/9/2011 9:42 AM, Edward Jaffe wrote:
On 12/9/2011 7:53 AM, Steve Comstock wrote:
I disagree. Why test a flag after every GET? QSAM essentially
does that for you and branches you to EODAD automatically; if
you find yourself in your EODAD routine you know you're ready
for the next phase of your processing, which might be just
shutting down (CLOSE and RETURN), but it might be more complex,
such as taking subtotals, CLOSE-ing one file and OPEN-ing
another, etc.
But to add the overhead of test-and-branch after every GET is
totally unnecessary.
QSAM GET is but one example of a whole class of similar operations provided by
many IBM and ISV systems services. The notion of an "open," followed by one or
many "gets," followed by a "close" is just how programming works for hundreds of
different resources--from REXX/CLIST variables, to ENQs, to logger, to BCPii,
and more.
The traditional approach is for the return code to be set non-zero (e.g., 4)
when end of data is reached. For example:
DO INF Do for all objects
SOMESERV REQUEST=GET Obtain next object
DOEXIT LTR,R15,R15,NZ Exit if no more objects
. .
process the returned data .
. .
ENDDO , EndDo for all objects
QSAM GET was invented before there were structured disciplines.
Right, so I would argue that the GET approach is more 'traditional'
than the 'traditional approach' you describe: it's been around longer.
Having the
system branch to an arbitrary 'EODAD' label outside the GET loop increases the
program's complexity and makes GET's behavior 'arcane' when compared to the
processing methodology used by nearly every other service that has been invented
since.
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.
An approach that sets a flag that can be tested in the loop solves this problem
nicely, making GET's processing more mainstream.
Well, I don't see it as a 'problem', I wouldn't characterize the
flag approach as 'nicely', and I disagree with your characterization
of GET processing as non-mainstream.
Other than that ...
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'.
--
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/
--
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
