|
Hans, If myself and others hadn't protested the original plan for right justifying text in a field and strongly suggest using EVALR instead of the original plan, we would have ended up with something like this: | > parms.transNo = %editc((%dec(transNo:%size(transNo):0) + 1):'X'); RPG programmers do not want to write parsers, compilers, editors, regexp search tools, etc. They want to move field A to field B as easily as possible. If that means it needs to be converted between character and numeric, then that's the way it is. For example, I'm currently contracting at a shop where their item number is stored in at least 6 different field formats, sometimes it is character, occasionally it is numeric; often with different field lengths. This is due to the vastness of the application and the different staff members working on it over the last 20 years. That fact that I may have to code something like the above over and over again, is just not practical and does nothing to get the old programmers into the new RPG IV stuff. If they could just do this: Eval A = B EvalR A = B Or EVAL A = %Char(numfield:*NOZEROSUPRESSION) They would say, okay I can do that. (Obviously, I'm joking about the *NOSEROSUPRESSION option.) -Bob >>jt wrote: | > ... Similarly I would | > ask, why would anyone want to code this: | > | > parms.transNo = %editc((%dec(transNo:%size(transNo):0) + 1):'X'); | > | > in order to increment a transaction number...??? I ask this | seriously: Why | > do you need "rocket science" to add 1 to an alpha transaction | > number?? Iirc, seems like only one person on this list even came up | > with an /alternative/, a simple data structure. I guess because if | > it ain't "modern", it ain't cool... | | That's really the wrong question. A more appropriate one is this: Why | would anyone want to implement a transaction /number/ as an alpha | string?
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact copyright@midrange.com.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.