VC for VS 2017 patch 10 on Windows 10, managed COBOL.

When the I-O-CONTROL paragraph contains two (2) SAME RECORD AREA clauses:

        SAME RECORD AREA FOR FILE1-1, FILE1-2, FILE1-3.
        SAME RECORD AREA FOR FILE2-1, FILE2-2, FILE2-3.

and

        OPEN INPUT FILE1-1, FILE2-1 OUTPUT FILE1-2, FILE1-3, FILE2-2, FILE2-3.

and

        READ FILE1-1 NEXT RECORD.
        READ FILE2-1 NEXT RECORD.

then the FD record areas for FILE1-2 and FILE1-3 have the same data as FILE1-1 and the FD record areas for FILE2-2 and FILE2-3 have the same data as FILE2-1.  This is the expected behavior.

HOWEVER,

When the I-O-CONTROL paragraph contains THREE (3)  SAME RECORD AREA clauses:

        SAME RECORD AREA FOR FILE1-1, FILE1-2, FILE1-3.
        SAME RECORD AREA FOR FILE2-1, FILE2-2, FILE2-3.
        SAME RECORD AREA FOR FILE3-1, FILE3-2, FILE3-3.

and

        OPEN INPUT FILE1-1, FILE2-1, FILE3-1
                OUTPUT FILE1-2, FILE1-3, FILE2-2, FILE2-3, FILE3-2, FILE3-3.

and

        READ FILE1-1 NEXT RECORD.
        READ FILE2-1 NEXT RECORD.
        READ FILE3-1 NEXT RECORD.

then the FD record areas for ALL FILEx-2 and FILEx-3 files have ALL SPACES.  The "re-mapping" of the logical record areas doesn't appear to have happened as it does when there are only one or two SAME RECORD AREA clauses.  This is the UN-expected behavior.

Has anyone run across this before?

I just tested your example and I do not see the behavior that you describe. It works perfectly for me in either managed or native code.

I tested with the latest product release which is Visual COBOL 5.0 Patch Update 2. I believe that you may be using an old product release. Can you confirm exactly which product release you are using?

As stated at the top Visual COBOL for Visual Studio 2017, patch update 10, on Windows 10.

We've been in a large project since late Spring and haven't had nor will have time to upgrade to 5.0.

Monday I will chop the offending program down to the essentials to see if I can replicate the issue in a manageable (read up-loadable) demo program.

'til then, thanks.

Visual COBOL for Visual Studio 2017, patch update 10, on Windows 10 does not tell me the major product version.

For Visual COBOL for Visual Studio 2017 V3.0 the latest patch update is 13 and
for Visual COBOL for Visual Studio 2017 V4.0 the latest patch update is 21

You can find the major product version in the Visual Studio Help--About Microsoft Visual Studio Dialog or in Control Panel-->Programs and Features.

If you let me known the major version number then I can test with that version to see if it is fixed in one of the available patch updates already.

I already have a cutdown program that should demonstrate it.

Sorry, Chris.  Late Friday burn-out.  The major product version is Visual COBOL for Visual Studio 2017 V4.0 and the latest patch update we've applied is 10.

I've cut the offending program down to bare minimum.  The original was built as a managed code COBOL class.  The cut-down demo is built as a managed COBOL console application and it still exhibits the same behavior (while debugging in the IDE).

I've attached it to this reply (at least I think that worked, .txt added as extension to accommodate upload rules).  The three input files each contained one record of 10 characters each.  The values were all "1"s, "2"s and "3"s to make them identifiable.  I put a breakpoint at the CLOSE statement, ran it in debug mode and either hovered over the different record areas or viewed the console window to view the results.

I varied the test runs by commenting out one or two SAME clauses in different combinations.  Any one SAME clause at a time works.  Any two clauses at the same time and the first output file record area of the first SAME clause has data but not the second, and both output file record areas of the second SAME clause are good.  All three clauses at the same time and NONE of the output file record areas have data.

Any idea what I am doing wrong?

Your full example program failed for me so I compared your full program with my program that I created from your first snippet (that works) and I found the problem.

The problem is that if your FD's are not in the same order as the files appear in the SAME RECORD AREA clause then it will fail. They don't have to be in the exact order but all the files described in the first SAME RECORD AREA clause have to appear before the files described in the second SAME RECORD AREA clause and so on. If I change your program to what I have below it works fine.

Please create a support incident for this and reference my name in the description and I will create a bug report for it and send it to development. BTW, the problem does exist in the latest release 5.0 PU2 but only for managed code. In native code it works correctly.

Thanks

Thank you!

Incident # 3210757 has been created.

I wasn't sure whether you meant Subject or Step-By-Step when you requested I put your name in "the description", so I put it in both.

Should I bother attaching my demo program to the incident or do you have that covered?