After applying SP4 an existing Web application may start generating fatal errors
|Date:||13 March 2008|
|Product/Release:||LANSA for the Web V11 SP4|
|Abstract:||LANSA for the Web application starts to generate fatal messages after applying SP4|
|Submitted By:||LANSA Technical Support|
There was a change made in SP4 for V11 to prevent the DISPLAY/REQUEST/POP_UP command from being executed more than once in one Web function request.
This change is documented in the SP4 readme. See readme extract.
However, the consequences of this change has the potential to affect a currently working LANSA for the Web application.
If you apply SP4 and your LANSA for the Web application starts to generate fatal messages as follows:
DCM1739 Unexpected DISPLAY/REQUEST/POP_UP command in <proccess> <function>. function/program <function> failed
then you are executing DISPLAY/REQUEST/POP_UP commands more than once in one Web function request.
The error message is being raised because data area DC@LWEB position 531 length 1 (IGNORE_UNEXPECTED_DISPLAY) is defaulted to 'N' in SP4. You can elect to ignore these errors by changing data area position 531 (IGNORE_UNEXPECTED_DISPLAY) to Y. This will cause the application to execute as it previously did. This will give an immediate resolution. But in the long term, we would suggest that you take the recommendation at the end of the CCS readme entry (below), which states It is highly recommended to enable the fatal error, especially for development machines, so RDML logic error can be caught as soon as possible.
CCS#: 0127630 (Defect)
Description: Prevent DISPLAY/REQUEST/POP_UP command from being executed more than once
Originator: LANSA USA
EPC Superseded: None
Detailed Description: To prevent the DISPLAY/REQUEST/POP_UP command from being executed more than once in one Web function request.
A Web function should normally execute the DISPLAY/REQUEST/POP_UP command only once. However, if a CALL command is used with EXIT_USED(*NEXT) and the CALL-ed Web function also has a DISPLAY/REQUEST/POP_UP command, the execution cannot be stopped as expected right after the DISPLAY/REQUEST/POP_UP command inside the CALL-ed Web function. The CALL-ed Web function will return to the caller and the RDML logic will continue. If there is another following DISPLAY/REQUEST/POP_UP command, including those that may be triggered by other CALL commands, the command will also be executed and the corresponding generated Web page will be ignored and hence will not be shown. However, as part of the data communication protection mechanism introduced since LANSA V11 CU1, a CGI program problem will occur if the user interacts with the generated Web page from the very first DISPLAY/REQUEST/POP_UP command while any subsequent DISPLAY/REQUEST/POP_UP command is being executed, i.e. within usually a short time-frame after the first Web page is shown.
It is now fixed that if a DISPLAY/REQUEST/POP_UP command is detected to be executed for the second time, a fatal error will be raised and cause the RDML logic to end immediately and then the Web job to terminate. On System i, an error message will be written to the job log. For RDMLX Web functions, an error message will also be written to file x_err.log. It is highly recommended to fix the RDML logic so that this kind of situation will not happen. This usually may involve changing the CALL command and/or checking additional conditions after the CALL-ed Web function returns to avoid any following DISPLAY/REQUEST/POP_UP command.
However, for existing applications which cannot be updated, the fatal error raised may not be a welcome effect. Those applications may appear to be working correctly before the data communication protection mechanism was introduced, although in fact the RDML logic is not exactly correct and the error has no way to be detected. For those applications to keep on working as before, there is a new runtime setting to disable the fatal error and simply ignore any subsequent DISPLAY/REQUEST/POP_UP commands after one such command has already been executed. Remember though, in general, execution will still be ended upon the first DISPLAY/REQUEST/POP_UP command encountered in the main Web function, no matter whether the command has been executed or ignored. To disable the fatal error, for System i, modify data area DC@LWEB position 531 length 1 to become 'Y'. For Windows, inside the LANSAWEB registry hive, create/modify a registry setting named IGNORE_UNEXPECTED_DISPLAY and change the setting to 'Y'. To re-enable the fatal error, change the setting back to 'N'. The changed setting will be effective immediately, i.e. clean-up is not required to activate the setting.
It is highly recommended to enable the fatal error, especially for development machines, so RDML logic error can be caught as soon as possible.