Exposing a 4GL Property of the SM"' System

Size: px

Start display at page:

Download "Exposing a 4GL Property of the SM"' System"

Gwenda O’Connor’
5 years ago
Views:

1 Exposing a 4GL Property of the SM"' System Paul J. Waldowski Amdahl Corporation Abstract In today's data processing environments, software engineers are continually striving to exploit the fourth generation language (4GL) characteristics of programming languages available within the corrputing industry. One of the many capabilities 4GLs have over third generation languages is the ability to generate more source code from the input without recompiling any code. The generated source code can then be executed from the code which created it by sirrply invoking a built-in property of the language. This paper exposes this 4GL property of the sas'" System through the use of the sas'" Macro Language in a data-driven sas'" program. INTRODOCTION Increasing customer demands for complete, robust applications to meet a variety of business needs, has placed a serious strain on developers within the computing industry. This common problem grows in complexity when the data processing environment is not fully exploiting the underlying technological developments available in today's market place. The use of many traditional programming languages which lack features and functionality results in a failure to reduce the effort and cost of developing and maintaining business information systems. The purpose of this paper is to expose a 4GL property of the SAS~ System through the use of the SAS~ Macro Language in a data-driven SAS'" program. This will in turn provide an environment that allows developers to concentrate on the business rules to retain control of the growth process which governs mdssion critical systems. Moreover, ~he standard being rectified is exposure to an architecture using data- and eventdriven concepts which always foster completeness I but never closure. To accomplish this objective successfully requires a strategy that offers a paradigm enhancing innovation, one that dr'astically improves upon what developers are already practicing. This change entails simple invocation of a built-in property that 4GLs have over third generation languages. In the case of the SAS~ System, the built-in property being exploited is the SAS~ Macro Language. This part of the SAS'" System provides an interface which can evoke the code generated from the source code without recompiling any code. This property will become evident during the discussion of the supplied data-driven SAS~ program. Before explaining how this program uses the 4GL property, the underlying property of both second and third generation languages and even 4GLs will be addressed. By discussing unit record processing and its history, we will be able to further expose the 4GL property of the SAS~ System. Finally, some closing remarks will be presented. UNIT RECORD PROCESSING Over one hundred years ago, Herman Hollerith, a statistician with the U. S. Census Bureau invented a code for recording data which continues to affect 216

2 today's data processing environments. This code was initially used on strips of paper. However, for better durability and ease of handling, the paper strips were soon replaced by what were commonly referred to as a punched card. These punched cards of fixed size and length were also known as a unit record. This code on punched cards and the hardware designed to interpret and process unit records li~ted software development to production at a cumbersome level. These punch cards were primarily created on keypunch machines to produce software from both second and third generation languages. In addition, these cards were processed by hardware: read by card readers, fed into sorters, interpreters, and collators [1]. From this technology, mechanical failures like card jams led to the use of unit record representation on a terminal as one line across the screen. If one were to look at a screen of at least twenty lines on most terminals, we could theoretically call it a window. In essence, this collection of records and the ability of the terminal to toggle to another screen or even host multiple sessions contains the property known simply as file level processing. The advent of personal computers and the software associated with this phenomenon reinforced this relatively basic concept. It also provided software engineers with the hardware necessary to evolve from unit record processing to a file level process. Table 1 presents a list of each generation covered above. In addition, an example or two of a programming language from each generation and the hardware designed to primarily support the generation are listed. Each generation independently controls its own functionality and representation within a given programming language. In fact, any language must handling the entire application oriented character, field, record, the file. Generation Table 1. Language(s) 2nd assembler 3rd COBOL, C 4th SASI»I HURON FILE LEVEL PROCESSING be capable of spectrum of data, i. e. and especially Hardware card reader terminal personal computer It is the file and its underlying characteristics that offer the paradigm enhancing innovation of having the data generate the source code required to perform the process automatically. Some may contend that development of code in this manner is unnatural and not always simple to uncover. To these users of older generations, this author suggests that the opportunity to change their own paradigms is not only the basis for discovering better practices for today's business information systems but the cornerstone for any type of future system. Regardless of any systems complexity, it must be fundamentally handled at the file level. If for no other reason, the maintenance costs below this level have failed to meet customer demands in a timely effective manner. The paradigm being rectified is the alteration of the information flow within the enterprise from the use of punched cards to an architecture using data- and event-driven concepts which always foster completeness, but never closure. This new paradigm also forces each software engineer to look in a different direction for the information to solve the important problems. Once each software engineer is looking in a different direction, they will have no choice but to see things they had never seen before. 217

3 EXPOSING THE 4GL PROPERTY The generations of programming languages could be defined in terms of various features and capabilities each contains. However, the essence of this discussion is to examine the 4GL property of the SAS~ System in the program presented in APPENDIX A. This approach is taken to show that the development of 4GLs like the SAS~ System not only simplified the coding process to handle the entire spectrum of application oriented data, but led to the natural creation of output files which contained executable source code. These files could then become an integral part of the algorithm which generated this code if the programming language had the capability of storing and fetching the code without rewriting applications or recompiling code. Fortunately, the SAS~ System can build this executable source code as an external file of macro call statements. This file can then be invoked by a %INCLUDE statement of the SAS~ Macro Language from the SAS~ source code which generated the external file and execute a macro like the one presented in APPENDIX B. In APPENDIX A, we have the main SAS'" program. The function of this program is to clean up a graphics catalog of existing graphs which will be refreshed by a new set of graphs generated from an input file. This input file is interrogated within the process by searching for VOLUME SERIAL NUMBERS. Each volume found will be represented by a unique graph which can be generated by invoking a macro statement with the correct parameter. This macro statement is also generated from the main program and is stored in an external file. The external file is then invoked by the statement, %INCLUDE MACSTMTS; from the source program. This simple but elegant technique is known as the 4GL property of the SAS~ System. CONCLUSIONS This program, as developed and evaluated, is intended to enhance the capabilities of developers of business information systems. It has achieved this by handling the input to generate more source code without recompiling any code. This generated source code is now executable from the same code which created it and exposed the 4GL property of the SAS~ System. REFEm:NCES 1. D'Arco, Anthony, Fuori, William M., and Orilia, Lawrence, Introduction to Computer Operations, Second Edition, Prentice-Hall Inc., Englewood Cliffs, NJ, ACKNOWLEDGMENTS Many people have contributed to this paper in various ways, and their efforts and ideas are most sincerely appreciated. Finally, a very special acknowledgment is due to my wife, Paula, for being a great source of support, encouragement, and for her extremely careful editing of the manuscript, which led to numerous improvements in style. AUTHOR CONUCT Paul J. Waldowski Amdahl Corporation Chevy Chase Pavilion Suite Wisconsin Avenue, N.W. Washington, D.C (202) (202) VOICE FAX paul.waldowski@amail.amdahl.com 218

4 APPENDIX A., AVERAGE RESPONSE TIME PROGRAM ("A DATA-DRIVEN APPLICATION") GLOBAL VARIABLES: ASOFDATE, MEMBER, MVSLEVEL, SYSTEM, and WEEKDAY INPUT: SMF RECORD TYPE 74 (RMF) DD CARD, //PDB PROCESS: 1. CLEANS UP THE DAILY GRAPHICS CATALOG BY USING THE TODAY() FUNCTION WITH PROC GREPLAY 2. BUILDS A FILE OF SAS MACRO STMTS. THE NUMBER OF STMTS. GENERATED IS BASED ON THE NUMBER OF UNIQUE VOLUME SERIAL NUMBERS FILTERED FROM THE INPUT FILE WITH PROC SORT NODUP. 3. THE FILE OF MACRO STMTS. HAVE THE FOLLOWING GENERIC FORMAT: %AVGRSPMS(VOLSER='VOLSER') OUTPUT: FILE OF MACRO STMTS. CALLED BY THE %INCLUDE MACRO STATEMENT., OPTIONS NOCENTER DQUOTE; GOPTIONS site specific; %GLOBAL ASOFDATE MEMBER MVSLEVEL SYSTEM WEEKDAY; %LET MEMBER=MSVOLSER; DATA _NULL_; / create graphics catalog variables / CALL SYMPUT ('WEEKDAY',PUT(TODAY()-1,WEEKDATE3.»; / cleanup SAS catalog entries so new / / graphics output can replace / / existing graphs from last week / PROC GREPLAY IGOUT=&WEEKDAY.. &MEMBER NOFS; DELETE _ALL_ / obtain input records from //PDB / DATA TYPE74 (KEEP=TIME AVGRSPMS DEVNR VOLSER); SET PDB.TYPE74; / create values for title stmts. / IF _N_ = 1 THEN DO; CALL SYMPUT('SYSTEM',SYSTEM); CALL SYMPUT ( 'MVSLEVEL',MVSLEVEL) ; END; / filter date request / IF PUT(DATEPART(STARTTIME),DATE7.)= LEFT(PUT(TODAY()-1,DATE7.»; / filter installation address range / IF VOLSER=', THEN DELETE; IF (DEVNR >= 0120X.AND DEVNR <= 034FX); / miscellaneous variables / CALL SYMPUT ( 'ASOFDATE', PUT(DATEPART(STARTIME),WORDDATE.»; TIME=PUT(TIMEPART(STARTIME),TIME2.); / remove duplicate VOLSER values PROC SORT DATA=TYPE74 NODUP; BY VOLSER; / list of VOLSERs to be processed DATA VOLSER(KEEP=VOLSER); SET TYPE 74; / alphabetize each graph by VOLSER PROC SORT DATA=VOLSER NODUP; BY VOLSER; / write macro statements to file DATA _NULL_; FILE MACSTMTS PAD; SET VOLSER; '}'; / "invoke data-driven programmingn %INCLUDE MACSTMTS; / / / / / 21~

5 APPENDIX B i AVERAGE RESPONSE TIME MACRO ("A DATA-DRIVEN INVOCATION") INVOKE: %AVGRSPMS(VOLSER='VOLSER') MACRO VARIABLE: VOLSER INPUT: SIX (6) CHARACTER VOLUME NAME PROCESS: PROC GCHART; OUTPUT: A GRAPH OF A VOLUME SHOWING MINIMUM, AVERAGE, AND MAXIMUM RESPONSE TIMES IN MILLISECONDS (MS) BY HOUR FOR THE DAY REQUESTED, %MACRO AVGRSPMS(VOLSER=); / obtain data about VOLUME requested / DATA V&VOLSER; SET TYPE74; IF VOLSER=" &VOLSER"; CALL SYMPUT ( 'VOLSER'," &VOLSER") ; PROC SORT DATA=V&VOLSER; BY TIME; PROC MEANS DATA=V&VOLSER NOPRINT; BY TIME; VAR AVGRSPMS; OUTPUT OUT=AVGRSPMS MIN=MINRSPMS MEAN=AVGRSPMS MAX=MAXRSPMS; 1 tit~e statements / TITLEl C=WHITE J=C "SYSTEM &SYSTEM"; TITLE2 C=WHITE J=C "MVS &MVSLEVEL"; TITLE3 C=WHITE "VOLUMESERIALNUMBER"; TITLE4 C=WHITE "&VOLSER"; TITLES C=WHITE J=C "&ASOFDATE"; / stack data for PROC CHART output DATA IO_RSPTM; TYPE= 'At; USER=MINRSPMS; TYPE='B' ; USER=AVGRSPMS-MINRSPMS; TYPE='C' ; USER=MAXRSPMS-AVGRSPMS; PROC GCHART DATA=IO_RSPTM GOUT=&WEEKDAY.. &MEMBER; LEGENDl LABEL=NONE VALUE= (T=l 'MINIMUM' T=2 'AVERAGE' T=3 'MAXIMUM'); LABEL USER="RESPONSETIMEMS"; LABEL TI:ME='\HOUR" i VBAR TIME / SUMVAR=USER SUBGROUP=TYPE FRAME DISCRETE LEGEND=LEGENDl NAME="MS&VOLSER" HREF=40 AXIS= S ~O DESCRIPTION= "VOLSERRESPONSETIME(MS) - &SYSTEM"; 1 pattern statements PATTERNl V=Xl C=RED; PATTERN2 V=Rl C=YELLOW; PATTERN3 V=Ll C=BLUE; PATTERN4 V=S C=GREEN; PATTERNS V=E C=BLACK; %MEND AVGRSPMS; / / SAS-is a registered trademark of SAS Institute Inc. in the USA and other countries. 220

OS/390 DASD I/O Drill Down Computer Performance Chart Using ODS SAS/GRAPH & MXG Software

Paper 216-27 OS/390 DASD I/O Drill Down Computer Performance Chart Using ODS SAS/GRAPH & MXG Software Neal Musitano Jr. Department of Veterans Affairs Information Technology Center Philadelphia, Pennsylvania