在COBOL中随使用量COMP而变化 [英] Variable with usage COMP in COBOL
问题描述
我试图了解带有COMP Usage子句的COBOL变量如何存储值.
我尝试了一个如下示例
01 VAR14 PIC S9(5) USAGE COMP.
MOVE 12345 TO VAR14
DISPLAY VAR14
在SPOOL中，VAR14的值以0000012345的形式出现.
S9(5) COMP的大小是4字节(根据手册)，因此我的理解是VAR14应该显示为000012345.
二进制表示形式如下:
0000 0000 0000 0000 0011 0000 0011 0100
有人可以帮助您理解输出值0000012345吗?
谢谢
在IBM的Enterprise COBOL中，有四种定义二进制字段的方法: COMP-4；二进制COMP-5.
那是怎么回事? COMPUTATIONAL字段("COMP"缩写，这里是所有COMPUTATIONAL字段"的缩写)是实现者定义的".这意味着在一个编译器中什么是COMP-something，在另一编译器中什么可能是COMP-something，甚至可能没有直接等价的内容.
是的，如果需要，您可以编写COMPUTATIONAL，COMPUTATIONAL-4和COMPUTATIONAL-5的代码.编译器会很高兴.
为了使事物标准化，1985年的COBOL标准引入了BINARY和PACKED-DECIMAL作为用法.为了可移植到其他COBOL编译器，这些将是COMP和COMP-3(压缩十进制)字段的最佳用法.
这些不同的二进制字段之间有什么区别?大多数情况下，没有.实际上，COMP，COMP-4和BINARY在编译器中是彼此的同义词(更准确地说，COMP-4和BINARY是COMP的同义词).
COMP-5，也称为本机二进制"，有所不同. COBOL具有所谓的十进制二进制"字段(COMP和同级).也就是说，数据以二进制形式存储，但其最大值和最小值是定义中使用的PICture子句的数量和全值.
COMP PIC 9 - can contain zero to nine.
COMP PIC S99 - (signed) can contain -99 to +99.
COMP PIC 999 - can contain zero to 999.
COMP-5不同.
COMP PIC 9 - can contain zero to 65535.
COMP PIC S99 - (signed) can contain -32768 to +32767.
COMP PIC 999 - can contain zero to 65535.
COMP-5的情况是，PICture用于定义字段的大小(与其他二进制字段一样)，但是每个可能的位值都是有效的.
PICture与定义的大小有何关系? PIC 9至PIC 9(4)将存储在半字大小的字段(两个字节)中. PIC 9(5)至PIC 9(9)将存储在一个字长的字段(四个字节)中. PIC 9(10)至PIC 9(18)将存储在双字大小的字段(八个字节)中.
好，那么这种差异(COMP-5使用所有位，COMP只代表PICture的十进制值)如何影响定义? 本机二进制"听起来不是比非本机"所提供的声音好得多，并且显然更快吗?
区别在于截断方式.并且，如同本机二进制"声音一样闪烁，它通常比使用COMP& amp;慢.一氧化碳，因为它被截断了.
COMP截断为PICture的十进制值. COMP-5会截断为字段的大小.
考虑(名称仅作演示之用，仅使用描述性名称):
01 PROGA COMP PIC 9(4).
01 PROGB COMP-5 PIC 9(5).
01 PROGC BINARY PIC 9(4) VALUE 9999.
ADD PROGC TO PROGA
ADD PROGC TO PROGB
记住PROGA的最大值为9999，并注意到19998很容易适合该字段的现有大小，因此编译器可以影响加法，然后将其截断为十进制值，全部就位.
请记住，PROGB的最大值为65535，并且绝对有很大的机会在原始字段中留出足够的空间来成功添加另外的65535，编译器必须生成一个两倍于原始大小的临时字段，另外，然后将其截断为原始最大值，以使结果恢复为原始字段.
ADD 1 TO PROGA
ADD 1 TO PROGB
请注意，对于这两个选项，添加到PROGA"(小于9999)仍将允许进行添加(显然)，但是添加到PROGB"将仍然需要字段的扩展以及所有其他方面的问题，因为PROGB可能已经具有65535的值，所以编译器必须允许这样做.
即将显示.您有COMP PIC S9(5)，并获得10位数字的输出.为什么?好的，您已经计算出大小，该字段的长度为4个字节.但是，这将为您提供五位数的输出，范围为-99999至+99999.让我们假装一下，您的领域是COMP-5 PIC S9(5).
对于COMP-5，所有位都是有效的，对于有符号字段，全字/字的范围是-2,147,483,648至+2,147,483,647.请注意，这是10位数字.与您在输出中获得的10位数字相匹配.发生什么事了?
编译器选项TRUNC.如果使用编译器选项TRUNC(BIN)，则将所有COMP/COMP-4/BINARY字段都视为COMP-5 .故事结局.您有TRUNC(BIN)，它是由您，您的项目或您的站点默认选择的.这不一定是一个好选择.
编译器选项TRUNC的其他值是STD，它对COMP/COMP-4/BINARY进行正常"截断，而OPT则在当时(性能)上做得最好.
请注意，强烈不应该这样:TRUNC(OPT)对程序员强加了合同. 我不会，绝对不能甚至不会考虑让COMP/COMP-4/BINARY字段的值不符合其PICture.如果我这样做，那全是我的错，句号，故事的结局，没有我的哭泣."
除了出于调查事情如何进行的目的外，请勿调整并更改TRUNC设置.如果这样做，您可以破坏事物，这可能是非常非常微妙的破坏.
我的建议:TRUNC(BIN)，除非有必要，否则不要使用它(有人决定，您别无选择)；如果您的网站不遵守合同，则使用TRUNC(STD)；如果您的网站对合同感到满意，则使用TRUNC(OPT).
对于需要的单个字段定义，请使用COMP-5.您需要在哪里?对于任何地方，都有一个二进制字段，其范围超出其PICture的十进制值".例如，查看CICS COMMAREA的大小以及指示单个示例有多大的字段.在COBOL程序中查找VARCHAR主机字段.与JAVA或C/C ++通信的数据可能就是这样.否则，对于新程序，最好使用BINARY，它表明您是1985年的最新产品.
出于调查目的设置TRUNC.
CBL TRUNC(STD)
ID (or IDENTIFICATION) DIVISION.
编译器选项也可以通过JCL中的PARM语句进行设置，但您可能无权访问. CBL将覆盖PARM中设置的任何值.有一个安装选项可以阻止使用CBL(也称为PROCESS).单个选项也可以在安装时固定".如果您的网站已修复TRUNC或阻止了CBL，则将无法尝试这些方法.
I am trying to understand how the COBOL variables with COMP Usage clause stores values.
I tried one example as below
01 VAR14 PIC S9(5) USAGE COMP.
MOVE 12345 TO VAR14
DISPLAY VAR14
In SPOOL the value of VAR14 is coming as 0000012345.
S9(5) COMP size is 4 bytes as per manuals so my understanding is VAR14 should be displayed as 000012345.
The binary representation as below:
0000 0000 0000 0000 0011 0000 0011 0100
Can someone please help in understanding the output value 0000012345 ?
Thanks
In IBM's Enterprise COBOL, there are four ways to define a binary field: COMP; COMP-4; BINARY; COMP-5.
How does that come about? A COMPUTATIONAL field (COMP for short, and here short for "all COMPUTATIONAL fields") is "implementor defined". Which means what is COMP-something in one compiler, may be COMP-somethingelse in another compiler, or may even have no direct equivalent.
And yes, you can code COMPUTATIONAL, COMPUTATIONAL-4 and COMPUTATIONAL-5 if you want. The compiler will be happy.
To standardise things, the 1985 COBOL Standard introduced BINARY and PACKED-DECIMAL as USAGEs. For portability to other COBOL compilers, these would be the best USAGEs for COMP and COMP-3 (packed-decimal) fields.
What is the difference between these different binary fields? Mostly, none. COMP, COMP-4 and BINARY are in fact synonyms of each other in the compiler (more accurately, COMP-4 and BINARY are synonyms of COMP).
COMP-5, also known as "native binary", is different. COBOL has what you might call "decimal-binary" fields (COMP and siblings). That is, the data is stored as binary but its maximum and minimum values are the number and full value of the PICture clause which is used in the definition.
COMP PIC 9 - can contain zero to nine.
COMP PIC S99 - (signed) can contain -99 to +99.
COMP PIC 999 - can contain zero to 999.
COMP-5 is different.
COMP PIC 9 - can contain zero to 65535.
COMP PIC S99 - (signed) can contain -32768 to +32767.
COMP PIC 999 - can contain zero to 65535.
What happens for COMP-5 is that the PICture is used to define the size of the field (as with other binary fields) but every possible bit-value is valid.
How does the PICture relate to the size of the definition? PIC 9 through PIC 9(4) will be stored in a half-word-sized field (which is two bytes). PIC 9(5) through PIC 9(9) will be stored in a word-sized field (which is four bytes). PIC 9(10) through PIC 9(18) will be stored in a double-word-sized field (eight bytes).
OK, so how does this difference (COMP-5 use all the bits, COMP can only represent the decimal value of the PICture) affect what is defined? Doesn't "native binary" sound much better, and obviously faster, than anything "non-native" would give?
The difference is in how they truncate. And, as scintillating as "native binary" sounds, it is generally slower than using COMP & CO, because of the truncation.
COMP truncates to the decimal value of the PICture. COMP-5 truncates to the size of the field.
Consider (names just for demonstration, only ever use descriptive names):
01 PROGA COMP PIC 9(4).
01 PROGB COMP-5 PIC 9(5).
01 PROGC BINARY PIC 9(4) VALUE 9999.
ADD PROGC TO PROGA
ADD PROGC TO PROGB
Remembering that PROGA has a maximum value of 9999, and noting that 19998 fits easily within the existing size of the field, the compiler can effect the addition and then truncate to the decimal value, all in-place.
Remembering that PROGB has a maximum value of 65535 and there is absolutely fat chance that there is enough room in the original field to successfully add a further 65535, the compiler has to generate a temporary field of double the original size, do the addition, and then truncate back to the original maximum value, getting that result back to the original field.
ADD 1 TO PROGA
ADD 1 TO PROGB
Note that with these two, ADD 1 TO PROGA, since it is less than 9999, will still allow the ADD to be done in place (obviously) but ADD 1 TO PROGB will still require the expansion of the field and all that mucking-about, because PROGB just may have a value of 65535 in it already, so the compiler has to allow for that.
Coming to DISPLAY. You have COMP PIC S9(5), and you get a 10-digit output. Why? OK, size you have worked out, the field is four bytes long. However, that should get you a five-digit output, in the range -99999 to +99999. Let's pretend for a moment that your field was instead COMP-5 PIC S9(5).
With COMP-5 you all the bits are valid, and, for a signed field, your range for a full-word/word is -2,147,483,648 through +2,147,483,647. That's 10 digits, note. Which matches to the 10 digits you got in your output. What happened?
Compiler option TRUNC. If you use compiler option TRUNC(BIN), all your COMP/COMP-4/BINARY fields are treated as COMP-5. End of story. You have TRUNC(BIN) either specifically chosen by you, your project, or as your site default. This is not necessarily a good choice.
Other values of compiler option TRUNC are STD, which does the "normal" truncation for COMP/COMP-4/BINARY, and OPT which does whatever is best (for performance) at the time.
Note, strongly not, that TRUNC(OPT) imposes a contract on the programmer. "I will not, must not, and will never even consider, allow a COMP/COMP-4/BINARY field to have a value which does not conform to it's PICture. If I do, it is all my fault, full-stop, end-of-story, and no crying from me".
Don't, except for the purposes of investigating how things work, ever just up and change a TRUNC setting. If you do, you can break things, and it can be a very, very subtle break.
My advice: TRUNC(BIN), don't use it unless you have to (someone decided, and you have no choice); TRUNC(STD) use if your site is scared of the contract; TRUNC(OPT) use if your site is comfortable with the contract.
Do use COMP-5, for individual field-definitions, where you need to. Where do you need to? For any place you have a binary field whose range is beyond the "decimal value" of its PICture. For instance, look to the size of the CICS COMMAREA and the field which indicates how big an individual example is. Look to a VARCHAR host-field in a COBOL program. Data communicating with JAVA or C/C++ may be like that. Otherwise, for new programs, prefer BINARY, which shows that you are slap-up-to-date with 1985.
Setting TRUNC for investigative purposes.
CBL TRUNC(STD)
ID (or IDENTIFICATION) DIVISION.
Compiler options can also be set by the PARM statement in the JCL for the compile, but you may not have access to that. CBL will override any value set in the PARM. There is an installation option which can prevent the use of CBL (also known as PROCESS). Individual options can also be "fixed" at installation time. If your site has fixed TRUNC or prevented CBL, you won't be able to try these things out.
这篇关于在COBOL中随使用量COMP而变化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
