3.7.1 Submit Job to Make File Definition Operational
When the option to "make a new or amended file definition operational" has been selected from the file control menu either of these screens may be presented first.
If LANSA cannot find any "reason" for making the file definition operational again (because it is not a new file definition and it has not been changed) the screen Create/Recreate a file from its definition will be presented first.
|
This screen asks that you manually specify the parts of the file that are to be re-created. Generally you would only use this screen if:
- The LANSA product vendor requests that the I/O module be recreated because of changes to the LANSA system.
- The IBM i physical or logical files or the I/O module associated with the file definition are accidentally deleted or become damaged in some way.
- You are re-installing your system after a total system failure and do not have valid backups of the physical and/or logical files.
Note that in the last 2 cases LANSA can recreate the physical and logical files but it cannot recreate the data they contain.
Select the desired part(s) of the file that are to be recreated by entering any non-blank character beside it.
If LANSA can find a "reason" for making the file definition operational, or if you have manually requested that parts of the file be recreated on the preceding screen, the screen Create/Recreate a File from its Definition will be presented.
|
The lower half of the screen details the actions that will be taken by the batch job and the reasons that they will be taken. In this example it can be seen that:
- The physical file CUSMST will be created in QTEMP first.
- The logical view CUSMSTV1 will be created in library QTEMP next.
- The I/O module I@CUSMST is then compiled into library QTEMP.
- The list of actions continues. This is indicated by the "+" sign at the bottom right of the screen. If desired use the roll up and roll down keys to scroll backwards and forwards through the list of actions/reasons displayed.
Input Options
WARNING: submitted batch job library list. Make sure that the job description being used does not cause the library in which the file resides to be made the IBM i "current library". Jobs submitted to make files operational where the "current library" and the library in which the file resides are the same may fail or produce unexpected results.
Produce File and I/O Module Source Listings
Specifies whether the DDS (data description specification) source listings produced by any CRTPF (create physical file) or CRTLF (create logical file) commands should be printed. In addition it specifies whether the RPG compiler listing of the I/O module program should be printed.
Mandatory. Prefilled to YES. Allowable values are:
|
YES |
Produce DDS and RPG compiler listings. |
|
NO |
Do not produce DDS and RPG compiler listings. |
Ignore Decimal Error
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 System Definition Data Area DC@A01. 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. |
Strip Debug Data Options
Specifies whether or not the RPG I/O module associated with the file definition should have its associated debug symbolic information removed. This information is only required in two situations:
- When attempting to use the IBM supplied debugging aids with the compiled RPG I/O module.
Since these situations are relatively rare, the default for this field is YES (debugging information should be stripped). By using this option, the size of the compiled I/O module will typically be reduced by 40 to 60%. This size reduction has no bearing on execution speed, just on the size of the compiled object.
To enable RPG I/O modules to be debugged, use option NO (debug information should not be stripped).
User Program to Call at Completion
Specifies the qualified name of a user defined program that should be called after the file has been successfully created or recreated. Typically this facility is used to execute a program that initializes a new file or modifies the data in a file that has been amended.
Optional. If used the program name must be specified as a standard object name (i.e. <program>.<library>) Special value *LIBL (search library list) is acceptable as the name of the library that is specified. LANSA does not validate the name or format of the program specified in any way.
When the program is called, it is passed two parameters:
|
If the user program fails the create / recreate job will end abnormally. Messages on the job log will indicate the cause of the failure. However, the file will have been successfully created or recreated and will be usable. In this case correct the problem in the user program and independently resubmit for execution.
Delete $$ File
Specifies whether or not the $$ version of the file should be deleted during the batch process. The request only appears if the $$ version exists. If NO is specified (which is the default), then the submit to batch will not take place and a message will be issued to say that the $$ version must be deleted. It is still possible to delete it manually using the DLTF command.
Where 9 and 10 character file names are not unique in their first 8 characters, a $$ version for a different file may erroneously be found to exist. It still must be deleted.