FUNL0132 To avoid, (primary-suggestion) re-run with CHECK (condition) ALLOW.

This message follows message FUNL0131 and suggests how to proceed given the conditions stated in FUNL0131. You may receive more than one instance of this message if multiple conditions are found in the file.

The job step return code is set to a minimum of 4 when this message is issued.

If your FUNL0131 message did not specify a Cancel: action, and you don't need to follow the primary-suggestion right away, then this message can be used for reference in future Fast/Unload jobs.

primary-suggestion provides information for handling the condition detected by Fast/Unload and reported as condition. The conditions that can be detected include all those that can be specified on the CHECK statement.

If a primary-suggestion is not present or is not applicable:

• You can force Fast/Unload to ignore the condition by specifying the CHECK condition ALLOW statement.
• The defaults in effect at your site can be customized.
• If condition is PROCS, this message indicates that the file has Model 204 procedures, and you have specified CHECK PROCS WARN or CHECK PROCS CANCEL. Unloading procedures, invoked for UAI unloads by default or by including the PROCS option on the UAI statement, is supported as of Fast/Unload Version 4.2. To complete the unload and not unload procedures, use UAI NOPROCS (and do not use CHECK PROCS CANCEL). To unload procedures, use UAI PROCS.

primary-suggestion can be any of the following, some of which are version-dependent:

• run M204 recovery or: This occurs when condition is either BROKE-PHYS or BROKE-LOGIC, which means that the value of the Model 204 FISTAT parameter indicates some corrective action needs to be taken to the data and/or indices stored in the file. If you are able to run Model 204 recovery, the "broken" file status should be corrected.
• run M204 Z command or: This occurs when condition is DUPDT, which means that the value of the Model 204 FISTAT parameter indicates that there may be deferred index updates which need to be applied to the file. If you are able to run the Model 204 process for applying the deferred updates, the index will be complete for unloading.
• may save procs via M204 COPY PROC command or Disp to USE dataset, then: This occurs when condition is PROCS, which indicates that the file has Model 204 procedures; Versions of Fast/Unload prior to 4.2 cannot unload procedures. To workaround:
  1. Ensure that any needed procedures have been saved, using either of the following:
     • Copy the procedures to a work file using the Model 204 COPY PROC command.
     • Copy the procedures to a USE dataset using the DISPLAY PROC command.
  2. Insert the following FUEL statement to avoid the cancellation or warning: CHECK PROCS ALLOW

  Note: If you are unloading for the purpose of a file reorganization, the COPY PROCEDURE command cannot copy an ALIAS and "reconnect" it to its underlying procedure.

• use UAI INV | OINDEX to unload ORD INVIS fields, or: This occurs when condition is INVIS, which indicates that you are unloading data from a Model 204 file without the OINDEX or INV UAI options, and the file contains some ORDERED INVISIBLE fields. If you are performing a UAI job, these invisible fields can be unloaded by adding OINDEX or INV. If you are not running a UAI job, or you don't need to unload the fields, the cancellation or warning can be avoided by the suggested CHECK statements.
• use FUEL ADD for derived INVIS non-ORD fields, {or | and then}: This occurs when condition is INVIS, which indicates that you are unloading a file with INVISIBLE non-ORDERED fields. Fast/Unload cannot unload these fields directly. However, if the invisible fields are deriveable from other visible fields in the file, and you have installed the Fast/Unload FUEL compiler, you can use the ADD statement to create the values and then they can be unloaded by UAI, PAI, or the PUT method of unload. The end of this text, {or | and then}, is determined as follows:

  or

  If you did not code a CHECK INVIS WARN or CANCEL statement, your program does not contain a FOR EACH RECORD loop (and your site must have customized the CHECK defaults). In the process of inserting one or more ADD statements, you will need to enclose them within a FOR EACH RECORD loop, which, in the absence of CHECK INVIS WARN or CANCEL, prevents the CHECK of invisible fields. You can add CHECK INVIS ALLOW if the ADD statement is not applicable to solving the problem.

  and then

  If you did code a CHECK INVIS WARN or CANCEL statement, you must remove it or change it to ALLOW to avoid the WARN or CANCEL with this file.