|
Re Indicators ...
https://authory.com/JonParisAndSusanGantner/Goodbye-Indicators <https://authory.com/JonParisAndSusanGantner/Goodbye-Indicators>
That was from 2002. More recently https://authory.com/JonParisAndSusanGantner/Guru-Classic-The-New-Basics--Indicators <https://authory.com/JonParisAndSusanGantner/Guru-Classic-The-New-Basics--Indicators>
I appreciate that you are doing this as a hobby but I do think that you seem to be missing the real benefits of RPG as a language. Hint: Columnar organization was never one of them.
One of the things I have always loved about RPG is the power of its I/O model. Declare a disk file and a display file. Use the same field names in both. Now a simple READ of the file and a WRITE (or EXFMT) of the display and magic happens. Under the covers RPG reads the record into a buffer, and extracts all of the individual fields into their own storage locations. When the Write is encountered the field data is gathered, placed in the buffer and sent to the device. There can be significant advantages in terms of volume of code (and a resulting reduction in potential errors) in that simplicity of approach. That's the benefit - not being forced into columns.
Indicators (as you'll see if you read those articles) are a historical (hysterical?) legacy of the old tabulating equipment that the original RPG was designed to simulate. They can just as easily be used when associated with a name.
But enough of this ...
What release level are you at any the way?
On Jun 10, 2021, at 2:39 AM, Patrik Schindler <poc@xxxxxxxxxx> wrote:
Hello John,
Am 10.06.2021 um 02:04 schrieb John Yeung <gallium.arsenide@xxxxxxxxx>:
It's a mix of established habit and not following a strict set of rules regarding that. :-) But you certainly have a point. Allow me to think over that.Second, there's a certain beauty to me in having a rigid format to follow.While I can appreciate the fun of sticking to artificial constraints, I am simply a bit confused about *which* constraints you are adhering to.
If you find it acceptable to use %CHAR, then how is it not acceptable to use %EOF or %FOUND, for example?
One important area where I'm deliberately using indicators is when I want to reflect program state in a display file. EOF of a file, BOF of a file. I can test within the program for the indicators being set to handle these cases gracefully, and at the same time have automatically the conditioning indicators for DSPF elements.
If you're allowing yourself %CHAR, then you must be using Extended Factor 2. Once you get that, strings are vastly less painful.True enough. But still less space as in, for example, C. Even if I restrict myself to 80 chars in width, a bit of indenting and the (s)printf in front, there's much more space than what's wasted until I'm allowed to write EVAL in what looks like the middle of the horizontal space. :-)
Don't get me wrong, I'm *not* complaining. Just pointing out that while I'm in general perfectly fine with positional RPG, there are areas, where I switch to something else. Since I know C syntax better, this is my choice. And, even that code can run on very old systems if done with that goal in mind.
the statement I'm quoting is "static strings [are] truly PITA in positional RPG". And my contention is: well, if "positional RPG" includes Extended Factor 2, then positional RPG also includes BIFs and continuation lines, and if you have all of those things, then static strings are not really all THAT painful.)True. Not *that*. But still… See above.
:wq! PoC
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.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.
midrange.com
