We have a situation where the EDI document is coming from mainframe into IS running on Windows 2000. We notice the entire document is coming in with a fixed length of 80 characters. Is it due to EBCDIC to ASCII translation. Anyway, as a result, te ISA segment is truncated after 80 chars and the remaining part comes in a new line as shown below.
This causes the tn.receive service to crash as it doesnt recognize the incoming document. I think it is due to incomplete ISA record with EOL character. Is there any quick solution to get over this problem. If we can fix the problem in the mainframe, it will be good. Or should we introduce any content handlers to solve these problems.
Does anyone work with EDI files coming from mainframe. If so, how did u handle these.
You are correct. The file sent from the mainframe contains an EOL character which invalidates the ISA segment in TN. You can FTP the data in ASCII to IS then use a custom service to strip the EOL character (I think I saw a shareware package out here that had a service to strip the line feed). Once you do that you can post the string to TN and everything should be fine.
By what method did the file reach your system? Might it have been sent via a BiSync protocol? We had this problem, but changing the receiving parameters resolved the problem.
You can do a fix process as described above, but there is a risk that a “good” file could be run thru the process and get “broken”.
IBM mainframe is pushing the file directly to the service(tn.receive wrapper service) using FTP. At that time, the service within has a stream with truncated ISA.
So I have 2 options to handle this
a. Modify the file while in transition from mainframe to IS sent via FTP. Foster - what is a Bisync Protocol. Can I use some FTP parameters so that mainframe will not include the EOL characters. I think the EBCDIC to ASCII translation that occurs while FTP introduces the EOL character. I want to prevent this somehow.
b. FTP the file to the IS filesystem and then schedule a job to pick that file, strip the EOL character and feed it to tn.receive. I want to avoid this if possible as I can have one process to receive files from all possible systems.
BiSync is an older, dialup, batch transmission protocol developed by IBM many years ago. Still is widespread use for EDI. Tends to introduce cr/lf pairs.
You would know if you were receiving a file directly via bisync. Could the mainframe have received it that way?
Check the transfer mode used for the FTP transfer mode" Bin or Ascii?
When we set the FTP mode to Bin, we are getting one big chunk (maybe there is no CRLF), however the data is all binary form. ASCII mode gets the data with proper text but with a CRLF. We will have to investigate only on the mainframe side to see if we can remove the EOL chars
The segment delimiter appears to be ^. The end result you want is to get a readable block that appears to be one long line. This is the correct format. Not easily human-readable but that’s the way EDI files generally work. To get human-readable you could use 0x0a as the segment delimiter which wraps the segments nicely.
Many translators support having EOL chars after the segment delimiters, such as LF, CR or CR/LF. The WmEDI package supports this too. However, it is not really “official” EDI–it’s a de facto practice.
For the EBCDIC to ASCII translation. I’m not a mainframer but you should be able to do the translation without also causing the 80-byte recl. If not, it’s not terribly difficult to do the E-to-A translation on the PC side.