Structured programming for virtual storage systems

  • Published on

  • View

  • Download

Embed Size (px)


<ul><li><p>The disciplines of structured programming and programmingfor virtual storage are examined to show how they affect eachother.</p><p>Considerations and techniques are proposed that, when appliedduring the process of structured design and coding, produceprograms that place fewer demands on the computer storageresources.</p><p>The techniques are illustrated by example programs.</p><p>Structured programming for virtual storage systemsby J. G. Rogers</p><p>The design and coding of computer programs have been affectedin recent years by two widely differing events. The introductionof virtual storage operating systems has reshaped our thinkingabout storage size and occupancy. At the same time, the disci-pline generally known as structured programming has causedgreat change in the process of design and coding. A body of lit-erature has grown in both these areas, but little has been writtenthat relates the two. This paper compares virtual storage sys-tems and structured programming, and shows the constraintsthat each places on the other.</p><p>The concepts involved in structured programming began emerg-ing in the late 1960s, when it became apparent that the complex-ity of very large programs was causing increasing problems inprogramming and maintenance. Structured programming hasbeen very successful in reducing that complexity. Structuredprogramming, however, has developed largely without regard tovirtual storage. This has been primarily because virtual storageoperating systems were not in general use during much of thedevelopment of the structured programming concept and be-cause the concepts of structured programming transcend partic-ular operating systems.</p><p>NO.4, 1975 STRUCTURED PROGRAMMING FOR VS SYSTEMS 385</p></li><li><p>structuredprogram</p><p>design</p><p>Implementations of virtual storage have proved not to be trans-parent to programs running in such systems. Because of this,techniques have evolved for coping with this lack of transparen-cy. These techniques have developed without regard to struc-tured programming and some suggestions that are quite alien togood structured programming practices have been made.</p><p>The orientation of this paper is toward preserving the conceptsof structured programming. The paper also shows that, in mostcases, the concepts of structured programming are quite suitableto the virtual storage environment. Presented first are brief de-scriptions of structured programming and virtual storage con-cepts, which are followed by a discussion of ways in which eachaffects the other.</p><p>Structured programming</p><p>The discipline of structured programming has evolved as ameans of increasing program reliability and reducing program-ming and maintenance costs by making programs much lesscomplex and thus more understandable. Some of the work inthis field has been concerned primarily with program design.i"whereas other work is more general.t"</p><p>The primary goal in the design of structured programs is to pro-duce modular program structure through successive functionaldecompositions. An example of this might be for a compiler tocreate a top-level module whose function is to compile the pro-gram, as shown in Figure 1. The first level of decompositionmight result in the following three modules: GET INTERNALTEXT, CONVERT SOURCE TO OBJECT, and WRITE OBJECT PRO-GRAM. The top-level module, COMPILE PROGRAM, calls theother three modules. A further decomposition of the GET INTER-NAL TEXT module might result in the following modules: GETPROGRAM STATEMENT, ANALYZE STATEMENT, and BUILD IN-TERNAL TEXT.</p><p>A module in the context of Figure 1 is a compilable unit ofsource code (e.g., a pLiI external procedure or a FORTRANsubprogram). Modules created in this manner should be madehighly independent of each other, which can be done by mini-mizing the relationships among modules (called module coup-ling), and by maximizing the relationships among parts of eachmodule (called module strengths?</p><p>The measure of the relationships among the parts of a module ismodule strength. Module strength is maximized if the parts ofthe module join forces to perform a single specific well-definedfunction." In this context, if a module calls another module, the</p><p>386 ROGERS IBM SYST J</p></li><li><p>Figure 1 Modular structure by successive decomposition of function</p><p>COMPILEPROGRAM</p><p>II I I</p><p>GET WRITEINTERNAL OBJECT</p><p>TEXT PROGRAM</p><p>II I I</p><p>GET ANALYZE BUILDPROGRAM STATEMENT INTERNALSTATEMENTS TEXT</p><p>function of the called module is considered part of the callingmodule's function. One test of a module's strength is to attemptto write a sentence about the module's function. The module inFigure I called ANALYZE STATEMENT is a strong module be-cause it can be described in a simple sentence with one verb andno words such as "if," "then," "next," "first," or "after."</p><p>The measure of the relationships among modules is module cou-pling. In this sense, a relationship exists between two modules ifthey refer to the same data. Some of the more common tech-niques used for referencing data among modules are externallydeclared data (such as data with an EXTERNAL attribute in PL!Iprograms), global data areas (for example, control blocks ordata in a FORTRAN COMMON area), and parameters or argu-ments.' Externally declared data and global data areas createhigh coupling, which means that the modification of one modulemay require the modification of many more modules. To mini-mize coupling, data should be explicitly passed as parameters orarguments.'</p><p>The nature of the data passed between modules should also beconsidered. The data are either control information - in whichthe calling module tells the called module what to do-or puredata. Control information should be avoided because it increasescoupling." If a module tells another what to do, the second mod-ule is not considered to be a "black box" module. The classifica-tion of data used in this paper depends on how the sending mod-ule sees the data.</p><p>Some other characteristics that should be considered are deci-sion structure, module size, and predictability. Whenever pos-sible, it is desirable to arrange modules in such a way thatmodules directly affected by a decision are located beneath the</p><p>No.4, 1975 STRUCTURED PROGRAMMING FOR VS SYSTEMS 387</p></li><li><p>structuredprogram</p><p>writing</p><p>module that contains the decision step.' Very small modulestend to create excessive overhead, whereas very large modulesmay be difficult to understand. Experience indicates that modulesof between ten and one hundred statements are the optimumsize." A module is said to be predictable if, for each time it iscalled with the same input, it produces the same output. In otherwords, the module does not "remember" what it has previouslydone and thus perform a slightly different function on subse-quent calls. Such a module is independent of its environment,and is more likely to be usable in several contexts.</p><p>The programming phase of structured programming is con-cerned with reducing proposed modules to source languagestatements. The primary concept involved in structured pro-gramming is the use of structures such as DO-WHILE and IF-THEN-ELSE to control a program's flow rather than using GOTOstatements. Another concept is the possible decomposition ofmodules into segments."</p><p>The process of segmentation is similar in many ways to the de-composition of a program into modules, each of which performsa single function. A module is segmented by decomposing itsfunction into more rudimentary subfunctions, each of whichbecomes a segment. Each segment is a separate entity whichexists in external storage and is included in the module in a pre-processor phase of the compiler. Just as there are-many levels ofmodules, each of which calls others at deeper levels, there aretypically many levels of segments, each of which contains IN-CLUDE statements for other segments.</p><p>Each segment created consists of source language statementsand perhaps INCLUDE statements for other segments. Thesource language statements in a segment define the controlstructure of the segment and perform part of the segment's func-tion. Each INCLUDE statement for a segment represents somedistinct function whose source statements are to be included later.</p><p>The concept of segmentation may be seen in Example 1, a pLiIprogram fragment:</p><p>Example 1IF COMMAND = 'START' THEN</p><p>DO;%INCLUDE STOPCMND:</p><p>END;ELSE</p><p>IF COMMAND = 'STOP' THENDO;</p><p>%INCLUDE STRTCMND;END;</p><p>388 ROGERS IBM SYST J</p></li><li><p>In Example 1, the programmer has written the control structurein the current segment. Because the intervening processing codehas been left to other segments, the control structure is easilyvisible and understandable. The segments STRTCMND andSTOPCMND are to be coded later. These segments are expectedto be more easily understood because they are small indepen-dent pieces of code, each of which performs a single function.</p><p>Mills9 describes the programming process as follows:</p><p>". . . one can write the first segment which serves as a skeletonfor the whole program, using segment names, where appropriate,to refer to code that will be written later. In fact, by simply tak-ing the precaution of inserting dummy members into a librarywith those segment names, one can compile or assemble, andeven possibly execute this skeleton program while the remainingcoding is continued.</p><p>"Now the segments at the next level can be written in the sameway, referring, as appropriate, to segments to be later writ-ten. . . . As each dummy segment becomes filled in with its codein the library, the recompilation of the segment that includes itwill automatically produce new updated expanded versions ofthe developing program."!'</p><p>There are several characteristics that segments should have in astructured program. The segment should be small enough to belisted on a single page, Le., have no more than fifty statements.Each segment should represent a single function, it should beentered only at the first statement of the segment, and it shouldexit only at the last statement.</p><p>The control logic contains no GOTO statements. In PL/I, thebranching control can be defined entirely in terms of DO loops,IF-THEN-ELSE, and ON statements. The resulting code can beread strictly from top to bottom, with greater understanding thanwould otherwise be possible."</p><p>Programming for virtual storage systems</p><p>Some programs tend to cause excessive paging when run in vir-tual storage systems. As these programs have been observedand the causes of paging analyzed, a set of techniques hasevolved. In contrast to the concepts of structured programming,which are applied systematically during the process of programdesign and coding, the concepts of programming for virtualstorage'</p></li><li><p>virtualstorage</p><p>because the present state of programming for virtual storage sys-tems is much more of an art than a science.</p><p>The virtual storage systems refered to in this paper are thoseimplemented in the IBM System / 370 series of computers. Inthese systems, virtual address space is divided into fixed-lengthpages that map into page-size units in the computer's real stor-age, which is generally smaller than its virtual storage. Thesepage-size units are called page frames. When a program refersto an address in virtual storage that is not currently in real stor-age, that occurrence is called a page fault. The operating systemis designed to bring the referenced page into real storage throughan action called paging.</p><p>Each program that runs on a virtual storage system has, at anyparticular instant, a working set of pages that belong to it. Theworking set is simply the pages in real storage that the programis predicted to use in order to run for a given interval of timewithout incurring a page fault. The actual working set typicallychanges with the time intervals of the program's execution. Ifthe set of programs that is contending for real storage space hascumulative working sets larger than the real storage available,then paging also occurs for that reason. If the rate of pagingbecomes so high that the system resources are used as much ormore for paging than for productive work, a condition calledthrashing is said to prevail.</p><p>When considering means for correcting an existing program thatappears to be causing thrashing, one may hastily conclude thatsuch a program may be incurring too frequent page faults. This,however, may not be the correct deduction from the facts. In thefirst place, not all page faults are incurred by a given program;other programs are incurring page faults as well. Further, if thegiven program were to run alone, it would probably not incurpage faults. Thus a more useful deduction may be that the givenprogram requires too much real storage to run in the prevailingmultiprogramming environment. Rather than seeking ways ofreducing page faults, it may be preferable to reduce the real stor-age necessary for the program by reducing the working-set sizeduring periods in which the working set size may be a problem.</p><p>To determine the measures necessary to reduce a program'sworking set size, a useful approach is to begin with the workingset and proceed backward into the program. This procedure hasthe desirable characteristic of beginning with large elements andconsidering successively smaller elements with each step. Intaking this approach, one assumes that the working set size istoo large, and at each step he looks at what can be done to re-duce the working set size.</p><p>390 ROGERS IBM SYST J</p></li><li><p>Figure 2 The recording ofcontrol sections, (A)Given working set,(B) Reduced workingset.</p><p>If a program's working set consists of too many pages, one'sfirst action is to analyze the contents of the pages. Next in theprogramming hierarchy below the working set is the control sec-tion, which is the smallest element of a program that is identifi-able by the linkage editor. Rearrangement of the most frequentlyreferenced control sections may be possible so as to occupyfewer pages, as shown in Figure 2. Here the heavy black linesrepresent page boundaries, and the shaded portions representcontrol sections currently being referenced. Figure 2A showsthat control sections A, C, E, H, and K are all that are currentlyneeded in the working set. Because of the way in which the pro-gram is packaged, however, the working set consists of fivepages. Figure 2B shows the control sections after rearrangementso that the current working set requires only three pages. Sincethe working set varies from time to time, the overall objective isto optimize the total execution of the program. Myers" gives agood description of the process of reordering control sections.</p><p>With the ability to reorder control sections, another considera-tion is to create control sections that lend themselves better toreordering. The easiest way to do this is to generate small con-trol sections that have desirable characteristics. Such small con-trol sections lend themselves to external arrangement to buildpages that have desirable characteristics. The ease with whichthis can be done varies considerably among the different lan-guages in use today."</p><p>At this point, the paradigm program has been decomposed intomodu...</p></li></ul>


View more >