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.


 DC@P200203      Create/Recreate a file from its definition            





 No specific reason can be found to recreate this file. From the  

 details below select the components of the file definition that are  

 to be recreated:



              Physical file . . . . . . . . . . _   Yes, No            


              Logical file(s) / view(s) . . . . _   Yes, No            


              I/O module  . . . . . . . . . . . _   Yes, No            






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




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:

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.


 DC@P200201      Create/Recreate a File from its Definition            


 File :   CUSMST     QGPL       Customer master file                   


 Submit this job as described below  . . . . . . . . . YES      YES,NO 

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

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

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

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

 Produce file and I/O module source listings . . . . . NO_     YES, NO 

 Ignore decimal error / Strip debug data options . . . NO/YES  YES, NO 

 User program to call at completion  . . . . . . . . . ______________  

 Delete $$ file  . . . . . . . . . . . . . . . . . . . NO      YES, NO 

 Object     Library    Type       Action to be taken / reason(s)       

 CUSMST     QGPL       PHY Create new physical file in library QTEMP   

                           Physical file does not currently exist      

 CUSMSTV1   QGPL       LGL Create new logical file in library QTEMP    

                           Logical file does not currently exist       

 I@CUSMST   QGPL       I/O Create new I/O Module in library QTEMP      

                           I/O module does not currently exist         


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




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:

Input Options

Submit This Job

Job Name

Job Description

Job Queue

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.

Output Queue

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:


Produce DDS and RPG compiler listings.


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:



Use the IGNDECERR(*YES) parameter.



Use the IGNDECERR(*NO) parameter.



Use the FIXNBR(*ZONED) parameter.



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:

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:








Name of physical file created or recreated.




Name of library in which physical file resides.


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.