QAD 101

[Chris Kelleher]

Folks,

Well, I am on my first ever MFG/PRO programming assignment. So
naturally

my first set of questions center around the setup of the
development environment. Here is what I have inherited:

/qad/qad85f/us (english)
/qad/qad85f/fr (french)

Both of the above have subdirectories for src, xsource, xrc and an r-code
subdirectory for each of the first two letters that program names begin
with.

When a src/program.p needs to be modified, it is saved as
xsource/xxprogram.p. However, when a src/include.i needs to be modified, it
is saved as src/xxinclude.i.

Any new or modified xsource/program.p is compiled with save into
xx/program.r.

/qad/qad85f/custom is not used at all and is totally empty.

Now, here are some of the problems that I have encountered with the above
scheme:

One of the very first programs that I had to modify was gpcmmt01.p -
Transaction Comments. Users were complaining because the original use of
SET TEXT (cmt_cmmt) was "zapping CRs" and wrecking comments that were
formatted to look more like (character) forms that they set up and copied
from Master Comments. So, I replaced it with a Progress Editor widget with
cut/paste, etc.

I could not save the modified program as xsource/xxgpcmmt01.p because I
would have had to (in turn) modify each and every calling program such that
their gprun.i or gprun1.i (etc) ran xxgpcmmt01.p instead of gpcmmt01.p.
Here is where I started to question this supposedly "QAD standard" (of
sticking "xx" in front of the original program names). Would it not be less
convoluted to use that /qad/qad85f/custom directory for all (as name
suggests) customized programs - which would be in PROPATH ahead of other
standard /qad/qad85f directories.

This "xx" scheme also causes the following two problems. The menu entry
needs to change from program.p to xxprogram.p. Some of the F2 lookups are
setup to work specifically for program.p and do not work for xxprogram.p,
without new entries being created. This (of course) applies to both test
and production.

The second problem centeres around with how to handle "fr" (french) in
addition to "us" (english). The "shop standard" is to put all customized
code both into us/xsource/xxprogram.p *and* fr/xsource/xxprogram.p - even
when there are no transaltions and where the two xxprogram.p(s) would be
identical. My thought here is to put into "fr" just those programs that
have french language differences. With all programs going into both set of
directories, one needs to either do diffs to determine that they are the
same or to apply all changes to both ... ouch !

However or rather wherever the source code is kept, it appears that the
r-code must be kept both in "us" and in "fr" (even when it's exactly the
same r-code) because those gprun[#].i includes seem to have a "hardcoded"
use of global_user_lang_dir in the RUN VALUE statements.

I would really appreciate it if you could either e-mail me a short
description of your dev environment setup and/or point me to what QAD might
have published on this and/or if you can comment on at least some of what I
have tried to explain above.

Thanks you for your help,
Frank.

We are all prisoners of our own experience(s)

 

[Chris Kelleher]

Frank

Unfortunately you are stuck with the standard QAD gprun.i and so you
will need to distribute your programs into the relevant directories (
us, fr etc).

However you could in fact configure your custom directory with these
sub-directories and place it first on the propath.

There is no reason why you could not place bespoke versions in the
appropriate custom directories ie for your example use

custom/us/gp/gpcmmt01.r

As you know this will work just fine.

The key problem with this is that QAD support will have to identify this
as bespoke - particularly as this is such a commonly used program. It is
also worth remembering that you may be changing a program now - but a
third party may be updating it in future.

In addition other considerations are patch application and upgrades to
MFG/PRO - not necessarily trivial tasks.

In general those who modify QAD use one or other method ( renaming or
custom paths) and each has its pros and cons.

 

[Chris Kelleher]

Frank,

This is how we organize it:

Source: qad85g/us/qsrc (hold all our custom code, contains .p, .t, .w, .i )
Executable: qad85g/us/xx
Trigger executable: qad85g/triggers

Naming convention for custom source is: xxsysXXXpo.p
e.g xxmfp999po.p ( xx=custom source, mfp= mfg/pro purchasing, 999=seq.
number, p=programming language, o=online (could have b=batch, etc...),
p=procedure) looks long winded but works for us.

When we write custom code, we always include mfdtitle.i and gprun.i

regards,

Kairm