MVSFORUMS.com

[jctgf]

Hello,

I need to write a TSQ with 30000 items.

I

[kolusu]

jctgf,

Please search before posting. Check this link

http://www.mvsforums.com/helpboards/viewtopic.php?t=5104&highlight=trunc

Kolusu

[jctgf]

yes, i did. i searched a lot but it's not any easy finding anything in the forum.

[jctgf]

I have a question, please.
It seems that the TRUNC option has some implications on the program performance.
It seems I can use COMP-5 for a specific data-item instead.
Is COMP-5 a standard COBOL II command, please?
Thanks.

[kolusu]

[jctgf]

thanks a lot!

[jctgf]

hi kolusu,

i tried to use the comp-5 data-item but it didn't work. it seems that comp-5 is a 10 digit binary and it causes an error in the readq command.

then i did the following:

[kolusu]

[jctgf]

hi!
i'm going to check my code again to see if i forgot the CBL TRUNC(BIN) parameter in it.
thanks!!

[jctgf]

Hi there Kolusu,

I double checked my program and it really works.

I think that READQ/WRITEQ expects to receive a two-byte binary variable and, as long as this condition is satisfied, things will work OK.

Cobol COMP data-items, for some reason that I would like to know why, are limited to 4 digits but it doesn't change the actual size of the variable. It's still a two-byte binary field and is able to contain values from
-32768 to 32768.

If I do what I did, I kind of fool Cobol and force a value into the variable that is compatible, despite not being compatible with its Cobol picture.

When READQWRITEQ Cics command receives the variable, it contains a valid value and therefore it is processed correctly. Despite the PIC the variable has, it seems to be what matters to the Cics API.

[kolusu]

[jctgf]

hi,

i filled ws-two-byte not moving the value directly to it. i moved the value to ws-integer. things will only work this way.

[RonB]

The reason why the use of WS-INTEGER works is because it can actually populate
the lower two bytes with a binary value that is larger than 4 decimal digits. The PICTURE clause does not come in to play when the field is specified on the EXEC CICS command because at execution time only the ADDRESS of the item is passed to the CICS service routines - and the PICTURE does not have any bearing on that because CICS assumes that the named item is a 2-byte binary item that CAN contain a value of up to 32767.

The reason that PIC 9(05) COMP generates a 4-byte binary rather than a 2-byte binary is because a 5 digit number greater than 32767 cannot be stored in a 2-byte binary.

FYI, If you coded W-ITEM-NUMBER as PIC s9(4) COMP-5, you COULD move a 5-digit number to it, as long as the number was less than 32768. According to the COBOL Reference Manual:

COMPUTATIONAL-5 or COMP-5 (native binary) These data items are represented in storage as binary data. The data items can contain values up to the capacity of the native binary representation (2, 4 or 8 bytes), rather than being limited to the value implied by the number of nines in the picture for the item (as is the case for USAGE BINARY data). When numeric data is moved or stored into a COMP-5 item, truncation occurs at the binary field size rather than at the COBOL picture size limit. When a COMP-5 item is referenced, the full binary field size is used in the operation.
_________________
A computer once beat me at chess, but it was no match for me at kick boxing.

[jctgf]

that's what the "redefines" solution is all about.

however, i think there must be a more elegant solution.

it's hard to understand how cics has a feature (populate up to 32k items in a tsq) and the only way to actually use it is thru such a programming trick.

if i had used a regular approach i'd only be able to handle 9999 items.

as to the tests, i did it all again and it really works wonderfully.

i still wonder why cobol doesn't allow to fill a 2-byte binary with a value bigger that 9999.

could it be to prevent and exception in case the programmer moves a value between 32787 and 99999 to it?

[RonB]