COBOL - Sequence unnumber action could not be performed.. Internal error: {}

[FALLAI-Denis]

Development environment used

• Z Open Editor version: 1.4.1
• Editor Platform
  • Visual Studio Code
  • Red Hat CodeReady Workspaces
  • Eclipse Che
  • Standalone Theia
• Editor Platform Version: 1.62.2
• Operating System: Windows 10 "1909"
• Java Version: java version "1.8.0_102" / Java(TM) SE Runtime Environment (build 1.8.0_102-b14) / Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
• Related to RSE API?
  • RSE API Plugin version:
  • Zowe CLI version:
  • Node.js version:
• Logs attached (see here how to get them): yes/no

Problem Description

During a "unnumbering" request, there is an error message without details, and no action is taken.

Observed behavior

2021-11-21T18:06:12.456+0100 ERROR: Sequence unnumber action could not be performed.. Internal error: {}

The COBOL source code is partially numbered (for some lines the line number field is blank), and some lines contain a non-numeric value at the location of the line number.

The source code is in error due to the misinterpretation of the language server.

If we pause the language server, that does not solve the problem on the unnumbering.

>>> Restarting VS Code fixes the problem! <<<

Expected behavior

Failing to be able to perform the action, Z Open Editor would have to be more explicit about the error itself.

[phaumer]

@FALLAI-Denis thanks. Do yo have a sample for us to reproduce this?

[FALLAI-Denis]

Hi @phaumer

At this time I have no use case to provide because the problem seems more related to a work context than to a particular source code.
As noted, restarting VS Code (reloading window) fixes the issue.

A priori, the numbering / unnumbering functions are not linked to the language server because they remain accessible even if the language server is paused. So even if the language server doesn't understand the source code it probably doesn't have any impact.

The affected COBOL source code was approximately 3000 lines long and several sources of same size were open in VS Code.

Reloading VS Code should clean up something in the context management of Z Open Editor which makes the numbering / unnumbering functions operational again. The activation of the unnumbering function was triggered just after reloading VS Code, whereas the problem usually arises after a long period of work.

Are the numbering / unnumbering functions pure VS Code (TypeScript / JavaScript code present in extension.js) or do they use Java routines from the embedded Eclipse module?

Basically, it is the anomaly message that should be improved: to provide information on the reasons for the failure of the function.

[phaumer]

These operation are implemented in the language server, though. They will not work without it running. I agree that we should improve logging in failure situations such as these. We will investigate.

[FALLAI-Denis]

Hi @phaumer

The problem appeared after pausing the language server and restarting it by opening a new COBOL file. Does this restart all language server functions correctly?

When the COBOL language server is restarted by opening a new COBOL file, is it also available for COBOL files already open when it was paused?

The unnumbering function was tested with succes just after reloading VS Code, without pausing the COBOL language server.

[phaumer]

@FALLAI-Denis yes, that is the intended behavior: when you pause the language server it will restart only if a file gets opened, i.e. for an already open file you need to close and open again. However, when you open another program the editor will check all the already open tabs and initialize these also again with the language server if they are COBOL.

The Pause action was introduced mainly to free up resources when switching between languages, especially in resource critical environments such as Eclipse Che. We were hoping that it would not be necessary to use it when the language server runs into issues. All these we would love to fix.

[FALLAI-Denis]

Hi @phaumer

The problem encountered is therefore explained.

To get to the end of things, it would be necessary:

• either deactivate the number / unnumber entries in the contextual menu when the language server is not active for the source being edited,
• either have a more explicit error message when the number / unnumber command is activated and the language server is not active for the source being edited.

---

Regarding language server issues, I opened a discussion #184 The language server is not a language compiler.

Today the functioning of the server language is of the "all or nothing" type, one cannot activate / deactivate by functionalities, but it is probable that certain functionalities are independent of the others.

It also seems to me that the language server tries to parse the source code as a whole and that this is not always possible due to the use of COPYBOOK and conditional compilation. The language server would have to do local analyzes of the source code, even if it means being less complete or less powerful.

Apparently when parsing a COPYBOOK (.cpy) the language server is less demanding than when parsing a COBOL (.cbl). This suggests that mechanisms limiting the scope of the analysis must therefore be in place in the language server.

Would it be possible to introduce a level of analysis in the language server, going from "all functions" to "minimal functions" to selectively deactivate the functions that could cause problems?
It seems to me that this is what is done for the detection of unreachable code.

To help debug the language server, it would be necessary to be able to activate logs or traces to capture information on the problems encountered.

[phaumer]

Fixed in Z Open Editor v3.2.0 by removing the menus when the language server is not running.