You might try this:
Change it to FB instead of VBS, make it file mode D1. Look at the
listing from the original unload; use the data for the last column
unloaded to determine the correct file length.
Nora Graves
[EMAIL PROTECTED]
Main IRS, Room 6513
(202) 622-6735
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Bertil Starck
Sent: Tuesday, March 20, 2007 4:43 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: DB2 Dataunload in z/VM and Load Data in z/OS with Format SQL/DS
problem
Hi!
Maybe someone has experience in this case and can give some hints.
We try to do a Dataload in z/OS of a DB2-table that we did a DataUnload
in z/VM.
In the z/VM I did:
'PIPE CMS FILEDEF OUTPUT1 DISK KSH4 DATA D4 (RECFM VBS LRECL 236'
Here's the log from the successfull Dataunload:
1ARI0801I DBS Utility started: 03/16/07 09:49:47.
AUTOCOMMIT = OFF ERRORMODE = OFF
ISOLATION LEVEL = REPEATABLE READ
0-- DATAUNLOAD
-- SELECT *
-- FROM KSH4.BTPOST;
-- OUTFILE(OUTPUT1)
ARI0852I DATAUNLOAD processing started.
ARI0868I DNAME=OUTPUT1 RECFM=U RECSZ=236 BLKSIZE=236
ARI0836I Default output record data field positions:
ARI0837I FFDAG 5-14
ARI0837I FFAR 16-21
...and so on
Sending the file to z/OS with FTP
This is the sysin DD-cards for the job in z/OS:
* Top of Data *
LOAD DATA RESUME NO REPLACE LOG NO INDDN SYSREC NOCOPYPEND
FORMAT SQL/DS
INTO TABLE KSH4.X99A0300
Bottom of Data ***
This is the result:
T DSNURWBF - AN INVALID SQL/DS FORMAT RECORD WAS ENCOUNTERED
T DSNURWBF - (RE)LOAD PHASE STATISTICS - NUMBER OF INPUT RECORDS
PROCESSED=1
NUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED,
REASON=X'00E40323'
The first bytes in the output from the Dataunload looks like this in
Hextype:
00E6 00E2 F2F0F0F0 60F0F660 F0F24040
W S2 0 0 0 - 0 6 - 0 2
Without Hextype:
WS2000-06-02
Maybe this first 4 byte is the problem, any hints?
Best Regards
Bertil Starck
Handelsbanken
CDTI-S
tel: +46 8 701 22 51
e-mail: [EMAIL PROTECTED]
