SDF INCLUDEs

When compilation of a block of HAL/S code takes place, the Simulation Data File (SDF) produced by Phase 3 of the compiler contains a large amount of information describing the format of the block, the variables it involves, the data types of any formal parameters and function returns, etc. In particular, therefore, it contains all of the information which is normally placed into that block’s template, and which must be placed in the code for any other block referencing that one. It is possible to instruct the compiler to INCLUDE not a template, but an SDF, and so to read this information directly from the Simulation Data File. The result in certain cases can be a significant saving in time, particularly when large COMPOOLs are being included.

No change needs to occur within the HAL/S source code itself. This means that with the possible exception of a modification in JCL, the use of this new facility can remain completely transparent to the user as long as an SDF file is available to the compiler.

When the compiler comes upon a D INCLUDE TEMPLATE compiler directive it will begin its search by looking through the SDF library, analogous to the template library. This search goes through the partitioned dataset specified on a DD card with ddname HALSDF, and then through that specified on the OUTPUT5 DD card. If both of these

HAL/S-FC User’s Manual USA003090 32.0/17.0

3-10 November 2005

searches are unsuccessful, it then goes on to search for a template in the regular way (i.e., by referencing the INCLUDE DD and OUTPUT6 DD cards).

If all compilations are taking place in a single job, (see Section 3.3.1), no new JCL is needed to allow SDFs to be included; the catalogued procedures will do this automatically. Otherwise, as is the case for templates, JCL modifications must be made, either by modifying the HAL.OUTPUT5 DD card to refer to a permanent dataset, or by adding a HAL.HALSDF DD card. In either case, the dataset referred to should be a partitioned dataset serving as a library of SDFs for the program complex. All JCL modifications and considerations here are precisely analogous to those discussed in Sections 3.3.2 and 3.4 above for OUTPUT6 and INCLUDE DD cards.

Two new optional subcommands (“SDF” and “NOSDF”) for the INCLUDE directive are now available with respect to the facility for SDF INCLUDEs. “D INCLUDE TEMPLATE

<block name> NOSDF” may be coded to instruct the compiler not to look for any SDFs but to engage only in a search for templates. This may be used for example when you know that no SDFs produced for the unit being INCLUDEd are available. Furthermore, since only SDFs produced by compiler release 17 or later possess the correct structure for use by this new facility, the compiler checks the SDF version for > 17. If true, it uses the SDF; otherwise, it searches the template library. In addition, although compilations producing object code for one machine generate templates which may be included by other compilations producing object code for a different machine, this is not the case with SDFs; again, the NOSDF subcommand should be coded to force template searching only. If you specify “SDF”, the compiler will check to see that any SDFs searched are compatible with both the target machine or current compiler release. If there is any code discrepancy between the SDF and program complex, the compiler will go directly to search for the appropriate template.

The second subcommand now available can be used only when the block being referenced is a COMPOOL. COMPOOLs in many applications may be extremely large, and individual programs or COMSUBs will typically reference only a few of the variables included in them. The templates for a COMPOOL by its very structure is just as large as the COMPOOL itself, and thus much extraneous information is passed to the compiler when a COMPOOL template is INCLUDEd. By coding:

D INCLUDE SDF <name of COMPOOL>:<variable list>;

it is possible to instruct the compiler to retrieve only the information actually needed from the SDF for the external COMPOOL. <variable list> in this case is simply a list of one or more symbols defined in the COMPOOL named. Structure templates may also be included (and indeed must be if structure variables employing them are to be included).

This is done by coding STRUCTURE <template name>. If <variable list> is long, it may be continued onto several successive ‘D’ cards following the INCLUDE SDF directive.

For example, suppose a COMPOOL named ALPHA contains a large number of variables as well as structure templates, and that information about only the variables BETA_STRUC, GAMMA, and DELTA are needed for the compilation of some procedure.

BETA_STRUC is defined in the compool as being a (qualified) BETA-STRUCTURE;

GAMMA is defined as being a GAMMA-STRUCTURE; and so is unqualified. DELTA is a scalar. Instead of coding

D INCLUDE TEMPLATE ALPHA

which would cause the template for the entire COMPOOL to be INCLUDEd, one can now code:

D INCLUDE SDF ALPHA: STRUCTURE BETA, D STRUCTURE GAMMA, BETA_STRUC,

D GAMMA, DELTA;

Notice that in order to employ this new SDF look-up facility, the compiler directive must have the form INCLUDE SDF <block name>. If INCLUDE <member name> is coded without the SDF keyword, search for an SDF will not take place (see Section 5.2 for more information on this form of the INCLUDE statement).

USA003090 HAL/S-FC User’s Manual 32.0/17.0

November 2005 3-12

This page is intentionally left blank.