[ |../../index.htm#lansa/ugub_40014.htm]
You are here:

4.7.1 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:

 |
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:

• User A is using process P (which has the usage HEAVY option) and decides to change it. The amendment is made and the job to recompile the process is submitted.
• The recompile job fails because it cannot allocate all components of process P for exclusive use.

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:

Produce RDML/RPG and DDS Source Listings
Specifies whether source listings should be produced by the batch compile job. Source listings produced include:
RDML

• A full listing of the RDML commands associated with each function.
• A representation of each screen format that was designed for each "RDML command" that displays information on a workstation.

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

RPG and DDS

• The DDS (data description specifications) used to create the display file associated with a function (if any).
• The compiler listing of the RPG program produced from the RDML commands associated with the function.

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

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:

• If RPG/400 Code Is Being Compiled

  	YES	Use the optimize option.
  	NO	Do not use the optimize option.

• If RPG/IV Code Is Being Compiled

  	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:
• If RPG/400 Code Is Being Compiled

  	YES	Use the IGNDECERR(*YES) parameter.
  	NO	Use the IGNDECERR(*NO) parameter.

• If RPG/IV Code Is Being Compiled

  	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.

  Sel/Function/Usable/Description
  This list of information that appears at the bottom of the screen details of 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.
  [ |../../index.htm#lansa/ugub_40014.htm]