sequential file text binary (unix to ZOS)

gge · Post by **gge** » Fri Feb 29, 2008 5:57 am

sequential file text binary (unix to ZOS)

ZOS file has lag problems (add of blanks).

I created a file in datastage text + binary

first column : char(1) text (values '1';'2';'9')
second column : decimal [4,0] binary (take 3 in binary not 4)
third column : char (10)

In datastage, I see only first column because datastage is not able to show binary columns (view data option).
unix sequential file viewed in datastage :
1
2
2
2
2
2
2
2
2
9

IN ZOS file the file is like a stairwell :
I put "-" instead of blanks " " to show :

1
-2
--2
---2
----2
-----2
------2
-------2
--------2
---------9

How is it possible in a stage Seq file to remove these blanks ?

Dis somebody has an idea or already solved this problem ?

Best Regards, Gabriel Georgin.

ArndW · Post by **ArndW** » Fri Feb 29, 2008 6:07 am

According to your metadata that will not be the output format. Can you view your file with a binary editor on UNIX to see what the contents actually are?

ArndW · Post by **ArndW** » Fri Feb 29, 2008 6:49 am

I am afraid that you haven't quite answered the question I wanted to ask, sorry. In DataStage run the job and view the output file in UNIX with a binary editor. I am fairly certain that there are no "lag problems" (a term that I haven't heard before) in that file. This conversion is almost certainly happening when you copy the file to ZOS, so DataStage cannot fix it.

gge · Post by **gge** » Fri Feb 29, 2008 7:34 am

The format in output for second column wanted was PIC 9(4) COMP-3
=> format 3 hexadecimal
in datastage it is : decimal [4,0] {packed} ("type format binary")

ray.wurlod · Post by **ray.wurlod** » Fri Feb 29, 2008 3:27 pm

What happens if you use an unsigned data type in DataStage? (I suspect it may be leaving a space for the sign character, though why this would accumulate I have no idea.)

gge · Post by **gge** » Sat Mar 01, 2008 1:56 pm

The wanted format was : PIC 9(4) COMP-3

But decimal[4,0] {packed} is PIC S9(4) COMP-3

SO i tried with decimal[4,0] {packed} type format = binary

My real problems is :
I have 5 columns :
1st column : char(1) (no problem but type format = text)

2nd column : decimal[4,0] (type format = binary)
wanted 3 length hexadecimal because COBOL Format is PIC S9(4) COMP-3 take 3 spaces for size in binary (problem because type format = binary and format really wanted PIC 9(4) COMP-3 for COBOL => unsigned)

3rd column : decimal[8,0] (type format = binary)
wanted 5 length hexadecimal because COBOL Format is PIC S9(8) COMP-3 take 5 spaces for size in binary (problem because type format = binary and format really wanted PIC 9(8) COMP-3 for COBOL => unsigned)

4th column : decimal[7,0] (type format = binary)
wanted 4 length hexadecimal because COBOL Format is PIC S9(7) COMP-3 take 4 spaces for size in binary (problem because type format = binary and format really wanted PIC 9(7) COMP-3 for COBOL => unsigned)

5th column : char(137) (no problem but type format = text)

Seq file stage at output with :
final delimiter = end
delimiter = none
quote = none

If I add unsigned => no change at output file in ZOS.
like a stair.

gge · Post by **gge** » Tue Mar 04, 2008 6:58 am

The issue seems to be like that :

"
Even though the message is not currently viewable in it's entirety, the portion that is visible gives you the clue on how to solve your problem. Basically, a "\n" (UNIX), or <CR><LF> (Windows) is just another string that can be manipulated with normal string functions. "

But I'm testing.

Because The differences between file seen in Hexadecimal or in text mode seem to be a CR(carriage return : 015 or 0D or D) + LF (Line Feed or new line : 012 or 0A or A).

With that asciitable i probably find a solution :
http://www.asciitable.com/

gge · Post by **gge** » Wed Mar 05, 2008 4:06 am

It is probably a problem of transfert from Unix to ZOS in mode text .

Because in mode binary it will be ok.

ArndW · Post by **ArndW** » Wed Mar 05, 2008 4:45 am

Ummm, since you have COMP-3 you must transfer in binary, otherwise the data is corrupted.

gge · Post by **gge** » Thu Mar 13, 2008 4:19 am

The solution :

In the shell script :

I added a :
sed 's/\x0D$//' file

So the file before being transfered have no '\r' or CR or 'x0D'

Only have a delimiter of end of line : '\n'.

gge · Post by **gge** » Fri Mar 28, 2008 10:59 am

The solution was :

Unix and Zos are not the same OS ...

So cp in Unix and cp in Zos are differents ...

cp in Zos ask for explicit information about delimiter ONLY for binary !

So "cp -F lf filesource filedest" in Zos => copy file source to filedest and not copy delimiter "lf" linefeed !

So becarefull about copy in unix and in Zos !