Hello alejandro rodriguez mancera,

You mentioned that different COPY file assignment paths are used in the Test vs QA environments. On thing that .gnt files will contain is the literals from the COBOL program - including those may be defined in COPY files. Could the COPY files be different? One thing you might try is to compile the program in both environments to create a listing file, adding the RAWLIST and COPYLIST compile directives (so that the listings will contain the contents of the COPY files, and not include listing headings). Then compare the listing files from Test and Production to see how they differ. Is the code exactly the same? Are different literals perhaps used?

Good afternoon,

Thank you very much for your support. I'd be happy to send you the generated .lst files for each environment. Please share an email address for this submission. This information is sensitive and I can't post it on the public forum.

I look forward to hearing from you.

Sincerely,

Alejandro

Hello alejandro rodriguez mancera,

Thank you for your update. I've thought of one more directive that might be helpful when you generate the listings. Please add the following to your specified compiler directives:

SETTINGS(COL) COPYLIST RAWLIST

Then compile to generate the listing files for comparison.

Before sharing any listing files, could you try comparing them yourself? If this is on Unix/Linux platform, you can use the diff utility, for example:

$ diff mytestpgm.lst myqapgm.lst

Are there any differences reported by the comparison? If so, do these differences involve actual COBOL statements?

alejandro,

You said that the files differed in size but not by how much. When programs are compiled there can be error reporting code included in the generated code which contains the source file name so if the paths differ in length between the test and production environments that would result in different length names being embedded in the generated code, resulting in different file sizes.

Good afternoon,

Thank you very much for your response. I have already shared this information with the client. He tells me that my assessment of this potential difference generator is correct. I requested the .lst files with the requested directives included. As soon as they are delivered, I will review them in detail to provide the client with the report with the most accurate differences.

I remain attentive to your instructions.

Sincerely,

Alejandro Rodriguez Mancera

Good afternoon:

Continuing with the migration work, in addition to the differences in the size of the generated .gnt objects, we can see that performance times have increased. They now take almost three times longer than previous executions.

I would appreciate it if you could provide me with documents or references on how to optimize the compiler to generate an object without unnecessary additional environments, as well as instructions on how to optimize the runtime to optimize execution times.

The new version of Cobol is Visual Cobol 10.

I look forward to your guidance.

Sincerely,

Alejandro Rodriguez Mancera

Hi Alejandro,

Regarding your other question... "we can see that performance times have increased. They now take almost three times longer than previous executions."

Are you talking about the entire application running start to finish is taking 3 times longer or is there a particular section of the application which is slower such as file handling or database access, communications, etc.?

You mention that you are now using version 10.

What version were you using previously?

On what platform, OS and version is this?

Have you changed other aspects in the environment such as hardware, OS, database versions, etc?

Thanks

Good morning,

Thank you very much for your support. Below are the responses:

Yes, the performance of the batch application has been measured (this migration has already been performed in production), taking up to 30% longer than the previous execution. This involves files, processes, database accesses, and other artifacts that operate in the Batch application.

The version previously used was Cobol Server Express 5.1; the new version is Visual Cobol 10.

The operating system on which it was previously installed was AIX 7.1; it was migrated to AIX 7.3.

The database engine is Oracle 19.0.0.

Thank you very much for your time. I look forward to your guidance.

Hi Alejandro,

Thanks for sharing the information about the platforms, O/S versions and prior version of COBOL you've used.  Please note that aside from COBOL, many components may affect performance and be different between your old and new installations, including hardware differences, network differences, file locations (stored on local disk vs. on remote/shared resources), Operating System changes, Database versions and configuration options. So you may want to consider and review those as part of your investigation of the performance difference.

Regarding COBOL, the behavior and performance of your application can be affected by compile-time and runtime settings. So as a first step, you might want to make sure that these were brought forward to your Visual COBOL installation.

For compile-time settings, you might want to  confirm that the same compile directives are being used when you compile in Visual COBOL as were used in Server Express. There are several places these could be specified. Examples include setting directives as part of "cob", "cob32" or "cob64" commands within scripts or makefiles that build your COBOL programs, or these might be stored in directives files; one example of this is a file named cobol.dir.

For run-time settings, try confirming that any COBOL Runtime configuration settings which were in effect in Server Express are present in your Visual COBOL application setup. Runtime configuration settings can be specified in an optional file created as $COBDIR/etc/cobconfig. So you might want to check that location in your Server Express installation. It's also possible to specify a different filename for a runtime configuration file, by setting the environment variable COBCONFIG; for example: $ COBCONFIG=$HOME/myconfig; export COBCONFIG. So you might want to confirm whether the COBCONFIG environment variable was set in your Server Express setup, and whether the file associated was brought forward (and $COBCONFIG set) in your Visual COBOL installation.

Next, you might be able to learn more about which portion(s) of your COBOL application are associated with the slowed behavior by using the Profiler feature. Profiler was available in Server Express, and it's been enhanced with additional features in Visual COBOL. This feature can help you isolate which programs (and Paragraphs and Sections within them) are taking the most time to execute. Here is a link to a section about Profiler in the Visual COBOL documentation. Also, there is a set of 3 YouTube videos available on using Profiler in Visual COBOL, which can provide further background:

Visual COBOL: Introduction to Micro Focus COBOL Profiler

Visual COBOL: Profiler Advanced Usage

Visual COBOL: Using Profiler in the Eclipse IDE

Finally, isolating performance issues is a complex topic, not well suited to investigation on the Community site. We recommend that you create a Support Case about this problem.

Good morning:

Thank you very much for your insightful comment. We are already working on using .profiler for parallel code optimization, as well as configuring enable optimization (-O). We have also requested the responsible department to create the corresponding support case to continue with compilation optimization and runtime optimization.

One last question: Do you know of any hotfixes or patches for Visual Cobol version 10?

Thank you very much for your support. My sincere wishes for a successful start to the week.

alejandro

Hi Alejandro,

The latest Patch Update available is Visual COBOL 10.0 Patch Update 5.

Good morning

Thank you very much for your response. Does this patch cover previous versions (Patch 4, Patch 3, Patch 2, Patch 1)? Do you have a description of the improvements contained in Patch 5?

Thank you very much. Sorry for so many questions.

atte.,

alejandro

Yes, Visual COBOL Patch updates are cumulative, so fixes in earlier Patch Updates will be included.

The fixes and enhancements included in a Patch Update are listed in a readme document, which is available as a separate file when you download the Patch Update installer. To save you some searching, I've also attached the readme document for Visual COBOL Development Hub 10.0 Patch Update 5 to this post.

Good morning

Once again, thank you very much for your support. We are awaiting support case creation. This has not yet been completed due to paperwork between the client and RocketSoftware. Is it possible for you to share a link where we can download Update 5? I request this since the defined channels have not yet been established and we have not made any progress on this test or the support case creation.

Thank you very much for your time.

Hi Alejandro,

Access to Product Downloads requires an active Maintenance Agreement with Rocket Software for the specified product. If you or your end customer has questions about this, the best approach might be to reach out to your Rocket Software Account Executive.