Changed it around using your tricky TR and it works.  Thanks so much!

A

>>> [EMAIL PROTECTED] 10/24/2006 4:48 PM >>>
 
 
In a message dated 10/24/2006 3:12:07 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:
 
>Working on the IEFACTRT routine and it has the following assembler  
statements for getting >return code ready to print on hasp:
>CVD   R0,RWORK            GET  ADDRESS OF COND FIELD
Assume R0 contains the return code of X'0000008B'.
After the CVD, RWORK (I assume it is 8 bytes long) contains  
X'000000000000139C', which is the decimal equivalent of hex 8B.
 
>MVC   M1CC-1(L'M1CC+1),=X'402120202020' MOVE IN EDIT  MASK

I assume that M1CC has a length attribute of 5.  After the MVC,  M1CC-1 will 
contain X'402120202020'.  

>ED    M1CC-1(L'M1CC+1),RWORK+5 CONVERT RET CODE TO CHAR
After this instruction, M1CC contains X'4040F0F1F3F9', which is the EBCDIC  
(printable) equivalent of decimal 139.

>However, I want the return  code to print as hexidecimal instead of decimal. 
 I tried the >following  after these prior 3 statements:
>NC    M1CC+1(4),=4X'0F'
After the NC, M1CC+1 contains X'00010309'.  The NC changes the  high-order 
half of each of the four bytes to a X'0' and leaves the low-order  half alone.
 
>TR    M1CC+1(4),=C'0123456789ABCDEF'
After the TR, M1CC will contain X'00010309'.  This is not EBCDIC, not  
printable, not decimal, not hexadecimal, but instead a  quasi-decimal.

>Why is it not translating the decimal to  hexadecimal???
In order to translate decimal to hex, you have to do the inverse of the  CVD. 
 I prefer to do it with the CVB instruction.  You had hex in R0  to begin 
with, then you converted it to decimal, then you mangled the decimal  rather 
than 
converting it back into hex.
 
You want printable hex, so replace the CVD, MVC, ED, NC, and TR with the  
following:
         ST     R0,FULLWORD
         UNPK   M1CC+1(9),FULLWORD(5)
         TR      M1CC+1(8),=C'0123456789ABCDEF'-X'F0'
After this, M1CC will contain X'F0F0F0F0F0F0F8C2', which will print as  
0000008B.
 
Your NC and TR will work, but only if the original hex number is first  
unpacked into twice as many bytes.  If you use the tricky literal I used,  you 
avoid needing to do the NC instruction.  After the UNPK, you can do  either 
your 
original NC and TR or my tricky TR.


Bill  Fairchild

"Facts are the enemy of truth." [Don Quixote in Man of La  Mancha]


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to