I am afraid that this is a restriction of Pro*COBOL itself, which is an Oracle product and has nothing to do with COBSQL which only interfaces Visual COBOL to Pro*COBOL for doing the actual source translation.

OpenESQL (which is a Micro Focus developed solution) does not have this restriction and will work with FREE or VARIABLE formats.

According to the Pro*COBOL Programming Guide:

Coding Area

You must code EXEC SQL and EXEC ORACLE statements in columns 12 through 72 (columns 73 through 80 are ignored).

Note: The precompiler option FORMAT, specifies the format of COBOL input lines. If you specify FORMAT=ANSI (default), columns 1 through 6 can contain an optional sequence number, and column 7 indicates comments or continuation lines. Division headers, section headers, paragraph names, FD and 01 statements begin in columns 8 through 11 (area A). Other statements begin in columns 12 through 72 (area B).

If you specify FORMAT=TERMINAL, columns 1 through 6 are omitted, making column 7 the left-most column.

Note: In this manual, program examples use the FORMAT=TERMINAL setting. The online sample programs use FORMAT=ANSI.

Thanks.

Hi Chris,

Thanks for your answer.

In pro*cobol 11gr2, we have now 3 formats for the source ansi/terminal/variable.

Here's the 11gr2 doc...

Coding Areas

The precompiler option FORMAT, specifies the format of your source code. If you specify FORMAT=ANSI (the default), you are conforming as much as possible to the ANSI standard. In this format, columns 1 through 6 can contain an optional sequence number, and column 7 (indicator area) can indicate comments or continuation lines.

Division headers, section headers, paragraph names, FD and 01 statements begin in columns 8 through 11 (area A). Other statements, including EXEC SQL and EXEC ORACLE statements, must be placed in area B (columns 12 through 72). These guidelines for source code format can be overridden by your compiler's rules.

If you specify FORMAT=TERMINAL, COBOL statements can begin in column 1 (the left-most column), or column 1 can be the indicator area. This format is also subject to the rules of your compiler.

You can specify FORMAT=VARIABLE to allow Flexible B Area Length.

Consult your COBOL compiler documentation for your own platform to determine the actual acceptable formats for COBOL statements.

If i use a source with $set SOURCEFORMAT(VARIABLE) set in the source itself (not in the cobol.dir file). The source generated is by pro*cobol is OK. but it failed after.

So...

Thanks.

Unfortunately Oracle Pro-COBOL only supports standard COBOL syntax (Fixed).

Daniel

Unfortunately Oracle Pro-COBOL only supports standard COBOL syntax (Fixed).

Daniel

Hi Daniel,

Thank for your answer by I think you are wrong.

When I use pro*cobol in (fixed, variable or terminal) format in a first step to generate the cobol source

and compil the source generated cobol : all is ok (with fixed cobol, variable cobol or free cobol sourceformat option).

The problem is that i want to use Visual COBOL to edit, compile and debug my sources. In this case, i have to use OpenESQL or COBSQL directives.

For some reason (migration process), Pro*COBOL is necessary for my project.

Thanks.

With Cobsql you can pass directives to Oracle Pro*Cobol pre-compiler. This is done by including the Pro*Cobol directive(s) after the end-cobsql  (or end-c) directive. So for example:

p(Cobsql) verbose end-cobsql comp5=yes endp

Is the way that you pass the comp5=yes directive on the command line to Pro*Cobol. So to get the checker (ie MF compiler), Cobsql and Pro*Cobol to understand variable length source code, use:

p(Cobsql) verbose end-c format=variable endp

The $set sourceformat(variable) only tells the checker and Cobsql that you are using variable length source code.

Note: You may not have done this with the previous version because this might have been set in Cobsql.dir file, your cobol.dir or the Pro*Cobol configuration file (I think it’s pcbcfg.cfg).

Thanks Adrian,

I use this kind of preprocess command

p(cobsql) cobsqltype=oracle8 end-cobsql CONFIG=procob.cfg endp

And my procob.cfg file is

mode=oracle

format=variable

picx=varchar2

ireclen=250

oreclen=250

sqlcheck=full

user=../..

maxliteral=31

I was wondering if COBSQL in last version of Mf Checker was able to manage VARIABLE or FREE.

May be an enhancement in progress?

I just tested this with Visual COBOL for Visual Studio and although it accepts the Pro*COBOL option of format=variable when I try to change the project directives to use sourceformat"variable" I receive the following:

CSQL-F-047: Cobsql cannot be used with the SOURCEFORMAT directive

This tells me that this is not currently supported as you suspected.

I will check with development to see wat the plans are for supporting this.

Thanks.

Hi Chris!

Oh thanks for your check.

Please, keep me informed.

Franck.

Can I ask you to create a support incident with Customer Care and please direct it to my attention?

Development would like me to create an Enhancement Request for this feature so that we can determine the amount of work etc to implement this and I would like it attach this to your support incident so that you may track its progress.

Thanks.

Hi Chris,

I will be back shortly with this problem... The project is now in production and we need new to integrate the project with the Eclipse IDE.

Franck.