CVTRPGFREE Activity
Convert fixed-format RPG code to free-form RPGILE code
Brought to you by:
ewarwoowar
Activity for CVTRPGFREE
-
Ewarwoowar modified ticket #79
Use of /FREE with Specification Type Causes Warning Message
-
Potential Invalid Offset in `%subst`
-
Cannot Compile INSTALL without First Creating BUILD Command
-
CVTRPGFREE released /README.TXT
-
-
Hi Anoop! Thanks for your kind words - they're greatly appreciated. I can be found on LinkedIn: www.linkedin.com/in/paul-de-valmency If you could leave a review here on SourceForge, that would also be most welcome.
-
Anoop Menon posted a comment on ticket #74
Thank you! Are you on any other social networks so that I can give you credit for this excellent project? I have already been recommending it on LinkedIn.
-
Cannot Compile INSTALL without First Creating BUILD Command
-
I hadn't considered that others might also be using Scott's utility as everuone I've spoken to about it wasn't aware of it. Also, it should invoke the version in the specified library. However, you are correct, and I'll amend it for the next proper release.
-
-
Brian posted a comment on ticket #83
BTW: You may also want to think about renaming the BUILD command (and BUILDR4 program) to something else or only create those objects if they do not exist in the library list. The issue that a user may have a different version of BUILD installed. Personally, I have branched Scott Klement's BUILD command and renamed it BLDOBJ. For your needs, you may want to just create it as CVTRPGBLD/CVTRPGBLDR4 or something along those lines to keep the object names closer to CVTRPGFREE.
-
DOH! Reworked version coming right up!
-
MCH1210 Thrown When Constant Has Continuation Character Immediately After Opening Quote
-
Yeah, I have to revisit the whole constant handling code as there are multiple issues with it. I've been putting it off, but I'll get onto it as soon as I can.
-
Cannot Compile INSTALL without First Creating BUILD Command
-
Potential Invalid Offset in `%subst`
-
Fixed in 1.5.14
-
Thanks again Brian. Doesn't need the 'Else' though.
-
That's odd, I didn't get any message in my testing. I just realised that I have conversion messages turned off by default !!!
-
Use of /FREE with Specification Type Causes Warning Message
-
Fixed in 1.5.14
-
MCH1210 Thrown When Constant Has Continuation Character Immediately After Opening Quote
-
Potential Invalid Offset in `%subst`
-
The solution to this one is a one-liner: From: If workCondCtrl <> 'AN' and workCondCtrl <> 'OR' and workCondCtrl <> 'SR' and workCondCtrl <> '/E' and workCondCtrl <> '+ '; To: If workCondCtrl <> 'AN' and workCondCtrl <> 'OR' and workCondCtrl <> 'SR' and workCondCtrl <> '/E' and workCondCtrl <> '/F' // <--- Handles ?/FREE directive and workCondCtrl <> '+ ';
-
-
-
Thanks Brian - that had escaped me! I've removed the amendments for this ticket and reposted the source until I can find the time to go through the code and bring it into line and test it thoroughly.
-
Keywords Followed by Spaces Before the Parameter Parenthesis Are Not Converted Correctly
-
-
-
Also, keep in mind that a definiton may span multiple lines. The following: d tkt48... d fld... d 1 s 1a d tkt48Ext... d Proc... d One pr extproc('QsnRtvMod') d modeInd 1a options(*OMIT: *NOPASS) Should return: dcl-s tkt48fld1 Char(1); dcl-pr tkt48ExtProcOne extproc('QsnRtvMod'); modeInd Char(1) options(*OMIT: *NOPASS); end-pr;
-
The the last parameter of the procedure findKeywordStart is used to return the "length" of the keyword (from the start of the keyword (x) up-to and including the opening paren, "("). For example, "const(" would have a length of 6; however, "const (" would have a length of 10. Knowing the length is critical to most of the code that follows calls to findKeywordStart. Currently, the code that follows these calls are still hard-coded to the keyword length assuming no blanks before the paren. For example:...
-
...posted to wrong issue...
-
The the last parameter of the procedure findKeywordStart is used to return the "length" of the keyword (from the start of the keyword (x) up-to and including the opening paren, "("). For example, "const(" would have a length of 6; however, "const (" would have a length of 10. Knowing the length is critical to most of the code that follows calls to findKeywordStart. Currently, the code that follows these calls are still hard-coded to the keyword length assuming no blanks before the paren. For example:...
-
The the last parameter of the procedure findKeywordStart is used to return the "length" of the keyword (from the start of the keyword (x) up-to and including the opening paren, "("). For example, "const(" would have a length of 6; however, "const (" would have a length of 10. Knowing the length is critical to most of the code that follows calls to the findKeywordStart. Currently, the code that follows these calls are still hard-coded to the keyword length assuming no blanks before the paren. For...
-
The the last parameter of the procedure findKeywordStart is the "length" of the keyword. For example, "const(" would have a length of 6; however, "const (" would have a length of 10. Knowing the length is critical to most of the code that follows calls to the findKeywordStart. Currently, the code that follows these calls are still hard-coded to the keyword length assuming no blanks before the paren. For example: x = findKeywordStart('CONST':%upper(DCLS.definition):l); If x > 0; DCLS.definition =...
-
The the last parameter of the procedure findKeywordStart is the "length" of the keyword. For example, "const(" would have a length of 6; however, "const (" would have a length of 10. Knowing the length is critical to most of the code that follows calls to the findKeywordStart. Currently, the code that follows these calls are still hard-coded to the keyword length assuming no blanks before the paren. For example: x = findKeywordStart('CONST':%upper(DCLS.definition):l); If x > 0; DCLS.definition =...
-
SCAN opcode not converting properly
-
Use of /FREE with Specification Type Causes Warning Message
-
Conversion stops with 'The call to CONVERTI_S ended in error'
-
Procedure definition not fully/correctly converted
-
Large key lists breaking width limit on conversion
-
Condition Eval statement spanning more than one line
-
Field definitions in C Specs are not converted
-
Missing Help Text for MBROPT Parameter
-
Keywords Followed by Spaces Before the Parameter Parenthesis Are Not Converted Correctly
-
-
-
-
Fixed in 1.5.12
-
SCAN opcode not converting properly
-
Absolutely. It would be a privilege to contribute more than just "complaints" via the ticket system.
-
Actually, I think I misunderstood the issue that was being reported, and I fixed the issue I thought was being reported! I've now gone back and checked again, and can see that I still haven't fixed what you were after, so I'll very gratefully adopt your fix if I may.
-
No apologies needed. THANK YOU for making the time to keep your project going. I fixed 7 of the easiest tickets that I commonly encountered because of my coding style. I was hoping you would find the time to look at the tough ones. Again, thank you.
-
No apologies needed. THANK YOU for making the time to keep your project going. I fixed 7 of the easiest tickets so that also happened to affected by my coding style. I was hoping you would find the time to look at the tough ones. Again, thank you.
-
Keywords Followed by Spaces Before the Parameter Parenthesis Are Not Converted Correctly
-
Sorry Brian, this appears to be fixed in 1.5.12, but I didn't make a note of when I did it, so assumed it was in an earlier version. I'll re-opne the ticket so I don't forget.
-
This was still a problem in 1.5.11. I fixed this by creating a procedure that would return the ending position of the keyword ... which is really the paren. - - - ------------------------------------ 5813 data records excluded ------------------------------------ 581000 BegSr subStandAlone; - - - ------------------------------------- 145 data records excluded ------------------------------------ 595600 x = FindKeyword('DTAARA':%upper(declKeywords): l); - - - --------------------------------------...
-
Keywords Followed by Spaces Before the Parameter Parenthesis Are Not Converted Correctly
-
Fixed in 1.5.10
-
Use of /FREE with Specification Type Causes Warning Message
-
Fixed in 1.5.12
-
Conversion stops with 'The call to CONVERTI_S ended in error'
-
Fixed in 1.5.12
-
Procedure definition not fully/correctly converted
-
Fixed in 1.5.12
-
Fixed in 1.5.12
-
Fixed in 1.5.12
-
Fixed in 1.5.12
-
Fixed in 1.5.12,
-
Use of /FREE with Specification Type Causes Warning Message
-
John R. Smith, Jr. posted a comment on ticket #78
I am getting the same error. Mine is related to a single byte comment in column 80. I changed it to be two bytes (column 80 and 81) and it ran correctly.
-
Kevin Passey posted a comment on ticket #78
Daniel everyone can see your source code in AP0213.txt
-
Daniel Pirani created ticket #78
Conversion stops with 'The call to CONVERTI_S ended in error'
-
Rodius Danny posted a comment on ticket #77
Sorry but the comment lines where not correctly copied. They are missing the asterisk before the -- lines.
-
Procedure definition not fully/correctly converted
-
Condition Eval statement spanning more than one line
-
Large key lists breaking width limit on conversion
-
'@' character in CVTRPGFRER source
-
Thanks Brian - yes I forgot - I'll close it now.
-
I believe this ticket was fixed in v1.5.05. Did you forget to close this ticket?
-
Large key lists breaking width limit on conversion
-
Condition Eval statement spanning more than one line
-
Condition Eval statement spanning more than one line
-
Field definitions in C Specs are not converted
-
Missing Help Text for MBROPT Parameter
-
Not converted message needed for I (input) and O (output) specs
-
Not converted message needed for I (input) and O (output) specs
-
Handling of OVERLASY vs POS in DS with DIM
-
Lines Not Converted Should Not Be Changed
-
Inclusion of C-Spec in /FREE Causes Conversion Warning/Error
-
Add MBROPT(*ADD|*REPLACE) to CVTRPGFREE Command
-
Add EXPR(*YES) to All Parameters on the CVTRPGFREE Command
-
Adding the following line of code in moveDefinitions subroutine fixes the issue - or %subst(directive:1:2) = 'SR' The final output will look like below - If %xlate(LO:UP:lineType) = 'C' and ( %subst(directive:1:1) = ' ' or %subst(directive:1:2) = 'SR'); //SR to indicate sub-routine
-
To be specific, the definitions are created in most cases except when the characters, S and R appear in the 7th and 8th positions. https://www.ibm.com/docs/en/i/7.4?topic=level-subroutine-identifier#csi
-
Field definitions in C Specs are not converted
-
Missing Help Text for MBROPT Parameter
-
-
-
1 >
