RE: Where's the RPG code in the IFS example? WAS: Having problems ac cessing IFS from RPGIV

Booth, 
Again, my clarity of speech leaves something to be desired...
As a programmer in any language, I can choose to use the same style forever
or change styles when the mood strikes me.  

In "old" RPG with the cycle and left-hand indicators, we wrote everything
inline.  We used subroutines only if we had more than 10 lines of code that
were repeated more than twice in the program.  We created hundreds of
scratch work files for holding temporary results and ignored good database
design precepts.  And it worked (mostly.)  We got a lot of work done despite
the "theoretical" shortcomings of our database and our programs.  The
problems we had increased in severity as our applications moved to the
interactive world - programs got heavily patched and became fragile as a
result.  It took longer and longer to make changes and we started to think
about doing things "the right way" - proper database design, modular code
and so on.  This was a partial success using RPG III, but we still used
monolithic programming techniques that resulted in complex, difficult to
understand code.  Familiar in "look and feel," but complex and hard to work
with.

The "new" RPG tends toward no indicators, no cycle, rare use of factor 1 -
sparse left-hand side!  It looks odd to a geezer like me, that's for sure.
But there are several things that make RPG IV crucial to modern code
development:
1) Reasonable sized variable names using mixed case
2) Fewer restrictions on the maximum sizes of variables/arrays
3) Local storage (procedures)

Remember when RPG III came out with IF/END and some folks wrote code with 15
END statements one after the other?  How hideous and weird that looked?  As
we got over the first blush of having "structured opcodes" and started
looking at how to structure our ideas instead of the code, it gradually got
better.  Both the way we coded AND the way it looked.

RPG IV will be no different.  Right now, programmers are going nuts
exploring all this new stuff.  The result is code that looks funny to my old
eyes.  As our minds expand to adopt the new ideas properly, we'll learn to
write better-looking code, and it probably won't be quite so foreign
looking.  I think that this is a normal progression, and the strangeness
will soon wear off.

In the interim, it is actually quite easy to write RPG IV code that looks
familiar to RPG III's style.  Instead of writing  things in the "function"
style, use a more traditional "call" style, so that eval
result=function(parm1:parm2:parm3)   becomes callp
function(parm1:parm2:parm3:result).  The definitions will continue to look
weird until we get used to the D specs, but you can hide those definitions
in a /COPY member so that your code looks something like this:
/copy funcdefn
...
callp function(...)

Which isn't so far from
/copy subrdefn
...
movel xxx parm1
exsr subroutine

As for the specific examples of the C function calls, they can be found in
the Unix-type API manual.  There's some initial confusion trying to mentally
convert the C data types into RPG data types; Barbara Morris posted this
table a while back:

Even though int * is a pointer, it can be thought of as an int
passed by reference, so it's better to prototype it in RPG as
an int passed by reference.  My own rules for converting C
prototypes to RPG prototypes are as follows:

      C         |       RPG
----------------|-------------------------------------------
  int, long     |    10i 0 value
  unsigned int  |    10u 0 value
  double        |     8f   value
  int *         |    10i 0
  unsigned *    |    10u 0
  double *      |     8F
  char *        |      *   value options(*string)
  void *        |      *   value
                | OR       LIKE(someStructure)
  XXX           |          value LIKE(XXX)
  XXX *         |          LIKE(XXX)
  ... (ellipsis)| figure out what the ... stands for
                | and make one or more prototypes to
                | match the various combinations, possibly
                | with OPTIONS(*NOPASS) on some parms

Where XXX is some struct/union, defined in RPG as a data structure.

This part is for those advanced folks who know C and are creating
RPG prototypes for homegrown C functions (i.e. not part of the C
runtime):
  Also, watch out for C's widening rules.  Even though
  short = 5I 0, when it comes to passing parameters by value,
  short=10i 0 and char=10u 0.  These differences don't always
  cause a problem since the use of registers to pass parameters
  can cause these differences to be hidden.  Luckily, the C
  runtime rarely if ever has short or even char parameters
  passed by value.  Unfortunately, C doesn't ALWAYS widen - it
  depends on the absense of a #pragma nowiden.
  (We have some help for this widening problem coming in a
  future release of RPG)


Buck Calabro
Aptis; Albany, NY

> -----Original Message-----
> From: boothm@earth.Goddard.edu 
> Sent: Friday, January 14, 2000 12:20 AM
> To:   RPG400-L@midrange.com
> Subject:      Re: Where's the RPG code in the IFS example? WAS: Having
> problems ac cessing IFS from RPGIV
> 
> Buck, I understand what you are saying.  I even agree with it.  The issues
> 
> are this though, imho.  The laborious and old RPG code with the left-side 
> indicators is RPG.  RPG programmers might not like the code but they 
> understand it and if they don't,  they know where to look it up.  RPG 
> professionals can be expected to deal with it.  The quasi-C++ code though 
> could show up in any RPG shop any day and most all of the RPG programmers 
> I know would not know what is happening, where to look it up, or even who 
> to ask for help.  I am not denying that this new C++ dialect  is valid RPG
> 
> code.  What I  am suggesting is that Toronto is not-so-slowly walking RPG 
> away from the RPG programmers out there.  I think the pursuit of the C++ 
> programming standard is really wrong because the ones that like and 
> understand C++ are going to code in C++;  they'll never be applying for 
> jobs in AS/400 shops.
> 
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---