Specifying Values for Different Environments - IBM-REXX

As described in the previous topic (Changing the Default Values for Initializing an Environment), you can change the default parameter values IRXINIT uses to initialize a language processor environment by providing your own parameters modules. You can also call the initialization routine, IRXINIT, to initialize a new environment. When you call IRXINIT, you can pass parameter values on the call.

Whether you provide your own load modules or invoke IRXINIT directly, you cannot change some parameters. You can use other parameters only in language processor environments that are not integrated into TSO/E or in environments that are integrated into TSO/E. In addition, there are some restrictions on parameter values depending on the values of other parameters in the same environment and on parameter values that are defined for the previous environment. This topic describes the parameters you can and cannot use in the two types of language processor environments. The topic also describes different considerations for using the parameters.

Parameters You Cannot Change

There are two parameters that have fixed values and that you cannot change. The parameters are:

ID
The value must be IRXPARMS. If you provide your own load module, you must specify IRXPARMS for the ID. If you call IRXINIT, IRXINIT ignores any value you pass and uses the default IRXPARMS.

VERSION
The value must be 0200.If you provide your own load module or call IRXINIT, specify 0200 for the version.

Parameters You Can Use in Any Language Processor Environment

There are several parameters that you can specify in any language processor environment. That is, you can use these parameters in environments that are integrated into TSO/E and in environments that are not integrated into TSO/E. The following describes the parameters and any considerations for specifying them.

LANGUAGE
The language code. The default is ENU for US English in mixed case (upper and lowercase).

PARSETOK
The token for the PARSE SOURCE instruction. The default is a blank.

ADDRSPN
The name of the address space. TSO/E provides the following defaults:

  • IRXPARMS – MVS
  • IRXTSPRM – TSO/E
  • IRXISPRM – ISPF

You can change the address space name for any type of language processor environment. If you write applications that examine the PARMBLOCK for an environment and perform processing based on the address space name, you must ensure that any changes you make to the ADDRSPN field do not affect your application programs.

FLAGS
The FLAGS field is a fullword of bits that are used as flags. You can specify any of the flags in any environment. However, the value you specify for each flag depends on the purpose of the flag. In addition, there are some restrictions for various flag settings depending on the flag setting in the previous environment. The following explains the different considerations for the setting of some flags.

Note:If your installation uses ISPF, there are several considerations about the flag settings for language processor environments that are initialized for ISPF.

TSOFL
The TSOFL flag indicates whether the new environment is integrated into TSO/E.

If IRXINIT is initializing an environment in a non-TSO/E address space, the flag must be off (set to 0). The TSOFL flag must also be off if the environment is being initialized as a reentrant environment. You can initialize reentrant environments only by explicitly calling the IRXINIT routine.

If IRXINIT is initializing an environment in the TSO/E address space, the TSOFL flag can be on or off. If the flag is on, the environment is integrated into TSO/E. REXX execs that run in the environment can use TSO/E commands, such as ALLOCATE and PRINTDS, and TSO/E programming services that are described in z/OS TSO/E Programming Services (for example, the parse service routine and TSO/E I/O service routines, such as PUTGET). The exec can also use ISPF services and can call and be called by TSO/E CLISTs.

If the flag is off, the environment is not integrated into TSO/E. In this case, REXX execs cannot use TSO/E commands, TSO/E programming services, or ISPF services, or interact with CLISTs. If the exec contains these type of services, unpredictable results can occur.

If the TSOFL flag is on (the environment is integrated into TSO/E), then:

  • The RENTRANT flag must be off (set to 0)
  • The names of the replaceable routines in the module name table must be blank. You cannot provide replaceable routines in environments that are integrated into TSO/E. Note that the module name table also includes several fields for the names of REXX exit routines (for example, EXECINIT, ATTNROUT, IRXEXECX, and EXECTERM). If the environment is integrated into TSO/E (TSOFL flag is on), you can specify the exits in the module name table.
  • The INDD and OUTDD fields in the module name table must be the defaults SYSTSIN and SYSTSPRT
  • The subpool number in the SUBPOOL field must be 78, in decimal. The TSOFL flag cannot be on (set to 1) if a previous language processor environment in the environment chain has the TSOFL flag off.

NEWSTKFL
The NEWSTKFL flag indicates whether IRXINIT initializes a new data stack for the new environment.

If you set the NEWSTKFL off for the new environment that IRXINIT is initializing, you must ensure that the SPSHARE flag is on in the previous environment. The SPSHARE flag determines whether the subpool is shared across MVS tasks.If the NEWSTKFL flag is off for the new environment and the SPSHARE flag is off in the previous environment, an error occurs when IRXINIT tries to initialize the new environment.

Module Name Table
The module name table contains the ddnames for reading and writing data and for loading REXX execs, and the names of replaceable routines and exit routines.The fields you can specify in any address space are described below. You can use the replaceable routines only in:

  • Non-TSO/E address spaces
  • The TSO/E address space if the language processor environment is initialized with the TSOFL flag off (the environment is not integrated with TSO/E).

The module name table also contains fields for several REXX exits. The fields are EXECINIT for the exec initialization exit, ATTNROUT for the attention handling exit, IRXEXECX for the exec processing exit (for the IRXEXEC routine), and EXECTERM for the exec termination exit. You can specify exits for exec initialization (EXECINIT), exec processing (IRXEXECX), and exec termination (EXECTERM) in any type of language processor environment. You can provide an attention handling exit (ATTNROUT) only for environments that are integrated into TSO/E.

LOADDD
The name of the DD from which the system loads REXX execs. The default TSO/E provides in all three parameters modules is SYSEXEC.

The DD from which the system loads REXX execs depends on the name specified in the LOADDD field and the setting of the TSOFL and NOLOADDD flags. If the TSOFL flag is on, the language processor environment is initialized in the TSO/E address space and is integrated into TSO/E. In TSO/E, you can store REXX execs in data sets that are allocated to SYSPROC or to the DD specified in the LOADDD field (the default is SYSEXEC). The NOLOADDD flag indicates whether the system searches SYSPROC only or whether the system searches the DD specified in the LOADDD field (SYSEXEC) first, followed by SYSPROC.

If the TSOFL flag is off, the system loads REXX execs from the DD specified in the LOADDD field.

Note: For the default parameters modules IRXTSPRM and IRXISPRM, the NOLOADDD flag is off (0). Therefore, the system searches SYSEXEC followed by SYSPROC. To have the system search SYSPROC exclusively, you can provide your own parameters module. TSO/E users can also use the EXECUTIL command to dynamically change the search order.

The system opens the specified DD the first time a REXX exec is loaded. The DD remains open until the environment under which it was opened is terminated. If you want the system to close the DD after each REXX exec is fetched, you must set the CLOSEXFL flag on.Users can also use the EXECUTIL command to dynamically close the DD. Note that the system may close the data set at certain points.

EXECINIT
The name of an exit routine that gets control after the system initializes the REXX variable pool for a REXX exec, but before the language processor starts processing the exec.

IRXEXECX
The name of an exit routine that is invoked whenever the IRXEXEC routine is called.

EXECTERM
The name of an exit routine that is invoked after a REXX exec has completed processing, but before the system terminates the REXX variable pool.

Host Command Environment Table
The table contains the names of the host command environments that are valid for the language processor environment and the names of the routines that the system calls to process commands for the host command environment.

When IRXINIT creates the host command environment table for a new language processor environment, IRXINIT checks the setting of the NEWSCFL flag. The NEWSCFL flag indicates whether the host command environments that are defined for the previous language processor environment are added to the table that is specified for the new environment.If the NEWSCFL flag is 0, IRXINIT creates the table by copying the host command environment table from the previous environment and concatenating the entries specified for the new environment. If the NEWSCFL flag is 1, IRXINIT creates the table using only the entries specified for the new environment.

Function Package Table
The function package table contains information about the user, local, and system function packages that are available in the language processor environment.

When IRXINIT creates the function package table for a new language processor environment, IRXINIT checks the settings of the USERPKFL, LOCPKFL, and SYSPKFL flags. The three flags indicate whether the user, local, and system function packages that are defined for the previous language processor environment are added to the function package table that is specified for the new environment.If a particular flag is 0, IRXINIT copies the function package table from the previous environment and concatenates the entries specified for the new environment. If the flag is 1, IRXINIT creates the function package table using only the entries specified for the new environment.

Parameters You Can Use for Environments That Are Integrated Into TSO/E

There is one parameter that you can use only if a language processor environment is initialized in the TSO/E address space and the TSOFL flag is on.The parameter is the ATTNROUT field in the module name table. The ATTNROUT field specifies the name of an exit routine for attention processing.The exit gets control if a REXX exec is running in the TSO/E address space and an attention interruption occurs. “REXX Exit Routines” on page 466 describes the attention handling exit.

The ATTNROUT field must be blank if the new environment is not being integrated into TSO/E, that is, the TSOFL flag is off.

Parameters You Can Use for Environments That Are Not Integrated Into TSO/E

There are several parameters that you can specify only if the environment is not integrated into TSO/E (the TSOFL flag is off). The following describes the parameters and any considerations for specifying them.

SUBPOOL
The subpool number in which storage is allocated for the entire language processor environment. In the parameters module IRXPARMS, the default is 0. You can specify a number from 0 – 127.

If the environment is initialized in the TSO/E address space and the TSOFL flag is on, the subpool number must be 78, in decimal.

Module Name Table
The module name table contains the names of DDs for reading and writing data and for loading REXX execs, and the names of replaceable routines and exit routines. The fields you can specify if the environment is not integrated into TSO/E (the TSOFL flag is off) are described below.

INDD
The name of the DD from which the PARSE EXTERNAL instruction reads input data. The default is SYSTSIN.

If IRXINIT initializes the environment in the TSO/E address space and the TSOFL flag is on, IRXINIT ignores the ddname.

If the specified DD is opened by a previous language processor environment, even an environment on a higher task, and the INDD value for the new environment is obtained from the previous environment, the new environment uses the DCB of the previous environment Sharing of the DCB in this way means:

  • A REXX exec running in the new environment reads the record that follows the record the previous environment read.
  • If the previous environment runs on a higher task and that environment is terminated, the new environment reopens the DD. However, the original position in the DD is lost.

OUTDD
The name of the DD to which data is written for a SAY instruction, when tracing is started, or for REXX error messages. The default is SYSTSPRT.

If IRXINIT initializes the environment in the TSO/E address space and the TSOFL flag is on, IRXINIT ignores the ddname.If you initialize two environments by calling IRXINIT and explicitly pass the same ddname for the two different environments, when the second environment opens the DD, the open fails. The open fails because the data set can only be opened once. The OPEN macro issues an ENQ exclusively for the ddname.

IOROUT
The name of the input/output (I/O) replaceable routine.If the environment is initialized in the TSO/E address space and the TSOFL flag is on, this field must be blank.

EXROUT
The name of the load exec replaceable routine.If the environment is initialized in the TSO/E address space and the TSOFL flag is on, this field must be blank.

GETFREER
The name of the storage management replaceable routine.

If more than one language processor environment is initialized on the same task and the environments specify a storage management replaceable routine, the name of the routine must be the same. If the name of the routine is different for two environments on the same task, an error occurs when IRXINIT tries to initialize the new environment.

If the environment is initialized in the TSO/E address space and the TSOFL is on, the GETFREER field must be blank.

STACKRT
The name of the data stack replaceable routine.If the environment is initialized in the TSO/E address space and the TSOFL flag is on, this field must be blank.

IDROUT
The name of the user ID replaceable routine. The system calls the routine whenever an exec uses the USERID built-in function. If the environment is initialized in the TSO/E address space and the TSOFL flag is on, this field must be blank.

MSGIDRT
The name of the message identifier replaceable routine. The system calls the routine to determine whether message IDs are displayed. If the environment is initialized in the TSO/E address space and the TSOFL flag is on, this field must be blank.

Flag Settings for Environments Initialized for TSO/E and ISPF

If your installation uses ISPF, there are several considerations about flag settings for language processor environments that are initialized for TSO/E and ISPF. In the default IRXISPRM parameters module for ISPF, most of the mask settings for the flags parameters are 0, which means IRXINIT uses the values from TSO/E (IRXTSPRM module).If you provide your own IRXISPRM load module, you should not change the mask values for the following flags. The mask values for these flags should be 0.

  • CMDSOFL — command search order flag
  • FUNCSOFL — function and subroutine search order flag
  • NOSTKFL — no data stack flag
  • NOREADFL — no read (input file) flag
  • NOWRTFL — no write (output file) flag
  • NEWSTKFL — new data stack flag
  • NOESTAE — recovery ESTAE flag
  • RENTRANT — reentrant/non-reentrant flag
  • SPSHARE — subpool sharing flag

The values for these flags in ISPF should be the same as the values that IRXINIT uses when initializing an environment for the TSO/E session. When IRXINIT initializes an environment for ISPF, IRXINIT uses the values defined for the previous environment (TSO/E) because the mask settings are 0. Using the same values for these flags for both TSO/E and ISPF prevents any processing problems between the ISPF and TSO/E sessions.

If you do want to change one of the flag values, change the value in the IRXTSPRM parameters module for TSO/E. The change is inherited by ISPF when IRXINIT initializes an environment for the ISPF screen. For example, suppose you want to change the search order the system uses for locating external functions and subroutines.The FUNCSOFL flag controls the search order. You can provide a IRXTSPRM parameters module for TSO/E and change the flag setting. ISPF inherits the changed flag setting when IRXINIT initializes an environment.

Using SYSPROC and SYSEXEC for REXX Execs

In the module name table, the LOADDD field contains the name of the DD from which REXX execs are fetched. The default TSO/E provides for non-TSO/E, TSO/E, and ISPF is SYSEXEC.If you customize REXX processing either by providing your own parameters modules or explicitly calling IRXINIT to initialize an environment, it is suggested that you use the ddname SYSEXEC. The TSO/E REXX documentation refers to this DD as SYSEXEC.

In TSO/E, you can store both interpreted and compiled REXX execs in data sets that are allocated to either SYSPROC or SYSEXEC. You can use SYSPROC for both TSO/E CLISTs and REXX execs. SYSEXEC is for REXX execs only. If an exec is in a data set that is allocated to SYSPROC, the exec must start with a comment containing the characters REXX within the first line (line 1).This is referred to as the REXX identifier and is required in order for the TSO/E EXEC command to distinguish REXX execs from CLISTs.

In the parameters module, the NOLOADDD flag controls the search order for REXX execs. The flag indicates whether the system searches the DD specified in the LOADDD field (SYSEXEC). With the defaults that TSO/E provides, the system searches SYSEXEC first, followed by SYSPROC. The system searches SYSPROC only if the language processor environment is integrated into TSO/E.

If your installation plans to use REXX, it is suggested that you store your execs in data sets that are allocated to SYSEXEC, rather than using SYSPROC. Using SYSEXEC makes it easier to maintain your REXX execs. If your installation uses many CLISTs and does not plan to have a large number of REXX execs, you may want to use SYSPROC only and not use SYSEXEC. To use SYSPROC only, you can provide your own IRXTSPRM parameters module for TSO/E or use the EXECUTIL SEARCHDD command.

If you provide your own IRXTSPRM parameters module, specify the following values for the NOLOADDD mask and flag fields:

  • NOLOADDD_MASK — 1
  • NOLOADDD_FLAG — 1

With these values, the system does not search SYSEXEC and searches SYSPROC only.You can make your parameters module available on a system-wide basis for your entire installation.You can also make your module available only to a group of users by making it available only on a logon level. You can place your IRXTSPRM module in a data set specified in the STEPLIB concatenation in the logon procedure. You must ensure that the data set is higher in the concatenation than any other data set that contains IRXTSPRM.

You need not provide your own IRXISPRM parameters module for ISPF because the NOLOADDD mask value in the default IRXISPRM module is 0, which means IRXINIT uses the flag setting from the previous environment. In this case, the previous environment is the value from the IRXTSPRM module you provide.

You can also use the EXECUTIL command with the SEARCHDD operand to change the search order and have the system search SYSPROC only.You can use EXECUTIL SEARCHDD(NO) in a start-up CLIST or REXX exec that is part of a logon procedure. Users can also use EXECUTIL SEARCHDD(NO) to dynamically change the search order during their TSO/E and ISPF sessions.

In TSO/E, you can also use the TSO/E ALTLIB command to define alternate exec libraries in which to store implicitly executed REXX execs. Using ALTLIB, you can specify alternate libraries on the user, application, or system level and activate and deactivate individual exec libraries as needed

Compressing REXX Execs
Compression provides a potential performance benefit by reducing the size of the in-storage image of the exec. This could have benefits for all users on a system for execs that are stored in VLF. If you do not want certain execs to be compressed, you can do any one of the following:

  • allocate the exec data set to the SYSPROC user level file using the TSO/E ALTLIB command, or to a file that can contain only REXX execs, such as SYSEXEC
  • include the character string SOURCELINE in the exec, outside of a comment
  • specify the compression indicator COMMENT.

REXX execs in the SYSPROC system level, or a CLIST application level library as defined by ALTLIB,are eligible for compression.TSO/E REXX can automatically compress an exec, or you can request that a REXX exec be compressed.

In general, compression eliminates comment text and leading and trailing blanks, and replaces blank lines with null lines, which preserves the line numbering in the exec. For comments, the system removes the comment text but keeps the beginning and ending comment delimiters /* and */. This preserves the exec line numbering if the comment spans more than one line. Blanks and comments within literal strings (delimited by either single or double quotation marks) are not removed. Blanks or comments within a Double-Byte Character Set (DBCS) string are not removed.

  • Automatic Compression

– If the system automatically compresses the exec, it replaces the first line of the exec (the comment line containing the characters “REXX”) with the comment /*%NOCOMMENT*/. If you review a dump of VLF, the /*%NOCOMMENT*/ comment is an indicator that the exec is compressed. For example, if the initial line 1 comment contains:

/* REXX */

then after compression, line 1 contains:

/*%NOCOMMENT*/

However, if the line 1 comment also contains other special options (the comment starts with /*%), TSO/E REXX inserts the option NOCOMMENT ahead of the other keyword options in line 1. The remaining keyword options of line 1 are not removed (compressed) from the line 1 comment. For example, if the initial line 1 comment contains:

/*% REXX xxxxxxx yyyyyyy */

then after compression line 1 contains:

/*%NOCOMMENT REXX xxxxxxx yyyyyyy */

If the system finds an explicit occurrence of the characters SOURCELINE outside of a comment in the exec, it does not compress the exec. For example, if you use the SOURCELINE built-in function, the exec is not compressed. If you use a variable called “ASOURCELINE1”, the system does not compress the exec because it locates the characters SOURCELINE within that variable name. Note that the system does compress the exec if the exec contains a “hidden” use of the characters SOURCELINE. For example, you may concatenate the word SOURCE and the word LINE and then use the INTERPRET instruction to interpret the concatenation or you may use the hexadecimal representation of SOURCELINE. In these cases, the system compresses the exec because the characters SOURCELINE are not explicitly found.

  • Controlled Compression

– To request compression of the REXX exec, the exec must begin with a special comment in line 1. A comment is called a special comment if it is the first comment in line 1 and the begin comment delimiter /* is immediately followed by the special comment trigger character %. That is, /*%

The trigger character is followed by one or more keyword options. If you specify more than one keyword option, separate them by one or more blanks. You can also use blanks between the trigger character and the first keyword option for better readability. Keyword options can be lower case, upper case, or mixed case. The following are some examples of using a special comment. Note that there are no changes to the special comment after compression.

/*% REXX xxxx yyyy NOCOMMENT */

then after compression the line is unchanged, except trailing blanks are removed, and the line contains:

/*% REXX xxxx yyyy NOCOMMENT*/

The scan for keyword options ends by: - an end comment delimiter (*/) - another begin comment delimiter /* to start a nested comment - the end of the line.Keyword options cannot continue onto the second physical line, even if the comment itself continues to line two. If TSO/E REXX does not recognize a keyword option, it is ignored.

Rule:DBCS characters cannot be used within the special comment in line 1 to specify keyword options. All keyword options must be specified using the EBCDIC character set. The compression indicator keyword options are COMMENT and NOCOMMENT, where:

COMMENT
indicates the exec is NOT to be compressed (the exec will contain comments).

NOCOMMENT
indicates the exec is to be compressed (the exec will NOT contain comments).

The COMMENT and NOCOMMENT compression indicators are only valid for execs which are invoked implicitly and are found in either a SYSPROC library or an application level CLIST library.

The following are some examples of using COMMENT and NOCOMMENT. In all of these examples the exec is invoked implicitly and is found in the SYSPROC CLIST library.

  • To indicate an exec is to be compressed, the author of the REXX exec might code the following:
  • /*%NOCOMMENT REXX */
    Say ’This exec will be compressed’
    x = 5 /* This comment will be removed from the exec */
    say ’x is ’ x exit 0 /* leave the exec */
  • To indicate an exec is NOT to be compressed, the author of the REXX exec might code the following:
  • /*%COMMENT REXX */
    Say ’This exec will not be compressed’
    x = 5 /* This comment will not be removed from the exec */
    say ’x is ’ x
    exit 0 /* leave the exec */

Recommendation:
The REXX identifier must still be specified within a comment in the first line of any interpreted exec found in SYSPROC. Otherwise, the procedure is treated as a CLIST.

  • If you specify the NOCOMMENT keyword option, the NOCOMMENT keyword option, and any other options are not removed from the special comment in line 1 after compression. For example, if the initial line 1 comment contains:
  • /*% xxxxxxx yyyyyyy NOCOMMENT /*REXX*/ */
    then after compression line 1 contains:
    /*% xxxxxxx yyyyyyy NOCOMMENT*/

Note:The REXX identifier was removed from the line 1 comment because it is not a keyword option in this instance. The nested delimiter /* ended the scan for special keyword options.

If a compression indicator is specified, the exec is not scanned for the string SOURCELINE. TSO/E REXX determines whether to compress the exec based only on the value of the compression indicator.The following are examples of using the compression indicator option. In all of these examples the exec is invoked implicitly and is found in the SYSPROC CLIST library.

  • Example of correct placement of the trigger character:

In the following example NOCOMMENT is a valid compression indicator option recognized by TSO/E REXX and indicates that the exec should be compressed. The string REXX is seen both as a keyword option and as the REXX REXX identifier.

/*% NOCOMMENT REXX */
  • Examples of incorrect placement of the trigger character:

In each of these examples NOCOMMENT is not treated as a compression indicator option because the trigger character (%) does not immediately follow the first begin comment delimiter /*. The string REXX in the first comment is seen as a valid REXX identifier.

/*REXX*/ /*%NOCOMMENT */
/*REXX /*%NOCOMMENT */ */
/* %NOCOMMENT REXX */
  • Example of specifying the compression indicator in mixed case:

In the following example the compression indicator option is specified in mixed case. The compression indicator option can be specified in uppercase, lowercase, or mixed case. The ″NOcomment″ indicator is a valid keyword option and indicates that the exec should be compressed. The start of the nested comment ends scanning for keyword options. The string ″REXX″ is seen as a REXX identifier and not as a keyword option. The words within the nested comment are not treated as keyword options.

/*% NOcomment /*REXX - Remove any comment text*/ */
  • Example of using two compression keyword options:

If both COMMENT and NOCOMMENT are specified in the set of keyword options in the comment in line 1, TSO/E REXX uses the last value specified. In this example, the exec sees the last compression indicator COMMENT and the exec is not compressed.Example of SOURCELINE that does not prevent compression: In the following example the string SOURCELINE is not apparent in the source text of the exec because it is formed dynamically during the processing of the INTERPRET statement. Use of the COMMENT keyword option informs TSO/E REXX not to compress this exec. Without the COMMENT indicator this exec would be compressed and this would have caused the SOURCELINE built-in function to obtain a null comment, that is

  • Example of a missing REXX identifier:

In this example, NOCOMMENT is specified as a keyword option but is not recognized because no REXX identifier appears in the line 1 comment. Any procedure invoked implicitly from a SYSPROC library that does not contain the REXX identifier is treated as a CLIST. Therefore, no scan for keyword options is performed and the system attempts to run this exec as a CLIST.

/*%NOCOMMENT */
  • Example of incorrectly specified compression indicator:

In the following example, the NOCOMMENT indicator is not recognized. The REXX identifier should be separated from the NOCOMMENT indicator by at least one blank. TSO/E REXX views NOCOMMENTREXX NOCOMMENTOREXX as a single unrecognized exec keyword option. Note, however, the word REXX imbedded within the keyword option
NOCOMMENTREXX is seen as a valid REXX identifier string.

/*%NOCOMMENTREXX*/

Rule:
Avoid concatenating data sets of unlike RECFM attributes to the SYSEXEC or SYSPROC libraries or to any of the REXX exec or CLIST libraries that are defined via the ALTLIB command. In addition, if RECFM=FB data sets are used in the library allocated to SYSEXEC, or in any exec library allocated via the ALTLIB command, all the data sets which comprise that library concatenation should have the same LRECL.Follow these directives or various failures, including abends or loops, during REXX exec load processing, can result.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM-REXX Topics