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

RE: Omitting Carriage return when sending data

From: "Carl Galgano" <cgalgano2@...>
Date: Sun Mar 10, 2002  11:27 pm
Subject: RE: [EDI-L] Omitting Carriage return when sending data
Michael:
I have always enjoyed your posts to this group in the past and your
posts have always been very informative, especially when it comes to the
internals of how the GXS network works. You have even helped me out
when I was looking for some info while writing an FTP routine for a
client to the GXS network. But your comments about the AS/400 are not
accurate. I do not dispute the fact that perhaps you have had some
implementation issues with clients who have an AS/400, however, it is
NOT the AS/400's implementation of the TCP/IP stack or it's FTP client
that caused you problems, it has to do with the way the AS/400 stores
data.

The AS/400 support many different files system. The traditional file
system on the AS/400 (known as QSYS.lib) is rooted in DB/2. As you
pointed out, the AS/400 file system uses EBCDIC as it's encoding (8 bit
rather than the 7 bit ASCII. Basically binary arithmetic tells you
there are 256 possible characters in EBCDIC and 128 with ASCII).
Sometimes when translating from EBCDIC to ASCII there are some
characters that do not have exact translations. However, this is not
the problem you have seen. The QSYS.lib file system generally uses a
file/record/field type structure that is based on fixed length records.
While variable length records are possible on the AS/400, they are
rarely used. When EDI is transmitted from an AS400 via FTP from a fixed
length file, the end of record indicator is converted to a hex (0a0d, ie
CR/LF). The CR/LF is not actually stored in the AS400 file, it is
implied by the fact that the record length is 80 (or 132) bytes in
length. There are 2 very simple solutions to this problem, and the
front ending of an AS400 with a PC is not required and certainly not
recommended.

1. The file can be converted to a different file system. As I
reference above, the AS/400 supports many different files systems. One
is called the IFS (Integrated File System) and can look to the AS/400
like a PC based file system, supporting a nested directory type
structure. The AS400 physical file (stored in the QSYS.lib) can be
converted to the IFS with the CPYTOSTMF (Copy to Stream File) command.
This command will convert the file to an ASCII file format, and there
are options on the command that specify how to handle the CR/LF issue.
One option is to exclude them. At that point in time, you would have a
file, exactly the way the GXS system wants to see it. FTP can then be
initiated from the AS400 and the file can be send from the IFS (remember
this is NAMEFMT 1).

2. The other option would be to have the AS400 physical file contain
the EDI data in an unwrapped format. Thus each segment would be
contained in a single AS/400 record, with NO segment terminator. Then
when the data is transmitted with FTP, specify that the server truncated
the trailing blanks (I believe this is the STRUCTURE FTP subcommand).
Thus the data will be transmitted with a CR/LF as the segment terminator
and NO trailing spaces. While the file will look like it is unwrapped
on the AS400, the FTP server will see this file as a wrapped file with
the proper segment terminators.

I hope this info is useful to you. I am very willing to help you if you
need help supporting clients that use the AS/400. IBM has a wonderful
secret in this server and does a very bad job (IMHO) of marketing it. I
want to be sure that misinformation about this hardware platform is not
spread, and that people do not use work around solutions, such as front
ending the communications for an AS400 with a PC. I have 4 AS400s in my
office running various OS version and of varying age. One of them is 10
years old, running an old version of the OS (for client support, some of
our customers still have some old stuff out there), and the machine has
been running for 10 years straight, 24/7/365 with 4 hours of downtime!!!
I can not report that level of reliability with the various W2000
servers that are also on our network.

Please let me know if I can help.

Regards.
cjg

Carl J. Galgano
EDI Consulting Services, Inc.
550 Kennesaw Avenue, Suite 800
Marietta, GA 30060
(770) 422-2995 - voice
(419) 730-8212 - fax
mailto: http://www.ediconsulting.com
AS400 EDI, Networking, E-Commerce and Communications Consulting and
Implementation
http://www.icecreamovernight.com
Premium Ice Cream Brands shipped Overnight
FREE AS/400 Timesharing Service -
http://www.ediconsulting.com/timeshare.html
"You ain't gonna learn what you don't want to know" - rw


-----Original Message-----
From: Burbury, Michael (GXS) [mailto: Sent: Sunday, March 10, 2002 4:38 PM
To: Redlin, Ian (MN10)
Subject: Re: [EDI-L] Omitting Carriage return when sending data


Hi there all,

The issue here is confusion about the two data transfer protocols.

Bisync 3780 is a block protocol and records are wrapped. Therefore at
the server end (GEIS) the 3780 program unwraps the data prior to
submission to EDI*EXPRESS for processing.

With TCP/IP FTP it does not do this. (Afterall, it's an Internet
protocol, not an IBM one)

You are not required and you should not block your data at 80bytes when
sending FTP. The data (assuming you are sending ANSI X.12) will be
variable length records and use the CR (Hex OD) as a segment terminator.
On the AS/400 which is EBCDIC - the HEX 15 character will translate to
an ASCII HEX 0D upon FTP in ASCII mode, so on the AS/400 your segment
terminator is the HEX 15 character.

Be sure to specify ASCII mode transfers in your FTP process.

The IBM AS/400 implementation of the TCP/IP stack and FTP has raised
several headaches for me, you are better to "front -end" your AS/400
with a PC, life will be easier.


Cheers...

Michael Burbury
GE ecXpress Australia.
System Administration
----- Original Message -----
From: "Redlin, Ian (MN10)" < To: < < < Sent: Saturday, March 09, 2002 4:07 AM
Subject: RE: [EDI-L] Omitting Carriage return when sending data


> Ron -
>
> The process of wrapping the data into an 80 character file, as you
> stated below, is creating the carriage return. If you view the file
> you create as hex data, after every 80 characters will be a 0d
> character (a
non-printable
> character).
>
> Ian Redlin
> IT Professionals
> Honeywell, ACS
>
>
>
> -----Original Message-----
> From: Ron Katz [mailto: > Sent: Friday, March 08, 2002 9:59 AM
> To: > Subject: RE: [EDI-L] Omitting Carriage return when sending data
>
>
> Mickey
> I am sending the file as ASCII.
> When I tested FTPing the file to my AS/400 as binary, all of the
> characters got converted to non displayable characters. When I FTPed
> in ASCII mode to the AS/400, the data looked good. What I mean by
> wrapped records is the segments continue on the next record, when it
> reached 80 bytes. This is how the data should be sent and the way we
> are currently doing it with Bysinc protocol. I don't see where I am
> creating any blocking factors. I am just writing to a file that is 80

> bytes.
>
> Ron Katz
> RK Consulting Inc.
> 401-334-2463
> >
> -----Original Message-----
> From: Mickey Dossey [mailto: > Sent: Friday, March 08, 2002 10:31 AM
> To: > Subject: RE: [EDI-L] Omitting Carriage return when sending data
>
> Ron, depends on your ftp client/options. Configuring the ftp to send
> the file as binary versus text is often a quick fix. Otherwise, there

> should be switches in your ftp command/software to specify how you
> send records. How exactly are you sending the file? Mickey Dossey
>
>
> ----- Original message ---------------------------------------->
> From: Ron Katz < > To: < > Received: Fri, 8 Mar 2002 10:22:16 -0500
> Subject: [EDI-L] Omitting Carriage return when sending data
>
> I am sending (FTP) an 80 byte ASCII file to GEIS consisting of an EDI
> document with wrapped records. GEIS says there is a carriage return
> character after each 80 byte record. I am not putting this carriage
> return character in the record. I suspect this is happening with the
> FTP. Can anyone suggest how to omit this carriage return character?
> Thanks in advance.
>
> Ron Katz
> RK Consulting Inc.
> 401-334-2463
> >
>
>
>
>
>
>
> Yahoo! Groups Sponsor
>
>
> ADVERTISEMENT
>
> <http://rd.yahoo.com/M=215002.1818248.3328688.1261774/D=egroupweb/S=17
> 05
>
005582:HM/A=847665/R=0/*http:/ads.x10.com/?bHlhaG9vbW9uc3RlcjcuZGF0=1015
>
601056%3eM=215002.1818248.3328688.1261774/D=egroupweb/S=1705005582:HM/A=
> 847665/R=1>
>
>
> <http://us.adserver.yahoo.com/l?M=215002.1818248.3328688.1261774/D=egr
> ou
> pmail/S=1705005582:HM/A=847665/rand=306758746>
>
> 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 the Yahoo!
> <http://docs.yahoo.com/info/terms/> Terms of Service.
>
>
> [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/
>
>
> 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/
>


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/





 
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-2013 All Rights Reserved.