Some day I designed a large ASSEMBLER program which needed to
read some QSAM files, and I soon discovered that the out-of-line branches
imposed by the EODAD processing violated the clean structure of the program,
because the input logic of the many files which were read in parallel
was somehow
complicated. If, for example, you deal with VSAM instead of QSAM, you
have very
natural return code handling after each GET macro call, which allows
structured
programming, using SP (structured programming) macros, for example.
To solve this problem, I ended up with a GET routine for every QSAM dataset,
where the EODAD address is part of the routine. The GET routine looked like
this (from memory, I don't have the sources at hand):
GET1 PSTART (R10,R14) start macro for local procedure
GET DATASET1 get record from dataset
XR R15,R15 set eof rc to zero
LR R5,R1 move record address to reg 5
LEAVE , success, leave proc (comma VERY important!!)
EOF1 DS 0H = EODAD address of DATASET1
LA R15,8 end of file, set eof rc to 8
GET1Z PSTOP (R10,R14) end macro for local procedure
so the EODAD branch is hidden in the GET-ROUTINE.
In our shop, we tell the developer to write ASSEMBLER modules without B
or J instructions. All control flow is done using SP macros, which have
been
developed or at least improved inhouse in the past 35 years (I don't
know the
beginning of the history, because I'm with this company since 1988 "only").
Kind regards
Bernd
Am 09.12.2011 22:56, schrieb Steve Comstock:
On 12/9/2011 2:13 PM, Edward Jaffe wrote:
> On 12/9/2011 11:33 AM, Steve Comstock wrote:
>>
>> 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:
>
> Actually, I wasn't talking about the linkage stack at all. I was
> referring to software-only stacking.
Ah, my mis-understanding.
>
> In the early days, people rarely coded hierarchically. Everything
> was a flat programming model, one routine following another with
> (one or more) branches to the label of the next routine. These
> days, people understand the value of nested logic. A software
> register stack is practically a necessity for such coding.
Totally agree with all of the above.
>
> I have made a simple stacking macro available publicly to help
> those who might be challenged to 'roll' their own. More
> sophisticated stack services (such as the one we use internally)
> handle so-called 'automatic' variables as well.
Excellent. One can also use the CEEENTRY macro to handle automatic
variables (although it does have some shortcomings, such as using
non-relative branching instructions).
>
> -- 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
