|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.