Novel Code

Novice coders write novel code—that is, code that reads cover to cover like a novel, from the first DATA step to the final RUN statement. As mentioned in the “Monolithic Software” section, serialized design is expected and unavoidable when data analytic processes must be sequenced due to prerequisites and inputs. However, SAS practitioners can be so accustomed to designing and developing monolithically that they fail to perceive opportunities where modular design would improve program flow or static performance attributes.

The following code simulates monolithic ETL software saved as a single program but conceptualized as three functional modules:

libname perm 'c:perm';
* ingestion;
data perm.raw;
   length char1 $10 num1 8;
   char1='burrito';
   num1=443;
run;
* analysis 1;
proc means data=perm.raw;
   by char1;
run;
*analysis 2;
proc freq data=perm.raw;
   tables num1;
run;

In some cases, this long-windedness is unavoidable and separating data processes into discrete modules—that is, separate programs—would not benefit dynamic or static performance. For example, the following attempt to modularize the ETL code does create a series of macros but provides no improved performance:

libname perm 'c:perm';
* ingestion;
%macro ingest();
data perm.raw;
   length char1 $10 num1 8;
   char1='burrito';
   num1=443;
run;
%mend;
* analysis 1;
%macro anal1();
proc means data=perm.raw;
   by char1;
run;
%mend;
* analysis 2;
%macro anal2();
proc freq data=perm.raw;
   tables num1;
run;
%mend;
%ingest;
%anal1;
%anal2;

All code is still contained inside a single program and that program demonstrates sequential processing of all steps. Nothing has changed except that the complexity of the software has increased due to unnecessary macro definitions and invocations. Faux modularity is often observed in SAS software because certain macro statements, such as %IF–%THEN–%ELSE conditional logic, are viable only inside the confines of a macro. Software may appear to be broken into discrete chunks of functionality, but these delineations are often created only so that macro statements and logic can be utilized.

In this example, both analytic modules could in theory be run in parallel to increase performance. As demonstrated in the “False Dependencies” section in chapter 7, “Execution Efficiency,” because the MEANS and FREQ procedures each require only a shared file lock on the data set, they can be executed simultaneously. The advantages of modularity cannot be realized until monolithic code is conceptualized not as a single entity but rather as discrete functional elements. Through functional decomposition, demonstrated in the “Functional Decomposition” section later in the chapter, this code embarks on its journey toward modularity.

Overly Complex Code

Whereas SAS practitioners should try to cram as much functionality as possible into every DATA step, this data management best practice does not translate to modular design. And that's okay! If you can ingest, clean, and transform your data in a single DATA step, there's no reason to arbitrarily kill one bird with three stones—keep the single DATA step. But certain functionality required in ingesting, cleaning, and transforming data can often be generalized to other software and thus can benefit through modularization and reuse.

The following %GOBIG macro, which appears in the “Flexibility” section in chapter 18, “Reusability,” dynamically capitalizes all character variables in a data set:

%macro gobig(dsnin= /* old data set in LIB.DSN or DSN format */,
   dsnout= /* updated data set in LIB.DSN or DSN format */);
%local dsid;
%local vars;
%local vartype;
%local varlist;
%local i;
%let varlist=;
%let dsid=%sysfunc(open(&dsnin,i));
%let vars=%sysfunc(attrn(&dsid, nvars));
%do i=1 %to &vars;
   %let vartype=%sysfunc(vartype(&dsid,&i));
   %if &vartype=C %then %let varlist=&varlist %sysfunc(varname(&dsid,&i));
   %end;
%let close=%sysfunc(close(&dsid));
%put VARLIST: &varlist;
data &dsnout;
   set &dsnin;
   %let i=1;
   %do %while(%length(%scan(&varlist,&i,,S))>1);
      %scan(&varlist,&i,,S)=upcase(%scan(&varlist,&i,,S));
      %let i=%eval(&i+1);
      %end;
run;
%mend;

When the following code is executed, a new Uppersample data set is created, and the values sas and rules become SAS and RULES!, respectively:

data sample;
   length char1 $10 char2 $10;
   char1='sas';
   char2='rules!';
run;
%gobig(dsnin=sample, dsnout=uppersample);

The dynamic macro capitalizes values in all text variables and can be implemented on any data set. However, the code is not functionally discrete and, as demonstrated later in the “Loosely Coupled” sections, it unfortunately is highly coupled.

The single functional requirement of the module is to capitalize the values of all text variables within a data set dynamically. And, in a nontechnical sense, this is what the end user perceives as the functional outcome. For example, when I hit <CTRL><B> in Microsoft Word, the characters I've highlighted are made bold—a single functional outcome. However, behind the scenes, the software must assess whether I'm turning off or turning on the bold and whether I've highlighted text or want to affect the cursor and subsequent text I'm about to type. Thus, despite having a single functional outcome, a functional requirement will often have numerous functional and performance objectives subsumed within it that are inherently required.

The %GOBIG macro could still be segmented more granularly. The first function performed opens a stream to the data set, retrieves the number of variables, and makes a comma-delimited list of character variable names. In modular software design, this functionality alone should be represented in a separate macro saved as a separate SAS program. The next function dynamically generates code that capitalizes the values, but the code is unfortunately wrapped inside a DATA step, decreasing reusability and violating the loose coupling principle of modular design. Thus, while the code may have only one functional requirement, other implicit functionality may be required to achieve that goal. The next section demonstrates functional decomposition, which aims to separate monolithic software and overly complex macros into true discrete functionality.

Functional Decomposition

Functional decomposition describes identifying separate functions that software performs, including both functionality explicitly described in technical requirements and functionality implicitly required to meet those objectives. In some cases, functional decomposition is a theoretical exercise and occurs during planning and design before any code has been written. This thought experiment involves decomposition of explicit software requirements to generate implicit tasks that will be required to achieve the necessary function and performance. In other cases, as described later, functional decomposition is the actual breakup of code into smaller chunks.

For example, the %GOBIG macro previously introduced in the “Overly Complex Code” section has a single functional requirement: create a macro that can dynamically capitalize the values of all character variables in any data set. However, during software planning and design, as SAS practitioners begin to conceptualize how this will occur, they functionally decompose the objective into additional functional steps required for success. If the software demands robustness, a first step might be to validate the existence and availability of the data set. A second step could be to create a space-delimited list of the character variables. A third step might be to exit with a return code if no character variables were found. A fourth step could be to generate lines of code dynamically that would capitalize the values with the UPCASE function.

After the thought experiment, it's clear that %GOBIG demonstrates diverse rather than discrete functionality. Developers might decide to coalesce some functions into a single module, while separating other functions into external macros that can be called from reusable macro programs. Thus, as a theoretical exercise, functional decomposition doesn't require software to be built modularly, but rather is intended only to identify distinct parts of composite software or requirements. Functional decomposition is extremely useful early in the SDLC because it enables future development work to be conceptualized, assigned, and scheduled based on overarching requirements. In project management, functional decomposition similarly describes breaking a project into discrete tasks that can be reconstituted to give a fuller perspective of the breadth and depth of the statement of work. Functional decomposition also often exposes unexpected process prerequisites and dependencies that can add complexity to software design—complexity that is much more welcome when discovered early in the SDLC than in the throes of development.

But in software development, functional decomposition does not represent only casual conversation and whiteboard diagramming; more than theory, functional decomposition is the literal cleaving of software into discrete chunks, typically saved as separate programs. For example, the ETL software demonstrated earlier in the “Novel Code” section was broken into three separate macros. However, because the macros were still confined to the same program, no performance gains could be experienced due to this limitation. The macro hinted at reusability, but the code would have had to have been cut-and-pasted into other software—and this only describes code extension or repurposing, not reuse.

During functional decomposition, the second identified implicit task of the %GOBIG requirement was to generate a space-delimited list of all character variables. The following %FINDVARS macro now performs that more specific task:

* creates a space-delimited macro variable VARLIST in data set DSN;
%macro findvars(dsn= /* data set in LIB.DSN or DSN format */,
   type= /* ALL, CHAR, or NUM to retrieve those variable types */);
%local dsid;
%local vars;
%local vartype;
%global varlist;
%let varlist=;
%local i;
%let dsid=%sysfunc(open(&dsn,i));
%let vars=%sysfunc(attrn(&dsid, nvars));
%do i=1 %to &vars;
   %let vartype=%sysfunc(vartype(&dsid,&i));
   %if %upcase(&type)=ALL or (&vartype=N and %upcase(&type)=NUM) or
         (&vartype=C and %upcase(&type)=CHAR) %then %do;
      %let varlist=&varlist %sysfunc(varname(&dsid,&i));
      %end;
   %end;
%let close=%sysfunc(close(&dsid));
%mend;

But wait, it actually does more! The developer realized that he could add one parameter and alter a single line of code to enable the macro not only to identify all character variable names, but also to identify either all numeric variable names or all variable names in general. With this additional functionality and its modular design, the %FINDVARS macro is a great candidate for inclusion in a reuse library to ensure that other SAS practitioners can benefit from its function and possibly later improve its performance.

For example, while modular, the %FINDVARS macro contains no exception handling, so it is susceptible to several easily identifiable threats. The data set might not exist or might be locked exclusively, both of which would cause the %SYSFUNC(OPEN) function to fail. This failure, however, would not be passed to the parent process because no return code exists. The code might also want to specify a unique return code if the macro is called to compile a list of character variables and none are found. Notwithstanding these vulnerabilities, additional performance can be added over time with ease when modules are managed within reuse libraries and reuse catalogs, discussed in the “Reuse Artifacts” sections in chapter 18, “Reusability.”

The %FINDVARS macro represents only the second of four implicit functions that were generated from the single functional requirement. The “Modularity” section in chapter 18, “Reusability,” demonstrates the entire modular solution that incorporates %FINDVARS into the %GOBIG macro. For a more robust solution, the “Exception Inheritance” section in chapter 6, “Robustness,” additionally demonstrates an exception handling framework that incorporates exception inheritance. In the next section, the second principle of modular design—loose coupling—is introduced and demonstrated.

Loosely Coupled Macros

Loose coupling is especially salient when modularity is achieved through SAS macro invocations as opposed to through SAS batch jobs that spawn new SAS sessions. When a new session is spawned, a SAS module runs with a clean slate—customized system options, global macro variables, library assignments, and other leftover attributes cannot influence the session, so it is more stable. However, when a module is invoked instead by calling a macro—whether defined in the program or defined externally and called with the %INCLUDE statement, the SAS Autocall Macro Facility, or the SAS Stored Compiled Macro Facility—that macro will always be susceptible to elements and environmental conditions in the current SAS session.

At the far end of the coupling spectrum are macros that are completely coupled. For example, the following %SORTME macro relies exclusively on attributes—the data set name and variable name—that are created in the program itself but not passed through the macro invocation. The macro walls, like a sieve, expect this information to percolate from the DATA step:

data mydata;
   length char1 $15;
   char1='chimichanga';
run;
%macro sortme();
%global sortme_RC;
proc sort data=mydata;
   by char1;
run;
%if &syscc>0 %then %let sortme_RC=FAILURE!;
%mend;
%sortme;

To decouple the %SORTME macro from the program, all dynamic attributes must be passed through parameters during the macro invocation:

%macro sortme(dsn= /* data set name in LIB.DSN format */,
   var= /* BY variable by which to sort */);
proc sort data=&dsn;
   by &var;
run;
%mend;
%sortme(dsn=mydata, var=char1);

The macro can now be called from other SAS programs because it relies on no host-specific information from the program besides the parameters that are passed. However, the original macro also included exception handling that tested the global macro variable &SYSCC for warning or runtime errors, and this logic must also be decoupled. Macros are porous to global macro variables in a SAS session, even those belonging to irrelevant programs. To ensure %SORTME is not reliant on or contaminated by existent values of &SYSCC or &SORTME_RC, both of these macro variables must be initialized inside the macro:

%macro sortme(dsn= /* data set name in LIB.DSN format */,
   var= /* BY variable by which to sort */);
%let syscc=0;
%global sortme_RC;
%let sortme_RC=GENERAL FAILURE;
proc sort data=&dsn;
   by &var;
run;
%if &syscc=0 %then %let sortme_RC=;
%mend;
%sortme(dsn=mydata, var=char1);

The %SORTME macro is now also decoupled from the global macro variables that it references. All information is passed to the macro through parameters, and from the macro through a single return code &SORTME_RC. The return code is initialized to GENERAL FAILURE so that an abrupt termination of the macro doesn't accidentally report a successful execution, a best practice discussed in the “Default to Failure” section in chapter 11, “Security.”

While the macro appears to be decoupled from the program, modifying the %SORTME macro invocation exposes another weakness. When the parameterized data set is changed from Mydata to PERM.Mydata, this now requires that the PERM library be available inside the macro. While the LIBNAME assignment for PERM may exist in the current SAS session, were the %SORTME macro saved as a SAS program and called as a batch job, the PERM library would not exist unless PERM were already globally defined through SAS metadata, the Autoexec.sas file, a configuration file, or other persistent method. This illustrates the importance of globally defining commonly used artifacts such as persistent SAS libraries and SAS formats.

Loosely Coupled Batch Jobs

Sometimes performance can be improved by replacing serialized program flow with invocations of batch jobs that can facilitate parallel processing and decreased execution time. Because macro variables cannot be passed to a batch job through macro parameters, all necessary information must be passed through the SYSPARM parameter of the SYSTASK statement. For example, the following program (parent process) now executes the Sortme.sas program as a batch job (child process):

libname perm 'c:perm';
data perm.mydata;
   length char1 $15;
   char1='chimichanga';
run;
%let dsn=perm.mydata;
%let var=char1;
systask command """%sysget(SASROOT)sas.exe"" -noterminal -nosplash -nostatuswin -noicon -sysparm ""&dsn &var"" -sysin ""c:permsortme.sas"" -log ""c:permsortme.log""" status=rc taskname=task;
waitfor _all_;
systask kill _all_;

The following child process should be saved as C:permsortme.sas:

libname perm 'c:perm';
%let dsn=%scan(&sysparm,1,,S);
%let var=%scan(&sysparm,2,,S);
%macro sortme(dsn=,var=);
%let syscc=0;
%global sortme_RC;
%let sortme_RC=GENERAL FAILURE;
proc sort data=&dsn;
   by &var;
run;
%if &syscc=0 %then %let sortme_RC=;
%mend;
%sortme(dsn=&dsn, var=&var);

The PERM library must be assigned inside the child process so that the PERM.Mydata data set can be accessed. However, enabling the batch job to function with the current SYSTASK invocation doesn't guarantee success for later invocations that might reference different libraries. Recall that loose coupling in part is designed to ensure that a child process can be called from as many parents as possible who can utilize the functionality. Thus, a hardcoded solution like this is never recommended. Moreover, if SAS system options were specifically required in the batch process, this request also could not be passed from parent to child given the current paradigm.

To deliver the necessary functionality, the manner in which SYSPARM is passed and parsed must become more flexible. The following updated SYSPARM value will now be passed from the parent process via SYSTASK—hardcoded here for readability, but passed through SAS macro variables in the actual SYSTASK statement:

opt=mprint * lib=perm c:perm * dsn=perm.mydata * var=char1

In this example, the asterisk is utilized to tokenize the SYSPARM parameters into individual parameters (tokens) and, within each token, the equal sign is utilized to further tokenize individual parameters into discrete elements. For example, OPT=MPRINT is first read, after which OPT is identified to represent the command to invoke the SAS OPTIONS statement, while MPRINT is identified as the specific option to invoke.

The updated parent process follows, with only the SYSPARM value modified:

libname perm 'c:perm';
data perm.mydata;
   length char1 $15;
   char1='chimichanga';
run;
%let dsn=perm.mydata;
%let var=char1;
systask command """%sysget(SASROOT)sas.exe"" -noterminal -nosplash -nostatuswin -noicon -sysparm ""opt=mprint * lib=perm c:perm * dsn=&dsn * var=&var"" -sysin ""c:permsortme.sas"" -log ""c:permsortme.log""" status=rc taskname=task;
waitfor _all_;
systask kill _all_;

The updated child process, saved again as C:permsortme.sas, now includes an additional %PARSE_PARM macro that tokenizes and parses the &SYSPARM automatic macro variable:

%macro parse_parm();
%local tok;
%let i=1;
%do %while(%length(%scan(&sysparm,&i,*))>1);
   %let tok=%scan(&sysparm,&i,*);
   %if %upcase(%scan(&tok,1,=))=LIB %then %do;
      libname %scan(%scan(&tok,2,=),1,,S) "%scan(%scan(&tok,2,=),2,,S)";
      %end;
   %else %if %upcase(%scan(&tok,1,=))=OPT %then %do;
      options %scan(&tok,2,=);
      %end;
   %else %if %upcase(%scan(&tok,1,=))=DSN %then %do;
      %global dsn;
      %let dsn=%scan(&tok,2,=);
      %end;
   %else %if %upcase(%scan(&tok,1,=))=VAR %then %do;
      %global var;
      %let var=%scan(&tok,2,=);
      %end;
   %let i=%eval(&i+1);
   %end;
%mend;
%parse_parm;
%macro sortme(dsn=,var=);
%let syscc=0;
%global sortme_RC;
%let sortme_RC=GENERAL FAILURE;
proc sort data=&dsn;
   by &var;
run;
%if &syscc=0 %then %let sortme_RC=;
%mend;
%sortme(dsn=&dsn, var=&var);

When the parent process executes and calls the Sortme.sas batch job, the %PARSE_PARM macro is able to assign one or more SAS libraries dynamically, ensuring not only that this parent process can pass the PERM library invocation, but also that additional, unspecified parents will be able to pass different library definitions. Although redundant (because the SYSTASK statement itself can specify SAS system options), the %PARSE_PARM macro can also recognize SAS system options and specify these with the OPTIONS statement. Finally, the macro variables &DSN and &VAR that represent the data set name and BY variable, respectively, are also still passed via SYSPARM, albeit in a more flexible form.

This type of dynamism may seem gratuitous and, for many intents and purposes, the added code complexity (inasmuch as time spent designing, developing, and testing a solution) may not provide sufficient business value to warrant its inclusion. Notwithstanding, software that truly demands loose coupling to support development and reuse of independent modules will require this extensive decoupling if modules are intended to be saved as separate SAS programs and executed as batch jobs.

To improve readability in this example, no exception handling is provided; however, in production software, all parameters should be validated and, with each successive level of tokenization, additional exception handling should prescribe program flow when exceptional values are encountered. Exception handling techniques are demonstrated throughout chapter 6, “Robustness,” and the validation of macro parameters and return codes is discussed in the “Macro Validation” sections in chapter 11, “Security.”

Passing SAS Global Macro Variables

Passing a global macro variable through a SAS macro invocation may seem uncanny, but it's one of the final indicators of loosely coupled code. For example, the following code creates PERM.Mydata, then prints the data set using a title supplied through the global macro variable &TIT1:

libname perm 'c:perm';
%let tit1=Mmmmm Mexican food;
data perm.mydata;
   length char1 $15;
   char1='chimichanga';
run;
proc print data=perm.mydata;
   title "&tit1";
run;

The PRINT procedure simulates a more complex process, so, espousing modular design, a SAS practitioner might wrap this functionality inside a macro module:

%macro print(dsn= /* data set name in LIB.DSN format */);
proc print data=&dsn;
   title "&tit1";
run;
%mend;
%print(dsn=perm.mydata);

The %PRINT macro can now be both defined and invoked in the same program, or the %PRINT macro could be saved as a separate SAS program so that it can be utilized by other parent processes as well. This second usage, however, exposes the vulnerability that the global macro variable &TIT1, while defined in this parent process, is not necessarily defined in other parent processes. Thus, as demonstrated in the following code, loose coupling necessitates that even global macro variables be explicitly passed through macro parameters:

%macro print(dsn= /* data set name in LIB.DSN format */,
   title1= /* title */);
proc print data=&dsn;
   title "&title1";
run;
%mend;
%print(dsn=perm.mydata, title1=&tit1);

Although this additional effort may seem redundant, it is necessary to ensure loose coupling. Because loose coupling represents the tiny pinhole in black-box design through which all interaction with a module must be prescribed and limited, if %PRINT is receiving information directly from global macro variables (in lieu of being appropriately passed parameters), the integrity of the macro is compromised. Moreover, the revised %PRINT macro can now be saved as a SAS program and called by a subsequent, independent parent process which will easily be able to identify the necessity to pass the parameter TITLE1 due to its presence in the macro definition.

Encapsulating Parents

The first test for software encapsulation is to run software from a fresh SAS session in which no code has been executed. Because modified SAS system options, global macro variables, WORK library data sets, open file streams, and locked data sets can all persist until a SAS session is terminated, only a clean slate can ensure a stable, consistent, uncontaminated environment. This freshness is one of the primary benefits of spawning SAS batch jobs, which execute in new SAS sessions.

It's critical that all global macro variables be uniquely named to avoid confusion, collisions, and corruption. Confusion results when software readability is diminished because of similarly named variables or, in some cases, reuse of macro variable names. Collision and corruption can occur when macro variable names are not unique and interact in unexpected ways. For example, the following code initially creates the global macro variable &PATH to represent the SASROOT directory:

%let path=%sysget(SASROOT);
%put PATH: &path;

However, when a %PATHOLOGY macro is called, it reassigns the &PATH macro, unknowingly overwriting the original value:

%macro pathology();
%global path;
%let path=pathogen;
%mend;
%pathology;
%put PATH: &path;
PATH: pathogen

To overcome this vulnerability, where global macro variables are intended to be enduring, consider macro names that are unlikely to be reused, even erring on the side of long and unwieldy to ensure that reuse is unlikely. Global macro variables are not the only vulnerability; local macro variables can also contaminate parent processes. The following code is intended to write the ASCII characters 65 through 69 (i.e., A through F) twice:

%macro inner(); * child;
%do i=65 %to 69;
   %put -- %sysfunc(byte(&i));
   %end;
%mend;
%macro outer(); * parent;
%do i=1 %to 2;
   %put &i;
   %inner;
   %end;
%mend;
%outer;

However, the code iterates only once and produces the following output:

1
-- A
-- B
-- C
-- D
-- E

In this example, because the macro variable &I in the %INNER macro was not defined as a local macro variable, it overwrites the &I in the %OUTER macro. When %INNER completes the first iteration, the value of &I is 70 and, when this value is assessed by the %DO loop within %OUTER, the %DO loop exits because 70 is greater than the threshold value 2. To remedy this error, %I must at least be defined as local within %INNER, but because %OUTER itself could also be invoked at some point as a child process, both instances of %I should be distinguished as local macro variables:

* CHILD;
%macro inner();
%local i;
%do i=65 %to 69;
   %put -- %sysfunc(byte(&i));
   %end;
%mend;
* PARENT;
%macro outer();
%local i;
%do i=1 %to 2;
   %put &i;
   %inner;
   %end;
%mend;
%outer;

While these examples have demonstrated the perils of macro variable creation and initialization, child processes can have other unintended effects on parent processes. For example, if a child process fails to unlock a data set (that it has explicitly locked), fails to close a data stream (that it has opened), fails to redirect log output (that it has directed with PRINTTO), or fails to KILL (or WAITFOR) a SYSTASK statement, each of these events can adversely affect functionality and performance once program flow returns to the parent process. In all cases, the best prevention of damage to parent processes is to launch child processes as batch jobs while the best remedy to limit damage is to prescribe exception handling that identifies exceptions and runtime errors within child processes and communicates these to parent processes.

Batch processing can eliminate many of the security concerns that exist when a child process is called. For example, in the black-box paradigm, the parent provides inputs to and receives outputs and return codes from children, but should be unaware of other child functionality. For example, in calling a child process by invoking a SAS macro, that child process could alter global macro variables or delete the entire WORK library relied upon by the parent process—because both parent and child are running in the same session. However, when a child process is instead initiated as a batch job, the new SAS session cannot access the global macro variables, WORK library, or system options of the parent session, thus providing protection against a number of threats.

In other cases, threats cannot be avoided, but they must be detected. An exception handling framework that detects and handles exceptions and runtime errors in child processes, provides necessary exception inheritance to parent processes, and prescribes a fail-safe path (if process or program termination is necessary) is the best method to minimize damage caused by software failure within child processes. Fail-safe paths are further discussed in the “Fail-Safe Path” section in chapter 11, “Security.”

Encapsulating Children

Nobody puts Baby in a corner, but sometimes you need to put Baby in a big black box. As demonstrated in the previous “Loosely Coupled” section, macros are susceptible to elements of the SAS session, such as global macro variables, system options, and WORK library data sets. Thus, modules should only rely on information passed through SAS macro parameters or the SYSPARM option. In some cases, module functionality will be dependent upon SAS system options, and if user permissions allow certain options to be changed within the SAS session, it is possible that these could have been modified.

The most effective way to protect child processes is to ensure they receive the necessary information from the parent, whether passed through macro parameters, the SYSTASK parameter, or some other modality. Especially where these parameters are dynamically passed, quality control routines within child processes should validate parameters to ensure that sufficient (and valid) information exists to continue. Macro validation is further discussed and demonstrated in the “Macro Validation” sections in chapter 11, “Security.”