Re: Move an entire record format as a whole

Hans,

Not to start debating a bad idea <g> but if you're going to brag about
"double the number of built-in functions" you might want to consider that
we're not stupid. If you already had CHAIN (for example) and you give us
%CHAIN()  but don't give us some new useful function, like the ability to
retrieve the length of a parameter passed to a Procedure (with out using
CEEDOD) I'm not sure I would be bragging about it.

In the Army, the letters "CF" stand for "Cluster F.ck". I can just see the
buttons at COMMON, now... (Dream sequence starting...)  "CF just another
Cluster F.ck". A solution looking for a problem where there is/was none.



Bob Cozzi
www.rpgiv.com


----- Original Message -----
From: <boldt@ca.ibm.com>
To: <RPG400-L@midrange.com>
Sent: Thursday, July 08, 1999 1:29 PM
Subject: Re: Move an entire record format as a whole


>
>
> Bob wrote:
> >Yes, the ability to read into a data structure would be good. Much more
> >important to me that CF... :)
>
> So far, it looks like most people like the idea, so I'll add
> it to our "proposed enhancements" list.  Ooops - it's already
> there!  (Thank Jon Paris).  You should see it in our next
> enhancement poll.
>
> Regarding the infamous CF-Spec, it's already done.  I had that
> one mostly coded even before I was scheduled to start on it!
> We've had a bit of design churn on it, but the effect of that
> was more new BIFs in the language.  V4R4 ended up with 38 BIFs.
> So far, we've added another 30.  I'm trying to convince everyone
> here that we should add another 8 so we'll be able to say we've
> doubled the number of BIFs!
>
> It's actually not as impressive as it sounds, though.  Almost
> all of these new BIFs simply duplicate function previously
> available only in opcodes.
>
> >I guess fundamentally, it would work like the program described files do
> >today,
>
> Of course.
>
> >but also allow the ability (maybe in phase 2) to read into the DS
> >without using the Input spec area. That is it would allow use to define
our
> >Input data with D specs.
>
> Do you mean "locate mode"?  We've been brainstorming various
> ideas here for a while, including that one.  But we've seen no
> clear consensus on what a "phase 2" would look like yet. There
> is still lots of design work to do on a "phase 1" for this idea.
>
> >Of course I wouldn't expect, nor would I want, you
> >to implement all that RPG cycle stuff from the Input specs in the D-spec
> >implementation.
>
> Of course!
>
> (Hmmm, on the other hand, how about some new BIFs: %LVLBRK,
> %MATCH, etc? :-)
>
> 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *