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




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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.