[EDI-L Mailing List Archive Home] [Message List] [Reply To This Message]

RE: Cleo 3780 & Sterling

From: "Cox, Ken" <ken.cox@...>
Date: Tue Jul 9, 2002  8:34 pm
Subject: RE: [EDI-L] Cleo 3780 & Sterling
?? What happened to the CRs in my Cleo code example ??
MONITOR scnrecv.log

AU 9 T2 NNNNNNN R2

TABLE asciiebc.ovr ebcascii.ovr

KE $$REQUEST ID=NNNNNN BATCHID='password'

RECEIVE /edi/data/scnin1.000

etc.

-----Original Message-----
From: Cox, Ken [mailto: Sent: Tuesday, July 09, 2002 4:27 PM
To: 'Parks, Howard (E) Ext 5288'; Subject: RE: [EDI-L] Cleo 3780 & Sterling


Hi,
Like Howard, I was never able to resolve this in a "proper" manner. (Cleo
works reliably, day in, day out for years, but I haven't dealt with their
"support" in years due to the smug attitude and no help at all I first
encountered. They may be different now, but years ago the answer I got was,
paraphrased, "Our product is a mature product and it works. You must be
doing something wrong.")

When we switched to Sterling Commerce in 1997, we were receiving an RS (hex
1E) every 80 characters, which was causing extra linefeeds in the data,
improperly splitting ISAs and any other segments longer than 80 characters
in length. I determined this (the RS/1E) from the log file produced by the
MONITOR statement.

My solution has two parts: 1) I modified the line in the ebcascii.ovr file
which read "0x1e 10" to read "0x1e 00".
2) I added a statement to my Unix script to get rid of the hex "00"
characters: tr -d "\000" < origfile > goodfile

You implement ebcascii.ovr with the Cleo TABLE statement. e.g. MONITOR
scnrecv.log AU 9 T2 NNNNNNN R2 TABLE asciiebc.ovr ebcascii.ovr KE $$REQUEST
ID=NNNNNN BATCHID='password' RECEIVE /edi/data/scnin1.000 etc.

Ken Cox
Brach's Confections

-----Original Message-----
From: Parks, Howard (E) Ext 5288 [mailto: Sent: Tuesday, July 09, 2002 2:49 PM
To: Subject: RE: [EDI-L] Cleo 3780 & Sterling


I was told, in the early days of my adventures with bisync and Cleo, that by
choosing the proper settings for the parameters, this problem with 80 byte
blocks or one run-on line could be solved automatically. I was never able
to achieve this. The VANs and Cleo people had different terms for
parameters, to confuse things, and each change on the VAN side required a
phone call and putting up with their grousing. Time for Plan B.

One of my prouder accomplishments was my "unblocker" program that turned a
file divided into 80 byte records (with lf characters as a record separator,
I think) into a file of one segment per line, terminated by a cr/lf. This
was written in DCL. This program required a small change for Wal-Mart,
enough of a change that I kept the two versions separate. The only trick
involved was finding where in the process to put this program, because this
transformation had to be done after the file was received (obviously) but
before it was imported into the translator, and the translator controlled
the whole process. The translator called a DCL program to invoke the Cleo
software, I discovered after some poking around, so that solved my problem.
I edited that program to add an invocation of my own.

While I never experienced the problem with lf as a segment terminator that
Chris described, we did see a few wrinkles. In most circumstances, after
each IEA segment, the remainder of the record would be space filled, and the
next record would begin with the ISA. On occasion, however, there would be
10-20 spaces after the end of the IEA and the next ISA would begin. Also,
we saw enough variation in element separators and segment terminators to
redefine them after each ISA was encountered.


Howard Parks
1 Peter 4:10


To unsubscribe from this group, send an email to:
Message Identifiers: <SALES>, <JOBS>,
<LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the list online at:
http://groups.yahoo.com/group/EDI-L


Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



[Non-text portions of this message have been removed]



To unsubscribe from this group, send an email to:
Message Identifiers: <SALES>, <JOBS>,
<LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the list online at:
http://groups.yahoo.com/group/EDI-L


Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



[Non-text portions of this message have been removed]




 
EDI to XML Mapping for EDIFACT/X12 Convert EDIFACT/X12 Schemas to XML Schema Legacy Data Conversion Tools Access Relational Data as XML Visual XSLT and XQuery Mapping Tools Simplify EDI Data Integration with Stylus Studio XML Enterprise Suite - Free Download!
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2007 All Rights Reserved.