On 12/10/2011 8:36 AM, Edward Jaffe wrote:
On 12/10/2011 4:08 AM, Bernd Oppolzer wrote:
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.
We have done similar things. Typically the caller places the DCB address in R1
and does a JAS[L] to the 'GetNextRec' subroutine. It expects back R1 (record
pointer for MACRF=L) and R15 (return code: 0=OK, 4=EOF). In addition to setting
return codes, the subroutine ensures R1 contains an invalid address in the EOF
case.
| L R1,InputDCB1 Point to input DCB 1
| JAS R14,GetNextRec Get next record
| DOEXIT LTR,R15,R15,NZ Exit if nothing left
| .
| .
|GetNextRec DC 0H
| STKPUSH (R14) Save link register
| DO , Do for GET
| GET (1) Get next record
| XR R15,R15 Set retcode = 0
| LEAVE , Exit
|GetNextEof DC 0H <--- EOF branches here
| L R1,=A(X'7FFFF000) Set invalid address
| LHI R15,4 Set retcode = 4 (EOF)
| ENDDO , EndDo for GET
| STKPOP (R14) Restore link register
| BR R14 Return
I didn't mention this technique because I knew Steve would not approve.
Wow! I didn't know I wielded such power. :-)
If he
thinks one TM/BNZ is too much overhead, imagine how he feels about adding a
JAS[L]/STKPUSH/STKPOP for every GET! :D
Of course, 'it depends' on the application and on installation
standards.
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").
A very sensible development strategy. It sounds you you guys were (and still
are) way ahead of your time. Thanks for sharing...
--
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
