AW: Infocenter - find how/when *SQL naming used over *SYS

Hi Jeff,

just add the following statement to your script:

SET CURRENT SCHEMA MyDataLib;

(look at the differences between *SYS and *SQL naming in my previous post.)

Birgitta
-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Jeff Crosby
Gesendet: Donnerstag, 13. Oktober 2005 22:17
An: 'Midrange Systems Technical Discussion'
Betreff: RE: Infocenter - find how/when *SQL naming used over *SYS

> I will be looking for an answer to the subject in the "new" 
> Infocenter.

I'm still battling an SQL problem that I posted about a couple of months
ago.  I have newly discovered it's an SQL vs SYS naming thing.  The
statement is:

RUNSQLSTM  SRCFILE(QSQLSRC) SRCMBR(DLT042) COMMIT(*NC)

The default on RUNSQLSTM is NAMING(*SYS).  When I run it, it works.  When
the sysopr runs it at month end, it fails.  The RUNSQLSTM output, when
sysopr runs it, says:

Naming....................*SQL

which _is_ the problem.  The resulting error is SQL0204 with text that says
the file is not found.  I have gone so far as to have sysopr sign on and run
this.  And it works fine.  Therefore my keen mind detected that there must
be something happening in her job prior to her running this at month end
that is causing some kind of 'environment' change.

Am I on the right track here?  I know I could probably add the NAMING parm
to the RUNSQLSTM, but that isn't really fixing it.

I don't see anything in the user profile that applies.  Or the job
description.  I would think that if the default for NAMING is *SYS, then the
default for NAMING _stays_ *SYS.  The only options are *SQL and *SYS.
There's no *JOB, *JOBD, *USRPRF, etc. as options.

Thanks.