I am having issues with using a CR (HEX 0d) as a terminator in GENTRAN. We have used unprintable characters as terminators for quite some time, including 0d0a (CRLF). Sometimes the 0d will be ignored and I end up with segments concatenated together. Gentran said they do not support non-printable characters as terminators. Has anyone else had this issue? Have any of you come up with a work-around? We tried adding mailbox rules, but these cannot be partner specific.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Unprintable characters as terminators in GENTRAN
- Thread starter MaureenL
- Start date
zedsded
IS-IT--Management
- Jun 9, 2002
- 68
To be safe, don't use any non-printable characters in Gentran. I had the same problem before, and it cost us a lot of money (chargeback). If you don't have a choice, the best thing to do is:
1. Call Sterling support and let them know what terminators your trading partner requires, and what you should use.
2. Verify if they will be able to send a "compliant" document to your trading partner based on their requirement.
3. The idea is, let Sterling be responsible for the data being sent by following their suggestions and for doing a "terminator work-around" - all because of the incapabilities of Gentran.
TIP: Gentran software is your translator - let them translate the data for you.
1. Call Sterling support and let them know what terminators your trading partner requires, and what you should use.
2. Verify if they will be able to send a "compliant" document to your trading partner based on their requirement.
3. The idea is, let Sterling be responsible for the data being sent by following their suggestions and for doing a "terminator work-around" - all because of the incapabilities of Gentran.
TIP: Gentran software is your translator - let them translate the data for you.
Just because you use Gentran doesn't mean that Sterling is necessarily your one and only VAN. In our case we use Gentran as our translation software, but use several methods for getting the edi data to/from our trading partners. (Vans, ftp, as2).
Some VANs will do delimter conversion for you, but that may be only for incoming data so that all data from them uses the same delimiter/separators. Sterling can do this and probably most of the other VANS if you ask. I don't think that data from you to you TP can be converted by the VAN, so whatever delimeters you use thats what they will get (unless they use conversion on their receiving end).
I have found that non-printable chars are a pain! Most of our TP will accept alternates and you should check with your TP to see if they will accept a alternate (printable) delimeter ("~" or "^" are ones we've used). In particular is seems the hex 0d and 0a are problems because the crlf is used by so many things for record termination. Even some methods of transmission use crlf for block records termination, so if you used it as a terminator it would be very messy.
I don't think I've run into a TP that ever had problems with the separators we normally use (*,>,~ for element, subsep and terminator).
As a additional step, maybe after translation you could run the output edi file through a process that replaces your gentran terminator with a cr. I don't know what o/s your running on but unix I've used a 'tr' command to do something similar to this.
LEE
Some VANs will do delimter conversion for you, but that may be only for incoming data so that all data from them uses the same delimiter/separators. Sterling can do this and probably most of the other VANS if you ask. I don't think that data from you to you TP can be converted by the VAN, so whatever delimeters you use thats what they will get (unless they use conversion on their receiving end).
I have found that non-printable chars are a pain! Most of our TP will accept alternates and you should check with your TP to see if they will accept a alternate (printable) delimeter ("~" or "^" are ones we've used). In particular is seems the hex 0d and 0a are problems because the crlf is used by so many things for record termination. Even some methods of transmission use crlf for block records termination, so if you used it as a terminator it would be very messy.
I don't think I've run into a TP that ever had problems with the separators we normally use (*,>,~ for element, subsep and terminator).
As a additional step, maybe after translation you could run the output edi file through a process that replaces your gentran terminator with a cr. I don't know what o/s your running on but unix I've used a 'tr' command to do something similar to this.
LEE
- Status
Similar threads
- Locked
- Question
- Locked
- Question