Skip to main content

[Migrated content. Thread originally posted on 14 December 2011]

Hello,

I am moving the demo I have been writting with Visual COBOL for .NET to another computer, and just executing the release version. Everything goes fine, except one of the modules. The error in the subject appears every time we execute it.

The project is managed, and uses a native COBOL program to access the file.

Another project that uses the same last module (the native one), but it is written in C#, using a managed COBOL bridge, never crashes.

And also there is another project similar to the first that works with that file too, and also works fine (notice that the program that reads the COBOL file is always the same).

The curious thing is that, after executing the second or the third project, the first one never comes to fail again.

Any ideas, by chance?

[Migrated content. Thread originally posted on 14 December 2011]

Hello,

I am moving the demo I have been writting with Visual COBOL for .NET to another computer, and just executing the release version. Everything goes fine, except one of the modules. The error in the subject appears every time we execute it.

The project is managed, and uses a native COBOL program to access the file.

Another project that uses the same last module (the native one), but it is written in C#, using a managed COBOL bridge, never crashes.

And also there is another project similar to the first that works with that file too, and also works fine (notice that the program that reads the COBOL file is always the same).

The curious thing is that, after executing the second or the third project, the first one never comes to fail again.

Any ideas, by chance?

The 9/161 file status means that the physical file being opened has different attributes than how it is defined in the program. This can mean different record size, number of keys, key definition etc.

I am not sure why the error would occur and then go away though unless the program logic is causing the file to be created with an open output after the 9/161 is occurring in which case the file attributes would then match what was in the program.

Project directives can also affect this error.
Are you using the same set of directives when compiling all of your modules?

Do you have the same version of Visual COBOL on the new computer or are you running COBOLRuntime 2010 on that system?

[Migrated content. Thread originally posted on 14 December 2011]

Hello,

I am moving the demo I have been writting with Visual COBOL for .NET to another computer, and just executing the release version. Everything goes fine, except one of the modules. The error in the subject appears every time we execute it.

The project is managed, and uses a native COBOL program to access the file.

Another project that uses the same last module (the native one), but it is written in C#, using a managed COBOL bridge, never crashes.

And also there is another project similar to the first that works with that file too, and also works fine (notice that the program that reads the COBOL file is always the same).

The curious thing is that, after executing the second or the third project, the first one never comes to fail again.

Any ideas, by chance?

Chris Glazier originally wrote:
The 9/161 file status means that the physical file being opened has different attributes than how it is defined in the program. This can mean different record size, number of keys, key definition etc.

I am not sure why the error would occur and then go away though unless the program logic is causing the file to be created with an open output after the 9/161 is occurring in which case the file attributes would then match what was in the program.

I nixed these causes because I use the file in I-O mode and never have modified any record. Also, the directives were the same in all cases, due I was always using the same native module to access the file.

But I noticed that I didn't use the "local copy" parameter in the references section. After fixing that, all started working properly.

I am not really sure what was happening, though.

Thanks for your reply anyway.
Terms & ConditionsAccessibility statement