This section contains some suggestions about what to do for specific types of incorrect output, and what might be at fault.
Logon rejection message
If you get a logon rejection message when you attempt to log on to CICS, it could be that the TYPETERM definitions for the terminal are incorrect. A message recording the failure is written to the CSNE log or, in the case of autoinstall, to the CADL log.
You are likely to get a logon rejection if you attempt to specify anything other than QUERY(NO) for a terminal that does not have the structured query field feature. Note that NO is the default value for TYPETERM definitions that you supply, but YES is the value for TYPETERM definitions that are supplied with CICS.
If you have a persistent problem with logon rejection, you can use the VTAM® buffer trace to find out more about the reasons for the failure.
Unexpected messages and codes
If the "wrong data" is in the form of a message or code that you do not understand, look in the appropriate manual for an explanation of what it means.
Messages that are prefixed by DFH originate from CICS--use the CMAC transaction or look in CICS® Messages and Codes for these. For codes that appear in the space at the bottom of the screen where status information is displayed, look in the appropriate guide for the terminal.
The following are examples of common errors that can cause messages or codes to be displayed:
If you suspect this may be the cause of the problem, check your application code carefully to make sure it cannot send any unintended control characters.
The default value for EXTENDEDDS is NO, but check to make sure that YES has not been specified if you know your terminal is not an extended data stream device.
Unexpected appearance of uppercase or lowercase characters
If the data displayed on your terminal has unexpectedly been translated into uppercase characters, or if you have some lowercase characters when you were expecting uppercase translation, you need to look at the options governing the translation.
These are the significant properties of the various translation options you have:
ASIS overrides the UCTRAN attributes for both TYPETERM and PROFILE definitions.
The UCTRAN attribute of TYPETERM is overridden by ASIS, but it overrides the UCTRAN attribute of a PROFILE definition.
The UCTRAN option for a PROFILE is overridden by both the UCTRAN option for a TYPETERM definition and the BMS or terminal control ASIS option.
The UPPERCASE option in the offline utilities (DFHSTUP, DFHDU640, DFHTU640) specify whether all lowercase characters are to be translated to uppercase characters.
Table 16 and Table 17 summarize whether or not you get uppercase translation, depending on the values of these options.
Profile | TYPETERM UCTRAN(YES) | TYPETERM UCTRAN(NO) |
---|---|---|
UCTRAN(YES) | Yes | Yes |
UCTRAN(NO) | Yes | No |
Profile | TYPETERM UCTRAN(YES) | TYPETERM UCTRAN(NO) |
---|---|---|
UCTRAN(YES) | No | No |
UCTRAN(NO) | No | No |
CRTE and uppercase translation
Initiating a CRTE session
The input required to start a CRTE routing session is of the form:
CRTE SYSID(xxxx),TRPROF(yyyyyyyy)
Translation to uppercase is dictated by the typeterm of the terminal at which CRTE was entered and CRTE’s transaction profile definition as shown in Table 18.
TYPETERM UCTRAN | CRTE PROFILE UCTRAN | INPUT TRANSLATED TO UPPERCASE |
---|---|---|
YES | YES/NO | ALL OF THE INPUT |
NO | NO | NONE OF THE INPUT. See note. |
NO | YES | ALL OF THE INPUT EXCEPT THE TRANSID. See note. |
TRANID | YES | ALL OF THE INPUT |
TRANID | NO | TRANSID ONLY |
Note:
If the transid CRTE is not entered in upper case, it will not be recognized
(unless there is a lower/mixed case alias), and message DFHAC2001 will be
issued. |
Input within the CRTE session
During the CRTE routing session, uppercase translation is dictated by the typeterm of the terminal at which CRTE was initiated and the transaction profile definition of the transaction being initiated (which has to be a valid transaction on the application owning region) as shown in Table 19.
TYPETERM UCTRAN | TRANSACTION PROFILE (AOR) UCTRAN | INPUT TRANSLATED TO UPPERCASE |
---|---|---|
YES | YES/NO | ALL OF THE INPUT |
NO | NO | NONE OF THE INPUT. See note. |
NO | YES | ALL OF THE INPUT EXCEPT THE TRANSID. See note. |
TRANID | YES | ALL OF THE INPUT |
TRANID | NO | TRANSID ONLY |
Note:
If the transid CRTE is not entered in upper case, it will not be recognized
(unless there is a lower/mixed case alias defined on the AOR) and message
DFHAC2001 will be issued. |
During a CRTE routing session, if the first six characters entered at a screen are CANCEL, CICS will recognize this input in upper, lower or mixed case and end the routing session.
For more information on the ALIAS attribute of the transaction definition, see the ‘Transaction’ section of the CICS Resource Definition Guide.
Be aware that when transaction routing from CICS Transaction Server for z/OS®, Version 3 Release 1 to an earlier release of CICS that does not support transaction based uppercase translation, uppercase translation only occurs if it is specified in the typeterm.
EXEC CICS SET TERMINAL and uppercase translation
In a single system, if the EXEC CICS SET TERMINAL command is issued for a terminal while it is running a transaction performing RECEIVE processing, unpredictable results may occur. This is because the command can override the typeterm definition regarding uppercase translation and RECEIVE processing interrogates the uppercase translate status of the terminal in order to establish whether translation is required.
In a transaction routing environment, the system programmer who issues the EXEC CICS SET TERMINAL command should be aware (for VTAM terminals) that the TOR terminal uppercase translate status is copied to the AOR surrogate terminal on every flow across the link from the TOR to the AOR. Consequently:
CICS client virtual terminal
If the codepage sent by a client is incorrect, this can lead to the entire screenful of data being incorrect. You must resolve this problem at the client end of operations.
The entire screenful of data might also be incorrect if the bit TCTSK_VIRTUAL_TERMINAL is not set on in the skeleton for the virtual terminal. The bit might have been overwritten, or not turned on when the virtual terminal was being created during CTIN processing.
Katakana terminals--mixed English and Katakana characters
If you are using a Katakana terminal, you might see some messages containing mixed English and Katakana characters. That is because Katakana terminals cannot display mixed-case output. Uppercase characters in the data stream appear as uppercase English characters, but lowercase characters appear as Katakana characters. If you have any Katakana terminals connected to your CICS system, specify MSGCASE=UPPER in the system initialization table to ensure that messages contain uppercase characters only.
The offline utilities DFHSTUP, DFHDU640, and DFHTU640 have an extra parameter to ensure all output is translated to uppercase. See the CICS Operations and Utilities Guide for details on how to use these parameters.
Wrong data values are displayed
If the data values are wrong on the user’s part of the screen (the space above the area used to display status information to the operator), or in the hard copy produced by a printer, it is likely that the application is at fault.
Some data is not displayed
If you find that some data is not being displayed, consider these possibilities:
The default values for ALTSCREEN and ALTPAGE are 0 rows and 0 columns, so no data could then be displayed if SCRNSIZE(ALTERNATE) were specified.
Early data is overlaid by later data
Early data can be overlaid by later data, so that data appears in the wrong order, when the SENDSIZE value of the TYPETERM definition is too large for the device receiving the data. This is because the buffer can wrap when it is full, with the surplus data overlaying the first data that was received.
The data is formatted wrongly
Incorrect formatting of data can have a wide range of causes, but here are some suggestions of areas that can sometimes be troublesome:
For a screen display, the number of columns specified must be less than or equal to the line width. For a printer, the number of columns specified must be less than the line width, or else both BMS (if you are using it) and the printer might provide a new line and you will get extra spacing you do not want.
The default values for PAGESIZE depend on the value you specify for the DEVICE keyword.
If your application is handling the buffering of output to a printer, make sure that an "end of message" control character is sent at the end of every buffer full of data. Otherwise, the printer might put the next data it receives on a new line.