× 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: Move an entire record format as a whole
  • From: boldt@xxxxxxxxxx
  • Date: Mon, 12 Jul 1999 12:14:16 -0400

Bob Cozzi wrote:
>Just for the record. I think that are far more important things needed in
>RPG IV than CF specs. I also think using "CF" just because the prompter
>already uses "CX" for the EVAL prompt is silly. I have suggested using
>another character, such as X so that it could be an "X-spec".

Just for the record, let me point out that "X-Spec" was OUR
first choice for a free-form calc syntax.  However, designs
evolve and change early in the development cycle as issues
are fleshed out.  We went to the CF-Spec syntax since it
seemed much more RPG-ish (as well as easier for us to code).

>
>Let me point out my issues with completely free-format changes to RPG IV.
>
>In training programmers in RPG IV I find that they run into one consistent
>issue: Management limiting their ability to use RPG IV because they (the
>management) then has to support applications in different languages. In
>other, because RPG IV is different from RPGIII, people are being
>restricted from using it.
>
>Now, add the X-spec to RPG IV. What happens? You not only have two different
>languages that management needs talent on, there is a 3rd variation. Hence,
>they need talent in 3 areas. It is too difficult to fill those voids for
>various reasons.

I don't mean to sound pedantic, but right now, there are five
variations of RPG IV, one per release.  RPG IV is an evolving
language.  Already, if you write new code, a program written
for V4R4 will look very different from a program written for
V3R1.  IMHO, the difference between V4R4 and V3R1 RPG IV is
bigger than the difference between V3R1 RPG IV and RPG III.

If training requirements deter people from moving to RPG IV,
then any new function (like your O-Spec keywords) would also
serve to deter migration.

At first, V3R1 RPG IV was little more than new spec positions
for an old fixed format language.  What justification was there
for moving at that time?  Isn't a feature-rich language a better
inducement for migration?

I agree that management tends to resist change.  But in many
programming shops, migration to RPG IV (as well as other
technologies) happens without direct management involvement or
knowledge.  The best way to reach the real users of our product
is features that programmers can best appreciate.

But there is another way to look at the current situation.
Today, the competitive marketplace is much different than it
was when RPG IV was being designed.  There are people out there
who wonder why we even bother to enhance RPG at all!  For
example, some are pushing technologies such as Java, and argue
that we should put more of our resources there.  So, there's a
problem, not just with getting people to move to RPG IV, but
with getting people to stay with RPG!

>
>Using CodeStudio or Code/400, I don't need the extra space to type in a
>freaking %SUBST or whatever. What I need as an RPG IV programmer, is
>enhancements to the language feature set and fixes to implementation flaws.
>I have said this before, I don't know how many comments I get concerning the
>complexities in coding (for example) an Externally Described Data Structure
>SUBFIELD.
>
>Hans, remember the System/38? Remember the security model? Originally they
>implemented effectively all the security controls you have today (with some
>exceptions). It took 6 to 8 years before many S/38 programmers began to
>understand the security model. There was too much there to understand all at
>once (back then) so we didn't bother.
>
>With Fixed Format RPG III, Fixed Format RPG IV, partial free-format RPG IV
>we have enough complexity. With the addition (today) of the X-spec, we add
>one more decision making issue and another layer of complexity.

And adding a new syntax for EDS subfields would not add
another layer of complexity?   (Sorry, couldn't resist!)

>
>Does this mean that X-specs should never be implemented? Not at all. I just
>think they are at least 2 to 5 years out, and that implementing new features
>and functions (such as keywords on the Output spec) are more important than
>yet another way to do CHECKR.

In a sense, you are correct that CF-Specs (please spell it
correctly) are 2-5 years out.  First, it will still be a
while before this release GA's.  Second, heck, there are
still a lot of people programming for V3R2. It may be 5
years until support for V4R4 is dropped and most people can
finally take advantage of the enhancements we're working on
today.

Regarding O-Spec keywords, as far as I know, you're the only
one asking for that.  (Techcinally, O-Specs already have
keywords - you code them using DDS.)  Which should we put more
emphasis on: something that lots of people want (such as new
BIF's) or something that only one person thinks is important?

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  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:

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.