Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large copybooks cannot be resolved #313

Closed
1 of 4 tasks
GhettoKiwi opened this issue Jan 25, 2023 · 5 comments
Closed
1 of 4 tasks

Large copybooks cannot be resolved #313

GhettoKiwi opened this issue Jan 25, 2023 · 5 comments
Labels
bug Something isn't working

Comments

@GhettoKiwi
Copy link

  • Z Open Editor version: 3.0.1
  • Editor Platform
    • 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
Copy link
Member

phaumer commented Jan 26, 2023

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 zowe/zowe-cli#1920 and we had thought that we worked around it, but perhaps we missed a case. Investigating.

@phaumer phaumer added the bug Something isn't working label Jan 26, 2023
@GhettoKiwi
Copy link
Author

Yes, using z/OSMF

@FALLAI-Denis
Copy link

FALLAI-Denis commented Jan 28, 2023

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
Copy link
Author

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
Copy link
Member

phaumer commented Mar 10, 2023

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

@phaumer phaumer closed this as completed Mar 10, 2023
@kristinochka kristinochka removed the bug Something isn't working label Apr 10, 2023
@phaumer phaumer added the bug Something isn't working label May 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants