× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Jon, I looked at your email address, do you work in Italy these days?

I think that it was 1993 when I did this architecture.  My statement,
"haven't upgraded to a RISC machine" is based on that date.  I thought it
was a mistake at the time but I couldn't convince the boss to change his
mind and I was too low on the totem pole to push very hard.  Please
reconsider your first three comments in light of that fact.  Jon, I
apologize for not making that clear.  We are in violent agreement.  When I
wrote the note, I was focused on the architecture considerations and I
failed to consider that someone might interpret that bit using today's
facts.  I did confuse you and included information across several years of
development.

One of the guys who worked for me wrote a code generator in C that created
file server programs (and the .h files) in C.  It worked like a dream and
the language was invisible to the application programmers but, at the time,
the boss refused to accept the generator.  He said something like, {the
application managers won't accept the programs because they have no organic
C programming skills}.  In this case, the {} means "paraphrase".  I tried to
argue with the boss but that was a life-limiting move - that man was, and
still is, VERY stubborn and one of the best red-faced shouters I have ever
met.  His track record on application and business decisions is awesome so
he might have been right.  At the time, winning wasn't a good gamble and
might have been unpleasant.

You may have noticed that I strongly supported the idea that the file server
programs should be "re-gener-able" at will.  Someone in the financials
application groups decided that it was a good idea to put the cost center
security logic into the file server program.  In my opinion, it was a mess
and still haunts.  Because the application managers were thinking of putting
other logic into the programs, it was important to them that they could
maintain the programs.  Coding them in C would have prevented that.  At the
time, I thought that was one of the advantages of coding them in C but ...
oh well.

Two years later, when they rearchitected and redesigned the entire suite,
all the application groups had one or more C programmers all of whom would
have seen the risk of putting business logic into the file server programs
and this would have been a non-issue.

At the time of this design and initial implementation, we could have chosen
to use either ILE C or the OPM version.  Timing again, sorry.

I agree that customers should stay current on OS releases.  I think that
they should be forced up.  I saw a note on the midrange list from someone
who was at V3R7.  Compared to V4R3 or V4R4, V3R7 is a very bad place to be.
I think that the right approach is to withdraw support for releases more
than a certain number of years old or more than a certain number of releases
back.  In my opinion and at this time, there is no justification for being
on V4R1 or earlier.  I think that V4R2 is not nearly as good as V4R3.
Software rot is bad for everyone.

I am leaving all of your comments on this note.  Every one of your points is
exactly right today.

Richard Jackson
mailto:richardjackson@richardjackson.net
www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Jon.Paris@hal.it
Sent: Tuesday, July 04, 2000 12:25 PM
To: RPG400-L@midrange.com
Subject: RE: ILE Conversion



 >> Why write the file server in OPM RPG?  Because most of your customers
haven't upgraded to ILE machines and you don't want to force them to - its
bad for business to force customers to do things.

I have to take issue with a number of points arising from this and other
comments in your note.

First - you say they "Haven't upgraded to ILE machines"  You mean they are
running V2 releases?  I'm not sure I'd want to keep such customers anyway.
All V3 and later releases support ILE.

Second - If you RPG IV in compatibility mode then its behaviour is almost
identical to RPG/400 anyway.  The benefits of RPG IV over RPG III are so
overwhelming I can't believe that you have seriously looked at the language
at all.

Third - It is perfectly possible to write full ILE programs (making full
use of subprocedures etc.) that can co-habit with OPM programs without an
enormous amount of work.

Fourth - who said the "old" programs had to share the new IO routines
anyway?  They can stay as-is and be converted as/when they get re-written.

As to writing the thing in C - you're confusing me here.  The only C
compiler is an ILE one - you said earlier that you don't want to force your
customers to use ILE - am I missing something here?.  Anyway, all of the C
I/O routines can be used directly from RPG IV with no need for a C compiler
on the box (not a trivial expense at present) so for those occasions when
more flexibility than supplied by RPG is required you can go that way.
Besides - there is no need to produce a complete I/O system that can handle
any file/any format/ any operation - simply routines that put in one place
the operations required of a specific file/file set.


Last - but by no means least - I think we _should_ force our customers to
do things from time to time.  Shouldn't we encourage them to upgrade to
supported releases?  One BP I know recently informed their customer base
that they would have to move to a minimum V4R2 level to receive the new
release.  The customer's reaction (much to their surprise) was "Oh good -
we thought we should move but were waiting for you to tell us we needed
to!"

IMHO if you allow your customers to "rot" as you appear willing to do, then
they are easy targets for the NT "solution" advocates.  What happens to
your business then?



+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.