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

[rob@xxxxxxxxx]

Tony,
I wouldn't think you'd have to concatenate leading zeros.  Wouldn't the 
'X' edit code do it?

And some would argue that concatenating several numeric fields into one is 
a no-no.  Why not leave them as separate fields?  This ain't a S/36 - the 
key fields don't have to be contiguous.  I have seen one numeric field 
converted into alphanumeric.  In a package.  The database designer would 
have preferred numeric.  However a valid marketing requirement was that 
they support people who converted from a different package into theirs and 
their previous package might have used alphanumeric values for that field.

Then again, I work for a company that used to have a separate class on how 
to interpret our item numbers because each character or two meant 
something.  Kills flexibility sometimes.  Suppose it helps to error check 
that you are entering the right item number.  Especially when the company 
used to keypunch.

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





Tony Carolla <carolla@xxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
10/28/2004 07:07 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?)






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.