File Status 9/161 when opening a file with CALL 'EXTFH'

[Migrated content. Thread originally posted on 04 February 2011]

In order to bind ISAM data to ADO controls, we have set up a trial project in Visual Cobol R3 that uses the Microfocus File Handler (we also use this in our NetExpress 4.0 projects).
Opening a file with call 'EXTFH' returns a file status 9/161 (something wrong with the file header?).
When running the same code in NetExpress, this returns a file status zero (which is ok).
Does someone know what might be the solution to this problem?
  • Have a look for a file named xfhlog which might tell us a bit more about why EXTFH doesn’t want to open the file. I would suspect the key information is incorrect but there are other reasons for this error.

    Assuming you’re calling EXTFH directly - are you using an OP CODE 6 call beforehand to get the FCD pre-populated with the file information?
  • You might want to check you are using the right FCD format.. I can't remember for sure but I think Net Express 4.0 was using FCD2 format for 32bit programs but for 64bit it used FCD3... ie: try adding the NOFCD3 directive.

    Some references anyway for you:
  • We have tried to open a file using the EXTFH, but it doesn't work.
    We have tried to open the same file NOT using the EXTFH and that appears to be succesfull.
    Can someone please review my small project and find out why de EXTFH keeps returning a file status 9/161?
    (I will send you the entire project including the file to be opened).

    Thank you in advance for any help that you can provide.
  • I'm pretty sure that the problem is with the version of the FCD copybook that you are using in your Visual COBOL program.

    In Net Express 4.0 it did use the FCD2 version and in Visual COBOL the FCD3 version needs to be used.

    As long as you are using "copy xfhfcd.cpy" in your program and not "copy xfhfcd2.cpy" then recompiling should bring in the correct copybooks. If you are accessing the FCD by offset rather than field name then you will have issues as the offsets have changed.

    I will take a look at your project if you zip it up and e-mail it to me at

    Please only send what is absolutely necessary to recreate the actual problem.


  • I had an incident today with a different customer who was also getting the status 9/161 when trying to open a file by calling EXTFH directly.

    What I found in this case was that they needed to add an additional line of code to the initialization of the FCD areas.

    move fcd--version-number to fcd-version

    In FCD2 copybook fcd--version-number = 0
    In FCD3 copybook fcd--version-number = 1

    If this line is missing in Net Express 4.0 then it didn't matter as long as the FCD area was initialized to low-values because fcd--version-number in the FCD2 copybook is = 0.

    If this line is missing in Visual COBOL or when using the P64 directive in Net Express then the file handler believes that it is using an FCD2 layout instead of FCD3, hence the 9/161 error.

    Perhaps this is your issue also?
  • We have tried this, but it doesn’t make a difference.
    We use the NOFCD3 directive because of the fact that we develop on a 32-bits platform.
    NOFCD3 will use the FCD2 in my opinion.

  • You mention in your earlier post that you are trying to bind file data to ADO.
    Does this mean that you are compiling your file handler code as managed instead of native?

    If this is true then you cannot use the NOFCD3 directive as FCD3 is required for managed code regardless of whether you are compiling for x86 or x64.

    This is from the Visual COBOL documentation:

    COBOL Development System FCD Used

    Mainframe Express FCD2
    32-bit Visual COBOL FCD2
    64-bit Visual COBOL FCD3
    .NET Support within Visual COBOL FCD3
    32-bit Server Express FCD2 or FCD3
    64-bit Server Express FCD3

  • Verified Answer

    Hi Rob,

    I have reviewed the material that you sent to me.

    The problem is that you are defining this in managed code and for managed code the XFHFCD3.cpy file MUST be used.
    The NOFCD3 directive has no bearing upon this.

    In your application you are not copying in the Micro Focus copybook XFHFCD.CPY which will automatically bring in the correct copybook to use, either XFHFCD2.CPY or XFHFCD3.CPY.
    Instead you are bringing in your own copybook named ws-fhndl.cpy which looks to be a hardcoded version of XFHFCD2.CPY but with some of the field names replaced by FILLER.

    In particular the fcd—version-number field does not exist in your copybook.

    What should be defined as:
    05 FCD-LENGTH pic xx comp-x.
    05 FCD-VERSION pic x comp-x.
    78 fcd--version-number value 0.

    Is replaced by:
    *> Reserved. Must be set to binary zeros
    05 filler pic x(03).

    You need to replace your copybook definition of the FCD area with our copybook and modify your program accordingly.
    You will need to add the following statement to your initialization:

    Move fcd—version-number to FCD-VERSION

    So the file handler knows which FCD is being passed to it.

  • I have deleted the NOFCD3 directive and use the xfhfcd.cpy instead of our own copymember and IT WORKS!
    Thanks a lot for your support Chris!