Problems with Stored Procedures

Tags:
IBM DB2
RPG
Hi, I have written a stored procedure in SQLRPGLE. I used option 15 to create a module, then CREATE PROCEDURE to define it. When I go into SQL to call it, it says External program SVLBR in V64BPCSUSR not found. This is where my module & stored procedure is located. Any ideas on what I missed? Thanks Terri Harteau Programmer/Analyst Felker Brothers Corp

Answer Wiki

Thanks. We'll let you know when a new response is added.

A couple people wrote in with advice. Here’s what they said:

“Terri still needs to turn the *Module object into a *Pgm object.”
– Randy Adamski

“When I’ve had this problem it was always because I wasn’t invoking the stored procedure with the required parameters.
This is with the same parameters and the same size and the same type.

“Do you have the stored procedure only one time? If you have created the stored procedure two or more times with different parameters without previously clearing them, then you have more than one stored procedure with the same name.”
– Francesc Ferrada

====================================================

The first comment is the one that is correct. You can’t create a stored proc directly from a *MODULE object; you need to bind the module into a *PGM (program) first. The stored proc would be created over the program.

Tom

Discuss This Question: 1  Reply

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • MichelleDavidson
    Jan said their shop experienced something similar: "This really sounds like the problem we had a while ago. We didn't create the stored procedure within SQLRPGLE, but with an SQL-statement (executed with RUNSQLSTM). So it's a little bit different, but the problem sounds the same. "Our problems were related to the fact that the stored procedure was created for testlibrary A, while later it had to be used for data in testlibrary B. "In the creation of the stored procedure, a "default collection name" is used for all the unqualified tables/views in the procedure. We have to use unqualified tables/view because of the different test and productionlibraries. Initially we used the defaults on the involved parameters of the RUNSQLSTM command. "The created procedure contained as default collection name the testlibrary A, and when we tried to use it for testlibrary B we received this funny message that the stored procedure could not be found event though it was really there. "We decided to create for every test/production library a separate stored procedure because we couldn't find a way to use "*LIBL" as the default collection name. I haven't had to look at this issue since then, so I don't know if this solution will still work." -- Michelle Davidson, editor, Search400.com
    435 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following