Re: Stored procedures

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

David

When you compile, you have the option to replace the program. That will 
put a copy into library QRPLOBJ, if it's being referenced by any job. So 
the debug server might have picked up such a reference, or whatever.

I would not get too upset - it's a feature to keep your jobs running 
when you replace things.

I find I always have to be careful to check for debug and running jobs - 
had that happen at a customer today with some custom code - a 
long-running job was sending messages that looked like my code from 2 
days ago - had to clear things out of QRPLOBJ and bounce this job.

And do check the user, as another post said - SEPs are not triggered for 
all users, just one - if it's an HTTP CGI server job you want to debug, 
you have to change the SEP to point at user QTMHHTP1, probably.

HTH
Vern

On 12/2/2010 8:43 AM, David FOXWELL wrote:
> I think it was one of "those" problems with sep. I had already tried refreshing the sep. Then, I recompiled the program and forgot about the debugger. When I called the procedure from strsql, it seemed to lock - it was the rdp debugger taking control! How is that possible? When I refreshed the sep, it didn't catch the call. If I recompile, I should be obliged to refresh the sep! N'est-ce pas!!
>
>
> > -----Message d'origine-----
> > De : wdsci-l-bounces@xxxxxxxxxxxx
> > [mailto:wdsci-l-bounces@xxxxxxxxxxxx] De la part de
> > Rick.Chevalier@xxxxxxxxxxxxxxx
> > Envoyé : jeudi 2 décembre 2010 14:55
> > À : wdsci-l@xxxxxxxxxxxx
> > Objet : Re: [WDSCI-L] Stored procedures
> >
> > David,
> >
> > Check the user ID the SEP was set up to use and the user ID
> > you are running the SQL under.  If they don't match I think
> > the SEP is ignored.
> >
> > Rick