#53 Issues with PIC type definition

[Inaki GE]

Hi,
I'm finding different issues regarding the PIC type definition in variables. In some cases Koopa does not parse them properly and displays "Not all input was consumed". Here you have some real examples:
:L:-IMP-REMESA PIC Z.ZZZ.ZZ9,99.
:L:-IMP-SALDO-FACTU PIC zzz.zzz.zz9,99
:L:-NUMERO PIC ---.---.--9.
:L:-VAL-POT-AUTORIZADA-BIE PIC 99999999.999.
:L:-D-BASE-DCHOS-RES PIC ZZZZZ9.99999.
:L:-IRE PIC Z99.99

Here you have a link with information about the definition of PIC data type:
http://www.pgrocer.net/Cis12/cobol3.html

If you need further details, don't hesitate to contact me.
Thanks.

[KrisDS]

I checked, and the problem is not with the picture clauses. The problem is that the ":L:" is not part of a legal cobol word.

There is a similar discussion on this in the forums ("look for copystatement replacing part of 88-datatype name"). I'm hesitant to allow colons in cobol words (which would be a quick way to resolve this) as I'm pretty sure it will break other stuff...

[Inaki GE]

Hi,
I have checked it again and I am pretty sure that the problem is because of PIC type and not ":L:" (however I will create a ticket to propose a improvement related to it).

I attach an example ("PIC issue type.doc") where you can verify it. I have used a trial and error method and the issue gets solved by redefining the PIC type.

I am looking forward to your answer.
Thanks.

[KrisDS]

In your attachment, could you take a screenshot of line 64 in step 3 ? Your current screenshot is showing a different location. Based on your description I still think that the trigger of the issue is the ":L:". But the screenshot does not show such a field...

[Inaki GE]

Hi,
I attach the doc file updated. I also attach the .cbl program and copy files so that you could check it.
In my opinion the cause of the issue is the PIC definition in the SDH002H0 copy, but let me know.
If you need further information, do not hesitate to contact me.
Thanks for your support.
Regards.

[KrisDS]

No, it is definitely due to the ":L:". If I replace all of those in the copy file with something like "LLL" then the copy file gets parsed correctly, including all PIC definitions.

What happens when Koopa sees a ":L:" is that it will fall back to skipping everything after the level number up to the nearest dot. In case of a:

PIC Z.ZZZ.ZZ9,99

that nearest dot lies inside the picture string. Which means the next thing it sees is ZZZ, which is something it can't make sense of as the start of something else.

By replacing the picture string with "X(1)" you basically allowed Koopa to continue after skipping the problematic part.

So, again, this is related to the definition of legal cobol words in combination with copy books. If you're doing preprocessing the real solution is to extend Koopa with logic which lets it apply the REPLACING clauses on the copy statement. That will take some work.

[Inaki GE]

Hi,
Now I see what you mean. Precisely, before your answer, I had opened a ticket about the possibility of extending the grammar for the COPY-REPLACING statement. See https://sourceforge.net/p/koopa/issues/54/

Including this option would make the preprocessing option quite powerful and, as we have stated, even some issues would get solved. Let me know about the availability and complexity.

Do not hesitate to contact me if you need I test something or provide further information.
Thank you very much.
Best regards.

[KrisDS]

I'll close this issue in favour your newer one.