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

[gotto@islandpacific.com]

We have the same issue (mentioned in another thread as well). We have to back support prior releases as well. To eliminate the /free stuff and /exec SQL would require the compiler to "read our minds". How would it know the difference between a fixed-format syntax error and a free format statement? Where there's a will, there's a way but this is a dilemma when given too much free-dom. Related to the format name being allowed to be the same as the table name; what about allowing multiple files with the same name being defined and provide a keyword requirement to make them unique. This would eliminate the need for "dummy" files with overrides. Wouldn't that be nice!?

[C Bougher]

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

The worst thing that can happen to rpg is to continue introducing reserved words. Lets make this eval corresponding an extension to eval or a bif. The best thing to do for rpg would be to make it completely free-form (f, d and p specs but not i and o specs) and allow files to be defined local to procedures. I like the proposed enhancements to conditional statements but it should follow this form. if(letter = 'A'){ pos = 1; lc = 'a'; }elseif(letter = 'B'){ pos = 2; lc = 'b'; } where the {} would be optional if there is only one line of code to execute and the parens are required. Chris.

[buck.calabro@commsoft.net]

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!!!). Hear, hear! The current NULL support is weak, at best. I would dearly love to see full NULL support. --buck

[buck.calabro@commsoft.net]

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

I don't see full OPDESC support in the list. For me, this is number 2, right after full NULL support. If we had full OPDESC support we could make our own BIFs to do practically every one of the chores on the list (excepting core language issues like the semicolon.) --buck

[costcopaul]

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

Null support needs to be improved. For example recently I wrote a procedure to return the save date of an object. Without null support I cannot return a null date if the object has never been saved. I had to resort to using *LOVAL (01-01-0001) and a boolean indicator indicating that no date existed.

[costcopaul]

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

Agree. If eval-corr is introduced does that mean that evalr will be discontinued and eval-r introduced? We are now used to *not* using the hypen. IBM needs to keep it that way.

[WoofDog]

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

Quote:The worst thing that can happen to rpg is to continue introducing reserved words. Lets make this eval corresponding an extension to eval or a bif. I absolutely aggree with that. But I wouldn't choose eval(c) like you propose, but rather a bif like %Map. In free RPG you don't have to specify the Eval opcode (it is assumed there on value assignments). Any opcode extention eliminates that possibility. DS1 = %Map(DS2); And I'd like to be able to specify Qualified on a file definition instead of Prefix. This would then allow me to map fields to/from a record format as well. DS2 = %Map(RF1); // Record format fields to DS subfields mapping RF1 = %Map(RF2); // Map all fields in two record format

[Guest.Visitor]

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

Dynamic Edit Code function: (EditC) Edit Code must be hard coded in RPG: %EditC(numvar :'3'); But API supports dynamic (variable) edit codes.New opcode should have variable edit code value as parameter: %EditC(numvar :edtcode) %Char function without leading zeros suppression: IMO, %Char shouldn't suppress leading zeros in the first place without specifing it. New opcode should have an optional parameter to suppress leading zeros: %Char(numvar [:Z]) Ex: var=123 (7p0); %Char(var); should result: "0000123" %Char(var :Z); should result: "123". Source file record lenght more than 80 characters: This is rediculous in the 21st century to be limited to 80 columns source line of the old punch card format. Bring this up to 128 or best 256 characters. Array definition in DDS:(I know this is a dead wish) In DDS we can specify +n or -n to increase/decrease length of a reference variable. What about *n to specify multiple elements that we can easily declare as array in RPG (see code below)

---

Code

[OzzieH]

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

the ability to do this: eval Value = SomeProcedure(Cust#=: 1084399, Part#=: 'ABC123-989') There's a delimiter issue to be resolved, but this provide for self-documenting code and the ability to specify the parms in any order regardless of how the caller has them definied.

[TCC]

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

By allowing this only on qualified data structures is good. I suspect (and hope) a compiler error will be issued if the qualified keyword on the data structure is removed. If one of the fields that is being implicitly moved is renamed though, the move will never happen and thus this statement has been considered a bug breeder in the COBOL world since Nixon was president. If you have %RANGE and %VALUES then why not add conditioned names ( 88 Level support) like COBOL has. The %ISXXXX are COBOL 8X enhancements and would be nice but with %RANGE and %VALUES added you can pretty much ‘roll your own’. On array initialization, if the inz keyword was pushed over to the left then the definition would appear much more clear.

[John Polucci]

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

More I would to see BIFs for text alignment to a printer file, display file or HTML CGI field like MS Word): D Title S 80A D Header1 S 80A D Header2 S 80A D String180 S 180A Title=%Center(Title) If you are outputting to print file, display file or CGI HTML. Center will center the output. If we change the report from 132 to 98, %Center will still keep the Title automatically centered. %Center can also be embedded: String180=%Center(Title) String180 received the contents of Title and center the contents. %Left_Align = Align the string or groups of strings to the left most position.(Like MS Word). %Right_Align Align the string or group of strings to the right most most position(Like MS Word). %Justified(Like MS Word Justified). Will justify a group of string across a page(Like MS Word) It is obvious to see as the bean counters play with reports,display files or HTML , these BIFs will automatcally change the positoning to the appropriate output. %parse = Will parse out a string in parsed format and place the contents into the appropriate alpah fields. This BIF is long overdue! 3333*4555*77788 %parse = string('*':Field1:Feild2:Field3) Field1=333 Field2=4555 Field3=7788 Let's challenge IBM(I can dream can't I?) Develop a BIF the is like MS Word Format: Field1 = %Font(Times New Roman:12:Bold) Field1 will have the font like MS Word document Times New Roman Size of 12 which is bold.

[DougCMH]

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

1) EVALC would be cool. 2) I like the idea of named parameters. 3) %RANGE and %VALUES works too. How about %LIKE? This would work like the SQL LIKE. And maybe a second version for regular expressions. 4) Dump /free and /end-free. If there's something in column 6, it is fixed format. Otherwise, it is free format. Simple. 5) Dump the P-Spec. Use begproc and endproc. 6) Remove the requirement that internally defined procedures (those in the same module where they are being called) must be prototyped. Let the compiler use the interfaces as the prototypes. (This is me being lazy). 7) I see problems with typeless parameters. How does the procedure tell what type the parameter is? I think procedure overloading would be the better way to go. 8) Free format SQL, please. 9) Let me assign the results of %scan, %check, %checkr etc, to a numeric array. If the SCAN opcode can do it, why not %scan? 10) Make valid: %dec(%len(variable):%decpos(variable)). 11) %DAYOFWEEK(MyDate). %DAYOFWEEK(MyDate:*iso). Like SQL. 12) %subdt(MyDate:*JULDAY) 13) Multidimensional arrays. How about dynamic arrays? 14) A version of %STR that uses a length parm instead of a null terminator. 15) I agree. Conditional names like COBOL's 88 levels. I'm just rambling now.

[John Polucci]

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

CRTBIF=Create BIF command. Why not? We have had the CRTCMD command for year to create unique operating system commands specific to an installation. Like CRTCMD, CRTBIF would have certain guidelines and procedures you would have to go through the BIF itself. May be home grown BIFS embedded into RPG would require a prefix of say ! instead of % now used. In creating a command we have a Controlling CL that need to be called. In the CRTBIF command we need to have a sub procedure in module. Instead of everybody knocking down IBM's door with their "own pet" BIF requests, we could build our own BIFs! Create a BIF called Parse which will parse out values from a character string: string = !parse('*': Field1:Field2) Field1 and Field2 will receive a data that has a delimiter of '*'. We use an ! instead of a % to distinguish home grown BIF from system defined BIFs. You may say we already have that capability right now by building our own sub procedures in our own service programs; that's true, but what IBM needs to do is give us a new object: *BIF. We could then use the DSPOJBD command to gives us *BIF information. In a sense, we could create a smaller more manageable unit than the module-the BIF! The *BIF object could be treated like all other objects with security management rights.

[Guest.Visitor]

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

10. Inline Optimization for Procedures Sounds good, but this would require re-compiles if any functions were changed. How would this work? Optimize by copying all in, or just some?

[Guest.Visitor]

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

I have to agree with gpiotto44. The Move op code covers so many situations. I realize that in free format this would not be purist in programming, but it sure does cover a lot of situations that would be quite cumbersome otherwise.