Subroutines and Parameter Passing

1. Subroutines and Parameter Passing Ch.8pp. 188-217 Topics 1&2

2. Why Use Subroutines? • Modular Programming Design • Smaller Programs are Manageable • Less time to Code and Test • Multiple Coders Coding in Parallel • Reduce Duplication • Reduce Storage Requirements

3. Example:MainRoutine I’m sure you remember flowcharts !!? This particular main routine is made up mostly of subroutines. Each subroutine CALL is noted by the flowchart symbol that resembles a PROCESS block but it has vertical strips down each side. Compare READREC flowchart symbol to Housekeeping. It’s nearly impossible to know what this program is doing since most of the documentation can be found elsewhere, but I would guess that a n input record is read in, somehow processed, and when done it prints something. No doubt, the main processing actually takes place in PROCESS subroutine. The loop continues until an EOF occurs on the input. How typical of a program? For our purposes, at this point in time, is the fact that READREC, PROCESS, and PRTCOUNT are all subroutines and I’d also be willing to bet that these subroutines must somehow communicate with each other. For example, how can PROCESS process without knowing what the input record is? How can PRTCOUNT print if it doesn’t know what was processed? p. 190

4. READREC READREC subroutine definitely does read a record, but that’s about all. The EOF part of the flowchart is included here for show, but if you remember, EOF checking was done by the main routine. In actuality, eof checking should be done where the read is done (here), but the flowchart was included in the main routine to show how one got from PROCESS to PRCOUNT since both subroutines were not both executed each time a record was processed.

5. PROCESS PROCESS has a subroutine as well, called PRTDET. So our other print, as we well may have suspected, printed out some summary or total information for the records that were processed. This sounds like it might be part of Small Town Hardware, printing a re-order list after determining if some item(s) needs re-order. Plus … Flowcharts for:PRTCOUNTPRTDETand PRINT (next line) p.181

6. The Coding for SubroutinesRemember, we covered internal subroutine linking way back in Week 5 Internal • In the REORDLST program: • AND in the READREC & PROCESS programs: BAL 11,READREC BAL 11,PROCESS BR 11

7. But … That’s Not All ! • What about - - • Saving Registers for each routine? • Any information to pass between routines? • Conventions for Register usage? • What is the RETURN register? • Where is information passed? • Where is information returned?

8. Saving Registers Without SAVE Macro …

9. Explanation of code on previous Slide The first thing a mainframe program must do is to preserve the previous environment (by convention). This includes the main program that got control by the goodness of the operating system and the main program intends to return control to the operating system. This is the purpose of the STM instruction. Save the CALLing programs registers in the CALLing program’s register savearea. That is what Reg 13 points to upon entry. So, registers 14 thru 12 (with wrap) are saved beginning in the 4th word of the 18-word savearea of the CALLing program (not in MYSAVE shown here). Addressability is still the prior programs since we have not yet established our own addressability. Now addressability is established with the BALR and USING. Next, since this program can now use it’s variable symbols, it can now complete the standard saving of pointers. First, pick up the address of its own savearea (LA 14, MYSAVE), so it can be saved in the CALLing program’s savearea (red arrow). Then, the first ST instruction saves off the address of the CALLING program’s savearea (in Reg13) in it’s own MYSAVE+4 (always at the second word of its own savearea – green arrows). Then save the address of MYSAVE in the CALLing program’s savearea. This establishes forward and backward pointers for connected saveareas. Should a program fail, saveareas can be traced (blue arrow, but the pointer really goes to the next higher-level savearea). As a subroutine programmer, this may be useful to make sure proper parameters were passed from CALLING to CALLED. Just prior to the subroutine returning to the CALLing program, it needs to re-establish addressability for the CALLing routine. To accomplish this, subroutine must return the registers back to the CALLer. An example of this is shown at location DONE. Get back the original Reg13 contents, which includes all the registers, one of which (Reg14) contains the return address to the CALLing program. This can be accomplished with the LM and BR 14 instructions.

10. Parameter Passing By now, you are probably not very surprised to find out that there is a standard convention for passing information between routines either. Establishing and adhering to conventions is a great idea these days as programmers working on the very same program may be a half a world apart. Communicating with each other is not so easy and it takes too long – even using e-mail can take days, especially when two programmers are not at work at the same time. Convention dictates that Reg 1 is used for this purpose. Essentially, Reg 1 on entry to a subroutine contains a pointer to a parameter area, made up as many address are required. The addresses point to the actual values and either the number of parameter addresses is fixed ahead of time, or some method is established to determine how many parameters are being passed. Refer to the diagram on the next slide.

11. Parameter Passing *

12. And the Coding ?

13. From the Other Side … (Subroutine)

14. In Mainframe, not PC/370 * • Macros support parameter passing

15. EndofSaveAreaandParameterPassingSlides