|
Steve, You mention "duplicate procedures" and removing them from 3 other service program's binder source. I'm guessing your problem is tied into these "duplicate procedures" in some manner. Can you provide some examples of the duplicates? Are there any messages other than "Pointer not set for location referenced"? Are you using a binding directory? Have you looked at what's in that? Consider doing a clean build by deleting all affected *SRVPGM, *MODULE, *PGM objects. Then recompile the modules and rebuild both the *SRVPGM and *PGM objects. HTH, Charles Wilt -- iSeries Systems Administrator / Developer Mitsubishi Electric Automotive America ph: 513-573-4343 fax: 513-398-1121
-----Original Message----- From: rpg400-l-bounces+cwilt=meaa.mea.com@xxxxxxxxxxxx [mailto:rpg400-l-bounces+cwilt=meaa.mea.com@xxxxxxxxxxxx] On Behalf Of Eric Wolf Sent: Tuesday, September 19, 2006 12:32 PM To: rpg400-l@xxxxxxxxxxxx Subject: Re: Service programs compiled incorrectly 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. > -- 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.