Answered How can I identify code blocks exceeding 32K limit

[Venkateswarlu N]

Question:
Error 12370 and 142 trying to open a program using AppBuilder
Attempt to update <name> record data exceeding <number>. (12370)
Attempt to update _trg record data exceeding 32000. (12370)
** Unable to update <filename> Field. (142)
** Unable to update _trg Field. (142)
Opening a file in the AppBuilder generates error Unable to update _TRG field( Field. (142)).
Opening an AppBuilder generated file in the Appbuilder generates error.

File was originally created in AppBuilder
File was later edited in the Procedure Editor.

Cause
The Procedure Editor and the Section Editor do not use the same underlying code. This issue can happen because the size of the procedure created by the Procedure editor is bigger than what Appbuilder allows (32K per segment, ie. definitions, main block, each procedure / function)

Solution
Is to get my program to adhere to 32k limit

Is there any technique to identify which of the code blocks are causing this error (i.e. > 32k)?

 

[Cringer]

Easiest way is to use your source control to compare revisions. You do use source control, right?

 

[Osborne]

+1 for Cringer's solution.

If the problem is due to an internal procedure there is the ability to obtain internal procedure sizes. Start a session with the parameters -yd which will create a file called client.mon which will record every program you compile or run. Open the client.mon file in Notepad and you will see something like this:

Per procedure segment information
---------------------------------
File Segment [HASHTAG]#Segments[/HASHTAG] Total-Size
---- ------- --------- ----------
C:\prog1.w
Initial 1 56144
A-Code: 1 1 111392
E-Code: 1 1 78580
Debugger 1 27072
Int-Proc: 1 1 2212
Int-Proc: 2 1 1740
Int-Proc: 3 1 1580

Check the Int-Proc: x values as one of these are likely to be the cause of the problem.

 

[Saptarshi Sengupta]

We have a very old code base and most of the revision history is maintained in code. This creates problems similar to the one described when working with AppBuilder.
We bypass this problem by adding separate procedure blocks for newer history items - For example: ip-History-Section-1 , ip-History-Section-2 , so on.
However, the best way to handle the problem is how Cringer advised. ClearCase, Subversion, etc all support this.