× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Taking this to its logical conclusion, why not change the RPG compiler so that it accepts all "C" syntax? Oh, we already have that, it's called the "C" compiler!

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Henrik Rützou
Sent: Friday, October 11, 2013 8:36 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Free format H, F, D and P specs

Scott, Jon and Barbara and others,

As always on this forum a little feather may become a big issue. However,
it is a little important to understand why IBM doesn’t use {[]} in RPGLE
code and I think this issue has been covered now.

For JAVA and C programmers this isn’t normally an issue since most source
files are in ASCII and whatever codepage is used {[]} falls within
x’00-x’7F’ that is shared in all ASCII and even UTF-8. On IBM I the C
source files reside in EBCDIC files and there will be problems if the CCSID
of the system, the job, the source file and the tools you maintain your
source code with doesn’t correspond or does correct translations.

In Europe we have lived with these problems for years starting back when
thirds party printers was attached to System/3 and during the early days of
the PC and all these conversations has cost billions of USD to fix in form
of redevelopment of drives etc. for local character support. In US you may
not have regarded this as a big problem because (as Vernon stated earlier)
you lived quite happily without them since all files by default was in
CCSID 1252, 819 and 37 that all corresponds.

I can only come up with two solutions; one is as you stated to code source
in Unicode (probably a big change to the compiler) another is to make the
compiler source file CCSID aware by a parameter.

The compiler should then do a pre-loop through the source file and change
any special characters only within instructions to the expected EBCDIC hex
value (probably in CCSID 37).

select;

when constantChar = *on; // do nothing

when ccsIdAware = *off; // do nothing

when char = u’0042’; // handle floating ’$’ in code instruction

char = x’5B’;

when char = u’007D’; // handle floating ‘}’ in code instruction

char = x’D0’;

etc. etc. …

This can be done without affecting backward compatibility and solve the
problem with existing field names that may contain $# (that in Danish must
be manually converted to ÅØ) and open up for floating single character
instructions like {[]} while still defining/passing constants unchanged in
the local CCSID.

If $myfield = ‘$’; // (in Danish)

Will pass the first $ as x’5B’ and the second $ constant as x’67’ instead
of now where we have to change the RPGLE CCSID 277 source code to

If ÅmyField = ‘$’;

That will pass the Å as x’5B’ and the $ as x’67’.

And exactly the same can be done for the C compiler because it probably
does it already!

I don’t think that the ‘??<’ and ‘??>’ syntax is implemented all over in
the base C compiler code. It is probably and more likely implemented as a
pre-compiler step replacing the syntax with a SBCS binary value the
compiler recognize.

And if a C IBM I workaround implemented as (*A)

if (my condition) ??<

some code

??> else

??<

other code

??>

Can be converted to the C compiler as (*B)

if (my condition) {

some code

} else {

other code

}

It shouldn’t be hard to convert the same in RPGLE to (*C)

if (my condition);

some code

else;

other code

endif;

Since it is possible to convert from *A to *B, it is of course also
possible to convert from *A to *C or *B to *C and if the purpose of making
RPGLE as close to common programming standards why not use *B as the common
way and let rather simple string handling technology in the compiler do the
job?

If the purpose with the syntax changes to RPGLE is to attract JAVA and C
programmers why not make the syntax changes as close to what they already
know and feel comfortable with? Technology changes at the speed of light,
but people’s general stubbornness to follow new path doesn’t change
overnight – that goes not only for old timers but also for young people
fresh from university (it is general human behavior) – we off all in the
RPG community should now that!

{[]} is character components that are basic syntax in all ASCII based
programming languages; it is also vital components in JSON that eventually
IMO will supersede XML in many areas over the coming years. Hanging into
not supporting these characters in code is like hanging into SNA as a
communication platform.

RPGLE will in a common market sense never become a superior main stream
language, but it could coexist with the myriad of other technologies that
today exists (ruby with nails etc. (Danish joke))– “refreshers” has however
to come up to speed in applying “common programming practice” and not dwell
with the shortcomings or other barriers the EBCDIC platform presents.

Where there is a will – there is a way!


On Fri, Oct 11, 2013 at 8:17 AM, <thomas.raddatz@xxxxxx> wrote:


Very good reply. Your suggestion of "dcl-proc" is absolutely clean and
straightforward.

Thomas.

rpg400-l-bounces@xxxxxxxxxxxx schrieb am 10.10.2013 20:07:35:

Von: mlavinder@xxxxxxxxxxxxxxxxxxx
An: rpg400-l@xxxxxxxxxxxx,
Datum: 10.10.2013 20:09
Betreff: Re: Free format H, F, D and P specs
Gesendet von: rpg400-l-bounces@xxxxxxxxxxxx

On 10/7/2013 11:47 AM, Scott Klement wrote:
IBM has announced support for free format in the H, F, D and P specs
this morning. Check it out
https://ibm.biz/BdDMwB


I don't really get the back and forth about brackets C-like syntax.
Coming from a .NET/Java background and then learning RPG, lack of curly
brackets and the use of colons never bothered me. I don't feel that RPG

needs to be C-like. People are obviously free to feel that would help,
but as a young guy than learned RPG in the last 10 years, it wouldn't
have mattered to me.

Like .NET / Java programmers Jon mentioned, the thing that BUGGED me to
death was having to break out of a free form grove every time I wanted
to declare a procedure. Even with my object-oriented background, I
initially resisted procedures and used sub-routines just to keep the
free-form flowing (not the brightest decision). Being able to do
procedures without leaving free is a huge step forward, without
question. What is being added is very, very positive and I am happy
about it.

B U T . . .

The issue I have with the free-form procedure definition isn't the lack
of brackets but its lack of consistency RPG itself. I could let it
slide when it was fixed, but I have a much a harder time doing that now.

I know WHY it looks the way it does (to be compiler friendly), but that
doesn't make it less ugly. I am perfectly fine with dcl-proc...end-proc
and I don't feel any overwhelming need for curly brackets. I do think
though that in lieu of dcl-pi and end-pi you should be able to use open
and closing parenthesis and then separate the parameter definitions by
colons.

That just makes sense. I can't really think of a language where the
procedure definition is radically different from the procedure call.

To me, this is absolutely how the procedure definition should look. At
least give the option to do it this way:

dcl-proc transform(
*n varchar(50) :
name varchar(10) const options(*trim) :
);

return '*** ' + name + ' ***';
end-proc;

// the call
transform(somvar:'My Name');

See the consistency? Maybe one might argue that my suggestion is
preference, but uniformity between the procedure definition and the
procedure call is pretty much a standard EVERYWHERE. So, you'll have to

excuse me I disagree that this is a "preference". The fact that you
declare a procedure one way and then call it another WILL absolutely,
without question, bug young programmers. Count on it.

I am not nitpicking or swearing a boycott. I will use the free-form
procedure definition the way it is, but hopefully people (specifically,
IBM people) will see and understand the point I am making here. I am no

compiler expert, but I have a hard time seeing why the above would be SO

hard to implement. That's probably due to ignorance, but I can say the
syntax isn't radical. It simply follows the pattern that already
exists.

That all said, happy to see this finally happen. The mini-rant above
isn't a deal breaker. Far more happy about this than frustrated, but
had to get this out there.

Go easy on me. :)



--
This is the RPG programming on the IBM i (AS/400 and 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.



--
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.
--
This is the RPG programming on the IBM i (AS/400 and 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.





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.