Re: Using API's ?

David,

     I certainly have no problem with people using the files in
QSYSINC library.  I was offering an alternative viewpoint, since
theres a lot you can't do with the QSYSINC stuff, such as making
the structures based on a pointer, or using more readable names
for the structures and the elements inside them.

What I got in response to this was "DONT EVEN THINK ABOUT IT" from
Eric N. Wilson, who apparently feels that using my own headers
is a "bad" or "unsafe" practice, and I disagree with this.

Similarly, I worked with someone once who told me not to use subfiles,
he said that they were dangerous, and that you should instead use
arrays.   The logic was that at some point, IBM may stop supporting
subfiles, or we may migrate to a system that can't do subfiles, but
there would ALWAYS be arrays.

My response to that was simply that IBM has always maintained support
for things for backwards compatability.  And I just can't see us
migrating from an AS/400 to another machine that supports RPG, but
doesn't support subfiles.   What were we going to do?  Convert back
to a System/36?!  If we did, subfiles would hardly be our biggest
problem.  I told him if he was worried about it, we should port
everything over to C  (this was before Java existed, so C was the
most portable choice)

At any rate, if you like QSYSINC, great -- use it.  All I'm saying
is that if you don't, making your own isn't a bad idea.



"David Morris" <dmorris@plumcreek.com> wrote:
> Scott,
>
> I think using qsysinc is something you do if you are interested in
> following "best practices".  For a good description of why this is
> considered best practices look in the system api programming
> manual.  It doesn't mean you have to do it, it is just best.  If I
>  were
> developing software for internal use I might not take the extra few
> minutes, but I think overall the use of these structures saves time.
> For an idea of what can, and has changed, scan qsysinc for the
> value *$A.  You will see hundreds of changes have been made
> over the years.  In most cases new formats or fields have been
> added so as to not affect existing programs.  That is not always
> the case.
>
> I do wish that IBM offered more flexibility in their design.  For
>  example
> they could support versioning that was smarter than the current
> format implementation.  They could also allow you to use the
>  structures
> without allocating storage and offer support for variable size data.
>
> David Morris
>
>
> >>> "Scott Klement" <infosys@klements.com> 09/09/99 04:19PM >>>
> Eric,
>       If IBM changed the parameters, or the layout of a data struct,
> programs would stop working when you upgraded to the new release.
> Its true that if you had used QSYSINC, its POSSIBLE that all you'd
> have to do is recompile the program to make it work.  But not really
> CERTAIN...
>
> However:
>       1) You can't use header files in CL programs, so any CL progra
>           using an API would need to be changed anyway.
>       2) There aren't header files for the Unix-type APIs, so if the
>           changed these, you'd have a problem anyway.
>       3) In most of the APIs IBM uses a "format" code and a data
>           structure so they can change the API without screwing up
>           backwards compatability.
>
> I've got lots of programs that survived the conversion from V3R1 to
> V3R2 that didn't use QSYSINC.
>
> So, I guess I'm wondering why you're making this statement?   Did it
> really happen to you?  If so, I'd be very interested in the specific
> WHAT did they change, and in WHICH API?!
>
>
>
>
> "Eric N. Wilson" <doulos1@home.com> wrote:
> > I have learned my lesson about creating my own headers for API's,
> >  will
> > give you a hint "DON'T EVEN THINK ABOUT IT". Early on in the
> >  development of
> > APIs on the AS/400 (V3R1???) IBM had the fields to a certain API
> >  defined one
> > way then on the next release certain very important fields changed
> >  their
> > lengths/types. Now I know that that is not to ever happen again bu
> >  just to
> > be safe I will continue to ?COPY QSysInc/QRPGLESRC,xxxxx just safe
> >  all
> > around.
+---
| 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
+---