Large copybooks cannot be resolved

[GhettoKiwi]

• Z Open Editor version: 3.0.1
• Editor Platform
  • [X] Visual Studio Code
  • [ ] Red Hat CodeReady Workspaces
  • [ ] Eclipse Che
  • [ ] Standalone Theia
• Editor Platform Version: 1.74.3
• Operating System (on which VS Code runs such as Windows 10 2004, otherwise name and version of platform such as OpenShift v4.3): Windows 10
• Java Version (when using VS Code or Theia, execute java -version and paste the details here): 11

• Problem Description

  I have a cobol module that has a copy-statement to a copybook that contains the following:

Level 01: 1 Level 02: 108 Level 05: 351 Lines: 612 Total Characters: 27771

It will resolve everything in the copybook up untill Line: 370, 370 being excluded. Amount of levels that can be resolved: Level 01: 1 Level 02: 63 Level 05: 203 Lines: 369 Total Characters: 16742

Any reference to variablesnames inside my cobol module, that comes after line: 369 will be shown with the error: "Unable to resolve reference to SOMEVAR"

[phaumer]

Can you and all the thumbs uppers conform that this is happening with z/OSMF only? Anyone observing this in RSE? The theory is that it is caused by https://github.com/zowe/zowe-cli/issues/1920 and we had thought that we worked around it, but perhaps we missed a case. Investigating.

[GhettoKiwi]

Yes, using z/OSMF

[FALLAI-Denis]

Hi,

Is the copybook retrieved locally from the remote z/OS system truncated after a certain position, or is this a problem with handling the declarations present in the copybook after a certain position?

For my part, I understand from the description of the issue that it is the treatment of the text replacement of the copybook by the COBOL Language Server which seems to be in question: from a certain position in the copybook, the replacement is no longer realized and all references by the COBOL program to statements after this position appear unresolved.

The value 16742 reminds me of a storage capacity problem in a working variable of the Language Server, (developed in Java ?). With a management of character strings in UTF16, this value could correspond to a declaration in the short format (maximum value 32767, and if we divide by 2 for an UTF16 encoding with a 2 bytes by character, we approach 16742 ).

[GhettoKiwi]

As far as I am concerned, the copybook is not truncated. The copybook is fetched to a local folder whenever the language server is analyzing the cobol module, and the full copybook can be opened up and read without missing anything. :)

[phaumer]

We believe we fixed this in v3.1.0. Please reopen if you still observe this behavior in the new version.