RE: Service programs compiled incorrectly

  Scott,

  The reason that I have been reviewing these avenues is because I have not
  changed any of the parameters being passed, I added a new procedure and
  recompiled using EXPORT(*ALL) instead of EXPORT(*SRCFILE).  That is when
  the problems started.  Unfortunately, I do not know if the original
  *SRVPGM had its' own activation group or was *CALLER or QILE.  Could this
  be another thing to look at?

  When I attempt to test the same steps that my users are doing, I do not
  get the errors.  When I have them sign off after getting an error, the do
  not get the error initially.  They get it after some time has transpired
  and are keying a lot of orders.

  Thanks for all you help so far...

  Eric

    ----------------------------------------------------------------------

    From:  Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
    Reply-To:  RPG programming on the AS400 / iSeries
    <rpg400-l@xxxxxxxxxxxx>
    To:  RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
    Subject:  RE: Service programs compiled incorrectly
    Date:  Tue, 19 Sep 2006 12:01:15 -0500 (CDT)
    >
    > > After I recreated the service programs correctly with new
    signatures, I
    > > recreated the programs using CRTRPGMOD and CRTPGM.
    >
    >Why?  I mean, yes, this'll solve the problems, but it seems like a lot
    of
    >effort, and unless you changed the parameter lists of your
    subprocedures,
    >you don't have to do this.
    >
    >
    > > It is not a signature violation - it is having a problem with some
    of the
    > > modules - getting bad data.  For example, a module RTVCUSMAS is
    supposed to
    > > get a record from the customer master record.
    >
    >All of your messages so far have discussed changing the binder source
    to
    >give yourself a different signature. You've also discussed handling
    >duplicate procedures. If you're not getting a signature violation
    error,
    >then I don't understand why you're doing all of that.  Your problem
    isn't
    >related to the signature!
    >
    >If you're getting bad data in the parameters it means that the caller
    is
    >passing the parameters incorrectly.  It has nothing to do with how the
    >modules or service programs are bound to one another.
    >
    > > I only added a module to the end of the binder source.
    >
    >That's nice, but irrelevant.  Since you've already run CRTPGM on
    >everything that calls it, you've already re-bound everything.  It
    wouldn't
    >matter where you added the "module" (I suspect you actually mean
    >"procedure") in the binder source.
    >
    > > In the case of the service programs with some duplicate modules, I
    > > removed the duplicates, recreated those service programs and bound
    them
    > > with the service program that had the other required modules.
    >
    >Why?  What does this error have to do with duplicate procedures?
    >
    >You have bad data in a variable.  Where does that variable come from?
    >Assuming it's a parameter, make sure the parameter definitions in the
    >caller match those of the receiver. If you're using a prototype, make
    sure
    >the caller's prototype is identical to the procedure interface of the
    >service program. Make sure they're getting the same prototype from the
    >same version of the same source member in the same library.
    >
    >If you're passing a data structure, make sure it's identical in both
    the
    >caller and receiver, including the data types of the subfields.
    >
    >If you're using options(*varsize) make sure that the procedure is very,
    >very, very careful to only use the portion of the field that was
    passed,
    >and not to reference the entire field.
    >
    >None of these have to do with service programs. They are related to
    >passing parameters.  Parameters really haven't changed much... the same
    >parameter passing conventions used on the System/38 are still used
    today.
    >Granted, we have new tools for working with them, but the same cautions
    >apply... you have to pass the correct number of parameters, and the
    data
    >types and lengths of each corresponding parameter have to match.
    >--