Free format ILE RPG
Torbjorn Gortz
Free format ILE RPG ----- Sounds great! -----
In a News/400 July article were the following text:
".....IBM's Toronto language lab is readying a major round of enhancements ....."
".....a completely free-format C-spec. Going beyond the "relaxed" format of EVAL,
this feature ignores RPG's columns and lets you write code across the entire line
(not just the right half, as with EVAL). The intent of this free-format specification
is to make RPG more expressive with longer identifiers, with indention, and
without EVAL opcode clutter."
Does anyone know more about these plans? (when? how? code details...)
If you do, please send an answer to this newsgroup.
I think these enhancements sounds great.
A loot of RPG-code is out there and many RPG-programmers develop new
routines in this language. Many companies rely its business administration
on RPG-programs. To be able to switch to free-format C-spec, would
after a start period make the language more clear and quick to write.
But the syntax has to be short, clear and clean.
The programmers ability to read and quickly grasp the code is very important.
I do not agree with the writer of the article, Roger Pence, that it is too late.
If you want to read the whole article, go to:
http://www.news400.com/issues/1999/July/Pence/5634.htm
IBM ----- free format ILE RPG will make the AS/400 even stronger.
Java is too big step for many RPG-programmers today.
We need enhancements on a language we already know well.
Many programmers still develop in RPG400.
I am convinced that if the ILE RPG will get free-format C-spec,
many programmers would go over to this language.
With best regards,
Torbjorn Gortz
IT-manager
Scandinavian Cosmetics AB
Sweden
torbjor...@scanco.se
torbjor...@swipnet.se
Thomas Hauber <twh@
There are just too many programs out there for RPG to die. For years we
have been hearing that RPG is dead and/or dying, but yet development
continues on.
Now everyone raise your hands. How many of you heard within the last 3
years from an IBMer that RPG wasn't going to have any major
improvements? And now what do we hear? A major enhancement!! Do you
suppose that the java dreamers in Toronto just woke up and smelled the
coffee (or lack thereof)?
Hmmm, let me think... what other language does this sound like? Cobol
perhaps. How long have we heard that Cobol is dead? That it will be
replaced? How many companies still use Cobol? I think that RPG is
similar to Cobol in this respect, many naysayers and doom prophecies.
But no real catastrophes.
--
NOTICE TO BULK E-MAILERS:
Pursuant to US Code, Title 47, Chapter 5, Subchapter II, 227,
and all nonsolicited commercial e-mail sent to this address is
subject to a download and archival fee in the amount of $500 US.
__
Pursuant to California Code Section 17538.4
(c) Upon notification by a recipient of his or her request not
to receive any further unsolicited faxed OR ELECTRONICALLY MAILED
documents, no person or entity conducting business in this state
shall fax or cause to be faxed OR ELECTRONICALLY MAIL OR CAUSE TO BE
ELECTRONICALLY MAILED any unsolicited documents to that recipient.
(d) Any violation of subdivision (c) is an infraction punishable by
a fine of five hundred dollars ($500) for each and every transmission.
Douglas Handy
>Does anyone know more about these plans? (when? how? code details...)
>If you do, please send an answer to this newsgroup.
>
>I think these enhancements sounds great.
Me too! But let me stress that using it wil be OPTIONAL, and they
have NO plans to ever stop supporting the (semi-) fixed format syntax.
So nobody needs to panic if you don't like the idea of free format.
IBM has not said which release we can expect to see this. They have
implied it may not make the next release, but have not (to my
knowledge) made any commitments.
However, there has been some public discussion about this on another
newsgroup-like forum (actually a pair of mailing lists -- one on the
400 in general and one specific to RPG). It generated nearly 500
messages because of all the interest, so I can't quote them all here.
But here is a subset of the message where Hans Bolt, from the RPG
Development team at the Toronto Lab, let the cat out of the bag on May
11:
"Well, a month ago, I would have given the "X-Spec" 50-50 odds of
making it into our next release. Here's an update: It's now
called the "CF-Spec" or "Free-form Calculation Specification"
and it's currently working in the lab! Most of the code is
already in place in the compiler. Believe it or not, this
enhancement turned out to be rather easy to code.
The general idea is to code F in position 7, blank in position 8,
and the free-form statement in positions 9-80. Start with the
opcode and extenders, followed either by the free-form expression
(for the current expression calcs) or by the Factor 1, Factor 2.
and Result Field operands (for the current fixed-form opcodes).
Everything is free-form within pos 9-80. There are no control
level indicators or conditioning indicators - use IF instead.
There are no resulting indicators - use BIFs %FOUND, %ERROR, etc.
instead. No definition of fields on calcs - use D-Specs for that.
CF specs may be intermixed with normal C specs, but we would
expect that programmers would likely keep the two styles separate.
This doesn't mean we're not still futzing about with certain
design issues, though, so I don't want to show any substantial
example of what the RPG code looks like."
Then he asked some questions on design preferences, and a flury of
activity ensued. Including some who are vehemently opposed to the
idea. Or at least one person, anyway. (Hi Bob!)
At this point, my understanding is that Toronto has basically decided
on the syntax and semantic issues, but has not formally released the
design specs. A prototype is running in their labs, but no promise
has been made on which release we will see it.
There will most likely not be a conversion utility provided by IBM the
way they did CVTRPGSRC, leaving that instead to third-party vendors,
magazine utility authors, etc. This lets IBM concentrate their
resources on adding new features for us. IBM also anticipates DF
would be used mostly for new code, not retrofiting old code.
In addition to the general idea of the syntax mentioned above, the
discussions resulted in ability to make coding EVAL and CALLP
optional, much the way LET is optional in BASIC. There are also
dozens of new BIFs planned, some of which perform the same job as
current fixed-format opcodes. This will let you code pretty much all
the calcs in free-format, if you so choose.
HTH,
Doug
Joe
CF If %EOF : Leave : Endif
or
CF Dou %EOF(File) : Read File : If not %EOF
... (indented code here)
CF Endif : Enddo
Douglas Handy wrote in message <9g=hN6pe6wk0hA7...@4ax.com>...
Torbjorn Gortz
I however hope they decide that you do not need to write "CF"
in position 6-7. It is much better to only have to leave position 6
blank, to have an (optional) free format calculation line.
There are two reasons why it is MUCH better to have only one
blank in position 6, and no fixed code on the free format
calculation line.
---1--- When you type in new code lines, you automaticly get
the cursor in the same position as the first nonblank position
on the line above. This makes the code typing much easier.
If you have the "CF" in position 6-7, you have to type these
on every line and then press an arrow-key to get to the
right position for the code. (Or have to copy lines first.)
(There is a possibility to make a skeleton line with "CF"
but this is also extra typing and codes you have to
manage.)
---2--- When you have a group of lines which have to be
moved to the left or right, you could in SEU type for instance
RR2 on the first line in the group and RR on the last line.
This moves the group of lines 2 steps to the right.
The group of lines could be several pages of code.
This often have to be done when you code in free format,
to for instance insert an new IF + ENDIF.
If you have the "CF" in position 6-7, this code will also
be moved, so you instead have to make insert or delete
on each line.
WHY make it strange and cumbersome, when it is so
easy to make it the simple way?
Why have a limit at position 80?
It is much easier to be able to write the free format
calculation code, all the way to the end of the line.
So no programmers happens to write some code
in position 81 and above, and the compiler ignore
this code. Let the programmer decide how long
code lines he wants to write.
Paul Cunnane
a) from my (limited) understanding of how the compiler works, this would not
be at all easy to implement;
b) I really don't think it lends itself to readable code (in BASIC any more
than it would in RPG). But that's just a personal opinion. :)
____
Paul
Joe <j...@NOSPAM.com> wrote in message
news:474F1F0C6F171B0B.17F328F7...@lp.airnews.net...
Nils Kilden-Pedersen
news:474F1F0C6F171B0B.17F328F7...@lp.airnews.net...
> Cool! Next lets allow multiple statements per line. example:
> CF If %EOF : Leave : Endif
> or
> CF Dou %EOF(File) : Read File : If not %EOF
> ... (indented code here)
> CF Endif : Enddo
I hope you're kidding. Stuff like that does not make code easier to read. Look at C.
Nils
Nils Kilden-Pedersen
no-parameter-procedures from variables.
Nils
Douglas Handy
>Cool! Next lets allow multiple statements per line. example:
I'm with the others on this one. I'd prefer not to see it supported.
And I also agree with Paul's assessment that it would probably be a
non-trivial task to retrofit into a compiler designed for RPG's
syntax.
So I'm not too worried about it being added. :)
Doug
Douglas Handy
>Also, it would be nice if you could call procedures as proc() so you can distinguish
>no-parameter-procedures from variables.
I know this is already implemented in the lab due to user requests.
And in fact the CF syntax will require it if you leave off the CALLP;
if you code the CALLP the trailing () will be optional, just as it
will continue to be for the regular extended-format2 calcs.
Doug
Torbjorn Gortz
> Cool! Next lets allow multiple statements per line. example:
I think this is easy to implement in a compiler.
I base this on my own work with a simple precompiler for RPG.
But multiple statements per line will make the code harder to maintain.
So I prefer that this is not implemented.
I however would very much like to see some second form of
the IF-statement which, if the compare is true, will execute the
statement on the rest of the line. Without an END-statement.
You have this in Visual Basic, and it is very effective when you
have to repeat many similar IF-statements with only one line
of execution.
If you have to code many IF + ENDIF-lines, the code will
be hard to read.
It is enough for the compiler to se if there is an executing
statement after the the IF-statement.
But maybe some programmers prefer to have another
name of the IF-statement which can execute a statement
on the same line.
(For instance IFDO, IFEX, IFX, IFTHEN, IFTRUE, IFT)
Maybe IFX is short and enough explanatory, X for execute.
It is important that it is short because you have to have
enough place to write the executing statement.
Torbjorn Gortz
Torbjorn Gortz
> However, there has been some public discussion about this on another
> newsgroup-like forum (actually a pair of mailing lists -- one on the
> 400 in general and one specific to RPG). It generated nearly 500
> messages because of all the interest, so I can't quote them all here.
Please tell me where this newsgroup-like forum can be found.
Best regards,
Torbjorn
Douglas Handy
>Please tell me where this newsgroup-like forum can be found.
Goto www.midrange.com, and look at the links for the various "lists"
to which you can subscribe. The CF specs were first discussed last
May in the general purpose MIDRANGE-L list. There are searchable
archives of this list available from the home page, too.
But most of the traffic regarding CF was on the RPG specific list,
RPG400-L, starting in late July. Archives of the other lists are not
available on the web.
Alternatively, you can subscribe by sending an email to
MIDRANG...@midrange.com for the general list, or
RPG400...@midrange.com for the RPG list.
Highly recommended.
Doug
Pete
and pre-processing, call it RPGV.
I hate to see good old fashioned RPG get dressed in trendy new clothes
that don't suit it ;)
Personally I have no issue with fixed format and it can be irritating
messing about adjusting the text to look properly nested after altering
code. Remember that most RPGers are mainteners (sadly).
--Pete
MJS400
Tim
All the difficulties about free formatting, multiple statements per line,
multi-line statements, one line if statements, compound if statements have
all been answered in the PL/1 compiler. The RPG folks don't have learn how
to parse free-format RPG, they can just finish plagiarizing the PL/1
compiler.
PL/1 has always had free formatted lines, pointers, local procedure support
(with or without parameters), user defined functions, built-in functions,
Recursion, global variables, local variables and the list goes on
It is good that the RPG developers have finally seen the light.
Nils Kilden-Pedersen <n...@pjc-corp.com> wrote in message
news:BpnE3.643$w4.2...@news010.image.dk...
> Joe <j...@NOSPAM.com> wrote in message
> news:474F1F0C6F171B0B.17F328F7...@lp.airnews.net...
> > Cool! Next lets allow multiple statements per line. example:
Pete
Was SDA and SEU, etc. written in PL/1?
--Pete
Krokkie
like
SET fieldname(Blue Reverse) etc ...
Nils Kilden-Pedersen wrote in message ...
Pete
If you're using RPGIV (V3R2), I think it's good to rename your
indicators, especially for screen attributes.
<Code>
D ptrInd S * INZ(%ADDR(*IN) )
D DS _IND DS 99 BASED(DS_IND)
D err_FIELD1 41 41
*RI, PC
D err_FIELD2 42 42
*RI, PC
<Code/>
Peter Moore
MJS400
Scott Klement
and you can sign up for them at http://www.midrange.com
Torbjorn Gortz wrote:
> Doug,
>
> > However, there has been some public discussion about this on another
> > newsgroup-like forum (actually a pair of mailing lists -- one on the
> > 400 in general and one specific to RPG). It generated nearly 500
> > messages because of all the interest, so I can't quote them all here.
>
> Please tell me where this newsgroup-like forum can be found.
>
> Best regards,
> Torbjorn
Barbara Morris
unique set of named indicators for each file.
Barbara Morris