Highlighted
Absent Member.
Absent Member.
3131 views

Compiler Directives

Jump to solution

I'm starting the progress of migrating RM Cobol (Linux) to RM Cobol/Visual Cobol(Linux) with Eclipse (Windows)

I've discovered the option to set the compiler directives in a file cobol.dir and have that control some of the compile, build and file options.


I was wondering what is the compiler directive for the cobol.dir to tell it to use RM. I know its completely lazy, because I can change the Dialect in the Build Properties ... but I'm intending of doing somewhere north of 1600+ programs, and anything that will allow me to move these from RM with a Text DE to RM with a Visual IDE would be helpful.

I know my cobol.dir is working because I've moved the idxformat"21" to it for RM File access, as opposed to having the set command in the programs.

Any tips for how to accomplish this ... any warnings for doing it this way?


Long Term the plan is to move from RM Text DE to RM Eclipse to VC Eclipse ... but for now I need to learn Eclipse and start using it regularly which will involve me getting away from RM Text DE.

0 Likes
1 Solution

Accepted Solutions
Highlighted
Absent Member.
Absent Member.

RE: Compiler Directives

Jump to solution

I'm trying to take this migration in bite-sized chunks. I'm trying to get my RM into the same Eclipse environment that Visual Cobol uses, because I'm going to need to be as comfortable with it as I am with my current texted based environment (Text editor).

I played around and found the solution I was looking for ... cobol.dir does not allow for setting the dialect to RM (DIALECT"RM"). I built my own .dir (rm.dir, I know original). And if add the line $set use"/data/esource/rm.dir" at the top of my old rm code, I can compile in Eclipse quickly without having to set the build properties to RM on every program.

For reference the contents of rm.dir are

idxformat"21"

DIALECT"RM"

For building runnable code, at the moment anyway.

I just

  1. Create COBOL REPORT PROJECT.

  2. New File and Link to the existing Code.

  3. Add the above $set command

  4. Save

  5. Watch it compile/build

  6. Make sure the program works, and make it live if it does

This way I can quickly go through my programs, and only deal with issues related to RM assumptions that are not built into DIALECT"RM" such as assuming we took the time to add filler to the end of all files.

Once I get all of my systems in the VisualCobol/Eclipse IDE, I start learning Visual Cobol, and converting them to that DIALECT.

Thanks so much for your responses. Where I got caught is that cobol.dir a default directives file for Eclipse/VisualCobol doesn't allow you to override the DIALECT to RM, but another .dir file would work just fine.

View solution in original post

0 Likes
3 Replies
Highlighted
Absent Member.
Absent Member.

RE: Compiler Directives

Jump to solution

Hi Eric,

There is a compiler directive called 'RM' that changes the behavior of certain features to be compatible with RM/COBOL. IT is discussed here: documentation.microfocus.com/.../HRCDRHCDIR5R.html

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Compiler Directives

Jump to solution

Let me first say that there is no directive that will provide 100% compatibility with RM/COBOL in Visual COBOL.

There are a couple of different directives that control a certain level of RM compatible depending on the features that you are using.

If you wish to turn on certain RM syntax so that it is recognized by the compiler, such as ACCEPT/DISPLAY LINE/POSITION, etc you can do this with the RM directive.

If you wish for the behavior to emulate RM at run-time and for the compiler to adhere to strict RM standards then you can turn on the DIALECT"RM" directive.

If your migration plan is to start adding additional Visual COBOL language features to your application then you should avoid using the DIALECT"RM" directive.

Thanks.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Compiler Directives

Jump to solution

I'm trying to take this migration in bite-sized chunks. I'm trying to get my RM into the same Eclipse environment that Visual Cobol uses, because I'm going to need to be as comfortable with it as I am with my current texted based environment (Text editor).

I played around and found the solution I was looking for ... cobol.dir does not allow for setting the dialect to RM (DIALECT"RM"). I built my own .dir (rm.dir, I know original). And if add the line $set use"/data/esource/rm.dir" at the top of my old rm code, I can compile in Eclipse quickly without having to set the build properties to RM on every program.

For reference the contents of rm.dir are

idxformat"21"

DIALECT"RM"

For building runnable code, at the moment anyway.

I just

  1. Create COBOL REPORT PROJECT.

  2. New File and Link to the existing Code.

  3. Add the above $set command

  4. Save

  5. Watch it compile/build

  6. Make sure the program works, and make it live if it does

This way I can quickly go through my programs, and only deal with issues related to RM assumptions that are not built into DIALECT"RM" such as assuming we took the time to add filler to the end of all files.

Once I get all of my systems in the VisualCobol/Eclipse IDE, I start learning Visual Cobol, and converting them to that DIALECT.

Thanks so much for your responses. Where I got caught is that cobol.dir a default directives file for Eclipse/VisualCobol doesn't allow you to override the DIALECT to RM, but another .dir file would work just fine.

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.