Re: Move an entire record format as a whole

Bob Cozzi
www.rpgiv.com


----- Original Message -----
From: <boldt@ca.ibm.com>
To: <RPG400-L@midrange.com>
Sent: Monday, July 12, 1999 11:14 AM
Subject: Re: Move an entire record format as a whole


> 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          *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *