|
David wrote: >Depends on how you do it. OPTIONS(*VARLEN) could speed up what >you are doing. If you are on V4R2 Varying makes a huge difference. I >converted our string routines to use Varying when V4R2 came out and it >made a big improvement. If you combining CONST and VARYING you >get ease of use, flexibility, and speed. The biggest drawback is that CL >calls have to append the length manually. Also the older (non-free format >opcodes like xlate don't automatically set the result length.) Ditto on encouraging the use of varying length strings. I'm posting in response to David's last point about fixed-format opcodes not setting the length of the results. This was a tough choice to make, since you would expect that the length should be set for all string results. Unfortunately, the fixed-form opcodes have some interesting semantics that complicated the issue. For example, how do you set the result length for the MOVE opcode which moves data right-adjusted into the result without erasing existing stuff at the left of the field? Other fixed form opcodes have similar behaviour in that by default, existing chars beyond the end of the source data are not removed. OK, there is an opcode extender that says to pad the result with blanks, but then, do we want to complicate the behaviour with different rules for the different options? We decided to try to keep things simple: For the free-form opcodes, you get the varying length behaviour you would expect. For the fixed-form opcodes, a varying length field acts just like a fixed length field defined with the current length. Or 1) fixed opcodes -> varying fields work like fixed length fields 2) free-form opcodes -> varying fields are free Needless to say, as more and more programmers move to newer releases that support varying length strings and more built-in functions, we expect more people to use the free-form opcodes. String processing is much much easier with the free-form opcodes. (Regarding XLATE, you'll have that as a built-in function in some future release. And there are at least a dozen more in my work plan!) Cheers! Hans Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the RPG/400 Discussion Mailing List! To submit a new * * message, send your mail to "RPG400-L@midrange.com". To unsubscribe * * from this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe RPG400-L' in the body of your message. Questions should * * be directed to the list owner / operator: david@midrange.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
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 [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.