COBOL file access across form calls

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?

 

  • 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.

  • 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?

  • 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!

  • 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.

  • Thanks Chris.

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

  • Verified Answer

    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.