Moving data from .DBF to DB2/2

Frank C. Fillmore, Jr.

unread,

Dec 4, 1996, 3:00:00 AM12/4/96

to

>How do i move data from an indexed dBASE .DBF file to a new database
>created in DB2/2?
>Is there a utility for this or are there procedures?

I'm about to do that very thing this morning. I use a product called
DataDirect Explorer from Intersolv (Rockville, Maryland). It is an any-to-any
data conversion tool. You open the .DBF file, connect to DB2/2 via CAE and
ODBC, and issue a SAVE AS...

Frank

Joost Vocke

unread,

Dec 4, 1996, 3:00:00 AM12/4/96

to

On Wed, 4 Dec 1996 08:46:11 EST, "Frank C. Fillmore, Jr."
<Fill...@WS1.TFG-RDBMS.COM> wrote:

>>How do i move data from an indexed dBASE .DBF file to a new database
>>created in DB2/2?
>>Is there a utility for this or are there procedures?
>
>I'm about to do that very thing this morning. I use a product called
>DataDirect Explorer from Intersolv (Rockville, Maryland). It is an any-to-any
>data conversion tool. You open the .DBF file, connect to DB2/2 via CAE and
>ODBC, and issue a SAVE AS...
>

This means you already had to define a database, table and columns.
Or does the DataDirect Explorer creates them for you from the .DBF
file?

Joost
UAP-NieuwRotterdam Verzekeringen

Development Control

unread,

Dec 4, 1996, 3:00:00 AM12/4/96

to

David,
There is no technical reason to produce dummy packages. Simply compile your
programs as per their source requirements, if there is DB2 dependencies then
they go through the pre-processor, if not then they do not. When it comes to
executing in a "batch tso" environment do the following:

Execute IKJEFT01 (or similar)
Run the main program and specify the required PLAN
Ensure that the PLAN specifies the correct Collection list
When the CALL is made to the DB2 dependent sub-routine then the TSO attach
will perform all the required connections and the package will be located
correctly.
There is no requirement for the mainline program to be bound or have any DB2
dependencies.
One point worth noting is that if the CALL is a static call then modifications
to the sub-routine will involve re-compilation and re-binding of it.
You MUST also re-link-edit the main-line program, or re-compile and link as
the Consistency token from the sub-routine is contained within the load module
of the main program and will not be updated unless you provide a new version
of the main program's load module.

Hope this has been of help.

Mike Sheppard (aka msh...@gil.com.au)

PS If this did not find it's way onto the DB2 list could you please place it
there as it may be of help to others.

At 07:40 AM 2/12/96 -0500, you wrote:
>We have a similar situation here where we are calling DB2 subprograms from
>non-DB2 programs. We create a "dummy" package for the non-DB2 program
>by doing a "set current date.....". The DB2 subprogram and the calling
>program packages are in the same collection.
>I would be interested in hearing how we could get the subprogram to execute
>(using tso batch attach) if there was not a package for the calling program.
>Thanks for any replys.
>----------------------------------------------------------------------------
>-------
>At 06:45 AM 11/26/96 GMT, you wrote:
>>In article <329A...@msmailv0.telecom.com.au>,
STar...@VCRPMAP.TELSTRA.COM.AU
>>says...
>>>
>>>We have some mainline programs that contain no DB2 code, but call db2
>>>subprograms. These have produced empty dbrms prior to our installation of
>>>DB2 4.1. Now DB2 refuses to produce a dbrm. What's the best solution.
>>> Just include a dummy DB2 call, or is there a more elegant solution.
>>>
>>>Thanks
>>>
>>>Steve
>>
>>It would appear that the empty DBRMs are produced by the main program being
>>put through the DB2 pre-processor. Prior to version 4.1 this produced an
empty
>>DBRM, now version 4.1 is 'smart' enough to not produce the DBRM, as it is of
>>no use. The modification of your compilation process to not put non-DB2
>>programs through the pre-processor would produce the most elegant solution
as
>>you will not get DBRMs produced and there would be no confusion. I know a
>>number of TELSTRA's DB2 support personnel, Dave Fletcher, Greg Farquahar,
and
>>I'm sure they would be able to assist with more details for your particular
>>application.
>>
>>Mike Sheppard aka msh...@gil.com.au
>>
>>
>David Williams, DBA
>Georgia Department of Labor
>
>

Frank C. Fillmore, Jr.

unread,

Dec 6, 1996, 3:00:00 AM12/6/96

to

>This means you already had to define a database, table and columns.
>Or does the DataDirect Explorer creates them for you from the .DBF
>file?

DataDirect Explorer creates the tables and columns based on the .DBF defintion.
It's a cool tool.