RE: "Real ILE" ( tangent from RPGIII compiler vs. Visual Basic) -- MIDRANGE-L

Hi Kimaly,

Yes, effective documentation helps, and I have done just that with the
service program development I've done here.  It's not so much that they
can't look at the code and see what it's supposed to do, but rather they
don't understand the mechanics of assembly (prototypes, binding directories,
activation group, etc) and the callable interfaces (getters, setters, and
actions).  They wonder, "why call that procedure to get that value, when all
I have to do is chain and get it directly......"  Or, "why do we need to
remove this business logic from this subfile load subroutine?  It's more
efficient to do both in this same loop...."  

There's a lot of basics to cover.... Lots of programmers to deal with...  (I
need a vacation... <g>)

Thanks,

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Kimaly Mayhew
Sent: Friday, June 17, 2005 8:08 AM
To: Midrange Systems Technical Discussion
Subject: RE: "Real ILE" ( tangent from RPGIII compiler vs. Visual Basic)


Hi Eric,

<Offer to help develop the staff and show them the ropes.  Try to get them
excited...  Yeah, well, that cuts into valuable production time and nobody
can afford to lose ground in the daily struggle to abate the looming piles
of change requests that dominate the desk..>

What I have found as a way around this issue, regarding not having the time
to train the co-workers that don't understand the ILE or /free is to
basically build a roadmap of documentation in the code itself. If the
comments tell you exactly what is going on - then it removes that obstacle.
Sooner or later you have to be able to prove the arguments just aren't
founded and they can be more productive!

 -----Original Message-----
From:   midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]  On Behalf Of DeLong, Eric
Sent:   Thursday, June 16, 2005 4:58 PM
To:     'Midrange Systems Technical Discussion'
Subject:        RE: "Real ILE" ( tangent from RPGIII compiler vs. Visual
Basic)

Hi Greg,

Nice opinion piece, fit for the old IMHO page.  

I think that if you conducted a poll, you'd find that many of the
participants on this list are "homegrown" programmers, trained on the job,
with limited "professional development" opportunities.  I suppose that's how
Midrange-L came into my life, looking for information and sample code for
self-education, and what I found was a community of like minded individuals
who actually shared their ideas and "tricks" with those of us who whished to
learn.

One thing about learning new stuff, is that once you see how to do it, you
want to use it in your day to day work, but all too often it is not allowed.
I bet you know what the number one excuse from management is....  "Nobody
else knows this stuff.  Nobody else wants to learn it.  Now go and forget
all this crazy new stuff....."  To be fair, sometimes the adoption of new
technology is not a good idea, and management is right in their objection..
But to hobble a programmer's professional development on the grounds that
"ILE is new" (what is it now, 11 years old?) is just sickening.  What to
do....

Offer to help develop the staff and show them the ropes.  Try to get them
excited...  Yeah, well, that cuts into valuable production time and nobody
can afford to lose ground in the daily struggle to abate the looming piles
of change requests that dominate the desk.. All in all, it's frustrating to
be told at every turn that your co-workers don't care to learn what you
know, so stop using that stuff.  

ILE really boils down to a shift into modular coding, and as such it
involves retraining at the most basic level of analysis.  Functional
decomposition is a foreign concept to most procedural coders, but it's
useful when breaking a complex transaction into its fundamental elements.
Fun stuff, to be sure, and not too easy to do in a "learn on your own time"
work environment.  

Anyway, fwiw, that's why I think you see some flames around here sometimes.
The movers in this community are trying to push forward, with considerable
resistance from the very people they are trying to empower.  Frustration
abounds.


Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Fleming, Greg (ED)
Sent: Thursday, June 16, 2005 8:00 AM
To: midrange-l@xxxxxxxxxxxx
Subject: "Real ILE" ( tangent from RPGIII compiler vs. Visual Basic)




>My point exactly. Converting a monolith app to RPG IV doesn't make it
ILE. >It's still the same monolith code and if you rewrite in ILE (Real
ILE).

This brings up something I seem to be struggling with.  

I'm one of those programmers someone else mentioned here who never had
much formal programming education.  I was in a clerical position in our
marketing department and responded to a job posting for a "trainee"
position doing RPG programming.  I sat down for two months with a basic
course from Manta and some slightly more in-depth courses from ATS, and
learned the basics of RPGIII, subfiles, etc.  This was eight years ago. 

Since then, I've kept up as well as I could. The transition to /Free was
a no brainer, just put the op code at the beginning of the sentence and
make some creative use of built in functions, and bob's your uncle.  I
also managed to get to Common a few years back in Nashville, and learned
what I could from Jon Paris and others of subprocedures and prototyping.

I currently do all my code in /Free, and use procedures for my entry
parms and all external program calls, as well as the occasional internal
subprocedure.  On some rare occasions, I've even used a binding
directory and /copy to prototype some procedures, but this is where it
all remains a little fuzzy.

It seems like there's plenty of information available about "how" to do
ILE, but not so much about "what" to do with it.  It's like learning to
speak a foreign language without ever visiting the place or living among
people who are from there.  You can get the syntax and vocabulary down,
but when you finally visit, your poor usage and pronunciation will leave
you nearly as ineffective at real communication as someone who never
learned any of it.  

When I was learning the OPM, the two senior programmers here were able
to show me how the "programming" I was doing fit into the context of the
business objectives, and also into the context of our programming
environment setup, change management software, etc.  

With ILE, we're all on the same page now, so it's like the blind leading
the blind.  I know how to compile a module and create a program
separately, but never seem to know why I would want to.  I was delighted
when I realized I could use a header spec to specify DFTACTGRP(*NO), so
I could use procedures and still do a CRTBNDRPG, because I couldn't
figure out how to keep track of separated modules and program objects.
Like when I go to check a program out of our production environment, how
do I know if it was a separate module or a bound program ?  

I guess a lot of this comes down to naming conventions and shop
standards and what-not.  I also often suspect that some of it has to do
with intelligence or level of competency.  It seems like it must be true
that some people are competent enough to handle OPM style programming,
but may not have the noodle to handle the increased complexity of a more
object oriented paradigm.  I sometimes suspect I'm something less than a
"real programmer", although I don't think that makes me useless.  There
are people who are going to fit best in data entry postions, and others
who will write programming languages and work with kernels and whatever
else there is deep in the bowels of the machine.  Then there are some of
us who will fall at various levels in between. Figuring out what one's
own level is can be a difficult process.  The Peter Principle says that
everyone will be promoted to his level of incompetence and generally
will be left there. 

Anyhow, it seems a lot of the discussion here has been centered around
the difficulty of getting programmers and shops to adopt the new
methodology, and it seems to me like this is an inhernent problem with
the pace of technology.  I think the ultimate educational paradigm
(wow..I used that word twice in one email...I must be smart) was
established in the middle ages.  Apprentice...Journeyman...Master.  You
work under the instruction and supervision of those who already know how
to do it "right", until you learn as much as they know.  

But our world doesn't have time for that.  There are some people who are
good at reading a manual on the latest programming language and
intuitively understand how it will fit into the world they know well
enough to run with it, but I think those are in the minority.  So it
seems that what we're left with is a newsgroup where really smart people
whine about the fact that there aren't more of them around.  

The solution?  Smart people should make more babies.  But then you
wouldn't have time to do all that programming, would you ?  

Just my two cents.

Greg Fleming