Re: Fw: CPYFRMIMPF EDI File

CPYFRMIMPF is a tool designed to generate /rows/ of described database data from previously exported _database_ data; database data that was exported in either a delimited or a fixed format, and irrespective of which format, has standard text line delimiters. Stream data is essentially incompatible with the concept of row data, whereby the latter can only _conceptually_ represent the former, and most generally that representation only as varying length rows. That is because when the stream data is not delimited for representation as multiple fields, it is almost surely either a binary stream for which any concept of a row is unnecessary complexity, or strings defined by some delimiter(s) which are typically manifest as /lines/ of text data for presentation versus as rows of database data. The distinction between lines and rows is that the row for a database file has no delimiters because its fixed or varying row size takes place of the delimiters used for the separation of distinct strings of text within a stream.

The given snippet of data is indicative of a stream which does not have any obvious text /lines/ of data, so it should be obvious that there is no direct copy into /rows/ of data. If there had been typical line termination characters, as recognized by standard text parsing utilities, the DSPF request would have presented the data in somewhat /readable/ strings of text, as separate /lines/ of data. The first requirement is to insert delimiters which define the /lines/ of data to such utilities. As someone suggested, it may be the tilde character which should be treated as a line delimiter, and thus what should be translated into a line feed or a combination of line-feed and carriage-return characters. That action would allow the text copy utilities to recognize what should be treated as separate lines of text data. If the data is not first modified to be in such a /standard/ form, the data should be processed by a user program versus a text copy utility [which expects standard line delimiters].

If the data need only be separated into 80-byte chunks without regard to intended delimiter to establish /lines/ of text data, then use either FTP or CPYTOSTMF which as I recall can break up the data into fixed length lines without needing standard delimiters.

Regards, Chuck

KHeeter@xxxxxxxxxxxxx wrote:

I am having a bugger of a time with getting a simple 80 character EDI
file from the IFS to a file called FILE080 in my library with one
field of 80 bytes. I will then ADD it to my Edi inbound queue. I have
done it a zillion times with .csv files, but not this EDI file, I do
not want delimiters. I just want the data to be copied exactly as it
is.

I tried a zillion variations of CPYFRMIMPF and CPYFRMSTMF to no
avail.

Can anyone help?

Here is a snip of the data:

Browse : /home/kathie/FILE.TXT <<SNIP>> ....+....1....+....2....+....3....+....4....+....5....+....6....+ ************Beginning of data************** ISA*00*0000000000*00*0000000000*08*6111470100 *01*074240599

*080614*074
8*U*00401*000034236*0*P*>~GS*PD*6111470100*074240599*20080614*0748*747*X*004010~
ST*852*045181099~XQ*H*20080613*20080613~N9*DP*059~N9*IA*3094424~N1*RL*TARGET~

<<SNIP>>

Display Attributes

Object . . . . . . : /home/kathie/FILE.TXT
Type . . . . . . . . . . . . . . . . . : STMF
Owner . . . . . . . . . . . . . . . . : HEETERK
System object is on . . . . . . . . . : Local Auxiliary storage pool . . . . . : 1 Object overflowed . . . . . . . . . : No
Coded character set ID . . . . . . . . : 819
<<SNIP>> Browse KATHIE/QDDSSRC SEU==> FILE080
*************** Beginning of data *********
0009.06 A R @FILE80
0009.07 A FLD080 80

Any help is greatly appreciated... Going Crazy!