Incorrout procedure

INCORROUT is when either output is missing, or output is incorrect.

Keyword: INCORROUT

Use this procedure to determine the appropriate search argument.

Always use the keyword INCORROUT for problems related to incorrect or missing output.

Keyword: utility module name

If the incorrect or missing output is associated with a utility, use the utility module name as a keyword. For example, if output from the File Select and Formatting Print utility (DFSERA10) is incorrect, use DFSERA10 as a keyword.

Keyword: command

If the output from a command is missing or incorrect, use the first three letters of the command as a keyword. Also, you should use the OR operator in the search argument with CMDxxx, where xxx is replaced by the first three letters of the command.

If, for example, the DISPLAY command provides incorrect output, use the following search argument: 
5655J3800 INCORROUT DIS | CMDDIS
For a structured database search, use this search argument: 
PIDS/5655J3800 INCORROUT PCSS/DIS

If applicable, you can add the output column or heading as a keyword in the search argument.

Keywords: columns, headings, fields

Whenever possible, you can add additional keywords to narrow the field of search results. If a particular heading, field name, or column is incorrect, use it as a keyword. For example, if the deadlock event summary section of the IMS Monitor report (DFSUTR20) is incorrect for the DMB NAME column, use the following search argument: 
5655J3800 INCORROUT DFSUTR20 DEADLOCK | DMB
For a structured database search, use this search argument: 
PIDS/5655J3800 INCORROUT RIDS/DFSUTR20
PCSS/DEADLOCK PCSS/DMB

If you receive too many search results, remove the OR operator (|) to focus the selection.

Keyword: database type or call

If the incorrect output is a database record, use the database type (such as VSAM, HDAM, or HIDAM) and possibly the call (such as GU, ISRT, or DELETE).

Additional diagnostics

This section does not apply to a Database Control (DBCTL) environment.

If the output is a transaction message produced as output from an application program, perform the steps below. (The message can be directed either to a terminal or to another application program. This is called a program switch.)

  1. If the output is missing, continue with this step; otherwise, go to step 2.
    1. When the output is missing, determine if the transaction is being scheduled.
      • Issue the /DIS ACTIVE command to make sure the transaction is not stopped.
      • Then issue the /DIS TRAN command to find out if the transaction is scheduled.

      QCT should decrease by at least one each time the transaction is scheduled and terminates normally.

      If the transaction is not being scheduled, go to step 1f.

    2. Determine if the message is being enqueued to the proper output destination by issuing one of the following commands:
      • Issue the /DIS TRAN command (for program switch). ENQCT should increase.
      • Issue the /DIS LTERM command (for output to terminal). ENQCT should increase.

      If the message is not being enqueued to the proper output destination, go to step 1e.

    3. If the output destination is another application program, it should be scheduled as a result of the message enqueue.

      If the transaction is scheduled but there is no input, the problem is probably within the SYS function.

      If the application program is not scheduled, go to step 1f.

    4. If the output destination is a terminal, verify that I/O errors did not prevent the message from being sent. Take both of the following actions.
      • Review the console log for I/O error messages.
      • Issue the /DIS LTERM command for operational status.
      If you detected valid I/O errors, stop here and correct the hardware problem. Otherwise, the problem is probably within the TM function. Stop here and build your search argument.
    5. Determine if the application program is using the proper PCB for the ISRT call.
      • Force a dump in the application program at the time of the ISRT call.

      If the proper PCB is being used, the problem is probably within the SYS function. Stop here and build your search argument. Otherwise, stop here and correct the application program.

    6. Determine if the resources necessary to schedule the application program are available.
      • Issue the /DIS ACTIVE command for the active region.
      • Issue the /DIS SUBSYS ALL command for all external subsystems connected to or in the process of being connected to IMS.
      • Issue the /DIS TRAN command to make sure the transaction is not stopped.
      • Issue the /DIS DATABASE command to determine if the necessary databases are available.

      If a resource is not available, stop here and make it available. Otherwise, force a console dump. Use the PST ANALYSIS step in procedure WAIT/LOOP procedure to determine the reason the transaction is not being scheduled. Stop here and build your search argument using that information.

  2. If the incorrect data is input to an application, perform this step, otherwise go to step 3.
    1. Verify the text data in the X'01' log record to determine if the data reached IMS properly.

      If the data did not reach IMS properly, go to step 2c.

    2. Force a dump in the application program immediately after the application program GU call, in order to determine if the data reached the I/O area correctly.

      If the data did not reach the I/O area correctly, the problem is probably within the SYS function. Stop here and report the problem. Otherwise, the application program received the data correctly. Stop here.

    3. Start the line or node trace and verify the data in the X'6701' log record to determine if the data reached the input TP buffer correctly.

      If the data reached the input TP buffer correctly, the problem is probably within the DC function. Stop here and report the problem. Otherwise, if the data did not reach the input TP buffer correctly, the problem is probably a hardware or an operating system failure. Stop here and correct the hardware or operating system problem.

  3. Determine if the message data is actually incorrect rather than merely formatted incorrectly.
    • Compare received data with expected data.
    • Check MFS blocks for correct format definition.
    1. Force a dump in the application program just before the ISRT call to determine whether the data is correct in the I/O area at the time of the ISRT.

      If the data in the I/O area is incorrect, the problem is probably in the application program. Stop here and correct the application program. Otherwise, continue. Verify the text in the X'03' log record to determine whether the data reached the message queue correctly.

      If the message did not reach the message queue correctly, the problem is probably within the SYS function. Stop here and build your search argument. Otherwise, continue.

    2. Start the line or node trace and verify the data in the X'6701' log records, in order to determine if the data reached the output TP buffer correctly.

      If the data did not reach the output TP buffer correctly, the problem is probably within the DC function. Stop here and build your search argument. Otherwise, if the data is correct in the output TP buffer, but not at the terminal, the problem is probably a hardware or operating system failure. Stop here and correct the hardware or operating system problem.

IRLM problems

Incorrect output from the IRLM can be divided into the following three areas:

  • Incorrect information on a display status command
  • Locks granted when locks should not be granted
  • Locks not granted when locks should be granted

For help in diagnosing these problems, call the IBM® Support Center. A support representative will tell you what type of documentation to gather.