Mark,
I suggested SQL, but unfortunately, Don's shop is still "old school."
Although they want to "take advantage of ILE," SQL is not part of the
equation, yet.
One day, the "old school" programmers that embrace memory based
programming will be limited to companies that have no future in
technology. RPG is great for encapsulated programming, but offers very
little to cross-platform technology without wrappers. Why write two (2)
or three (3) programs when I can write one (1) that does it all?
Stored procedures have been around for years. However, if a procedure
is written to call an RPG program, it's limited to RPG standards. Why?
Because RPG is "Short for Report Program Generator, a programming
language developed by IBM in the mid-60's for developing business
applications, especially generating reports from data." Even RPGLE is a
wrapper for functions that convert "ILE" functions into simple RPG. As
a professional outside of the IBM world, would you employ someone that
has experience in BASIC, Pascal, and VB 2.0 for a position that requires
a comprehensive knowledge of OOP? For some reason, IBM maintains
support for archaic languages in a modern world. I've been forced to
migrate through the various offerings of OOP. Why does IBM still
support many of the programming criteria available during the days of
input cards? Can TV repairmen that know the ins and outs of tube
technology still get a job without training on new technology? No. Why
support a technology that doesn't fit the time?
As a forward thinking programmer, what do I really lose writing a
program in Java that uses industry standard data types except in
terminal emulation? Why not write stored procedures that return
industry standard results as opposed to ODBC dependent results? We are
not an industry of dictation, as many of the DB providers would like to
think. We are an industry of results. IBM knows this, or they wouldn't
have introduced open-source programming into the support line. Eclipse,
a Java IDE, for all of you nay sayers, is wholly owned and controlled by
IBM. All of your "open source" additions to the code are being
harvested by IBM to include in their next version of "WebSphere." News
flash...Most of the pertinent additions to WebSphere were designed for
free under the guise of "open source." How much did you pay for your
last upgrade?
Machine language and memory addresses are only valuable if your company
processes thousands of transactions per second. When was the last time
you checked system utilization and panicked? These are methods of the
past when memory and storage was at a premium. Don't buy the hype.
That's why IBM has changed their licensing model. It's all about
connections and users. If IBM can't compete with the processing power
of the competition, they die. If IBM can't compete with the pricing,
they die. Their ONLY saving grace is the "old school" faction that
still thinks that the IBM way is the only way.
Would IBM introduce cross-platform programming if they didn't see the
writing on the wall? As an IT professional, would you seriously pitch
hardware and software that costs on average three (3) times as much if
not for the "old school" factor? This is exactly why IBM has made the
iSeries, now System I, platform independent. From a hardware
perspective, the machines are second to none. However, if I had to
convince an executive to spend three (3) times as much on hardware and
twice as much on "old school" programming, how do you think I'd fare?
The power is in internal, server-side, processing. Maintenance, from a
financial perspective, is secondary until something drastic occurs. IBM
professionals...how often does that happen?
The bottom line is $75K is always better than $250K when it comes to the
pitch. It matters not if I believe in IBM's products. If IBM can't
compete with the price offerings of other companies, they will continue
to lose market share. This is a business fact, and one of the many
reasons that "old school" programmers should embrace, not shun, the
inevitable. I challenge any IT director to justify the financial
necessity for specialists if the job can be done by one (1) versus two
(2) or three (3). This is the challenge you will face by your
controller, CFO, CEO, CIO, etc. Trust me.
DB2 is just another database. If a company employs 20 Java programmers
that can access and write data via JDBC, do you honestly think you can
defend the necessity for two (2) or three (3) guys that can only write
native RPG? It didn't work for us. Data is data. You can argue speed
all you want. If the speed difference is milliseconds, or even seconds,
this is an online culture. "Your transaction may take up to 60 seconds"
is not uncommon. We can not rely on direct connect as the only means of
justification when everyone else is providing immediate responses with
less financial overhead.
In my opinion, any shop that is intimidated by tried and true methods
because it's not the "norm" is destined for failure, operationally
and/or financially.
I apologize in advance to anyone I have offended, but I know from
personal experience that what we perceive as superior does not equate to
justification to the powers that be. If you are in a situation that
your business can survive on RPG or even ILE alone, you have my envy.
Most of us must embrace the possibilities afforded by several languages
under a strict budget. In my experience, "specialists," especially in a
proprietary environment, are extremely limited in there career potential
unless they are toward the end of their career path and have no need to
keep up with the Jones'. I used to work for one. Trust me; I had to
make several modifications to his programming logic when the company
wanted to advance. Forward thinkers program for the future. Providers
program for the now based on what they already know.
Tom Armbruster
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Murphy, Mark
Sent: Tuesday, January 22, 2008 2:57 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Passing Parameters
You know what? This is an elegant solution to a difficult problem. And
it will work well. But, six
months down the road, it will be unmaintainable to the vast majority of
RPG programmers. <disclaimer>
If you understood what this program was doing and were able to come up
with the correct answer, you
are one of the few </disclaimer>. The reason is that it depends upon
side effects in order to work.
By defining the parameter as a pointer, and the CheckField as a based
field, you were at least
acknowledging in the code that something is going on outside of the
sub-procedure that the
sub-procedure is depending on to make it work. Unfortunately if
CheckField were passed in without
using the parameter, there is no way to know that the parameter value
will change without some line of
code explicitly changing it. It is not an expected thing for a
parameter being passed into a
sub-procedure to change when a read is performed within the
sub-procedure, particularly when no
parameters of the sub-procedure are named for fields in the file being
read. BTW naming a parameter
of a sub-procedure for a field in a file will not cause the parameter to
be changed when that field is
read.
To make this more maintainable, I would use SQL to read through the
file, and actually pass in the
name of the column that you want to compare, along with the comparison
value. That way you could
build a custom SQL, and execute it. The sub-procedure no longer depends
on side effects to work, and
the maintenance programmer can tell exactly what you are doing, and can
easily deduce why you are
doing it.
Case in point. It took some discussion and a fairly long thread before
Scott figured out just what
you were trying to do. Imagine if you were looking at this some time
down the road and were unable to
determine why this worked. Without the explanation of what you were
trying to accomplish, how long
would it have taken him? And Scott is no slouch when it comes to RPG.
Would Joe programmer be able
to figure it out in a reasonable amount of time? Not likely, and then
you would have another of the
special purpose sub-procedures like you have right now.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Don Wereschuk
Sent: Tuesday, January 22, 2008 2:23 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Passing Parameters
Scott: You're absolutely right. I was having a bad day and wasn't
thinking straight and some detail
got me confused and frustrated and I apologize for the confusion
concerning my code. Your sample along
with Adam's put me back on track and I was able to code the procedure
and have it work the way I
wanted ( a good night's sleep and a fresh start also helped) I do thank
you and all others for the
help and suggestions. They did help.
Thanks, Don.
******************************************
Don Wereschuk
ISD - Programmer/Analyst
Simcoe Parts Service Inc.
Phone: 705-435-7814 Ex: 302
Fax: 705-435-6746
mailto:dwereschuk@xxxxxxxxxxxxxxx
******************************************
"Save the Cheerleader - Save the world" - Hiro Nakamura
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, January 22, 2008 12:36 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Passing Parameters
Hi Don,
Scott, your code was very similar but what I was trying to do was
pass the name of the field and not the actual data in the field ( not
filerec.PLCD but 'filerec.PLCD'
Sorry, your code does NOT pass the name of the field. If you think it
does, then you don't even understand what your code does.
What it does is pass the ADDRESS of the field. That's what the %addr()
is for, it passes the address of the field. How the heck did you write
your code at all if you didn't understand this?
The reason your code works is because the address of the field is within
the space in memory occupied by the filerec data structure. So when
data is read into filerec, your pointer points to the particular field
within the data structure. It has nothing to do with the name of the
field, it has to do with it's address -- that is, where it's stored in
memory.
Under the covers, in the internals of the machine, my code will look
identical to yours. The difference, at the human-level, is that I'm
passing a subfield of the data structure directly, whereas you're
passing a pointer to a subfield of the data structure, and then
dereferencing them. ultimately, we both end up with a 50A field that's
in the same area of memory as your file subfield, so they do exactly the
same thing.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
midrange.com
