How to Use "Like" For Field Definitions in External I/O ServiceProgram Prototypes

I'm trying to move toward External I/O service pgms. Here's the
planned approach:
1) Prototypes would be in their own source member.
2) Prototypes would get /COPY into any pgms that use them as well as
the external I/O service pgm.

I'm trying to find a way to code the parms and return values without
hard-coding. Here's where I get stuck:
1) When I do /COPY into the service pgm, the Like keyword works
because the file is in the external I/O service program.
2) The /COPY for the prototype does not work in the program because
there is no file to base the word "Like" from.

Chipper Miller wrote:[color=blue]
> I'm trying to move toward External I/O service pgms. Here's the
> planned approach:
> 1) Prototypes would be in their own source member.
> 2) Prototypes would get /COPY into any pgms that use them as well as
> the external I/O service pgm.
>
> I'm trying to find a way to code the parms and return values without
> hard-coding. Here's where I get stuck:
> 1) When I do /COPY into the service pgm, the Like keyword works
> because the file is in the external I/O service program.
> 2) The /COPY for the prototype does not work in the program because
> there is no file to base the word "Like" from.[/color]

You can make your /copy file more independent by using externally
described data structures in your /copy files.

D myfile_types e ds extname(MYFILE)
D qualified
D based(template)

D myproc pr
D idnum like(myfile_types.idnum)
D quantity like(myfile_types.quantity)

Using LIKE with external _file_ fields (vs external _DS_ fields) isn't a
good idea if you have any numeric, date, or time fields. LIKE picks up
the format (packed, zoned) of the field in that source member, which
might be different from the actual format in the external file, or in
another program. The most common case is a zoned field in a file
sometimes becoming a packed field in the program. Using an externally
described DS forces the compiler to use the same format as the actual
format in the file.

One other thing about prototypes in copy files; if you have any date or
time parameters or return values, and they aren't coming from
externally-described data structures, you should always code the DATFMT
or TIMFMT keyword in the /COPY file. Otherwise, the format depends on
the DATFMT or TIMFMT keyword in the H spec which might not be the same
for all modules using the prototypes.

About "based(template)", this is a coding convention that says "this
definition is only going to be used for LIKE and LIKEDS definitions".
Some people use BASED(dummy), or based(typedef); it doesn't matter what
you use, but it's best to always use the same name. Using BASED means
that the compiler won't allocate any storage for these based variables;
it _will_ allocate storage for the basing pointer, which is why it's a
good idea to always use the same name so you can use the same pointer
for all of these. Using the name "TEMPLATE" will make it easier to
switch over to using the TEMPLATE keyword when you get to V6R1.

On Aug 18, 6:35*pm, Barbara Morris <bmor...@ca.ibm.com> wrote:

<snip>

Thanks, Barbara!

I forgot to mention:
* In some programs, I will be adding the External I/O service pgm but
there will also an F-Spec for that file in the program. Am I correct
that the "Qualified" keyword along with the fact that the "Like" word
does not create any conflicts with the D-Spec names?
* In other words, like(myfile_types.idnum) will not be the same as
idnum for the I-Specs that were created by the Externally Described
"MyFile" from the F-Specs.

Also forgot to mention:
In some cases, there may be two external I/O service pgms for the same
file -- each logical file will also have its own service pgm. Should
I use the /IF NOT DEFINED(myfile_types) to minimize this situation?
Or simply have myfile_types_01 for logical file 1, myfile_types_02 for
logical file 2, etc?

Thanks again for all your help (both this time and in times past)!

Chipper Miller wrote:[color=blue]
>
> I forgot to mention:
> * In some programs, I will be adding the External I/O service pgm but
> there will also an F-Spec for that file in the program. Am I correct
> that the "Qualified" keyword along with the fact that the "Like" word
> does not create any conflicts with the D-Spec names?
> * In other words, like(myfile_types.idnum) will not be the same as
> idnum for the I-Specs that were created by the Externally Described
> "MyFile" from the F-Specs.[/color]

Yes, you are correct.
[color=blue]
> Also forgot to mention:
> In some cases, there may be two external I/O service pgms for the same
> file -- each logical file will also have its own service pgm. Should
> I use the /IF NOT DEFINED(myfile_types) to minimize this situation?
> Or simply have myfile_types_01 for logical file 1, myfile_types_02 for
> logical file 2, etc?
>[/color]

Would both logical files have the same name, "MYLOGICAL"? If yes, and
if they would both have identical sets of subfields, then either one of
your schemes would work. But you can't just check /IF NOT
DEFINED(myfile_types). /IF doesn't check whether an RPG variable is
defined. It only checks /DEFINE names. So you'd have to /DEFINE
MYFILE_TYPES_IS_DEFINED or something like that.

If you have multiple service programs for the exact same file, it would
probably be easiest to have a separate copy file with the filename_types
data structure, and copy it into the source file with the prototypes for
that service program.