× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.