Solving ambiguous refernce error for COBOL program in Einspect

[wasi...@cooltoad.com]

I have a Native COBOL program which opens two files, with similar structures, where the field name of the 01 level is the same.

For example

FD FILE1.
01 NAME.
02 TITLE.
02 AGE.

FD FILE2.
01 NAME.
02 TITLE.


In Inspect on G-series, I could display using

"Display file1.name.title" or just "display file1" would display the complete structure

In einspect on J-series though I am getting

No symbol FILE1 in current context on giving "PRINT FILE1"

PRINT "file1.name.title" gives

Reference to NAME is not unique.
Add more qualification to disambiguate the reference.

Any way to correctly find & reference file1.name versus fil2.name in einspect for cobol programs

[Raj Vanjara]

I think eInpspect doesn't allow file-name to be part of qualified name of variable.
I searched a bit but didn't find anything which would solve this problem, but I still think that there has to be some way of doing it because this same code works and gives desired results with Non-native object and Inspect.

[Keith Dick]

The fact that it works with the COBOL85 compiler and Inspect mostly shows that the COBOL85 compiler does a better job of describing the data structures than the ECOBOL compiler does. It doesn't say much about whether the ECOBOL compiler's implementers or EINSPECT implementers intended to do a better job and there just is a bug, or they just didn't care to be able to qualify a data name with the FD name. If wasighara (the original poster) wants to get to the bottom of this problem, the only thing I can think to suggest is to open a case with the HP support people.

[wasighara73]

I should have updated. Using "info locals" I could see all variables' data and was able to get through my purpose of seeing its content. Interesting, that its a bug, was thinking maybe I was doing something wrong.

About opening a ticket. Will do that if someone confirms its a bug.

[Keith Dick]

wasighara73 wrote:
> I should have updated. Using "info locals" I could see all variables' data and was able to get through my purpose of seeing its content. Interesting, that its a bug, was thinking maybe I was doing something wrong.
>
> About opening a ticket. Will do that if someone confirms its a bug.
>

I don't believe any of us who aren't HP employees in the NonStop Software Development group can give a definitive answer about whether it is a bug or not. It is a bug if HP intended to be able to qualify by the FD name. If HP decided that qualifying by the FD name wasn't worth the effort to implement, it is operating as intended. I could not find anything in the Native Inspect manual that says anything about qualifying by the FD name (though I might have missed it). If I had the ability to open a ticket about this, I would do so. I'd take the position that it is a bug that I cannot use the FD name to qualify the reference to fields of a record so as to be able to name such fields in native Inspect commands when two FDs have identical record declarations. If HP did not intend to allow qualification by FD name they will say so. If they agree that qualification by FD name should be possible, they will admit it is a bug or a design oversight. If there is a way to qualify
references to fields in FDs that we are overlooking, they will explain how to do it.