On Fri, 2009-05-08 at 09:41 -0300, Arí Ricardo Ody wrote: > It's out matter but, I'm working with legacy > modernization. The company I work deals with > legacy modernization. Mainly in mainframes
So, are you trying to convert COBOL code to some more modern language? If not, I still don't understand what you are trying to do. Moreover, very few modern languages implement COBOL semantics, especially as regards decimal arithmetic. You will likely need to generate assembler code for your target platform, and that is even more of a "legacy" approach to software than coding in COBOL. [Note: double precision floating point does *not* implement decimal semantics, in spite of it seeming an easy substitute.] The "modern" language that is most likely to provide you with decimal capability is Java; it also runs even slower than COBOL. Assuming you are trying to automate conversion of COBOL source to some newer language, then you will largely need to write a parser for the COBOL grammar. This is far from trivial. You will then need to write an emitter for your chosen "modern" language, so that you rebuild the COBOL semantics as exactly as possible. >From your original message, you seem to be still working on the parser. I would suggest you use a more compiler theoretical approach than just generating a string list. If you encode the parsed COBOL source into some internal meta-language, this will make your emitter much easier to write. Better yet, if your encoding includes some semantic analysis of the COBOL source, you can optimize the generated code so that it both runs better and is easier maintained in your "modern" language. Just my 2¢ worth. -- Regards, Dave [RLU #314465] ======================================================================= david.w.n...@ntlworld.com (David W Noon) ======================================================================= _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal