Highlighted
Absent Member.
Absent Member.
2896 views

COBOL file access across form calls

Jump to solution

In VisCOBOL using multiple form programs (.cbl) in a single solution...

...can you tell me please if I open file A in the main form (Form A)...make a call out to another form ( FORM B) in same solution)..is the file I opened in the main form still opened as I opened it to begin with (e.g as I-O or extend etc) or do I have to close it in the main form and re-open it in FORM B in order to continue to work with it?

 

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: COBOL file access across form calls

Jump to solution

Development has fixed the problem with defining external files within a class program and the fix will be available in an upcoming release.

As a workaround, you would have to define the external file in a COBOL program instead of a class and then call the program from within a method of your form class. (or don't use external files and make sure that the file is closed before accessed in a second)

I did find one additional problem with this is that while debugging through the programs that use the external file it is currently not possible to view the contents of the data record of the external file by using Watch variable or by hovering with the mouse. The processing is correct but an attempt to view the record results in a "Unable to evaluate expression" error.

Thanks.

View solution in original post

0 Likes
6 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: COBOL file access across form calls

Jump to solution

Files are treated as local to the program in which they are defined unless they are defined with the EXTERNAL clause in which case they are shared by all programs in the run unit that also have them defined as being EXTERNAL.

Example:

if form1 has the following definition:

fd test-file external.

01 test-record.

    05 key1   pic x(3).

    05 rest   pic x(10).        

and does open input, read next and accesses key1

and then invokes form2 which has the same definition and form2 does read next it will get key 2.

This is because when you use EXTERNAL each program will reference the same file connector.

If you do not specify EXTERNAL then each program will access a different file connector and you will most likely run into problems unless you ensure that the file is closed in the first program before you open in a second program.

That being said, in an OO application that is using Windows Forms it would probably be better to actually create a class for your file handling that provides for static methods to open, read, write, etc to the file that could then be accessed from any program in your application. This would ensure consistant access from all locations and would ensure that your file was only being opened once.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: COBOL file access across form calls

Jump to solution

I've attemped to use your solution within one of our solutions as follows...

File is now defined as...

          SELECT PAYFIL ASSIGN TO DISK, "PAYFILE"

             ORGANIZATION IS INDEXED    

             ACCESS MODE IS DYNAMIC      

             LOCK MODE IS MANUAL WITH LOCK ON MULTIPLE RECORDS

             RECORD KEY IS PY-KEY

            FILE STATUS IS PAY-REPLY.

FD read as...

      FD PAYFIL IS EXTERNAL.    

      01 PY-REC.

         03 PY-KEY.

            05 PY-EMP-NO                PIC 9(16).

           etc....

My solution comprises of TWO .cbl programs. Both carry the FD & SL copybooks (as seen above).

I get the following error on compilation...

COBCH1268 - A static file cannot reference instance items

and the cursor shows the error on the FILE STATUS IS PAY-REPLY line.

What am I missing?

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: COBOL file access across form calls

Jump to solution

Further analysis...

OK...found out to code the PAY-REPLY as EXTERNAL as well so now reads as..

01 PAY-REPLY  PIC XX EXTERNAL.

in both programs...

Tried recompiling...

Got the error...

COBCH0857 - System error - failure during ILASM phase.

Really baffled now!

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: COBOL file access across form calls

Jump to solution

There does seem to be a problem with defining these external files within a forms application, in that the compiler reports the error that you are seeing against the main class.

I have reported this to development and I am awaiting a reply.

Sorry.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: COBOL file access across form calls

Jump to solution

Thanks Chris.

Just to let you know that I updated my VisualCOBOL version to 2.1 on Friday.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: COBOL file access across form calls

Jump to solution

Development has fixed the problem with defining external files within a class program and the fix will be available in an upcoming release.

As a workaround, you would have to define the external file in a COBOL program instead of a class and then call the program from within a method of your form class. (or don't use external files and make sure that the file is closed before accessed in a second)

I did find one additional problem with this is that while debugging through the programs that use the external file it is currently not possible to view the contents of the data record of the external file by using Watch variable or by hovering with the mouse. The processing is correct but an attempt to view the record results in a "Unable to evaluate expression" error.

Thanks.

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.