IBM zoned, packed what the ... is this?

[jmoore207]

I am getting a file from a client which I assume is coming from a mainframe and is being transfered over to a unix box. I am running the file through sql-loader to populate an Oracle table. The field I am having a problem with is being moved to fields depending on which code it is. The position of the field is:

tbelec position(027:033) "nvltbelec ,'0')" ,
The problem is the input from the ftp'd transfer file has an ascii character and I cannot for the life of me figure out how to make Cobol get rid of it. Here is what some of the fields look like. It does not always have acharacter at the end.
0000400
000020p
0000400
000020p
0000084
0001500
000013s
000020p
0000400
0015000
0001000

Any ideas on how to fix this? Thank you!

 

[fredericofonseca]

That looks like a ASCII sign representation of a negative value, but not from a mainframe, but rather another system.
Ascii negative numbers go from p (-0) to y (-9)

as you are using SQL*Loader you just need to use the correct load options and column definitions to have it load the numbers correctly

You need to see exacly what is the source of that file, what is the record definition and map it correctly on your CTL file

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[papadba]

FWIW - those numbers are neither mainframe packed-decimal not mainframe zoned-decimal.

They do look like the zoned-decimal values we used with MicroFocus COBOL on UNIX.

If you want the sending program to produce more "friendly" numbers the code can be changed to use an edit mask to present numbers like
0001500
0000133-
0000200-

instead of

0001500
000013s
000020p

A picture of 9999999- should preserve the leading zeros and generate the minus sign for negative values in the output. The input would be defined as pic s9(7).

 

[BruceMartin]

As already stated this is an Ascii Cobol, with the negative sign included in the last digit.

20p = -200
20q = -201
20r = -202
....
20y = -209

Currently the field is defined as s9999999,
You could ask for the format to be changed e.g. -9999999 would give you -0000200 instead of 000020p
or decipher it your self.