Jon,

I agree that we should not start discussing history. I mentioned a) and b)
as examples of "curious" decisions. The list of reserved verbs could have
been extended with RPG-IV but I also understand that IBM decided to keep
RPG-IV most compatible with RPG-III.

Point c) is an example of something that does not work and that should
have been fixed before adding new features.

Last but not least, I do not like all the new "dcl-" verbs. It is the same
as with Delphi where all these "begin" and "end" do not help to make the
code more readable.

Anyway, the decision has been made, we can not change it and I still like
RPG. I am not going to close "tools400.de" due to the "dcl"s. ;-)

Regards,

Thomas.

pg400-l-bounces@xxxxxxxxxxxx schrieb am 10.10.2013 15:04:45:

Von: jon.paris@xxxxxxxxxxxxxx
An: rpg400-l@xxxxxxxxxxxx,
Datum: 10.10.2013 15:05
Betreff: Re: Free format H, F, D and P specs
Gesendet von: rpg400-l-bounces@xxxxxxxxxxxx


On 2013-10-10, at 3:02 AM, thomas.raddatz@xxxxxx wrote:


Stuart and Vern,

What's up? Everyone wants something, IBM delivers a solution, and
all
(I
know, not everybody) we get is carping at what it is.

Of course everybody wants to get totally /free and hence voted for
that
enhancement. On my opinion the problem is, that IBM's solutions are
sometimes somewhat "complicated" or let us say "strangely". For
example:
a) if/endif, select/endsl, etc.

Why do we have to add a semicolon to the IF and ELSE statements? Other

languages use brackets for that and the semicolon is used to end a
statement. A single IF is not a complete statement.


This has been discussed to death years ago - do we really need to
rehash?

It was needed in part because RPG's columnar past and very relaxed
reserved word rules meant that the parser needed to know where an
op-code began because there were many programs that used variable
names such as READ, WRITE, OPEN, etc.

Alternatives such as OP(READ) FILE(CUSTOMER) etc. were far worse.

b) P/D specs

Why do we need to use 'P' and 'D' specifications to start a procedure?
'P'
for procedure is great and actually the input parameters and the
return
value belong to the signature of the procedure. So why use 'D'
specifications for that?

Because? Again - this is now 15 year ancient history. If you want
to argue that the whole past should have thrown away and a new RPG
that looked just like C/Java be designed I won't agree with you -
but at least you'd have a point worth debating.

c) Full qualified names

Actually great stuff, but does not work with LIKE, LIKEDS, %size() and

%elem():

D address_t ds qualified template
D firstname 50a varying
D lastname 50a varying
D city likeds(city_t)
D street 50a varying
D city_t ds qualified template
D zip 10a varying dim(100)
D name 50a varying
D address ds likeds(address_t)

// The simple qualified name is not specified correctly.
D tCityName s like(address_t.city_t.name)

D size s 10i 0
D elem s 10i 0
/free
// The simple qualified name is not specified correctly.
size = %size(address.city.name); // error
elem = %elem(address.city.zip); // error
*inlr = *on;
/end-free

There might be good reasons for that because of the age of the RPG
compiler. But of course nobody understands that at first glance. Or
nobody
of the compiler lab uses RPG to write production code. Or the compiler

developers are too close to RPG.

There are a couple of things that have been quite tricky when I
started
with my WSDL2RPG and especially the lack of full qualified names for
%elem() and %size() is very hard.


I agree and I'm sure the team want to ultimately fix it. I'm not
sure why the compiler can't handle it.



Just my two cents.

Thomas.


--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a criminal
offence. Please delete if obtained in error and email confirmation to the sender.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.