10 New Functions We'd Like to See in RPG IV

[Guest.Visitor]

10 New Functions We'd Like to See in RPG IV

Why couldn't we have free format declares similar to the CL form of declares. Anything could be declared. For example: DCL xxxxx *FILE or DCL C1 *CURSOR. If a cursor is declared then the compiler could determine how the SELECT opcode should be used in free format. If the SELECT opcode is used without the declared cursor then it is being used as SELECT...WHEN...ENDSL. When used with a declared cursor it would know it is an SQL statement. Get the idea.

[randrsn1@uiuc.edu]

10 New Functions We'd Like to See in RPG IV

Two things need to be added: 1. free format SQL 2. a new object type: published procedure interfaces . /copy is error prone & sucks . Java does it . potential to overload procedures . it's just like external file descriptions

[jvalance@sprynet.com]

10 New Functions We'd Like to See in RPG IV

I agree with a lot of the suggestions here, but especially the improvements to free format.[*] Definitely get rid of /free, /end-free[*] Definitely free up the rest of the fixed format specs[*] Definitely improve embedded SQL to be free format[*] Allow multiple statements on one line While we're at it, let's get rid of the requirement to start code in column 7. The original use for this was so that the card puncher could automatically put a sequence number on your cards as you keyed in your program, so that if you drop your card deck on the floor, you could rearrange the cards in the correct order. Keeping this vestige alive in free format RPG seems a bit ridiculous. I know in fixed format RPG lots of people use this area to indicate the "change request number" or some code that indicates what lines have changed for a particular maintenance request, but these "comments" can easily be put at the end of the line, not the beginning, using // syntax. I also think there's a lot to be said for procedure overloading (not sure about type-less parameters). I agree with Buck on better OPDESC support, so we can create much smarter procedures on our own. I also like the idea of keyword parameters and default values - this could make code much easier to read, especially when optional/nopass parms are involved: myProc( parm1='123': parm3='ABC': parm6='XYZ'); As with CL commands, the keywords should be optional. What I haven't seen here is requests for improvements to the IDE for developing RPG IV code. I would imagine that, if everyone participating in this discussion is enlightened enough to be pushing the limits of RPGIV, then they're probably also using CODE/400 or WDSC to write/maintain RPG. CODE/400 provided a good AS400 IDE, but it was created in a bygone era (and with OS/2 in mind), and definitely not with free format in mind. WDSC provides a great Java IDE, but the LPEX editor and RSE need to be more customized for RPG/CL/DDS development. Perhaps there should be an RPG perspective, just as there is a Java perspective, with buttons for common functions like compile, debug, etc., and easily accessible editor options, without having to dig through multiple levels of options as in the current preferences page. The improvements I'd like to see most in the IDE relate to simple, common features of almost every free format editor:[*] Get rid of 80 column limit, and the need to skip over the first 7 characters on every line.[*] Tab key should indent the source by one tab stop! I can't get this to work, even though buried within Window/Preferences there are at least 3 or 4 places where tabs can be set.[*] Press enter should add a newline at the cursor, and maintain the indent level.[*] Shift/down-arrow or Shift/up-arrow or Mouse-drag across several lines should select the entire line and allow tab to indent one tab stop, and back-tab for outdent. This is how every free format editor works, including MS Word. Currently, to do this in LPEX, you need to start with alt-L to select lines, then use F8/F7 (one space at a time), then alt-U to unselect the lines.[*] Provide an auto-format function, which would indent code automatically. This could be especially helpful to RPG coders who have never worked in any free format language. Also, add some form of intellisense to the editor:[*] For qualified data structures, if I key in the DS name followed by a dot, show me the names of the subfields and allow selection.[*] Allow an F-key that shows me the procedure names for which there are prototypes defined either in the current member or via /copy[*] etc., etc. - Basically, look at other free format editors/IDEs (Eclipse, Visual Studio, etc.) and bring the LPEX editor up to date. Along with intellisense, there should be something similar to Javadoc in RPG. I believe the most compelling reason to embrace RPGIV/ILE is the ability to create reusable code in service programs (similar to java classes). But without a way to easily document and cross reference these components, using this on a large scale can become quite a challenge. Also, while I'm mentioning WDSC, it needs a simple way to run and save SQL statements against the current connection, without going through hoops in the data perspective. Porting the Ops Navigator SQL editor into WDSC would work nicely, but bring the editor up to date - PLEASE! i.e. Token highlighting, support for mouse wheel, resizable fonts (so us old guys don't go blind prematurely), etc. It's great to see all these suggestions, but the question is - how do we get IBM to do what we want? I'm hoping Mr. Cozzi has some connections at IBM that will pay heed to what is written here. I hope we're not just writing on the walls, hoping IBM will venture down this alley and discover what we're thinking. Someone should send this entire thread to the decision makers at IBM responsible for iSeries languages and development tools.

[LarryDucie]

10 New Functions We'd Like to See in RPG IV

Peter, You can already do this - just base your template DS on a pointer. This will tell the compiler to not bother allocating storage as you'll handle this yourself. You can even call your pointer "typedef". You can base as many data structures on the typedef pointer as you wish. You don't even need to define the pointer in your program - the compiler will create it for you! You can then create your data structures based on your template structures as before. Although I agree with your sentiments (using a typedef pointer means you will still be allocating 128 bits for the pointer itself) I can certainly live with using the based keyword for a while yet. So, just add the keyword "based(typedef)" on the top line of your template DS - job done! Cheers Larry Ducie

[avrahamn@coop.co.il]

10 New Functions We'd Like to See in RPG IV

But with the introduction of procedures, we cannot build a command on a procedure, now this is really a someting we are missing.

[tdaly@sddsystems.com]

10 New Functions We'd Like to See in RPG IV

In leiu of an *ANYTYPE option on a parameter definition or complete support for OPDESC, we could borrow an idea from some PC languages. Languages such as VB have a "variant" data type which is commonly used to interface with ADOs. Variants are "tagged data types" which follow a very specific structure. While we don't have to duplicate the structure exactly we can borrow the idea and develop our own technique. On a wintel pc the variant type is always 16 bytes long, the first two bytes indicate the type of data in the last 8 bytes. (There are 6 bytes between the type indicator and the actual data, but I'm not going to go into that right now.) There are many data types supported, one of which is a pointer type. Pointers in OS/400 are 16 bytes long in contrast to 8 bytes in wintel land, so our version of a variant would have to be longer than the pc version. So let's say we make our version of variant 18 bytes long, the first 2 bytes to indicate the type of data contained in bytes 3-18. And a standard set of values to indicate the data type. You could make it a convention to pass all your procedure parms as variant type. Of course the price for the flexibility is that every procedure would have to first decode the data passed and then possibly transform it into a usable form. I'm just throwing this out there to start the conversation, I'm certainly open to any ideas or overlooked considerations. Tom D. "Better living through structured data"

---

Code

[tdaly@sddsystems.com]

10 New Functions We'd Like to See in RPG IV

There are a couple of improvements that I'd like to see but it would break backward compatibility. Maybe it's time to rename the language and thus sidestep that issue. An ideal time to do so would have been last year with the i5/Power5 launch, but I think it's time to rename the language nevertheless. As for what that name would be.... So in no particular order: The first thing is arrays. Multidimensional arrays are a must. The current method of defining arrays is clumsy, but I understand how the thing evolved. A clear method of defining and referencing arrays is needed. And if you want to get really wild and crazy, allow negative indicies. The worst thing that can happen to rpg is to continue introducing bogus C-isms. Things such as the += operation. This is hideous! Does it really kill you to type a few extra characters so we have normal algebraic expressions? A problem with C is it's obsession with terseness. I'd like to see += and its ilk eliminated. The third thing I like to see is a decent looping construct, rather than the lame stuff we have now. I had hopes with FOR but it's just a pointless rework of DO. The current syntax of: FOR index-name = start-value BY increment TO|DOWNTO limit is weak. TO|DOWNTO??? C'mon! How about that being determined by the sign of the increment? A positive sign means "TO", a negative "DOWNTO" That way you could code something like: FOR index = start TO limit BY step and cover both ascending and descending in the same construct. Much as you can in oh let's say BASIC. Since decades ago. Requiring TO or DOWNTO needlessly limits the usefulness of FOR. I see that the same idiocy has been brought foward to CL. It should be remedied there as well. A lot of enhancments have been made to data structures, and I'm glad to have them. But they've gotten a little off kilter. For example: D KEYDS DS LIKEREC(MYREC : *KEY) results in a Qualified DS. WTF? If I wanted Qualified I would have specified it. The whole world of datastructors needs to be revisited. In the example above I had intended that when I read in the data record MYREC that I would then have KEYDS loaded with the values of the keys of that record so I could then CHAIN %kds(KeyDS) to another file. But for some reason there's an implied QUALIFIED. I don't like that implication. I just think that the world of datastructors needs to be cleaned up, they've gotten a little messy. %Range and %Values, sounds good! EVALC or %MAP, either way. Definitely no hyphen. As for being a bug generator, maybe there's some way to mitigate that? I haven't done COBOL since school and that was a long time ago. But I always liked MOVE_CORRESPONDING. %ISNUMERIC would be nice... if it really worked. I don't like #8, if (A = B) code = 3. I'd lump this in with +=. User Defined Types / TYPEDEF . This would be a biggy. Tremendous even. I like the ability to have compile options specified in the H specs. I'd like to see a similar thing for DDS database files. I'm thankful for the improvements we've had! But it is time to gather up all these changes, reorganized things, and start out afresh. Well that's it for now.

[DougCMH]

10 New Functions We'd Like to See in RPG IV

Just some thoughts... Multidimensional arrays. Sounds good to me. The ability to define the index range (negative or otherwise) might be useful. Indices of, say, 1990 to 2010 might be meaningful... += etc. I have no problem with these. I use them. I think they were added because a statement like x = x + 1 isn't algebraic. Think about it: x = x + 1. Solve for x. Mathmatically, what is x? FOR statement - I totally agree! LIKEREC producing a qualified DS. I have no problem with this. If I don't want the DS to be qualified, then I use EXTNAME. That's really the only difference between LIKEREC and EXTNAME. LIKEREC is qualified, EXTNAME isn't. One thing I will say about EXTNAME though. Get rid of that "E" before "DS". You don't need it. If the DS name is also the name of the file, use EXTNAME by itself. Oh, and get rid of the "S" (use STATUS keyword) and "U" (use UDTAARA, or DTAARA(...:*AUTO)). I love the idea of EVALC, but COBOL as an ADD CORRESPONDING, too. Getting complicated, now? A working %ISNUMERIC would be nice. I'd love an %ISDATE, though. Would a TYPEDEF be necessary? Today, you could code

 D MyTemplateDS DS based(TypeDef) 

where the TypeDef pointer is never defined and always null. What do you guys think of a WITH/ENDWITH option for dealing with qualified names, like Pascal has? Too lazy?

 with A.B.C.D;  endwith; 

[tdaly@sddsystems.com]

10 New Functions We'd Like to See in RPG IV

LIKEREC producing a qualified DS. I have no problem with this. If I don't want the DS to be qualified, then I use EXTNAME. That's really the only difference between LIKEREC and EXTNAME. LIKEREC is qualified, EXTNAME isn't. I guess I stepped into it on that one! I missed the fact that *KEY was added to EXTNAME in V5R2. Some other ideas:

To get the number of fields in a format FormatName:Fields 

To get the name of a field in a format FormatName:Field(x):Name where X is the ordinal.

To get the value of a field in a format FormatName:Field(x):Value where X is the ordinal. Or FormatName:Field(FieldName):Value . 

This could be broadened to "structure name" instead of just a FormatName. What I'm thinking about is the fact that the majority of the code in let's say a subfile program is the same. The alogorithm does not change. What does change is the particulars... the fields to load from the db to the dspf... the keylists... etc. Things like DspfName:Field(a):Value = DBfmtName:Field(b):Value would lead to a more data driven way of coding. In the above, "A" and "B" could be parms loaded from a file specifying the particulars to a generic SFL program. Want to create a new SFL pgm? Just pass the particulars to the generic program. Tom D.

[Guest.Visitor]

10 New Functions We'd Like to See in RPG IV

I offered this on a similar thread over at 'the other' iSeries news site. I'm not interested in selling anything here so please don't get the wrong idea. If any of the posters here is interested, we'd be willing to let you use our RIO tool to convert your RPG to C++. This wouldn't create magical new interfaces for you, but would address many of the RPG limitations you may currently be frustrated with. Of course it wouldn't hurt to have some C or C++ background... Chris Wilson ASC

[gotto@islandpacific.com]

10 New Functions We'd Like to See in RPG IV

This tool also converts to Java, I believe. It is from ASC (www.asc-iseries.com). I haven't used the tool; just know it exists.

[peterklevy]

10 New Functions We'd Like to See in RPG IV

Actually that's exactly what I do to get around that problem. (I should've mentioned it in my original post.) It's more of a kludge than an actual solution because as you've said, even though you don't declare the "non-existant" pointer the compiler declares it for you. I agree that it's not much of a waste in storage, but I get tired of having to use kludges in RPG when languages like "C" seem so beautiful in their design. A TYPEDEF keyword could be used for so much more than just data structures.

[MCWebsite.Staff]

10 New Functions We'd Like to See in RPG IV

** This thread discusses the article: 10 New Functions We'd Like to See in RPG IV **
This is a discussion about 10 New Functions We'd Like to See in RPG IV.

Click here for the article.

[avrahamn@coop.co.il]

10 New Functions We'd Like to See in RPG IV

** This thread discusses the article: 10 New Functions We'd Like to See in RPG IV **
"Today, the only reason you use compile-time data is because there's no easy way to initialize an array's elements on the Definition specification". I do Not agree with that. I think that we ned both: the ability to initialize arrays on the definition statements, and we still need to define compile time arrays when there is a big array an it would look ugly and hard to read if initialized only on the definition INZ('xx').

[Guest.Visitor]

10 New Functions We'd Like to See in RPG IV

** This thread discusses the article: 10 New Functions We'd Like to See in RPG IV **
Just my opinion but a modern language should have FULL support for null values: not only on database fields (and the same support in SQLRPGLE and RPGLE!!!). Marco