Capabilities and restrictions

There are two basic equivalencies that you will use to convert JCL cards to SCLM macro statements:

Every JCL EXEC card with PGM=abc will correspond to an FLMTRNSL macro with COMPILE=abc in your language definition. Conditional execution of BUILD translators may be addressed through use of the FLMTCOND macro.
Every JCL DD card will correspond to an FLMALLOC macro or an FLMSYSLB macro associated with an FLMALLOC macro in your language definition.
In the case of STEPLIB, the JCL DD card will correspond to the DSNAME parameter in the FLMTRNSL macro. A STEPLIB concatenation of more than one data set would use the TASKLIB parameter. The TASKLIB parameter is set to the ddname associated with the data set concatenation. FLMCPYLBs are used to specify the data sets on an FLMALLOC macro with DDNAME set to the TASKLIB ddname. When both DSNAME and TASKLIB are specified, the DSNAME data set is searched first, followed by the TASKLIB data sets, followed by the system concatenation.

In the case of SYSLIB-type ddnames for a compiler, the data sets must be specified FLMSYSLBs. Then either ALCSYSLB=Y must be specified on the FLMLANGL macro and/or FLMCPYLBs must be specified for the appropriate FLMALLOC macros. For an example of this, refer to the COBOL (FLM@COB2) or C/370™ (FLM@C370) language definitions supplied with SCLM.

Three areas of restrictions can prevent a simple, one-to-one translation of JCL cards to SCLM macro statements:

Backward referencing of data definition names (DDs)
If a JCL DD card uses the "refer back" technique to reference a previous DD card (other than the card in the preceding step), or if a DD card refers to a data set using a ddname that differs from the data set's ddname in a prior step, conversion to an SCLM language definition can involve the use of an intermediate translator or a ddname substitution list in order to allocate the correct data set name for the program. (An intermediate translator is not needed if the succeeding translator supports DDNAME substitution lists; in this case, the succeeding translator can "hard code" the DDNAME and use IOTYPE=U on the FLMALLOC macro.)
Complex conditional execution
A JCL deck that specifies skipping all steps after a specified condition code from one or more previous steps is directly converted to appropriate FLMTRNSL macros with appropriate GOODRC values. Other conditional executions of BUILD translators can be addressed by using the FLMTCOND macro. For example, if the JCL is set up to run BUILD translator X if any previous return code is 4, but run Build translator Y if any previous return code is 8, you can use the FLMTCOND macro. FLMTCOND is only valid for use with BUILD translators. Conditional execution of non-BUILD translators can require modification of the translators or interface programs to handle the control of execution.
TSO Address Space compatibility
Some programs that run from JCL will not run in the TSO Address Space in which SCLM resides without a special interface translator. IBM® has provided interface programs for several common IBM programs with this characteristic. For example, the FLMTMSI (SCRIPT), FLMTMJI (JOVIAL), and FLMTMMI (DFSUNUB0) translators all use the TSO Service Facility IKJEFTSR.

If you have JCL that runs program XYZ without any errors, but fails when you try to run program XYZ from an FLMTRNSL macro, this may be the problem. You must write a translator to call the program using IKJEFTSR.

The following sections describe how to convert JCL cards and decks into functionally equivalent SCLM language definitions and provide suggested strategies for working around restrictions and conflicts.