|
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. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.