|
Wow, gone from cycles and control breaks to implicit versus explicit! :)
And of course they were mostly 6000-line behemoths, 500+ lines of which were GOTOs!
Yep, sigh.. I once worked on a "multi-bodied program" ported originally from the S/34 to the S/36 to the AS/400, one program for each screen. It was nice to have the logic separated so.
You may save a few lines of code and a few minutes of your precious time
by coding a cycle pgm that, at least initially on the surface, looks pleasingly elegant to the untrained eye. ---> Or to some trained eyes too! Beauty (and frequently "elegance") is in the eye of the beholder is it not? It may even look not only pleasant but as a utilitarian benefit to some programmers, and James is now an example of someone new to it who appreciates the "benefit". I appreciate his appreciation, :) because I've taught RPG to COBOL programmers who couldn't get it that the compiler wrote so much code for them! As to implicit, we have much more in the new and improved RPG than we ever had. Externally described files where the field definitions are implicitly assumed in the source, expression evaluations that require intermediate steps that used to be explicit in the RPG and now are implicit. Try it on a simple calculator ha ha, that's the way we used to have to do it in RPG haha! Documentation is big to me, and clear maintenance-friendly code. Sometimes instead of the "Other" operation in a "Select" code-group, I'll write out the actual condition, for that reason. It's also important to remember, because "implicit" is coming at us fast in the segmentation made irresistably attractive with the coming on of ILE and service programs and subprocedures and the use of C-functions with names that are longer than a source record itself! That's also why when you do use service programs to have a prefix-naming convention or some way to easily track your subprocedure use to its service program. Alan ------------- (Smiling for Christmas...)
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.