An exercise in separating client-specific parameters from your - PowerPoint PPT Presentation

An exercise in separating client-specific parameters from your program Erik Tilanus The Netherlands WIILSU 2015 Milwaukee

Do you recognize this? You write a 'one-time' program for one particular situation 'Quick and dirty': everything directly in the program, since you are going to throw it away afterward The program's results are such that people ask you to run it again, but that requires some updates to be made...

What is the problem? You just learned the concept of a parameter “A parameter is a constant with the nasty property of being variable” Examples: a reporting month, a department code, a sales tax percentage

A case study in parameter management Case: a simple airline revenue management system A revenue management system optimizes revenue by controlling capacity made available for each possible fare: 'Expected marginal seat revenue' (EMSR) principle If you have 60% chance to sell an extra seat at $100 or an 80% chance to sell the seat at $80. What is your best guess in the long run? .6 * 100 = 60 ; .8 * 80 = 64. So in the long run the $80 fare is more attractive.

Structure of a RMS

Dozens of parameters Booking classes (which, how many) Measuring points ('snapshots') for booking curves (when, how many) History period on which to base forecast Log-in information for download and upload to the reservation system Single value parameters and series of values Example single value: maximum number of booking classes Example series: snapshots (-1, 0, 1, 2, 3, 5, 7, 10, 14, … days before departure)

First line of attack Single value parameters stored in macro variables Series parameters stored in formats and informats All concentrated at the beginning of each program module Advantage: single location to change the value and the new value is used throughout the program Disadvantage: in a system like the RMS that consists of more program modules: each should have these definitions.

Second line of attack Create a separate module with all the definitions and (in-)formats (Utilities.SAS). Include this module in all other modules Advantage: single location to change the value and the new value is used across all program modules Disadvantage: when using the same system for more clients: separate Utilities.SAS module for each customer

Example of Utilities.SAS * path for software modules; %global programpath; %let programpath = e:\RMS\source; * path to store temporary files; %global work_path; %let work_path=%SYSFUNC(GETOPTION(WORK)); PROC FORMAT; INVALUE dbd -1 = 29 0 = 28 ... 98 = 1 other = 999; RUN;

Third line of attack Store all parameters in one or more SAS data sets or text files in the same library where the airline data is stored Let the Utilities.SAS module generate all macro variables and (in-)formats from that data Advantage: easy to update (FSEDIT or Notepad) Allocate the library and automatically load the right parameters. Disadvantage: none that I can think of.

The Parameter file

Revised Utilities.SAS (1) *--------------------------------------------------; * Load macro variables form the parmfile data set ; *--------------------------------------------------; DATA _null_; SET RMS.parmfile(firstobs=2); *first obs is a dummy observation to define all fields as lower case; CALL EXECUTE( '%GLOBAL '||parameter||';'|| '%LET '||parameter||'='||value||';'|| '%PUT '||parameter||'= &'||parameter||';' ); RUN;

Revised Utilities.SAS (2) *--------------------------------------------------; * Define translation DBD to snapshot ordinal ; *--------------------------------------------------; DATA cntlin; SET RMS.snapshots END=eof NOBS=nobs; RETAIN fmtname 'dbd' type 'I'; start = snapshot; label = nobs+1-_n_; OUTPUT; IF eof THEN DO; HLO = 'O'; label = 999; OUTPUT; END; RUN; PROC FORMAT CNTLIN=cntlin; RUN;

There is more to do with Utilities.SAS We use it already to generate macro variables and (in-)formats Also good place to store macro definitions Place to define general data views And anything else that is applicable to the complete application

Conclusion and summary Don't believe yourself when you think your program is for one-time use Define your parameters in macro variables or (in-)formats at the beginning of your program or in a separate module Use that module also for e.g. macro definitions and other common elements Consider to store parameters in data sets and generate macro variables and (in-)formats from there

Questions? Any time during the conference Or e-mail to erik.tilanus@planet.nl