RE: Prototyped Procedures -- RPG400-L

Obviously you can use 'N' or '*', etc... and yes an RPG programmer
"should" know what those are. However, how many times have I seen
articles or discussions regarding the differences between 'I' and 'B'
and should it be 2B or 4B or 5I or 10I. I do find an advantage to
like(int) or like(pointer), they are easier for me to read. Isn't that
the goal of many of the newer RPG enhancements, there is no "need" for
free format, fixed works just fine, however free is much easier to read
(at least for me). The indicators for the various opcodes work fine
also, but I much prefer to use the new bifs, according to your logic,
since they do the same thing there is no reason to use the bifs,
especially since %eof(FILENAME) is much longer than *IN90, and any RPG
programmer "should" know what that means.

I also use Like and LikeDS to define new data types, though ideally I
would like to have a keyword that specifically indicated that a field or
data structure was only being used as a definition. This could prevent
the data type definitions from accidently being used, and prevent the
space for them from being wasted. Though in most cases the waste of
space is negligible, and if you are really worried about it the based
trick will prevent even that. What I don't like about the based trick is
that it doesn't tell me if the variable is a data type definition, or if
it is actually going to be used as a based variable. Similarly without
some kind of "standard", which will vary from shop to shop, or comments
in the code, and how many people put as many of those in as they should,
there is no way to tell the programmer that "addressDS" or "address_T"
or "address*" is a data type not an actual variable. 

As for specifying the length of a variable, I was only suggesting it
for the compiler defined types. Since it would be extremely annoying to
have only some of the basic data types available from built in Like
definitions. It would be a lot like the current issues where for some
things you must mix free and fixed format code. (I will not comment on
whether or not you need to do many of those things.) I don't see any
reason for user defined data types to be able to have a length defined,
though I am sure that someone will come up with one.

Joe Lee

>>> rpg400-l@xxxxxxxxxxxxxxxx 02/03/2005 13:52:20 >>>


> I do that also, though what I'd really like is for the basic
"types",
> such as Indicator/Boolean, Pointer, Int, LongInt, etc... to be
included
> somehow in the compiler, so that I don't have to /COPY them into
every
> program.

They are.  Indicator is called 'N', Pointer is '*', Int is 'I'... 
That's 
the way RPG works, it uses a single character to represent the type.

I don't feel that you gain anything at all by typing the following:

      D myVar           s                   like(int)

instead of the following:

      D myVar           s              10I 0

You're really saying the exact same thing. An RPG programmer knows (or

SHOULD) what "10I 0" means. He reads the line of text as "10 digit 
integer". You explicitly using the word "int" doesn't really add
anything 
to it... in either case he knows it's an integer.  The programmer is 
reading the same thing, it's just a slightly different way of saying
it.

You know what I mean?  Six of one, half a dozen of the other.

On the other hand, you can use likeds() and like() to create your OWN
data 
types. Instead of just assigning "english" names to RPG's data
types...

For example, your business may have a standard for how an address is 
defined. In the USA, you might have two lines that represent the street

address, then a city name, state abbreviation and zip code.

So, you might define that in a /COPY file like this:

      D Address_T       ds                  qualified
      D                                     based(TEMPLATE)
      D   Line1                       40A
      D   Line2                       40A
      D   City                        13A
      D   State                        2A
      D   ZipCode                      9A

When you want to use it, you'd create your own copy like this:

      D myAddr          ds                  likeds(Address_T)

That's the same way that you'd use a typedef in C.  In C you'd have 
something like the following:

      struct _Address {
         char line1[41];
         char line2[41];
         char city[14];
         char state[3];
         char zipcode[10];
      };
      typedef struct _Address Address_T;

(the lengths are one byte longer to save space for a x'00' at the end)
When you wanted to use it, you'd code:

      Address_T myAddr;

So, it's not really that different from what you can do in RPG.

> Packed, zoned, and character might be problematic, but maybe
> they could be handled with something like: like(packed:30:9), or
> like(char:32), or even like(varchar:1024) for a varying length
character
> field.

For what you're trying to do (make English names for RPG data types)
your 
idea of specifying a length makes sense -- but, again, if you were
allowed 
to do that, it'd be the "six of one, half dozen of the other" thing
again. 
Whether you code "32A" instead of like(char:32) doesn't really buy you

anything except a program that looks slightly more like the English 
language.

On the other hand, if I were writing a service program, and that
program 
accepted parameters of a fixed type... maybe Address, as in the
previous 
example...  I wouldn't WANT you to be able to specify a length. I would

want your address to exactly match the one in the service program so
that 
they'd be compatible with one another.

So, I put my ADDRESS_T data structure in a /copy member.  You code 
LIKEDS(Address_T) to make your own copy of it... pass it as a parameter
to 
a procedure in my srvpgm (the prototype would also specify LIKEDS, and

would also be in the /copy member) and then we'd be working with the
same 
thing.

-- 
This is the RPG programming on the AS400 / 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.