COBCH1674 Internal dictionary overflow. Program too large

Hi,

I have a large program in WPF that was developed in Cobol 3.0 and that did not give any problem. Now I upgraded to version 6.0 and when I compile it gives the error "COBCH1674 Internal dictionary overflow. Program too large".

Due to the error specifications, the solution would be to reduce the number of lines but I am unable to do so.

I contacted Microfocus support and the solution they gave was to segment the program in several but I don't know how to do it.

The program has about 480 variables defined in the xaml and has all its treatment (definition of size, color, position, etc.) defined in the program according to the situation. it also has the procedures related to "clicks" made in each field (and there may be 4 per field).

I've tried to pass these routines to an external source but it gives an error because it doesn't recognize the variables.

Attached is a zip file containing the sources (screen and program), as well as a printout of the final screen of the application (reservation planning).

Thanks for your help.

Best regards

Alberto Ferraz

Can you please provide me with the support case incident number that was assigned to this so that I can research it?

Thanks

Hi Chris,

Case 00490160-Visual COBOL - Issues with the editor and COBCH error

Thanks

Alberto Ferraz

It looks like the support engineer recommended that you split up your source code into smaller modules and he also explained to you that we cannot look at the problem unless you send us a complete project with which we can reproduce the error. The zip file attached to this post only contains the reservas.xaml and the reservas.xam.cbl files.

I tried importing these into a new WPF project and it will not compile because of missing copybook files, .ico files and missing 3rd party assemblies.

I would recommend at this point that you cutdown your application so that only the files required to reproduce the error are included. I would suggest that once you have a complete reproduce that you upload it to the support case and continue to work with the Support Engineer who is assigned to it. If the same application used to work in 3.0 and no longer works then we will certainly look into the issue deeper, provided we have a reproduce.

Thanks

Hi Chris,

As you suggested, I prepared a project with the program in question so that they can analyze what the problem is and, eventually, suggest how to solve the problem.

I send it as an attachment.

Note: I already sent to Microfocus support for Martin Turner. I look forward to feedback.

Best regards

Alberto Ferraz

Thank you for providing a complete example.

From taking a quick look at this I see that you are including a SQL(DBMAN=ODBC) directive at the top of the program. This means that the program will be preprocessed and the OpenESQL preprocessor which will expand the sources under the covers to be even much larger than the program as it stands.

First off since this is managed .NET code you should be using SQL(DBMAN=ADO) instead of ODBC as ODBC is for native code and ADO is for managed code.

I would recommend that the best way to partition this program is to move all of the SQL logic into a subprogram that can be called from the main form program. This would divide your program into a separate UI layer and a data layer instead of mixing the two together. This should also reduce the program size to the point where it can be compiled. 

I checked the open incident for this problem and I do not see that it has been updated since April 6th when Martin recommended that you split up the program. In order for us to send the program to development for a look you will have to upload this file to the open incident.

Thanks.