Comments on: CPYFRMIMPF Issue

By: tomliotta

tomliotta — Sat, 31 Dec 2011 10:10:16 +0000

Okay, so it should start with ‘how was it “exported”?’

I just see them as all data blank..

How are you viewing the file? Are all of the fields character fields? There are no numeric fields in FUELMAST?

Does the number of blank records match the number of exported records?

If you run under debug, do any hints show up? You will probably need to use STRDBG UPDPROD(*YES).

You might also use CPYFRMIMPF FROMRCD(*FIRST 1) so that only one import record is processed. That will shorten any test runs.

You might also use CPYFRMIMPF ERRRCDFILE(MYLIB/ERRF) so that any error records will be copied to an error file. After a test, check to see if any error records were logged.

Tom

By: tomliotta

tomliotta — Sat, 31 Dec 2011 09:18:07 +0000

…Isn’t the place the data is imported from or to..

Sheesh! There you go again, forgetting to remind me to get new glasses! You really gotta do something about that memory.

Ah, well… it definitely makes a lot more sense that way. I should have actually read your first response and noticed it then. Once something is misread, it’s almost impossible to see it correctly until someone else points it out. The mind is marvelous, but it can foul up spectacularly.

Tom

By: philpl1jb

philpl1jb — Sat, 31 Dec 2011 07:44:02 +0000

Tom

FLDDFNFILE(MYLIB/QDDSSRC member DATA)
Isn’t the place the data is imported from or to
It’s the member that contains a description of the file structure of the to file.
Kinda like using an .fdf file when uploading in client access.

Phil

By: tomliotta

tomliotta — Sat, 31 Dec 2011 01:46:41 +0000

I’d wonder first if this really is an “import” file. That is, how was it “exported”?

Tom

By: tomliotta

tomliotta — Sat, 31 Dec 2011 01:43:13 +0000

The CPYTOIMPF and CPYFRMIMPF commands are generally intended to provide the DB2 EXPORT and IMPORT functions that are found in DB2 on other platforms. As long as general DB2 database concepts are held in mind, their behavior can be a little more comprehensible. (They can definitely throw some curves at times.) Their purpose is somewhat described by this statement from CPYFRMIMPF help text:

The term import file is used to describe a file created for purposes of copying data between heterogeneous databases.

But this question gets a little confused when the file name is QDDSSRC because it implies that this doesn't really involve a "database" file but a source file instead. A source file has some particular characteristics that might need to be taken into account. Maybe if the details of how data got into the oddly defined streamfile is given, an appropriate CPYFRMIMPF command can be built. Tom

By: philpl1jb

philpl1jb — Wed, 28 Dec 2011 13:25:07 +0000

So Tom’s usually right, try CPYFRMSTMF

The method I described only works with char fields and positive zoned fields. Not so useful.

Phil

By: philpl1jb

philpl1jb — Wed, 28 Dec 2011 12:53:44 +0000

Tom
I think Ron’s trying to copy a fixed length text file into CEIOH/FUELMAST
Since it’s fixed length it has no delimiters.
With it’s structure described in
FLDDFNFILE(MYLIB/QDDSSRC member DATA)
apparently he’s getting blank lines..

Ron – check the job log – it never helps but gives me time to think about it. It might have a list of error.s

I usually copy this type of file to a flat file on the 400 then use CPYF with fmt *NOCHK to populate the target file.
.
Phil

By: tomliotta

tomliotta — Wed, 28 Dec 2011 12:39:38 +0000

If you are using DTAFMT(*FIXED) and STRDLM(*NONE) and STRESCCHR(*NONE), why are you using CPYFRMIMPF? Why don’t you use CPYFRMSTMF?

And if you’re copying into a source file, why are you using CPYFRMIMPF instead of CPYFRMSTMF?

And why would you have a streamfile with fixed-length of 468 if you’re really intending to copy into a DDS source file? No DDS uses records that long.

Working up an answer might be easier if those are made clear.

Tom