My usual litmus question is: Will I want to call this code from some other
mechanism ? If the answer is Yes, then it needs to be modularized.
I even go a step further: I write (or have written) a lot of very small
procedures, but each peace of code is encapsulated and must be executable
from outside (i.e. exported procedures).
For me procedures are nothing else then "mini-programs" (located in service
programs) that can be called from everywhere.
Even though you think today a peace of code can only be used within a
specific program. Next week or in half a year you need exactly the same
peace of code. What to do? Copy it? Bind the module multiple times? ... or
convert it into an exported procedure in a service program?
I either way you won't have to care about that, if you created an exported
procedure from the beginning.
I did not follow all comments, but here are my thoughts what a modern RPG
programmer should be.
A modern programmer (independent which programming language is used) must be
able to think modular (independent whether the language is procedural or
OO), build small reusable pieces of code (independent whether they are
called functions, procedures or methods).
Also a modern programmer should be able to structure the code. Even small
functions can be written in spaghetti style.
Once you are able to think modular, learning another programming language is
almost only using a different syntax.
The second step a modern RPG programmer should do, he should learn SQL.
Not only how to embed SQL into an RPG program, but learn how to move
business logic into the database.
Translating an RPG program with native I/O 1:1 into embedded SQL does not
make any sense. You need to think set based.
For example complex views will help to reduce the source code to a minimum.
If you need more than one SQL-Statement for fulfilling the task, you may
create an UDTF (User Defined Table Function).
May be you have a DBE (Database Engineer) who will be able to design complex
views and UDTFs.
These Views and UDTFs can be used where ever you can use SQL, i.e. it does
not matter whether the it is called from within an RPG program or a JAVA
class or a C# Program or whether it is used for downloading data to EXCEL.
Also a modern RPG programmer should learn to write and consume web services.
Because the data might be necessary in an environment where SQL cannot be
used, but if your RPG program can be called over the Web and you'll be able
to provide the result as XML-document or as JSON data, it is perfect.
As for the user interface, ... GREEN SCREEN is out. If you are not a
WEB-Designer, your Web-sites might be weak. But if you have someone who can
design your interface and call your RPG programs through a Web-Sercice.
Perfect.
In either way you should have a look at JavaScript and the OPS-Tools that
are available.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Richard Schoen
Sent: Montag, 5. Februar 2018 20:27
To: midrange-l@xxxxxxxxxxxx
Subject: Re: What is a Modern RPG Programmer???
Good relevant example.
I understood the reasoning for modularizing but wanted to see an RPG
-specific example of that.
As you said it does require some forethought on future use cases.
My usual litmus question is: Will I want to call this code from some other
mechanism ? If the answer is Yes, then it needs to be modularized.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
------------------------------
message: 5
date: Mon, 5 Feb 2018 12:32:28 -0500
from: Rob Berendt <rob@xxxxxxxxx>
subject: Re: What is a Modern RPG Programmer???
Richard,
In my case the first reason I used a subprocedure instead was to force
myself to make subprocedures the habit and subroutines the exception.
Otherwise it was just easy to fall back to what was easier and more
comfortable.
The second reason was to see if it could be pushed along the evolutionary
path.
Ok, using your global variable example. BPCS does not have an on-hand
field. To calculate on-hand you have to use onhand = OpeningBalance +
Receipts + Adjustments - Issues And, unless you also subprocedure your file
i/o these are usually global variables.
So you're thinking why make these a subprocedure vs a subroutine? Follow
along...
Let's say you make this a subprocedure so you can then do currentOnHand =
onhand(OpeningBalance, Receipts, Adjustments, Issues) Ok, not very clear why
this would be anymore productive? I totally agree.
However follow along...
So now you move this subprocedure out into a service program.
So now you create a function
Create Function OnHand as...
And your function calls your external RPG subprocedure export from your
service program.
Still not intuitively obvious as to why this is more productive? I can
understand. Follow along...
Now you create a view
Create View IimView as (
select colA, colB, ...,
onhand(OpeningBalance, Receipts, Adjustments, Issues) as OnHandBalance from
iim...
Now your users can use their favorite query tool to query the data and no
longer have to calculate the onhand (and risk getting it wrong) on each and
every query they write. They query the IimView instead of the IIM file
directly. And if you choose to use the view to pretty up the columns, like
change the names from IMOPB, IMREC, IMADJ, IMISS, IMBS :-) to more
meaningful names, convert the 8,0 date formats into real dates, etc you can.
Now, does that make some sense? You really have to look long term.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
