×

Good News Everybody!

The new search engine is LIVE!

Please report any problems to david (at) midrange.com.




Hi James,

One of my customers manages hospitals, and they have the same problem -
minor differences between hospitals that used to require separate programs.
What we came up with was a data area that contained all kinds of information
that programs could test to determine how to run, e.g. a default tape drive
name, a hospital id, etc.

In a given program if the hospital id is xyz, it would do one thing; if it's
abc it does another.

This has the advantage that you do not have to have multiple compiled
versions -- a single version does the job.

hth,
Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax



----- Original Message -----
From: "James Rich" <james@eaerich.com>
To: <rpg400-l@midrange.com>
Sent: Tuesday, August 14, 2001 9:56 AM
Subject: RE: if defined syntax in sql rpg?


> On Tue, 14 Aug 2001, Buck Calabro wrote:
>
> > >CRTSQLRPGI does not have a DEFINE keyword.
> > >How can I tell the preprocessor to define BMP
> > >when using CRTSQLRPGI?
> >
> > It's a pain, isn't it?  The precompiler is simply too primitive to
support
> > all the things that the RPG compiler can do.  Don't blame Toronto; the
> > precompiler is apparently owned by somebody else (the database folks?)
> > Enough griping...
>
> So you mean I'm not just missing some compiler key word?  Is there some
> reason the regular RPG preprocessor can't be run before the SQL
> preprocessor - or the SQL preprocessor be taught about preprocessor
> macros?!?!?!?!
>
> > David Morris made a suggestion some time ago that I am just starting to
> > implement (as my code becomes more sophisticated <cough>.)  Isolate all
the
> > SQL stuff in a separate service program.  Make it so generic that you
don't
> > need precompiler/compiler directives, etc.  Bind that service program to
> > your mainline (is there a better name for "the program that uses the
> > services of a service program?) and then the RPG-only mainline can use
all
> > the tools available without being hampered by the SQL precompiler.
>
> The problem is that I need to chose between two different SQL statements.
> The idea here is that our code should be portable across different
> customers.  I've had it with our shop keeping a unique copy of the same
> program for every customer's little unique quirk of their database.  I
> want one copy only that is portable to all our customers.  One of our
> customers has a numeric field in their customer master file that is alpha
> in our other customers' customer master file.  We have a customer lookup
> written in SQL that selects on this field.  I need different select
> statements depending on whose machine I am compiling on.  So I have:
>
> C/if defined(USE_NUM_COLOC)
>
> <use numeric comparison in select>
>
> C/else
>
> <use alpha comparison in select>
>
> C/endif
>
> Other than that little select statement the rest of the program is
> identical to all our other customers' versions.  I don't want another copy
> laying around that I have to maintain.  But how can I tell the
> preprocessor to define USE_NUM_COLOC?  Or is there another way to
> accomplish this without preprocessor variables?
>
> James Rich
> james@eaerich.com
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.