Re: Service programs compiled incorrectly

["Eric Wolf" <eric_a_wolf@xxxxxxxxxxx>]

  Steve,

  The steps I followed last night were as follows (but am still having
  problems):

  1)  Recreated the primary service program using binder source.

  2)  Removed the duplicate procedures from 3 other service program's binder
  source.

  3)  Recreated the 3 other *SRVPGM binding the primary to them using the
  BNDSRVPGM parameter.

  4)  Recompiled all affected programs using CRTRPGMOD and CRTPGM.

  5)  I am still receiving the "Pointer not set for location referenced".  I
  have not moved any of the module names around in the binder source.  I now
  add new procedures to the end of the *CURRENT defintion.

  If I cannot solve the problem, I will have to remove the service programs
  from my libraries by re-writing the code to do standard "calls".  I hate
  to have to do this but I will have no choice.

  Eric

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

    From:  "Steve Richter" <stephenrichter@xxxxxxxxx>
    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 10:02:05 -0400
    >On 9/19/06, Eric Wolf <eric_a_wolf@xxxxxxxxxxx> wrote:
    > > Steve,
    > > I have tried everything that I can think of to resolve the problem.
    > >
    > > >maybe CRTPGM was used to recreate the bombing programs after the
    > > >SRVPGM was created with EXPORT(*ALL) and before it was created with
    > > >the binding source.
    > > After I recreated the service programs correctly with new
    signatures, I
    > > recreated the programs using CRTRPGMOD and CRTPGM.
    > >
    > > >start with the error message. If it is a signature violation,
    display
    > > >the help text and find the name of the service program it is
    > > >complaining about. You can use DSPPGM to see what signature the
    > > >program is expecting for each SRVPGM it references.  And you can
    use
    > > >DSPSRVPGM to see the signature of the service program. However the
    > > >signatures got the way they are, they have to match.
    > > 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.
    > >
    >
    >Once CRTPGM is done, the system uses an export number to link the
    >calling program and the actual procedure exported from the SRVPGM.
    >What this means is when PGM1 calls PROC_GetName in SRVPGM2 it actually
    >does a call to an export number instead of a procedure name. It uses
    >the export number of PROC_GetName in SRVPGM2 that existed when PGM1
    >was created. If you come along after the CRTPGM of PGM1 and recreate
    >the SRVPGM and cause the export number of PROC_GetName to be changed,
    >then all hell is going to break out. PGM1 will still be calling the
    >original export number of PROC_GetName but since the list of exports
    >was changed ( and the signature is hardcoded ) you will actually be
    >calling a completely different procedure in the SRVPGM.
    >
    >This is a possible cause of your problem.
    >
    >I think you need to assign a new signature in the binding source and
    >recreate the service program. Then CRTPGM all the programs - at least
    >the ones you know about.  That should eliminate these odd errors
    >because all the programs that call into the service program will now
    >be calling with the correct export number. The only errors that remain
    >should be signature violations. When you get those, follow the error
    >message text and CRTPGM the failing program.
    >
    >-Steve
    >--
    >This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
    list
    >To post a message email: RPG400-L@xxxxxxxxxxxx
    >To subscribe, unsubscribe, or change list options,
    >visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
    >or email: RPG400-L-request@xxxxxxxxxxxx
    >Before posting, please take a moment to review the archives
    >at http://archive.midrange.com/rpg400-l.
    >