× 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.


  • Subject: Re: RPG IV and vendor packages
  • From: Rob Berendt <rob@xxxxxxxxx>
  • Date: Tue, 3 Aug 1999 10:17:00 -0500

I believe that you are right on the large vendor package issue.  Many people on 
this list have wrote that the first thing they do when they make a modification 
is to do a CVTRPGSRC.  We pay our vendor for support.  Trying to get support 
after 
you do a CVTRPGSRC, (let alone the modification) could get really tricky.  
Probably 
why we have test data for modded and unmodded code.

The vendors do have some tricky issues to deal with.  Unlike IBM, they want to 
support their customers who stay on the older releases.  After all, they charge 
the 
customers a yearly chunk for maintenance and they make a profit.  If they've 
got 
some poor sap running V2R3, or earlier, and they are paying their maintenance, 
then 
they probably write their code to that level.  Their arguement is probably, if 
they 
can get the task done using ancient techniques, and the newer code makes no 
difference in the appearance of the actual screen, then why should they limit 
their 
market to only companies running the latest and greatest?

I wonder if they should be running the newer releases with the newer code.  
After 
all, how many people stay really far behind on OS/400 but keep current with 
their 
application software versions?  I know that we just put BPCS 4.05CD on 400's 
running 
V3R2, V3R7, V4R2, V4R3 and V4R4.

I know we can all come up with reasons to upgrade.  However most of them appeal 
to
us as technical professionals versus business reasons.
We can argue for reduced maintenance for modular code.  I love procedures, but, 
can't you achieve some 
degree of modularity using CALL?  Review old magazine articles, prior to 
procedures,
and you'll believe so.
Faster execution time?  Better be sure to back this up, legally!
For instance my old RPG cycle report program blows the doors off any SETLL/READ 
version
I've tried to do the same task with.  Most times faster execution time can be 
achieved 
cheaper with new hardware.  But if a vendor can get away with charging for a 
new version,
and get the money instead of IBM then they should go for it.  That might jolt 
some of
them into ILE - if you can PROVE the performance, and they can get money for it.
Retention of staff?  There are a lot of programmers that don't care to learn 
anything
new.  They punch their clock, draw their paycheck and go home.  We all have 
different
interests and priorities.






jteff19@idt.net on 08/03/99 09:15:13 AM
Please respond to RPG400-L@midrange.com@Internet
To:     RPG400-L@midrange.com@Internet
cc:      
Fax to: 
Subject:        Re: RPG IV and CF-spec "keep it IBM"


I am a consultant rather than a contractor. My clients get my expertise
rather than just my time. There was no RPG IV code at any client that
I've been at for the last 3 years when I wallked in the door. On the
otherhand, there was quite a bit by the time I left. I didn't just start
writing RPG IV and dump it in thier laps. I sold them on the benefits of
RPG IV first and only started coding in it with thier blessing. The lack
of RPG IV in the large vendor packages has definately hurt the
adoption of RPG IV. That should not be an excuse for us not to learn
it on our own.

Joe Teff
+---
| 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
+---END



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.