DB2 V7 Import/Run Script problem

[Graham Hobbs]

Hello,

My old laptop has DB2 V7 thereon. The only fixpaks I ever applied were
FP1 (although I cant truly remember if I actually did this one) and
FP2. Because it/they entirely satisfied my needs I applied no more
fixpaks. And I didn't keep FP1 or FP2:-( but we're going back six or
seven years here!

I got a new laptop and put my V7 thereon. As experienced with the old
machine, the 'bit' of DB2 I critically needed didn't work. So off I
went to the download site and lo and behold found fixpaks 1 thru 14
(or thereabouts) with the GLARING exception of FP2_WR21246.

So I figured FP3 should fix me up. But it didn't. My problem remained.

So, two questions if I might:

does anybody by any chance have FP2?
and/or
has anybody experienced my problem, if so, which FP rectified the
problem?
--------------------------------------------------------------------------

My DB2 is:
Version 7
service lvl 0
release 1
mod 0
running under Windows NT4.0 SP6

---------------------------------------------------------------------------

Here's what happens:
I imported the following script (partial list only) via the Command
Centre:

CONNECT TO WCB3;
DROP TABLE DODBDATA;
CREATE TABLE DODBDATA (
CUSTOMER_NUMBER_AAAAAAA_NUMBER CHAR(5) NOT NULL,
CUSTOMER_NAME_BBBBBBBBBBB_NAME CHAR(33) NOT NULL,
ADDRESS_1 CHAR(33) NOT NULL,
ADDRESS_2 CHAR(31) NOT NULL,
POST_CODE CHAR(7) NOT NULL,
ATTENTION CHAR(10) NOT NULL,
VAT_REGTN_VVVVVVVVVVVVVV_REGTN CHAR(10) NOT NULL,
IN_STOCKS_TTTTTTTTTTTTTTTTTTTX DECIMAL(7,00) NOT NULL,
TOTAL_CARS DECIMAL(7,00) NOT NULL,
ZD_FIELD DECIMAL(3,01) NOT NULL,
ZU_FIELD DECIMAL(3,02) NOT NULL,
PRIMARY KEY (
CUSTOMER_NUMBER_AAAAAAA_NUMBER
)
);
CREATE INDEX DODBDATA_I2 ON DODBDATA (
CUSTOMER_NAME_BBBBBBBBBBB_NAME
ASC);
INSERT INTO DODBDATA (
CUSTOMER_NUMBER_AAAAAAA_NUMBER,
CUSTOMER_NAME_BBBBBBBBBBB_NAME,
ADDRESS_1,
etc

Then I ran the script and got the following errors (partial list
only)(sorry about the formatting):

---------------------------------Script-----------------------------------
E:\conrad\DODB\ZZJ30DDL.CMD
-----------------------------------------------------------------------------
SQL1001N "WCB3;" is not a valid database name. SQLSTATE=2E000DB21034E
The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it
returned:SQL1024N A database connection does not exist.
SQLSTATE=08003

DB21034E The command was processed as an SQL statement because it was
not a valid Command Line Processor command. During SQL processing it
returned:SQL1024N A database connection does not exist.
SQLSTATE=08003
etc, etc

.... but

WCB3 is a database name and the 2E000 says 'Connection name is
invalid'. So I figure the semi-colon after the WCB3 must have
something to do with it and

a) the script parser ain't that smart
b) you have to tell DB2 the semi-colon is a stmt delimiter (in which
case - I ain't that smart).

What really puzzles me is in the old days when FP1/FP2 did the trick,
now FP2's gone (and why?), yet FP3 didn't carry the fix. Can't figure
that at all! Thought these fixpaks were cumulative.

Any help would be gratefully appreciated.
Thanks
Graham Hobbs
--
Posted via a free Usenet account from http://www.teranews.com

[Knut Stolze]

Graham Hobbs wrote:

does anybody by any chance have FP2?

FixPaks are cumulative, i.e. all changes in FP2 are also in FP3. That's
true to FP1 thru FP7 and FP8 thru FP14 in V7. In V8, all FPs are
cumulative.

and/or
has anybody experienced my problem, if so, which FP rectified the
problem?
--------------------------------------------------------------------------

My DB2 is:
Version 7
service lvl 0
release 1
mod 0
running under Windows NT4.0 SP6

---------------------------------------------------------------------------

Here's what happens:
I imported the following script (partial list only) via the Command
Centre:

CONNECT TO WCB3;
DROP TABLE DODBDATA;
CREATE TABLE DODBDATA (
CUSTOMER_NUMBER_AAAAAAA_NUMBER CHAR(5) NOT NULL,
CUSTOMER_NAME_BBBBBBBBBBB_NAME CHAR(33) NOT NULL,
ADDRESS_1 CHAR(33) NOT NULL,
ADDRESS_2 CHAR(31) NOT NULL,
POST_CODE CHAR(7) NOT NULL,
ATTENTION CHAR(10) NOT NULL,
VAT_REGTN_VVVVVVVVVVVVVV_REGTN CHAR(10) NOT NULL,
IN_STOCKS_TTTTTTTTTTTTTTTTTTTX DECIMAL(7,00) NOT NULL,
TOTAL_CARS DECIMAL(7,00) NOT NULL,
ZD_FIELD DECIMAL(3,01) NOT NULL,
ZU_FIELD DECIMAL(3,02) NOT NULL,
PRIMARY KEY (
CUSTOMER_NUMBER_AAAAAAA_NUMBER
)
);
CREATE INDEX DODBDATA_I2 ON DODBDATA (
CUSTOMER_NAME_BBBBBBBBBBB_NAME
ASC);
INSERT INTO DODBDATA (
CUSTOMER_NUMBER_AAAAAAA_NUMBER,
CUSTOMER_NAME_BBBBBBBBBBB_NAME,
ADDRESS_1,
etc

Then I ran the script and got the following errors (partial list
only)(sorry about the formatting):

---------------------------------Script-----------------------------------
E:\conrad\DODB\ZZJ30DDL.CMD
-----------------------------------------------------------------------------
SQL1001N "WCB3;" is not a valid database name. SQLSTATE=2E000DB21034E
The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it
returned:SQL1024N A database connection does not exist.
SQLSTATE=08003

DB21034E The command was processed as an SQL statement because it was
not a valid Command Line Processor command. During SQL processing it
returned:SQL1024N A database connection does not exist.
SQLSTATE=08003
etc, etc

... but

WCB3 is a database name and the 2E000 says 'Connection name is
invalid'. So I figure the semi-colon after the WCB3 must have
something to do with it and

Please look again at the error message. It says that "WCB3;" is an invalid
database name. You probably did not specify -t option when executing the
script. Thus, the trailing ';' is not treated as statement terminator as
you assumed it would.

a) the script parser ain't that smart
b) you have to tell DB2 the semi-colon is a stmt delimiter (in which
case - I ain't that smart).

What really puzzles me is in the old days when FP1/FP2 did the trick,
now FP2's gone (and why?), yet FP3 didn't carry the fix. Can't figure
that at all! Thought these fixpaks were cumulative.

Which "fix" are you talking about? Your mistake when running the script?

p.s: Since V7 (all FP levels) is out of service for more than 1 year,
chances are slim that you will get a lot of help here. You should consider
moving to V8 or V9 (DB2 Express-C in free of charge).

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany