You are here: LANSA for i User Guide > 4. Processes and Functions > 4.7 Compile a Process from New or Amended Definition > 4.7.2 Submit the Job to Compile a Process Definition

4.7.2 Submit the Job to Compile a Process Definition

When the option to compile a process definition has been selected from the process control menu a screen similar to the following example will result:

 

 DC@P300302             Compile / Re-Compile a Process     

 

 Process  : XXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX       

 

 Submit this job   . . . . . . . . . . . . . . . .  YES         YES, NO

 Using Job name  . . . . . . . . . . . . . . . . .  XXXXXXXXXX         

       Job description   . . . . . . . . . . . . .  *LIBL/QBATCH       

       Job queue   . . . . . . . . . . . . . . . .  *JOBD             

       Output queue  . . . . . . . . . . . . . . .  *LIBL/QPRINT      

 Compile the process as well as functions below  .  NO          YES, NO

 Produce RDML / RPG and DDS source listings  . . .  NO  / NO    YES, NO

 Optimise/Ignore decimal data errors . . . . . . .  NO  / NO    YES, NO

 Allow debug / Program observability   . . . . . .  YES / YES   YES, NO

 Dump code generator work areas  . . . . . . . . .  NO          YES, NO

 Produce Documentor details  . . . . . . . . . . .  YES         YES, NO

 Generate HTML pages / Validate numerics . . . . .  YES / YES   YES, NO

 Generate HTML/Validate numerics . . . . . . . . .  YES/NO      YES, NO

 Generate XML. . . . . . . . . . . . . . . . . . .  YES         YES, NO

   Sel    Function    Usable      Description                          

    _     XXXXXXX     XXX         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

    _     XXXXXXX     XXX         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

    _     XXXXXXX     XXX         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

 

 Fnn=Help  Fnn=Exit  Fnn=Cancel  Fnn=Messages       

 

 

If the compile request is confirmed, a batch job will be submitted to compile the process definition.

Note that the batch compile job does not require exclusive use of the process for the entire time it is executing.

As each individual RDML function is compiled it is locked for exclusive use then released again when it has finished.

Similarly, the entire process is only locked if and when the process itself is to be compiled. It is unusual to compile processes in a development environment, so this should not be a problem.

When recompiling processes that use the usage HEAVY option (refer to 4.4.1 Specify the New Function's Details for more details), it may be necessary for any user of the process to sign off and sign on again to actually release all the locks held on the process.

This complication most commonly presents a problem in the following situation:

Since user A was using process P he/she should have signed off and on again before submitting the recompile job.

If user A was accessing LANSA from command entry mode then an alternative to signing off and on again would be to exit from LANSA back to command entry mode, enter the command RCLRSC *CALLER, then invoke LANSA again to submit the recompile job.

Note: this complication only arises for processes that use the usage "HEAVY" option.

Input Options

Submit This Job?

Refer to Submit This Job? in Common Input Options.

Job Name

Refer to Job Name.

Job Description

Refer to Job Description.

Job Queue

Refer to Job Queue.

Output Queue

Refer to Output Queue.

Compile the Process as well as Functions below?

Specifies whether or not the process should be turned into compiled form (in addition to any of the RDML functions selected from the list on the lower portion of the screen).

Any RDML function must be associated with one and only one process. The process is responsible for invoking and controlling each of its associated RDML functions.

It is not mandatory that a process be compiled. If it is not compiled an "interpretive" version of the process will be used at execution time. However, for better throughput it is possible to compile the process as well as its associated RDML functions.

The recommended procedure is to use the "interpretive" version of the process during application development. Just prior to placing the process into a production environment it should be compiled to gain the maximum throughput possible.

Mandatory field. Default value is determined from the system definition data area. Refer to The System Definition Data Area Overview. Allowable values are:

YES

Compile the process as well as any selected RDML functions.

NO

Do not compile the process. An "interpretive" version of the process will be used to control the associated RDML functions.

Produce RDML/RPG and DDS Source Listings

Specifies whether source listings should be produced by the batch compile job. Source listings produced include:

RDML

Mandatory field. Default value is determined from the system definition data area. Refer to The System Definition Data Area Overview. Allowable values are:

YES

Produce RDML source listings.

NO

Do not produce RDML source listings.

RPG and DDS

Mandatory field. Default value is NO. Allowable values are:

YES

Produce RPG and DDS source listings.

NO

Do not produce RPG and DDS source listings.

Note that if errors are found in RDML commands associated with a function, a source listing of them will be produced regardless of whether or not it was actually requested .

Optimize Compiled Programs

Specifies whether or not optimization should be used when compiling the RPG program that results from the "function control commands".

How this feature is implemented depends on the version of RPG code being compiled. For more information on the different versions of RPG code that can be compiled refer to ILE Implementation.

This facility is provided for compatibility with the IBM i. No claims are made regarding the effect of using (or not using) the optimization option. Refer to the IBM supplied CL reference manual for details. Using this option may increase the time taken to compile a process.

Mandatory field. Default value is determined from the system definition data area. Refer to The System Definition Data Area Overview . Allowable values are:

 

  YES

Use the optimize option.

 

  NO

Do not use the optimize option.

 

  YES

Use the OPTIMIZE(*FULL) parameter.

 

  NO

Use the OPTIMIZE(*NONE) parameter.

Ignore Decimal Data Errors in Programs?

Specifies how decimal data errors should be dealt with in the compiled RPG program that results from the "function control commands".

How this feature is implemented depends on the version of RPG code being compiled. For more information on the different versions of RPG code that can be compiled refer to ILE Implementation.

This facility is provided for compatibility with the operating system and because it is required by some installations. It is strongly recommended that this option is not used. Refer to the IBM supplied CL reference manual for details.

Mandatory field. Default value is determined from the system definition data area. Refer to The System Definition Data Area Overview. Allowable values are:

 

  YES

Use the IGNDECERR(*YES) parameter.

 

  NO

Use the IGNDECERR(*NO) parameter.

 

  YES

Use the FIXNBR(*ZONED) parameter.

 

  NO

Use the FIXNBR(*NONE) parameter.

Allow Debug/Program Observability

Specifies whether the functions compiled from this process should be able to be used in DEBUG mode.

DEBUG mode operates at 2 levels within LANSA.

The first level is LANSA debug mode which allows debugging facilities to be used at the "RDML command level". Refer to a section later in this chapter for more details.

The second level is the debug facility provided by the operating system. This facility allows the RPG program generated by LANSA for a function to be debugged. Refer to the appropriate IBM supplied manuals for more details on how this level of debug is used.

If NO / NO is used all functions within this process cannot be used in debug mode at either level. The reason that debug mode is disabled is because the RPG program will not contain symbol table and debug information. If debug is used on the program a message indicating that the program is not "observable" will result. By not including this information the size of the compiled RPG program is reduced by 40% to 50%, thus saving disk space and improving performance.

Mandatory fields. Default value is determined from the system definition data area. Refer to The System Definition Data Area Overview. Allowable values are:

YES /YES

Allow functions to be used in DEBUG mode/Do not remove program observability.

NO/NO

Do not allow functions to be used in DEBUG mode/ Remove program observability.

NO/YES

Do not allow functions to be used in DEBUG mode/Do not remove program observability.

YES /NO

Allow functions to be used in DEBUG mode/Remove program observability.

Dump Code Generator Work Areas?

Specifies whether the internal work areas used by the LANSA code generator should be dumped at the end of the compile job. This option would normally only be used when requested by your product vendor to aid in problem diagnosis or correction.

Mandatory field. Default value is NO. Allowable values are:

NO

Do not dump code generator work areas.

YES

Dump code generator work areas.

Produce Documentor Details?

Specifies if details for use in LANSA/DOCUMENTOR should be produced when this process and/or function(s) is compiled. This option will only appear if Documentor is enabled for the current partition.

If NO is specified, any previously produced Documentor details will be deleted for the process and/or function(s) being compiled.

Mandatory field. Default value is determined from the partition definition. Allowable values are:

NO

Do not produce Documentor details.

YES

Produce Documentor details.

Generate HTML Pages?

Specifies if HTML pages should be generated for DISPLAY/REQUEST/POP_UP commands when this function(s) is compiled. This option will only appear if the process is Web enabled.

Mandatory field. Default value is YES. Allowable values are :

YES

Generate HTML pages for each DISPLAY/REQUEST/POP_UP command in each function that is compiled.

NO

Do not generate HTML pages for each DISPLAY/REQUEST/POP_UP command in each function that is compiled.
This value should be used with caution. It is generally only used when changes to the function have not included modification of any DISPLAY/REQUEST/POP_UP command. This allows HTML pages that have been modified using an HTML editor to be preserved.

Validate numerics?

Specifies if input numeric fields should be validated via JavaScript according to the allowable number of digits before and after the decimal point. This option is only applicable if  the 'Generate HTML pages' option is 'YES'. This option will only appear if the process is Web enabled.

Mandatory field. Default value is NO unless the DC@OSVEROP data area contains *WEBNUMVAL. Allowable values are :

NO

Do not generate JavaScript function calls for input numeric fields for each function being compiled.

YES

Generate JavaScript function calls for input numeric fields for each function being compiled.

Generate XML?

Specifies if XML should be generated for DISPLAY/REQUEST/POP_UP commands when this function(s) is compiled. This option will only appear if the process is XML enabled.

Mandatory field. Default value is YES. Allowable values are:

YES

Generate XML for each DISPLAY/REQUEST/POP_UP command in each function that is compiled.

NO

Do not generate XML for each DISPLAY/REQUEST/POP_UP command in each function that is compiled.
This value should be used with caution. It is generally only used when changes to the function have not included modification of any DISPLAY/REQUEST/POP_UP command. This allows XML that has been modified using the XML editor to be preserved.

Sel/Function/Usable/Description

This list of information that appears at the bottom of the screen details all of the RDML functions that are part of the process.

Note: When the advanced menus and an Impact List are being used, only functions which exist in the Impact List will be shown in the list of functions.

The function name is shown under the column "Function". The "Usable" column indicates whether or not the function is currently in a state in which it can be used (i.e. executed). The final column headed "Description" displays the user description associated with the function.

The most important column is that headed "Sel" (select). A non- blank entry against an RDML function in this column indicates that it should be selected for compilation (or re-compilation) by the batch job that is to be submitted.

Where a function is not currently usable the "Sel" value will be pre-filled with a "/" indicating that it will have to be compiled before it can be used.

If required, use the roll up and roll down keys to scroll through the list of all functions. Alter the "Sel" (select) values as desired to add to or remove from the list of functions that will be compiled (or re-compiled) by the batch job.

Note that each selected function is an independent RDML program and will be converted into an RPG program. If a large number of functions are selected for compilation (or re-compilation) then the batch job will accordingly take a long time to complete.

If the process is Web enabled, graphical HTML pages will be generated for screens in the function when the function is compiled.