COBOL Bit Field

PhilHibbs · Post by **PhilHibbs** » Tue Jul 12, 2011 7:12 am

Any tips on how to read a source file that has a PIC 1(8) field?

The source file is EBCDIC so defining it as PIC X(1) will mangle the bits up. DataStage doesn't like PIC 1(8), and if there is a PIC code for 1-byte unsigned binary integer then I can't figure it out.

Is it possible to override the EBCDIC to Unicode translation at the field level? If so I could declare it a CHARACTER field and use the Pos function to work out which bits are set. There might be some bit combinations that cause problems, but I think we're only expecting a small number of combinations so we might be lucky.

FranklinE · Post by **FranklinE** » Tue Jul 12, 2011 9:31 am

I'm unfamiliar with the clause PIC 1(#). Is there a usage clause in the Cobol code for the field in question? Anyway, I'm not sure how helpful I can be without understanding the storage format you are facing under EBCDIC. One thing I do know in 7x, there is darn little help converting raw binary to anything useful.

MicroFocus considers what you describe the "tinyint" format, and suggests a default of PIC S9(4) usage comp-5. Reference 3.2 Integer Data Types for what little detail they offer.

PhilHibbs · Post by **PhilHibbs** » Tue Jul 12, 2011 10:15 am

FranklinE wrote:I'm unfamiliar with the clause PIC 1(#). Is there a usage clause in the Cobol code for the field in question? Anyway, I'm not sure how helpful I can be without understanding the storage format you are facing under EBCDIC. One thing I do know in 7x, there is darn little help converting raw binary to anything useful.

MicroFocus considers what you describe the "tinyint" format, and suggests a default of PIC S9(4) usage comp-5. Reference 3.2 Integer Data Types for what little detail they offer.

PIC S9(4) would be a 16 bit binary, but the field is a single byte.

FranklinE · Post by **FranklinE** » Tue Jul 12, 2011 10:55 am

Gods, sometimes I hate Google. It thinks it knows better than I do what I want. :?

Anyway, found this: http://www.tek-tips.com/viewthread.cfm? ... 04&page=66

In other words, PIC 1(8) would be the same as PIC 9(1) COMP-5.

Let me know if that works.

PhilHibbs · Post by **PhilHibbs** » Wed Jul 13, 2011 2:28 am

FranklinE wrote:Gods, sometimes I hate Google. It thinks it knows better than I do what I want. :?

Anyway, found this: http://www.tek-tips.com/viewthread.cfm? ... 04&page=66

In other words, PIC 1(8) would be the same as PIC 9(1) COMP-5.
Let me know if that works.

No luck I'm afraid, I still get a "short read", and the field is still defined with Storage length = 2 in the Derived Attributes.

PhilHibbs · Post by **PhilHibbs** » Wed Jul 13, 2011 4:51 am

Solved it! I redefined these two fields:

Code: Select all

               05 IND-CHAR            PIC X.                             
               05 F-TITLE             PIC X(10).

as this:

Code: Select all

               05 IND-TITLE-1.
                  10 IND-CHAR            PIC X.
                  10 F-TITLE             PIC X(10).
               05 IND-TITLE-2 REDEFINES IND-TITLE-1.
                  10 IND-CHAR-2          PIC 9(2) COMP.
                  10 F-TITLE-2           PIC X(9).

Then I extract the bits of the low byte of IND-CHAR-2 thus:

Code: Select all

BitAnd( DSLink1.IND_CHAR_2, 1) > 0
BitAnd( DSLink1.IND_CHAR_2, 2) > 0
BitAnd( DSLink1.IND_CHAR_2, 4) > 0
BitAnd( DSLink1.IND_CHAR_2, 8) > 0
BitAnd( DSLink1.IND_CHAR_2, 16) > 0
BitAnd( DSLink1.IND_CHAR_2, 32) > 0
BitAnd( DSLink1.IND_CHAR_2, 64) > 0
BitAnd( DSLink1.IND_CHAR_2, 128) > 0

Simples! For some reason BitExpand just returned a string of zeros, so I pulled the bits out individually. F_TITLE is the 10-character TITLE field, F_TITLE_2 and IND_CHAR are discarded.

PhilHibbs · Post by **PhilHibbs** » Wed Jul 13, 2011 5:51 am

Re-opening the topic because it is only partially solved. I tested it on a Windows machine, but our Z/OS Linux server is big-endian so it interprets the two-byte binary integer differently. How can I force it to be little-endian? Is there a COMP- code that specifies byte order?

*Edit* Or, is there a way of detecting what the platform endian convention is in DataStage?

*Edit* Actually given that there are other binary numerics in the data, and they are going to be big-endian, I think we'll just live with the fact that this job will only work correctly on a big-endian architecture and if we do ever need to port it to little-endian then we'll just override the schema from platform-default to big-endian.