How is a singned numeric represented ina fixed-length file? 1

[petertmartin]

We are looking at passing data as a fixed-length message (via MQSeries) to a COBOL copybook on the mainframe.

If I have a simple copybook e.g.

01 TEST1 PIC S9999V99.

How is the sign represented? Am I correct in assuming -10.00 would be -001000 and +10.00 would be +001000, otherwise how can a negtive number be reprented in a fixed-length file?

I am also unsure as to what impact, if any, the following types of clauses have on the fixed-length file (are they only used for memory management?):

SIGN IS LEADING SEPERATE CHARACTER
SIGN TRAILING SEPERATE
COMP-3

Thanks.

 

[Lunker]

Without any of the extra phrases you ask about your TEST1 field would not contain an actual + or - sign. The sign is defaulted to be stored in the zone portion of the rightmost byte. Your field of PIC S9999V99 with a value of +10.00 would be stored as F0F0F1F0F0C0 and -10.00 would be stored as F0F0F1F0F0D0. A 'C' in the zone represents positive numbers and a 'D' represents negative.

If you use SIGN IS LEADING, then the sign is stored in the zone of the leftmost byte. The phrase SIGN IS LEADING SEPARATE would cause an extra byte at the beginning of the field to store the '+' or '-' sign. SIGN IS TRAILING SEPARATE would cause the '+' or '-' to be stored at the end of the field.

COMP-3 will cause the data to be stored in packed format.

 

[etom]

Packed format (COMP-3) would be represented as follows:

S9999V99 COMP-3 value +10.00.

x'0001000C' <-- 4 bytes with the sign in the last half byte.

-10.00 = x'0001000D'

Comp-3 field lengths can be calculated.
If number of digits is even - divide # of digits by 2 and add 1.
If number of digits is odd - add 1 to # of digits and divide by 2.

Example: 6 / 2 = 3 + 1 (because 6 is even) = 4 bytes.
(5 + 1) / 2 = 3 bytes.

Using the rules above, a 6 digit number takes the same space as a 7 digit number. For this reason, some installations require programs to always code Comp-3 fields with an odd number of digits so you have access to the full size of the field.

etom

 

[webrabbit]

If the data is comming from a pc (Windows), then it is probably in ASCII rather than EBCDIC. Although the rules are the same (the sign is stored as Lunker stated), but the encoding is different, and normal ASCII to EBCDIC translation won't translate the sign correctly. You must tell the COBOL compiler that the file is ASCII, and it will know how to translate the sign.

PACKED-DECIMAL (COMP-3) does not need to be translated, and if the file is processed with a normal ASCII to EBCDIC translater, it will be mis-translated.

 

[petertmartin]

In my original question, the fixed-length message is ASCII. I have no idea about ASCII to EBCDIC conversion, all I wanted to understand was how I a positive and negstive value would be represented in an ASCII fixed-length field if the copybook item is defined as follows:

01 TEST1 PIC S9999V99.

 

[Dimandja]

Yes, Peter, if you are not working with an IBM mainframe, forget packed decimals and EBCDIC. Lunker already (and correctly) fully answered your question.

Lunker deserves a star, if only for taking the time to succinctly answer a question that has been asked and answered repeatedly in this forum, without showing signs of fatigue.

Dimandja

 

[petertmartin]

Thanks for all your replies. However, this might be me just being thick, but, I still don't understand what format a signed numeric is in an ASCII flat file that represents a copybook record (assuming my terminology is correct).

 

[slade]

Hi Peter,

Your last post complicates the problem even further. It sounds like your system is ASCII based. On the other hand, the mainframe is EBCIDIC based. If possible try the following.

It may be helpful to initially define the field as PIC X, where 'n' is the number of positions in the field, including all punctuation.

While I'm not privy to the org structure of your environment, you may then let the pgmr on the mainfame side look at the data and a hand written representation of that data (i.e. what the data truly represents). From this he can determine how to define the field as a numeric data item and also determine how the data will be converted to EBCIDIC. Be sure to provide examples of both positive and negative values.

Regards, Jack.

 

[petertmartin]

We develop Internet-based applications that are written in J2EE and run on WebSphere Application Server. Typically the J2EE application uses MQSeries to communicate with the mainframe (zSeries) via IMS.

The J2EE application accepts data as XML, the programmer will convert the XML document to a fixed-length string and then be send it over a message queue (alongwith the relevant MQ headers), the fixed-length string is sent as ASCII.

I understand this is a common approach, however, I have no idea how it all works on the mainframe and how the developer converts the ASCII to EBCDIC (although I understand MQSeries can also do this) and gets the data into the copybook.

We have done this in the past, however, creating the fixed-length message hasn't been efficient and the copybook has always been non-numeric e.g.

03 USER-INPUT.
05 CONTRACT-TYPE PIC X(5).
05 USER-GROUP PIC X(8).
05 GROUP-NUMBER PIC X(8).
05 LETTER-NUMBER PIC X(8).
05 AGENT-NUMBER PIC X(8).
05 AGENT-NO PIC X(6).

We want to create a smarter way of doing this in the J2EE application and be able to support numeric picture clauses. Hence my question, we don't understand what a COBOL programmer would expect to see in an ASCII fixed-length string for a signed numeric.

Cheers
Peter.

 

[webrabbit]

It appears that you are not presenting your question clearly. Do you know what your data looks like and want to know how to code the copybook to describe the data, or do you have a copybook and need to know what the data should look like? COBOL is very flexable and can read just about any data, you just have to describe it properly with the PICTURE strings.

 

[Dimandja]

What webrabbit said, plus you certainly know that MQSeries specifically addresses translations issues. I were you, I'd let MQSeries do its thing first - it was designed for it.

Dimandja

 

[petertmartin]

Ok, I am not doing very well here, assuming I have the following copybook what would the corresponding ASCII fixed-length record look like (I have included some test data below)?

All I want to do in Java is write an ASCII fixed-length record that a COBOL programmer can load into the copybook.


01 DATE.
05 DATE-YEAR PIC 99.
05 DATE-YEAR-BINARY REDEFINES YEAR PIC 9(4) BINARY.
01 PRODUCT.
05 PRODUCT-NAME PIC X(25).
05 PRODUCT-PRICE PIC 9(5)V99.
05 PRODUCT-QUANTITY PIC 999.
05 PRODUCT-DISCOUNT PIC S(5)V99 SIGN
05 PRODUCT-TOTAL PIC S(10)V99.
LEADING SEPERATE CHARACTER.

Test Data1:
DATE-YEAR: 88
PRODUCT-NAME: MY PRODUCT
PRODUCT-PRICE: 1020.00
PRODUCT-QUANTITY: 5
PRODUCT-DISCOUNT: -100
PRODUCT-TOTAL: 5000.00

Test Data2:
DATE-YEAR: 2000
PRODUCT-NAME: ANOTHER PRODUCT
PRODUCT-PRICE: +20
PRODUCT-QUANTITY: 2
PRODUCT-DISCOUNT: 0
PRODUCT-TOTAL: 40.00

 

[webrabbit]

Your copybook is a little scrambled. I assume you mean
[tt]
01 INPUT-RECORD.
03 DATE.
05 DATE-YEAR PIC 99.
05 DATE-YEAR-BINARY REDEFINES YEAR PIC 9(4) BINARY.
03 PRODUCT.
05 PRODUCT-NAME PIC X(25).
05 PRODUCT-PRICE PIC 9(5)V99.
05 PRODUCT-QUANTITY PIC 999.
05 PRODUCT-DISCOUNT PIC S(5)V99
SIGN IS LEADING SEPARATE CHARACTER
05 PRODUCT-TOTAL PIC S(10)V99
SIGN IS LEADING SEPARATE CHARACTER.
[/tt]
Test Data 1:
[tt]
88MY PRODUCT 0102000005-0010000+000000500000
[/tt]
Test Data 2:
[tt]
yyANOTHER PRODUCT 0002000002+0000000+000000004000
[/tt]
where yy is 0x07D0.

 

[petertmartin]

Thanks, one last question (hopefully), if the &quot;SIGN IS LEADING SEPARATE CHARACTER&quot; was omitted from the copybook would the ASCII record still look the same?

 

[webrabbit]

No. Each field would be one byte shorter, and the sign would be an overpunch.

Test Data 1:
[tt]
88MY PRODUCT 0102000005001000}00000050000{
[/tt]
Test Data 2:
[tt]
yyANOTHER PRODUCT 0002000002000000{00000000400{
[/tt]
where yy is 0x07D0.