RE: /free vs Fixed (was: RPGIII to get a facelift?)

Wondering...

Does anyone think the curly brace use as within Java was considered for
RPG/Free?

It certainly eliminates 'endif' and 'enddo'. :), Ken

dow x<100 {
 x=x+1;
 }

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Bob Cozzi
Sent: Thursday, October 28, 2004 6:07 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: /free vs Fixed (was: RPGIII to get a facelift?)

Tony,

Have you tried this to solve your numeric issue?

  Eval  myTextNumVal = %editc(myNumVal:'X')

Works for me.
-Bob
P.S. Oops! I forget the ; after the statement. :)

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Tony Carolla
Sent: Thursday, October 28, 2004 7:07 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: /free vs Fixed (was: RPGIII to get a facelift?)

I use free format exclusively (except for those cases when I MUST use a GOTO
(<--rarely)).  I agree with you on some of these points.

On Thu, 28 Oct 2004 18:48:58 -0500, Bob Cozzi <cozzi@xxxxxxxxx> wrote:

> Where's the issue?  The semicolon on the IF and the ELSE statements.
> I can get used to entering /Free and /end-free once, but when you code 
> 10 million IF statements in your lifetime and for 9,999,995 of them 
> you
forget
> to enter the ; and have to recompile, it gets to be bothersome.

I agree.  And I don't think that the semicolon should be allowed after the
IF statement, but after the ENDIF.  the IF clause is by no means ended at
the first instruction that is to be executed for the positive case--It's
just the beginning.

> 
> Then there's the very extensions to the opcodes in free format that 
> I'm beginning to dislike a lot. Take the CHAIN opcode. I love the ad 
> hoc
keylist
> idea. It is a wonderful feature, but then, instead of allowing us to
simply
> use data structures as keylists or allow us to declare key lists on D
specs,
> they added that "opcode parameter keyword" thing.  So now we have 3 
> different free format syntaxes for the CHAIN opcode. That in addition 
> to
the
> fixed format CHAIN syntax.
> 
> Rules for CHAIN in Free Format:
>  If you use a KEYLIST, then just the keylist name is specified.
>  If you use an ad hoc keylist, enclose the fields in parentheses.
>  If you want to use data structure subfields are key fields, specify 
> the data structure name and enclose it in a %KDS() parameter keyword.
> 
> If the free format syntax is so much better, why all the extra 
> syntaxes
"if
> this, then do this, else do that" I mean just try teaching this to 
> students... They many get turned off to /FREE immediately even though 
> they love the ad hoc keylist capability.
> 
> If data structures did not fit the ad hoc keylist model, that is allow
them
> to simply be enclose in parens, then data structures should not have 
> been allowed. In stead, keylists should have been allowed on the D 
> spec and specified as usual (with no parens) then if you only want to 
> use a partial keylist (a subset of the fields in the keylist) enclose 
> the keylist in parens and specify the number of fields to use as the 
> 2nd value, like
thisL
>   Chain myKeyList  CustMast;
>   Chain (myKyelist: 2) custmast:
> In fact,
>   Chain (myKeyList) Custmast;
> Should also work today, but it does not (as far as I remember).
> 
> For those who say, "I already have a data structure created that has 
> the keyfields I need, why not allow %KDS?" I say, why not this instead:
> 
> D  MyKeyList          KL             LIKEDS(MyKeyDS)

This would be very nice.  I actually use the ad-hoc keylist everywhere,
because it is crystal clear exactly what fields are being used to key to the
file, whereas a %KDS data structure leaves the person editing the code later
to do the 'scroll back to the D specs'
routine, and sometimes, if you specified the DS to be like the key fields of
the record format, even look at the DDS for the PF.

Additionally, sometimes the %KDS, during compile, does not compile
correctly.  

Also, as far as free-format goes, what's wrong with MOVE?  I understand the
fundamental diffences between MOVE and EVAL, but why extinct it?  One of the
data extracts I do demands the creation of a 'unique identifier', which
includes text versions of several numeric fields.  Without MOVE, the leading
zeroes go away, forcing you to either /end-free, MOVE, /free (fugly), or
EVAL, concatenating '0000...', and substring (complex).


--
"Enter any 11-digit prime number to continue..."
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.



--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.