Originally posted by: PaulBrettIBM

The PC environment and the Unix environment normally use different end-of-line characters in text files.

The PC uses <CR><LF> (0x13 0x10) whereas the Unix platforms use just <LF> (0x10).

The end-of-line characters are placed into the file as the text lines are written by the application (for example, an editor) based on the environment the application is running on (Windows versus Unix). If you are sharing text files between the PC environment and the Unix environment, one of the environments sees end-of-line characters at the end of each line of text that it does not normally expect.  Some applications (such as WTX/ITX) may not successfully process a text file if the wrong end-of-line characters are in the text file.

Typetrees can use the <NL> identifier, and the engine uses either <CR><LF > or <LF> depending on the execution platform.

Where data is incorrectly transferred (in Binary mode) from PC to Unix however, the wrong end-of-line character sequence will be in place in the file, for the execution platform.

An example trace might show:

(Level 2: Offset 389, len 6, comp 3 of 3, #1, DI 000000000007:)
Data at offset 389 ('00000<CR>') fails maximum size requirements
TYPE X'0012' (total_hours element example).

(Level 2: Offset 389, len 6, comp 3 of 3, #1, DI 000000000007:)
Data at offset 389 ('00000<CR>') is INVALID data of TYPE
   X'0012' (total_hours element example).

(Level 1: Offset 297, len 98, comp 1 of 1, #4, DI 000000000008:)
Data at offset 297 ('Work A.         ...') is INVALID data of TYPE
   X'0007' (timesheet example).

(Level 0: Offset 0, len 396, comp 1 of 0, #1, DI 000000000009:)
Data at offset 0 ('FirstName       ...') is INVALID data of TYPE
   X'0006' (all_employees example).

   INPUT 2 exists, but its type is in error.

   End of Validation messages for INPUT CARD 2.

The tell-tale sign here is that the <CR> sequence is showing as part of the data.

It is therefore important to ensure that the data matches expectations (which in most cases would be <CR><LF for PC and just <LF> for Unix).

Thank you.

Paul.

Follow me on Twitter

Originally posted by: PaulBrettIBM

Some of this content was copied from this great article:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ioea600/smbadap021003899.htm

Thank you.

Paul.

Follow me on Twitter

Originally posted by: DeM0n

What about host ?? i.e when we are dealing with mainframes...what all should we need to take care of ?? any examples like the one above ?

Originally posted by: PaulBrettIBM

z/OS hosts use the EBCDIC character set, so it's even more important to transfer files in an appropriate manner.  A text file transferred in Binary instead of ASCII, might shows a trace such as:

(Level 2: Offset 0, len 76, comp 1 of 3, #1, DI 00000001:)
Data at offset 0 ('&"£$%^&*<CR>') was found to be of TYPE
   X'0005' (Name TextItem root).
(Level 2: Offset 76, len 0, comp 2 of 3, #1, DI 00000001:)
COMPONENT number 2 of TYPE X'0003' (Row root)
  is required, but does not exist.

...instead of what you expected:

(Level 2: Offset 0, len 4, comp 1 of 3, #1, DI 00000001:)
Data at offset 0 ('Paul') was found to be of TYPE
   X'0005' (Name TextItem root).
(Level 2: Offset 5, len 2, comp 2 of 3, #1, DI 00000001:)
Data at offset 5 ('42') was found to be of TYPE
   X'0006' (Age root).

Thank you.

Paul.

Follow me on Twitter