Буквено-цифрово преместване към числово

Буквено-цифровото преместване към цифровата променлива доведе до неочаквани резултати. Ето кода 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" в числова променлива и интересното е, че НЯМА проблем и при кондиционирането му. Споделете вижданията си. Благодаря за проявения интерес.


mainframe cobol alphanumeric
person Raja Reddy    schedule 26.05.2011    source източник
comment
Бих проверил дали това не е грешка в DISPLAY (или функция). Опитайте се да напишете IF WS-VAR-NUM EQUAL 1 THEN ..., за да проверите истинското съдържание.   -  person Dr. belisarius    schedule 26.05.2011
comment
Опитайте MOVE '001' към WS-VAR-STR. Преместване на '1' към WS-VAR-STR премества '1'. Move не извършва преобразуване на типове.   -  person tonyriddle    schedule 26.05.2011
comment
@tony Вижте например това tek-tips.com/viewthread.cfm?qid= 705710   -  person Dr. belisarius    schedule 26.05.2011
comment
@belisarius Подпрограмата за конвертиране във връзката, която предоставихте, е как го направихме. Той премахва нецифрови знаци, подравнява надясно цифровите знаци и нулира полето. След това този резултат може да бъде преместен в числовото поле.   -  person tonyriddle    schedule 26.05.2011

Отговори (1)


arrow_upward
3
arrow_downward

По принцип сте извършили незаконно MOVE. Преместването на буквено-цифрови в цифрови полета е валидно при условие, че съдържанието на буквено-цифровото поле съдържа само цифрови знаци. Този препратка обобщава валидни/невалидни ходове.

Какво очаквахте като резултат?

Преместванията на буквено-цифрови полета в цифрови се извършват без „преобразуване“. По принцип просто сте пуснали една цифра, последвана от два интервала в числово поле. '1' беше добре, двата интервала не бяха. Последните два байта на WS-VAR-NUM съдържат интервали.

Но чакайте... защо последният знак е нула? Отговорът на това е малко по-сложен. Елементите, декларирани като PIC 9 нещо, са представени в Zoned Decimal. Всяка цифра от зонирано десетично число е представена от един байт. 4-те бита от висок ред на всеки байт са зонови битове; 4-те бита от висок ред на байта от нисък ред представляват знака на елемента. 4-те бита от нисък ред на всеки байт съдържат стойността на цифрата. Ключът тук е къде се съхранява знакът. Той е в битовете от висок ред на последния байт. Вашата декларация не включва знак, така че операторът MOVE издухва битовете на знака и ги заменя с цифрови битове от висок ред по подразбиране (не забравяйте, че единствените валидни знаци за ПРЕМЕСТВАНЕ са цифри - така че този процес на корекция винаги трябва да дава валиден резултат). Битовете от висок ред на зонирана десетична цифра без знак винаги са HEX F. Какви са битовете от нисък порядък на последния байт? Интервалът има ebcdic HEX стойност 40. Нула е HEX F0. Тъй като операторът MOVE "поправя" знака автоматично, вие завършвате с HEX F0 в цифрата от нисък ред, която се оказва, както познахте, нула. Нито една от другите „цифри“ не съдържа знакови битове, така че те са оставени както са били.

И накрая, оператор DISPLAY преобразува зонирани десетични полета в тяхното еквивалентно символно представяне за представяне: Нетният резултат е: '1 0'.

BTW Горната дискусия е как работи на IBM z/OS платформа - други набори от символи (напр. ASCII) и/или други платформи може да дадат различни резултати, не защото IBM прави грешното нещо , но защото програмата извършва незаконно MOVE и резултатите по същество са недефинирани.

person NealB    schedule 26.05.2011
comment
Благодаря за такова търпеливо и кристално ясно обяснение, въпреки че е очевидно, че случайно направих незаконен ход. Също така благодаря за разбирането на намерението ми да разбера причината за резултата след такова движение. Посочихте ли нещо, за да разберете това, ако е така, моля, споделете тези ценни неща... това наистина си заслужава! - person Raja Reddy; 30.05.2011