Bugs for free format sources and others
SQL precompiler for COBOL
Status: Beta
Brought to you by:
piper1
Menu
▾
▴
1 Attachments
#2 Bugs for free format sources and others
When processing a source file that is in free format the following problems appear:
-
Running dbpre with dbpre -f stockMT -I../copybooks
does not process free format source correctly as it chops off the first 6/7 chars.
duplicates source lines 3 times. -
Running dbpre without -f with free sources :
Ignores inbedded "*>" in the sources (see stockMT.lst)
Ignores exec sql copy statements - see code with : -
---
EXEC SQLINCLUDE MySQL-SQLCA.cpy
END-EXEC.
In the lst file produces a blank line after every source line (se stockMT.lst).
3. Marks as an error EXEC SQL COMMIT WORK END-SQL.
This is valid but even with the WORK preceeded with *> still produces an error.
4. PREPARE is not accepted - valid sql coding.
Testing stopped as errors are too great to continue.
Bug confirmed.
To be honest, the free format mode is not very well tested, i am still using the old, fixed columns, style.
I'm going to have a look at it with your attached example, but that might take some time, because I will be more or less offline for the next 3 weeks.
PREPARE:
Correct, dbpre does not support the full SQL standard right now, but might in the future. It all depends on how many reactions i get, how many ppl are using it.
If no one is using it, no further development is obviously needed.
Have these reported issues now been fixed for release dated October 2021 ?
I'm looking at it right now.
EXEC SQL INCLUDE has a copybook with the suffix .cpy, dbpre doenst expect that and works only with copybooks without any suffix. I'll try to make that more flexible, so both formats can be used.
EXEC SQL BEGIN DECLARE SECTION - dbpre doesnt need that, i'll try to make dbpre to ignore that.
PREPARE/EXECUTE - dbpe doenst support that right now and i fear, i have no environment to test that properly.....
Your syntax like DELETE from [STOCK-REC] WHERE [Stock-Key] = :HV-DynamicParm
I have never seen a precompiler which needs table and field names enclosed in brackets...
Well... doesnt look that easy to process your source code with dbpre.....
Last edit: The_Piper 2022-10-08
The brackets and preceding colon is from Micro Soft SQL server, and ditto the rest of rdb syntax used. Going by my 75 year old memory was trying to see what dbpre did with it :)
That way, I would hopefully know what needed changes.
Big grief is that on the .lst and .cob dbpre, is double spacing each source line and that is odd as in Windows each line is ended by a CR,LF combo but for *nix it is only one of them LF, so what is dbpre doing that seems to be the reverse process?
I will now go through the stockMT source and remove all references with [ ] and the preceding colon and see what happens next :)
One less reported error so not a lot :) but I noticed your examples uses colon preceding vars in some cases.
It would help if the dbpre manual had a full list of supported SQL commands and syntax as currently shoving a source file through is the only way to find out :(
It would also help if there are warnings and/or errors reported to the .lst file that at the end i.e., dbpre relisted together the the source line number and warning/error i.e.,
403 SYNTAX ERROR: unknown command >BEGIN<
818 SYNTAX ERROR: unknown command >LINKAGE< for :
linkage section.
This one dbpre must have lost track of where it is in the source file but cannot see where from .
It is a right pain trying to find the problems going through the listing.
Ah, okay, i have never used Micro Soft SQL server, that explains it ;)
Confirmed, thats a bug, going to fix that.
Edit: the problem was cr lf at end of line, each cr and lf produce one line of output, first line with the source code, 2nd line is empty.... Fixed
In all cases (i jhope), thats to tell dbpre that this is a host variable.
Agreed, gioing to brush up the manual a little bit.
Agreed, i am going to collect the first 100 error messages or so and list them at the end of the .lst file
Fixed, iirc it was a problem with EXEC SQL...END-EXEC and that happened before the LINKAGE SECTION.
Last edit: The_Piper 2022-10-09
You might want to look into the exec SQL syntax you are not processing for such as PREPARE etc to see what dbpre needs to do as mysql/mariab supports these.
I am attaching the copy of stockMT.scb (and if I can find the generated stockMT.cbl) as used with the JC pre-processor (which you can find in the GC contrib area for the documentation on it) the code for which is a LOT shorter than the one I am using to pre-test dbpre.
Some of the /SQL syntax is to load into prog the layout of a RDB table as a 01 group level.
See both source for what is generated - might be useful.
Sorry, got sidetracked again, but this is still on my to-do list.
Going to work on it hopefully soon.
OK, will look forward to it.
I did consider changing the JC precompiler to accept SQL code i.e., EXEC SQL etc but got side tracked as I also wanted to allow for other rdbms systems at some point.
This way it would act as a one stop shop for many, even if it isn't me doing the coding.
I was allowing for a $SET SQL xxxxx as the first few lines or so to specify what the RDB is to be used.
Yes it is in Cobol, but I am more current with that than C although I can make sense of code to a point but I can get lost sometimes as it has been many years since I did use it often-ish.
I was never fond of it as it is too close to Macro Assembler in thought processing (I mean mine when coding) and I have not done that since the 60's and that was on IBM 1401 systems and a bit later on ICL 1900's and never heavily - i.e., major programs.
Vince