EXEC is not defined

[Sundar Raman P]

I am trying to compile https://github.com/aws-samples/aws-mainframe-modernization-carddemo code with gnuCOBOL but I get the below error:

Is it because the vocabulary is mismatching or there are some IBM copybooks which are left from being copied. How to copy them?

Error:

SBANK35P.cbl:126: error: 'EXEC' is not defined
SBANK35P.cbl:126: error: 'CICS' is not defined

  124 |       * Call the appropriate routine to handle the business logic
  125 |            IF BANK-MAP-FUNCTION-GET
  126 >               EXEC CICS LINK PROGRAM(WS-BUSINESS-LOGIC-PGM)
  127 |                              COMMAREA(WS-BANK-DATA)
  128 |                              LENGTH(LENGTH OF WS-BANK-DATA)

[Vincent (Bryan) Coen]

This application is for running on a IBM mainframe that has CICS installed.

You cannot even use it using TK4 and 5 as the Cobol is too old for the
level of Cobol used.

Other than that you would need access to OpenKICS which is not easy to
obtain.

On 14/08/2023 13:49, Sundar Raman P wrote:

I am trying to compile
https://github.com/aws-samples/aws-mainframe-modernization-carddemo
code with gnuCOBOL but I get the below error:

Is it because the vocabulary is mismatching or there are some IBM
copybooks which are left from being copied. How to copy them?

Error:
SBANK35P.cbl:126: error: 'EXEC' is not defined
124 | * Call the appropriate routine to handle the business logic
125 | IF BANK-MAP-FUNCTION-GET
126 > EXEC CICS LINK PROGRAM(WS-BUSINESS-LOGIC-PGM)
127 | COMMAREA(WS-BANK-DATA)
128 | LENGTH(LENGTH OF WS-BANK-DATA)
SBANK35P.cbl:126: error: 'CICS' is not defined

[Ralph Linkletter]

You could try it with WINZOS at wincobol.com.
It is Windows only.
WINZOS presumes you are familiar with zOS based COBOL development.
If you are not comfortable with the above then WINZOS is not a good fit.

It does have CICS and DB/2 support using GnuCOBOL
The CICS preprocessor is a RYO
The DB/2 preprocessor is IBM's

Ralph

[Anonymous]

As noted in the README,

Technologies used

COBOL
CICS
VSAM
JCL
RACF

GnuCOBOL gives you COBOL with support for VSAM semantics. CICS, JCL, and RACF are up to you to supply.

COBOL applications frequently make use of other technologies via a preprocessor. Many such preprocessors use the form

EXEC X
     X-language
END-EXEC

where X names the preprocessor responsible for converting the x-language syntax to COBOL. When the application is compiled, the source code is passed through as many precprocessors as necessary, until pure COBOL is emitted to the compiler. If a preprocessor is not invoked, then the compiler sees the EXEC keyword, and emits an error message,

error: 'EXEC' is not defined

because EXEC is not part of the COBOL language and is not defined as user-defined function.

In your case, X is CICS, but the README promises future examples for IMS and DB2.

There is no free version of CICS. OpenKICKS is a viable option on Linux if you;'re willing to invest time and money.

[Simon Sobisch]

Everything EXEC is out of scope for GnuCOBOL as this isn't COBOL but something else.
Normally you'd use a preprocessor to translate those to plain CALL statements, for example: OpenKicks (I'm not familiar with that @pottmi or @jklowden may be of help) then a DB2 preprocessor (there's one included in the DB2 client) or general SQL processor like esqlOC / GixSQL, then GnuCOBOL.

[Sundar Raman P]

I am trying to use this COBOL parser: https://github.com/uwol/proleap-cobol-parser for handling this and other requirements such as generating call-graph, control-flow graph of a COBOL codebase. Any inputs from the community on using this tool would be appreciated:)

[Simon Sobisch]

Other than "please read their docs, and issues, post an issue there if you have problems and possibly use the tool they based on that https://github.com/proleap/proleap-cobol and then come back to tell us more about this option, ideally in a separate thread"? No.

[Vincent (Bryan) Coen]

On 15/08/2023 16:11, Sundar Raman P wrote:

I am trying to use this COBOL parser:
https://github.com/uwol/proleap-cobol-parser for handling this and
other requirements such as generating call-graph, control-flow graph
of a COBOL codebase. Any inputs from the community on using this tool
would be appreciated:)

A quick look at it shows it may well not be suitable for your possible
requirements.

It does depend on what you are trying to gain from using it or any other
such tool.

In days gone by, I used to use a FlowCharter product that you feed in a
Cobol program and a full flow chart would be printed in a line printer
(using continuous stationery) - can use a lot of paper.

A great idea on paper at least but ends up harder to read and follow the
program flow - the Cobol source is easier to read along with comment of
what each block or section is doing and all of my program as so
commented if only when there is a gap or doing the work and having to
re-read it for bug tracing etc.

There is a tool called Doxygen that does a detailed break down but again
is very verbose where the original Cobol code is easier to read.

Brian T, like it a lot does it does nothing for me. Note it really works
best for C code which as output from the Cobol compiler is even less
helpful unless you really are having issues finding a bug but here there
is the Cobol tools of READY TRACE, RESET  TRACE and at a lower level
usage of the machine code with a different Debug tool such  as GDB, at
least for *nix.