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

That's ok Bob.  We didn't think it was free form.  Who'd use an eval in 
free form?  :-)

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Bob Cozzi" <cozzi@xxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
10/28/2004 08:06 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
cc

Fax to

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.