Solved: Eclipse Errors - Micro Focus Community

Eric Boatman · ‎2014-09-16

Is there a way to tell Eclipse that Echo is a reserved word for Accept Statements, which it is for RM Cobol (Until I remove them all).

Either Eclipse tells me that every ECHO is an error, or I add Echo to the Working Storage, which makes Eclipse happy, but then the Program won't build because I have a Reserved Word in Working Storage ...

I can ignore the Error messages for ECHO, but we have a prompt heavy system, and I won't be able to use Eclipses find error features.

I just need to tell Eclipse that ECHO is ok, for now.

Eric Boatman · ‎2014-09-22

Figured out how to make it work ... changed that last filler to.

03 FILLER PIC X(20) VALUE Z' < /dev/null'. which supplies the correct null at the end of the command line.

View solution in original post

Scot Nielsen · ‎2014-09-16

Hi Eric, are you compiling with the dialect(rm) directive?

If not, try adding this at the top of the source file starting in col 7:

$set dialect(rm)

ppimental · ‎2014-09-16

Hello Eric,

It appears you may aleady have dialect(rm) turned on, either through $set dialect(rm) or through the Eclipse. In either event, the ECHO entry in Working Storage will be flagged as a reserved item if dialect(rm) is on. Using the default MF/COBOL dialect should enable ECHO to be set as a varible in Working Storage. This is a case where the RM Dialect does not provide 100% compatibility. We recommend that you use the Compatibility Guide, in the online help facility, under Micro Focus Visual COBOL 2.2 ...., Programming, Compatibility, Compatility with RM/COBOL Applications, to modify the code so that you will not need to use dialect(rm).

Eric Boatman · ‎2014-09-16

So no work around ... to make Eclipse happy, while I'm importing my RM/Cobol?

Chris Glazier · ‎2014-09-16

I am not seeing the error of which you speak when I use dialect"rm" or just the rm directive.

I believe that you also had an open incident regarding the call "system" but it failed if you set dialect"rm" on because of the different call-convention used when dialect"rm" is on.

I find that both the echo and the call "system" work correctly if I use $set rm instead of $set dialect"rm" at least when testing under Windows.

The following compiles and runs fine under VC 2.2 for Eclipse update 1 when I run it locally under Windows.

$set rm
      identification division.
      program-id. Program1.
      environment division.
      configuration section.
      data division.
      working-storage section.
      01 field-1 pic x(10) value "12345".
      01 any-key pic x.
      procedure division.

display "test"

accept field-1 line 5 position 5 echo
call "SYSTEM" using "notepad.exe c:\temp\test.txt"

accept any-key

goback.

end program Program1.

ppimental · ‎2014-09-17

using $set rm also works with Visual COBOL for Eclipse with remote projects on DevHub, though you will want to terminate the string call using all SYSTEM with a null terminator such as

CALL "SYSTEM" USING "touch /home/support/test.txt \0" .

Or

CALL "SYSTEM" USING z"touch /home/support/test.txt"

the z will tell COBOL to null terminate the string that follows.

Otherwise a file will be created named test.txt8? instead of test.txt.

The accept echo statement also works under this scenerio.

Eric Boatman · ‎2014-09-17

Using $set RM vs $set DIALECT"RM", worked great!!

Is $set RM the better choice when choosing RM Methods?

ppimental · ‎2014-09-17

For RM library routines you may need to follow the second example in the KB below:

community.microfocus.com/.../20176.rmcobol-library-routines-call-convention.aspx

Also consult the compatibility guide in the onlines for the product for other known compatibility issues.

For specific RM methods, you may encounter varying levels of success.

Eric Boatman · ‎2014-09-19

I have found an issue ... if you build the Using Portion of the Call "SYSTEM" in working-storage, you cannot specify the Z option. Which makes for some unpredictable results. Such as the system inventing some additional e-mails, that are completely bogus.

ppimental · ‎2014-09-19

If you can supply a small reproducible test case, that would be useful.

Eric Boatman · ‎2014-09-19

Is there a way to specify the Z option in the Call and still use a Working-Storage variable for the Call?

Something like.

CALL "SYSTEM" USING Z,VARIABLE-BUILT-SCRIPT.

?

Chris Glazier · ‎2014-09-19

No this will not work.

As Phil had mentioned can you show us an example of what you are doing?

It should be something like:

01 my-command pic x(20) value z"mycommand".

call "SYSTEM" using my-command.

Be aware that if the PIC clause is larger than the literal in the value clause that trailing spaces will appear after the null and this may be causing the problem.