字母数字移动到数字

发布于 2024-11-09 12:10:10 字数 861 浏览 6 评论 0原文

字母数字移动到数字变量会导致意外结果。这是代码 fyr：

  DATA DIVISION.                                 
  WORKING-STORAGE SECTION.                       
  01  WS-VAR-STR       PIC X(3) VALUE SPACES.                
  01  WS-VAR-NUM       PIC 9(3) VALUE ZEROES. 
  PROCEDURE DIVISION.                            
      MOVE '1'         TO WS-VAR-STR                  
      MOVE WS-VAR-STR  TO WS-VAR-NUM
      DISPLAY 'STRING > ' WS-VAR-STR '< MOVED > ' WS-VAR-NUM '<'

      IF WS-VAR-NUM >= 40 AND <= 59
         DISPLAY 'INSIDE IF >' WS-VAR-NUM
      ELSE 
         DISPLAY 'INSIDE ELSE >' WS-VAR-NUM
      END-IF
      GOBACK                                     
      .  

    OUTPUT:
    STRING > 1  < MOVED > 1 0<
    INSIDE ELSE >1 O

结果很奇怪，想弄清楚为什么将“1”作为“1 0”移动到数字变量中，有趣的是在调节它时也没有问题。请分享您的观点。感谢您的关注。

原文

Alphanumeric movement to Numeric variable caused unexpected results. Here is the code fyr:

  DATA DIVISION.                                 
  WORKING-STORAGE SECTION.                       
  01  WS-VAR-STR       PIC X(3) VALUE SPACES.                
  01  WS-VAR-NUM       PIC 9(3) VALUE ZEROES. 
  PROCEDURE DIVISION.                            
      MOVE '1'         TO WS-VAR-STR                  
      MOVE WS-VAR-STR  TO WS-VAR-NUM
      DISPLAY 'STRING > ' WS-VAR-STR '< MOVED > ' WS-VAR-NUM '<'

      IF WS-VAR-NUM >= 40 AND <= 59
         DISPLAY 'INSIDE IF >' WS-VAR-NUM
      ELSE 
         DISPLAY 'INSIDE ELSE >' WS-VAR-NUM
      END-IF
      GOBACK                                     
      .  

    OUTPUT:
    STRING > 1  < MOVED > 1 0<
    INSIDE ELSE >1 O

The result is bizzare and want to figure why '1' is moved as '1 0' into numeric variable and interestingly there was NO issue in conditioning it as well. Do share your views. Thanks for your interest.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

狼性发作 2024-11-16 12:10:10

基本上你已经做了一个非法的MOVE。将字母数字字段移至数字字段是有效的
前提是字母数字字段的内容仅包含数字字符。
此参考
总结有效/无效的动作。

你期待什么结果？

将字母数字字段移动到数字字段无需
'转换'。基本上，您只需将一位数字后跟两个空格放入数字字段即可。 “1”没问题，两个空格
不是。 WS-VAR-NUM 的最后两个字节包含空格。

但是等等...为什么最后一个字符是零？这个问题的答案有点复杂。
声明为 PIC 9 的项目以分区十进制表示。
分区十进制数的每个数字都由一个字节表示。
每个字节的高4位为区域位；低位字节的高4位分别代表
物品的标志。每个字节的 4 个低位包含数字的值。关键在这里
是存储标志的地方。它位于最后一个字节的高位。你的声明没有
包含一个符号，因此 MOVE 语句会清除符号位并将其替换为默认值
数字高位（请记住，MOVE 的唯一有效字符是数字 - 所以这
补丁过程应该始终产生有效的结果）。无符号分区十进制的高位
数字始终为十六进制 F。最后一个字节的低位是多少？空格的 ebcdic 十六进制值为 40。零是十六进制 F0。由于 MOVE 语句自动“修复”符号，因此您最终会得到低位数字中的十六进制 F0，您猜对了，它恰好为零。其他“数字”都不包含符号位，因此它们被保留为
他们是。

最后，DISPLAY 语句将分区十进制字段转换为其等效的字符表示形式
用于演示：最终结果是：“1 0”。

顺便说一句上面的讨论是它在 IBM z/OS 平台上的工作方式 - 其他字符集（例如 ASCII）和/或其他平台可能会产生不同的结果，而不是因为 IBM 做错了事情，但是因为程序正在执行非法的 MOVE 并且结果本质上是未定义的。

Basically you have done an illegal MOVE. Moving alphanumeric to numeric fields is valid
provided that the content of the alphanumeric field contains only numeric characters.
This reference
summarizes valid/invalid moves.

What were you expecting as a result?

Moves of alphanumeric fields into numeric ones are done without
'conversion'. Basically you just dropped a one digit followed by two spaces into a numeric field. the '1' was ok, the two spaces
were not. The last two bytes of WS-VAR-NUM contain spaces.

But wait... why is the last character a zero? The answer to this is a bit more complicated.
Items declared as PIC 9 something are represented in Zoned Decimal.
Each digit of a zoned decimal number is represented by a single byte.
The 4 high-order bits of each byte are zone bits; the 4 high-order bits of the low-order byte represent
the sign of the item. The 4 low-order bits of each byte contain the value of the digit. The key here
is where the sign is stored. It is in the high order bits of the last byte. Your declaration did not
include a sign so the MOVE statement blows away the sign bits and replaces them with default
numeric high order bits (remember the only valid characters to MOVE are digits - so this
patch process should always yield a valid result). The high order bits of an unsigned zoned decimal
digit are always HEX F. What are the low order bits of the last byte? A space has an ebcdic HEX value of 40. A zero is HEX F0. Since the MOVE statement "fixes" the sign automatically, you end up with HEX F0 in the low order digit, which happens to be, you guessed it, zero. None of the other 'digits' contain sign bits so they are left as
they were.

Finally, a DISPLAY statement converts zoned decimal fields into their equivalent character representation
for presentation: Net result is: '1 0'.

BTW The above discussion is how it works out on an IBM z/OS platform - other character sets (eg. ASCII) and/or other platforms may yield different results, not because IBM is doing the wrong thing, but because the program is doing an illegal MOVE and the results are essentially undefined.

回复收藏 0 原文

~没有更多了~