Fixes are available
APAR status
Closed as program error.
Error description
For below EGL: function fun2() qualifiedData employeeRecordEGLDB2; a int = 1; qualifiedData.eID = 1; get qualifiedData forupdate resultset; replace qualifiedData; end In EGL 8, the generated cobol for 'replace qualifiedData;' is below: EZESQLRPL-QUALIFIEDD-33 SECTION. MOVE 0086 TO EZERTS-ERROR-NUM SET ADDRESS OF EZECRS-CURSOR-BLOCKS TO EZEAPP-CURS-BLK-PTR IF EZECRS-QUALIFIEDD-33-CLOS OR EZECRS-QUALIFIEDD-33-SETI OR EZECRS-QUALIFIEDD-33-SIWH MOVE -99 TO EZESTA-EMPLOYEE-24-RC PERFORM EZE-THROW-RTE-EXCEPTION END-IF SET ADDRESS OF EZECRS-CURSOR-BLOCKS TO EZEAPP-CURS-BLK-PTR IF EZECRS-QUALIFIEDD-33-ID = 1 MOVE 0 TO EZERTS-ERROR-NUM IF EZERTS-PRC-NUM = 28 //EZERTS-PRC-NUM is the line number of ?replace qualifiedData? EXEC SQL update EMPLOYEETEST set uName = :QUALIFIEDD-33.UNAME-26, PASSWORD = :QUALIFIEDD-33.PASSWORD-27, fName = :QUALIFIEDD-33.FNAME-28, lName = :QUALIFIEDD-33.LNAME-29, office = :QUALIFIEDD-33.OFFICE-30 :QUALIFIEDD-33.OFFICE-30-I, sex = :QUALIFIEDD-33.SEX-31 :QUALIFIEDD-33.SEX-31-I, EMail = :QUALIFIEDD-33.EMAIL-32 :QUALIFIEDD-33.EMAIL-32-I WHERE CURRENT OF EZECURSOR1 END-EXEC END-IF EZERTS-PRC-NUM is defined as below: 05 EZERTS-PRC-NUM PIC 9(4) COMP-4. The line 'IF EZERTS-PRC-NUM = 28' is using the line number of ?replace qualifiedData? as condition. The line number of Replace statement in program is 76481, which is out of the range of 9(4), so the SQL update will never get executed. MOVE 76481 TO EZERTS-PRC-NUM //after the Move, the value of EZERTS-PRC-NUM is 10945.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * **************************************************************** * PROBLEM DESCRIPTION: * **************************************************************** * RECOMMENDATION: * **************************************************************** In V7/V8, EGL COBOLgen requires that the line number should be known when doing a generalized replace (that is when a result set id has not been given). This is because the replace code doesn't actually know where the get was done and which variables are to be used. In the customer case, the line number was ? both 9999 and 65535, which caused a failure in the IF statement that was trying to determine which line number the replace came from.
Problem conclusion
The code has been updated in 2 ways. First, the runtime line number variable has been defined as 9(4) comp-4 for many years. This only allowed a maximum of 9999 in COBOL. The variable has been (safely) altered to be 9(4) comp-5 which even though uses the same amount of storage, can safely hold up to 65535. Second, the IF statement that checks the line number now compares against another 9(4) comp-5 variable instead of directly. When compared directly, the IF statement would fail. When used with another variable, then any overflow (value ? 65535) would overflow in both the other variable and the runtime line number in the same way, which will still cause a successful match.
Temporary fix
Comments
APAR Information
APAR number
PM68290
Reported component name
RATL BUS DEV
Reported component ID
5724S5000
Reported release
801
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2012-07-06
Closed date
2012-10-08
Last modified date
2012-10-08
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
RATL BUS DEV
Fixed component ID
5724S5000
Applicable component levels
R801 PSN
UP
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSMQ79","label":"Rational Business Developer"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
08 October 2012