|
View previous topic :: View next topic
|
| Author |
Message |
amarjit singh
New User
Joined: 08 Mar 2013
Posts: 30
Location: india
|
|
|
|
Hello Experts,
A file is received by email from mainframe. Could you please help me, how to modify the line advance from LF to CRLF ?
regards,
amarjit |
|
| Back to top |
|
 |
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
| Well, as the mainframe (z/OS) does not use LF or CRLF the LF must have been put there by a program in which case get the program changed. If it came from UNIX then get it FTPed as the FTP software will do the conversion for you. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| Nic has given you a good explanation; but on the other hand, I'm thinking - why do you ask this question; what prompted you to think about LF/CRLF - specially for a file sent by an e-mail (SMTP)? |
|
| Back to top |
|
|
amarjit singh
New User
Joined: 08 Mar 2013
Posts: 30
Location: india
|
|
|
|
| Anuj Dhawan wrote: |
| Nic has given you a good explanation; but on the other hand, I'm thinking - why do you ask this question; what prompted you to think about LF/CRLF - specially for a file sent by an e-mail (SMTP)? |
Thank you NIC and Anuj.
there is a mainframe program which prepare jcl, submit job via internal reader, read PS file and send the data as attached text file through TCPIPSMT.
Now the client asking: line advance changed from CRLF to LF. Please modify so that file has CRLF as it was originally created.
i am not sure how to approach for the above issue. please guide.
thanks,
amarjit. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
You need to go to the client and ask them what changed on their end. RFC 2821 is the official statement of what an SMTP message looks like, and it explicitly states that CRLF is used in:
| Quote: |
2.3.7 Lines
SMTP commands and, unless altered by a service extension, message
data, are transmitted in "lines". Lines consist of zero or more data
characters terminated by the sequence ASCII character "CR" (hex value
0D) followed immediately by ASCII character "LF" (hex value 0A).
This termination sequence is denoted as <CRLF> in this document.
Conforming implementations MUST NOT recognize or generate any other
character or character sequence as a line terminator. Limits MAY be
imposed on line lengths by servers (see section 4.5.3).
In addition, the appearance of "bare" "CR" or "LF" characters in text
(i.e., either without the other) has a long history of causing
problems in mail implementations and applications that use the mail
system as a tool. SMTP client implementations MUST NOT transmit
these characters except when they are intended as line terminators
and then MUST, as indicated above, transmit them only as a <CRLF>
sequence. |
and from the wording of this quote, the ONLY way an LF would replace CRLF would be if that were done by the receiving system -- not the SMTP originating system nor any relays along the way. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| amarjit singh wrote: |
| there is a mainframe program which prepare jcl, submit job via internal reader, read PS file and send the data as attached text file through TCPIPSMT. |
Pardon my ignorance but I think, TCPIPSMT, is a local program at your shop, which might mean anything, however, I'll assume it's a program used to send an e-mail from zOS.
Second, where do you send the data - Unix Box, a Win Base System or..?
I'll assume - it's win base system because UNIX only needs LF , it is Windows which needs both CR and LF. Is that correct?
Well - made all those assumptions but you'll be surprised to know that if they are true, you're entitled to follow what Nic has said at first place. |
|
| Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011
Posts: 556
Location: USA
|
|
|
|
As an experiment, try sending the email to yourself. Open it in Windows something and see if it looks ok.
If it looks ok in notepad, it has cr/lf. If it only looks right in wordpad, then it's probably only cr. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| I assumed TCPIPSMT is the SMTP started task that z/OS runs via TCP/IP. If it is something else, however, then the question becomes what is your site using to send emails? |
|
| Back to top |
|
|
amarjit singh
New User
Joined: 08 Mar 2013
Posts: 30
Location: india
|
|
|
|
| Anuj Dhawan wrote: |
| amarjit singh wrote: |
| there is a mainframe program which prepare jcl, submit job via internal reader, read PS file and send the data as attached text file through TCPIPSMT. |
Pardon my ignorance but I think, TCPIPSMT, is a local program at your shop, which might mean anything, however, I'll assume it's a program used to send an e-mail from zOS.
Second, where do you send the data - Unix Box, a Win Base System or..?
I'll assume - it's win base system because UNIX only needs LF , it is Windows which needs both CR and LF. Is that correct?
Well - made all those assumptions but you'll be surprised to know that if they are true, you're entitled to follow what Nic has said at first place. |
thank you all for your respective responses.
The requirement is to change the LF to CRLF.
Not sure what the problem actually is. Fact is that a Job is generating another job via INTRDR which create the SMTP input which is a sequential dataset having fixed record length. TCPIPSMT is a started task running on the mainframe that sends the emails via TCPIP.
As Robert said, the problem is when it is extracted from the email on the addressee's side. This is where a CR LF issue could be corrected.
But i am unable to get to the point of problem and how to rectify it.
regards. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Are you using an attachment?
If yes, what kind of attachment -- MIME or plain text or something else?
SMTP will transmit EBCDIC text data to a Windows / Unix system and convert the EBCDIC text to ASCII text; the CRLF is automatically appended to the records by SMTP (as long as the EBCDIC record length does not exceed the 998 maximum allowed by RFC 2821). And as long as your site is using standard SMTP, then the transmitted file will have CRLF and if that is not what your client is receiving then you need to look at the receiving system and subsequent processing to find the issue.
You may have to get your site support group to put a network sniffer on the line to trace the data coming from the mainframe; if there is X'0D0A' in the data then you've got CRLF and the problem would be isolated to the receiving system and any subsequent processing being done. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| Quote: |
| I assumed TCPIPSMT is the SMTP started task that z/OS runs via TCP/IP. |
Thanks TANSTAAFL ..err...'Donald Knuth'...err Rob..hff..Bob! Did I leave any of your nick? 
Thanks Robert...  |
|
| Back to top |
|
|
amarjit singh
New User
Joined: 08 Mar 2013
Posts: 30
Location: india
|
|
|
|
| Robert Sample wrote: |
Are you using an attachment?
If yes, what kind of attachment -- MIME or plain text or something else?
SMTP will transmit EBCDIC text data to a Windows / Unix system and convert the EBCDIC text to ASCII text; the CRLF is automatically appended to the records by SMTP (as long as the EBCDIC record length does not exceed the 998 maximum allowed by RFC 2821). And as long as your site is using standard SMTP, then the transmitted file will have CRLF and if that is not what your client is receiving then you need to look at the receiving system and subsequent processing to find the issue.
You may have to get your site support group to put a network sniffer on the line to trace the data coming from the mainframe; if there is X'0D0A' in the data then you've got CRLF and the problem would be isolated to the receiving system and any subsequent processing being done. |
Thank you all.
The issue got resolved. I informed the same to the vendor and it was corrected from their side after consulting with user. Thank you everyone for the quick responses which helped to clear the doubt. Regards. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
So we've invested a good amount of time for an issue, which was nonexistent, at your end... 
Nonetheless, glad to hear that you got it working! |
|
| Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011
Posts: 556
Location: USA
|
|
|
|
I would like to ask that you get the resolution from the client/vendor and post it here. What was done to fix the issue?
The next person reading this would be grateful, I'm sure. |
|
| Back to top |
|
|
amarjit singh
New User
Joined: 08 Mar 2013
Posts: 30
Location: india
|
|
|
|
| Ed Goodman wrote: |
I would like to ask that you get the resolution from the client/vendor and post it here. What was done to fix the issue?
The next person reading this would be grateful, I'm sure. |
Hi,
even i would love to know the solution..
scenario: it was an incident ticket raised by the user. i summerized all the above suggestion given by respective forum members and replied to user. Taking suggestion into account, user directly had a discussion with 3rd party vendor and informed us to close the ticket as the issue has been resolved. if i get a chance to know the solution from user (which i doubt), i wiil post here for future reference. thanks. |
|
| Back to top |
|
|
|
|
