I am using the FF Schema and convertToString service to generate the EDI STs. Some of the segments are getting generated with unnecessary field delimiters. I am not sure if it is a bug as this behaviour occurs for only some segements.

For eg “}” is the segment delimiter and “~” is the field delimiter and the output of the convertToString service is as follows :

ST~816~031208112}
BHT~0059~25~XXX02~20030603}
N1~B4~XXX Inc.}
HL~14}
N1~DS~JENTZEN, MARLEN & BETTY~GA~000000184}
REF~1W~JEN}

In the above REF segment, ‘~’ delimiter is coming at the end though the field REF03 and REF04 are optional and I dont have it in my EDI record that gets passed to ‘convertToString’ service. Any idea why the output gets generated with two “~” at the end. Is it a bug ?

Thanks for your help

I guess the REF03 is getting a null map value that might be the reason its putting the (~~)shown in your REF segment at the end,So,Pls check the 816 Values in the pipeline before you are mapping to convertToString service.

HTH.

RMG,

I did check the REF03 and REF04 fields. Both of them are null and they dont even exist within the EDI Idata record. btw, they are optional and hence should not try to generate field delimiters if they dont exist in the EDI Idata record. So, I dont know what causes them to create these delimiters.

what version of wm are you using?

I am using 6.0.1 with Service Pack 1. Please let me know if there are any more extra patches to add.

I think this is the new behaviour in 6.0.1 In 4.6 the extra Element delimiters were not present but I notice them in 6.0.1 they are now present. If I remember correctly EDI Translators do the same thing so I do not expect any problems with it.

HTH

yes,according to v4.6 its not happening(no extra delimiters) and works fine…regarding in 6.01 i am not sure…since we are in the design phase for implementing in that…but good to know this nature before…

Thanks for sharing…

Hi folks,

I’m facing a problem regarding this issue … I’m defining no segment-delimiters … neither in the template nor as parameter to convertToString, but even this way, the output string includes a LF character in the end of the line.
Does anyone knows what causes this behavior?
I’m using IS 4.6 …

Thanks in advance.

“LF character in the end of the line.”

So are you seeing new line for each segment?

This is curious … If I open the result string in notepad, it shows a character represented by a square, but if I open it in wordpad I see a new line for each segment … windows’ stuff!
Unfortunately, the app that will read the flat file, thinks (or don’t think :^) … ) like notepad and waits for a cr/lf in the end of the line.
Back to the odd question, why wM puts a LF if I’m not defining any segment delimiter in any place?

character represented by a square indicates spaces in the file (in notepad).You can check this Hexa values from ultra-edit tool.

LF problem-i guess your template might be creating that new line and LF delimiters,Can you pls check the flatfile you are using…since convertToString default delimiters uses differently.

Renato,

The character you see represented by the square is the newline (LF) character and not a space. Depending on the what you are using to view the file you will see a newline or the viewers representation of the newline character. Ultra-EDit, Textpad will get you the proper viewing where as Notepad will not.
in 4.6 wm will always end every record (segment delimiter) with a hex 10 newline character. There is no way around it. Even if you leave it out of the template or place another value in there it will always be hex 10.
In other words all records will be separated by a LF.
If wm exists on one platform (say UNIX) and you app on another (say WIN) and you’re FTPing the files back and forth add the ASCII command to the FTP script to get rid of LF translation problem. UNIX expects a hex 10/15 (CR/LF) where as Windows expects a hex 10 (LF) (or the otherway around) The ASCII command in the FTP script translates between them.
Hope I haven’t gone off on the wrong tangent.

HTH

Regarding 4.6 always placing a 0x0a at the end of every segment, that’s not the behavior I’ve seen. We’ve been able to use any segment delimiter we want and have not experienced “forced” LF delimiters. The default segment delimiter is LF. I’ve never successfully used delimiters specified in a template (only used custom templates a couple of times) so don’t know if there might be a bug or if it just doesn’t use delimiters from a template properly when creating output. Maybe delims in a template are for reading use only?

Passing delimiters to convertToString and to the EDI enveloping services has always done the right thing for the EDI projects I’ve worked on. I did a flat-file project to generate a flat-file but didn’t need to use a template–the EDI module can create a flat-file without a template in some cases. In this case, the delimiters were passed to convertToString and they were placed properly in the file.

UNIX normally uses 0x0a (LF) for EOL
Windows normally uses 0x0d 0x0a (CR/LF) for EOL
Mac normally uses 0x0d (CR) for EOL

As Chris points out, if files are FTP’d around and you want to keep CRs and LFs untouched, you’ll want to use binary mode.

Notepad (pre-XP) only understands CR/LF EOL. Stand-alone CR or LF appear as non-printable chars (usually an empty white box) as do other control characters. Wordpad understands multiple types of EOL markers, as does the aforementioned TextPad.

We just ran into nasty UltraEdit behavior–it massages end-of-line (EOL) markers to normalize to CR/LF pair. So a single CR or LF is changed to CR/LF. LF/CR is changed to CR/LF. CR/CR/LF is changed to CR/LF. Has anyone else seen this UltraEdit behavior? Is there a way to turn it off?

In UltraEdit, I try to always remember to use the menu FILE_CONVERSIONS DOS to UNIX or UNIX to DOS to handle the conversions. Since I work mostly on Windows to UNIX, it removes the ^M from the end of each line.

Ray

What we’re seeing is that the EOL munging is happening automatically. EOL is always forced to CR/LF.

Rob,

Rob, yes my comments are directed toward the templates and not convertToString

In using the templates for flat files in 4.6 the docs specifying 10 (hex) as the segment delimiter. No matter what value you place there it will always be the hex 10. This drove me crazy last year and tech support confirmed it.
The behaviour is different if specifying the delimiters in convertToString where you can specify alternate delimiters.

Hi guys,

Thanks for the useful tips … Since I need to deliver this doc to another server I’ll try to use the FTP (ASCII mode) to solve that issue … I hope it works!

Many, many thanks.

I think I learned quite a bit about the various forms of the end of line characters in different systems. Thanks for all the info.

Coming to the original post of mine, it looks like 6.0.1 is having a bug and generating these extra delimiters when I call convertToString as people using 4.6 dont experience this behaviour. Again, I think these delimiters should not impact when run through various EDI translators.

As always, thanks to all of you for contributing

Hi I am using WM 4.6 with the EDI adapter package. When I use the convertToString service for some reason a ‘:’ is being placed within the data string. I am not using a template, instead I am providing a namespace record of my structure alonq with the segment (~) and field (*) delimiters. I guess I am doing something wrong but I am not sure what. My record is defined like the x124010 997 (ISA,GS,ST,AK1,AK2,AK5,AK9,SE,GE,IEA) with the AK2 and AK5 segments as record lists.
Any help will be greatly appreciated.
Thanks

That looks like the default subfield delimiter. Just checking to see if you defined any subfield delimiter in the service convertToString. If u can post the generated EDI data, we may be able to help you identify the problem.

Thanks for the quick response Manohar. No I am not supplying a sub-field delimiter. Here is how my data appears,
ISA00 * ZZE725 EZ25003015544774480898201315U0040100000000011P~:GSFAE725 E7250035544774482003062513150000000001X004010~ ST9978383~AK1IN21~AK28500219~AK5A~AK28100220~AK5A~
AK28100221~
AK5A~
AK28100222~
AK5A~
AK28100223~
AK5A~
AK28100224~
AK5A~
AK28100225~
AK5A~
AK28100226~
AK5A~
AK28100227~
AK5A~
AK28100228~
AK5A~
AK28100229~
AK5A~
AK28100230~
AK5A~
AK28100231~
AK5A~
AK28100232~
AK5A~
AK28100233~
AK5A~
AK9A151515~
SE348383~

…1P~:GS… doesn’t look right.

It should be …1P*:~GS…

How is the ISA being created?

You need to fill your sub-field delimiter also when you call your convertToString service and in your case, it looks like it is ‘:’ generated by system. As Rob pointed out, your ISA seems to be wrong.
The last 3 characters in your ISA just before ‘GS’ represents the delimiters field, subfield and segment respectively. These are mandatory.

FYI

IS 601 Fix17 fixes Unwanted Delimiters in EDI segments.