Re: Passing Parameter as Variable vs as address of variable

Hello Daniel,

thanks for your elaborations! Especially because you do the chore of formatting on your phone! I'm cutting away statements where I see no further value in commenting. Please assume an implicit "thanks for the explanation" for these. ;-)


Am 27.08.2023 um 09:43 schrieb Daniel Gross <daniel@xxxxxxxx>:

You typed and formatted/quotes all of that on a miniature screen? :-O Thanks for your efforts!

Thanks - but I‘m from the generation that took a lot of flak in the news groups where you easily got hit by a *plonk* for posting „TOFU“ ;-)

Same here. I still moan Outlook taking over the world, and making TOFU the braindead default.

Yes - safety is good - because of this we define ALL parameters as „const“ - only parameters that should „pass back“ values are not „const“.

We use „value“ only in very special cases.

Since I wasn't aware of CONST in this context, I'll keep this in mind. Thanks a lot!!

You’re really missing out a lot. Most things I write are V7R3 and above and **free RPG - because this is what I develop.

Most people on the platform do. Most people on the platform are also professionals. I'm a hobbyist. :-)

When calling „normal“ programs (*PGM objects) then you have to resort to passing by reference. The „value“ keyword is not supported for *PGM calls.

But „const“ is supported - so you can do a lot there.

As said, I need to check if this is supported with V4R5.

This means, there is no variable scoping, and inadvertent change of variables within the program flow is a constant source of corner cases to catch.

This is where local procedures (defined in the same member) are handy. Yes you have to type a bit more initially - but you have variable scoping and real parameters - so hell yeah, use it.

I'm not convinced, yet. Also, to me, it's not only "a bit" more and muscle memory is strong. ;-)

In C, retval = dothis() feels very easy.

Yes - here we are - create service programs with procedures, and you can have exactly this with procedures outside of your source member.

This is what I also have on my slate to grok and train into muscle memory.

In classical RPG, probably old enough to when there is no EVAL, I guess messages are involved. A topic I constantly fail to wrap my head around.

Message handling is really not easy

Thanks for confirming my suspicions.

- especially because „snd-msg“ and „on-excp“ arrived late to the party and one had to use system APIs for everything.

For me, they did not even arrive. ;-)

Thanks for the hint! Need to look into this, and if it's already available with V4R5.

Can’t say that - but I really think you should jump ship to a never release if somehow possible.

Uhm, no, thanks. I've just recently briefly tried V5R2 on my 150, the latest release supporting that model. It ain't no fun. The amount of used disk space almost doubled and the increased amount of data needs to be read, paged out, occupies RAM, and needs to be funneled through the CPU and IOP. In short: Everything you do feels a lot slower. Given the fact that a 150's main CPU seems to be clocked at just 50 MHz, this is no wonder. Given how quick a 150 can retrieve data for a subfile or other means (avoiding SQL!), this is quite impressive, especially when running the much less bloated V4.

To me, a 150 has huge advantages over all newer models I'm aware of:

- With V4 you don't need any license keys, which is the biggest problem for a hobbyist like me, when e. g. disks have been scrapped or security-erased or whatever, proof of ownership, install media and other things have long been dumped.
- A 150 draws between just 70 and 100W, depending mainly on how many and which disks are used.
- A 150 runs comparatively modern V4, while V3 on IMPI feels even more dated.
- A 150 accepts almost any decent (second hand) DDS tape drive as a replacement for the increasingly pricey QIC cartridges. Also, DDS is much quieter.
- A 150 can be equipped with a stock ATX PSU with modest effort and lot losing any function, or appearing to be botched. This saves more power (newer PSUs have higher efficiency), or is a viable replacement for defective PSUs. I've documented how this is to be done on try-as400.pocnet.net.
- A 150 can be easily case-modded with adhesive bitumen mats and temperature controlled fans to be *very* quiet, mainly depending on the disks.

Summarizing, a 150 running V4R5 is what all my efforts use as a given baseline. Thanks to backwards compatibility, that stuff runs on newer releases also. With one exception: I can't compile my sources on V5R4. The compiler crashes. :-) But I didn't take time to closely analyze what happens. I don't care too much.

If only for private interest - PUB400 is your friend. If you company has problems investing in new hardware, then the company behind PUB400 could maybe part of the solution.

Again, I'm a hobbyist. My reasons to do (or not do) things are very different than these from a professional. If you are interested, we can continue that highly off-topic discussion privately.

Staying on V4R5 is definitely not good - this is so far behind, that somehow nobody can help you a lot.

Not big deal. For quite some time, I'm helping some hobbyists. I admit, we barely touched programming yet. :-)

:wq! PoC