I need help with analysis of a COBOL object module.

John Poulakos · Posted: Fri Jan 24, 2020 9:08 pm

I have a number of programs that we think may have been compiled with a bad compare several years ago. I don't have source or listings and I can't recompile them. The code in question is a compare of a two byte value in a data definition to a literal value of 20 when it should be 40. So, basically all I have to work with is the object or load module.

I can identify a two byte compare statement in the object code. Where I am running into problems is in identifying the address of the literal value being compared. I need to know the address where the Constant Global Table (CGT) begins in the program and the base register assigned to the literal pool. It has to be there, or a dump program wouldn't be able to identify data. I just don't know where to look.

sergeyken · Posted: Fri Jan 24, 2020 10:41 pm

No chance, if the original code was more complex than

John Poulakos · Posted: Sat Jan 25, 2020 2:08 am

I have had some success. I can identify the literal pool in storage as it always starts with FFFFFFFC. I can make a reasonable guess at the base register that points to the literal pool, by process of elimination. Literals are never the first operand in a statement, so I can eliminate any registers used in a first operand.

For example:

Phrzby Phil · Posted: Sat Jan 25, 2020 8:59 am

What an interesting challenge.

How critical is this program?

Might you need to rewrite it? Sill have the specs?

Do your production control procedures allow for this, and what will be your validation testing?

John Poulakos · Posted: Tue Jan 28, 2020 8:34 pm

Apoorva · New User Joined: 28 Jan 2020 Posts: 49 Location: India

Can you change D50139188AF0 to 952839191800 which translates to

CLI X'919'(R3),X'28' ==> X'28' = DECIMAL 40 (4 BYTE INSTRUCTION)
LR R0,R0 ==> THIS IS JUST TO FILL UP REMAINING 2 BYTES

So, 6 byte CLC has been changed to CLI/LR.

Apoorva · New User Joined: 28 Jan 2020 Posts: 49 Location: India

In my previous suggestion I have assumed that x'918' off R3 is always zero. If this is not true then the previous solution will not work. Then best way is to set up a SLIP TRAP at that "CLC" instruction, and take a dump. In the dump, you need to check if there are any eye-catchers before or after x'AF0' off R8 so that you could locate them in either LOAD or OBJECT, and change those 2 bytes to 40.

John Poulakos · Posted: Thu Jan 30, 2020 9:29 pm

THANKS A LOT FOR TRYING!
The only thing I can be sure of is D501. I can't set a SLIP TRAP because there could be many D501 statements and I have to check them all for 20 and 40. I can't look for eyecatchers because the 20 or 40 are in the literal pool and could be part of another literal (or not). The way the COBOL compiler works is if a statement specifies a literal value, the compiler scans the literal pool to see if the value exists. If it does, it just points an address to it. If it doesn't, it adds it.

For example, if 1920 already exists in the literal pool and I have a statement that uses a literal of 20, it will simply point an address to the 20 in 1920. However, if the literal 20 is requested before 1920 exists, then a value of 20 is added to the literal pool. Then if 1920 is specified as a literal it will also be added to the literal pool, because it could not be found in the scan.

I have found a method that works 95% of the time. COBOL initialization code always ends at FC. This is followed by the PGT which is fairly easy to identify, as it always contains blanks and zeros and character values. The first value following the PGT that can recognized as a valid fullword address or value is the value that needs to be added to the displacement in the CLC instruction.

In this example, look at the data following FC. The first value that looks like a valid address is at 140. That value is 15C.

Phrzby Phil · Posted: Thu Jan 30, 2020 9:43 pm

A fascinating analysis, but I must repeat my question above:

Do your production control procedures allow for this, and what will be your validation testing?

We programmers love technical challenges, but are the managers/users knowledgeably on board with this approach?

Not that you seem to have another, other than replacing the package.

John Poulakos · Posted: Thu Jan 30, 2020 11:05 pm

Apoorva · New User Joined: 28 Jan 2020 Posts: 49 Location: India

Interesting challenge! Looks like you have a plan. I hope you will soon resolve the issue. Please keep us posted. It will be a new learning to us also.

Phrzby Phil · Posted: Tue Feb 11, 2020 9:27 am

Love to see an update on this problem.

John Poulakos · Posted: Fri Feb 14, 2020 11:55 pm

Well it took awhile, but the problem has been resolved. I started with 189 programs. By searching joblib, proclib and scheduler tables, I determined that 90 of the programs were not used and were obsolete. Of the remaining 89 programs, 53 used only 2 digit years and did not use century. 10 programs had date check routines that would ABEND with 1920 date, if run. Of the remaining 26 programs, 10 created reports than nobody looked and 5 updated DB2 tables that were no longer used. Some of those tables seemed to have been used for year 2000 processing. There were 11 programs that were using 1920 and updating DB2 tables. 9 of them were putting 1920 in date stamps in DB2 tables, which was easy to find and fix. Only two were using 1920 as part of selection criteria that caused invalid data selection. Special runs of these two programs, after they were recompiled, fixed that problem.

There were some awful programs to look at, with some program techniques that made them even worse. They seriously over-used copybooks, adding 10k - 15k lines to every program, for things that weren't even used. They commented out every line of code they ever changed and left it in the programs (and copybooks). Some programs had 2k - 3k lines of dead code. All database functions used a copy/replace logic to an interface module; no actual SQL.

I finished figuring out what damage the last program would cause this morning.

Phrzby Phil · Posted: Sat Feb 15, 2020 2:22 am

Thanks for the update.

During my career I was always big on keeping things clean - dead code, programs, files, etc. Well worth it in the long run.

Of course, management has to agree.

John Poulakos · Posted: Tue Feb 18, 2020 8:16 pm

I forgot to mention I started with over 500 programs and found that 189 had the bad compare. I was able to automate the object module analysis process to speed things up.