In the current program that I am working on, I am trying to:
1) Read records from an input file.
2) Convert the first two characters (basically has my numbers) to Packed decimal using PACK instruction
3) Adding the numbers
4) Converting packed decimal result back to character using UNPK
5) Writing the record into output file.
Below is the program that I am using.
* READ NUMBERS FROM I/P FILE, ADD AND PLACE RESULT IN O/P FILE
FLEADNU CSECT
STM 14,12,12(13)
BALR 12,0
USING *,12
ST 13,SAVE+4
LA 13,SAVE
OPEN (INDCB,(INPUT))
OPEN (OUTDCB,(OUTPUT))
WTO 'DISPLAY1'
IOLOOP MVC INAREA,=80C' '
WTO 'DISPLAY2'
ZAP TEMPNUM,ZEROES
GET INDCB,INAREA
PACK TEMPNUM,INPNUM
AP TOTAL,TEMPNUM
WTO 'DISPLAY3'
B IOLOOP
FINISH UNPK OUTNUM,TOTAL
WTO 'DISPLAY4'
PUT OUTDCB,OUTAREA
CLOSE (INDCB)
CLOSE (OUTDCB)
EXIT L 13,SAVE+4
LM 14,12,12(13)
XR 15,15
BR 14
INDCB DCB DSORG=PS,MACRF=(GM),DDNAME=TESTIN,EODAD=FINISH, X
RECFM=FB,LRECL=80,BLKSIZE=0
OUTDCB DCB DSORG=PS,MACRF=(PM),DDNAME=TESTOUT, X
RECFM=FB,LRECL=80,BLKSIZE=0
INAREA DS 0CL80
INPNUM DS CL2
FILLER DS CL78
OUTAREA DS 0CL80
OUTNUM DS CL2
FILLER1 DS CL78' '
OUTLINE DC CL80' '
TOTAL DC PL2'0'
TEMPNUM DC PL2'0'
ZEROES DC PL2'0'
SAVE DS 18F
END
My input and output records are 80 bytes.
I am giving the below inputs in my input file.
10
20
30
05
And I am getting the below in the output file.
06E
Could you help me out here in understanding why the result is coming as 06E instead of the expected result 65.
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
You are seeing 06E because the sum is a positive number. The packed number is x'065C' which unpacks as C'6E', because X'C5' whicnis the last byte unpacked is the letter 'E'.
What you need to do, after the
Code:
FINISH UNPK OUTNUM,TOTAL
instruction is to make the last digit printable as a number. This is achieved by adding the instruction
When you post code, like your little program, surround it by phpBB code tags. You can find out about these tags by using Google.
Carefully read and understand the discussion about the zoned decimal, packed decimal, and decimal codes, and the UNPK instruction in Principles of Operation. Zoned decimal does not necessarily mean 100% readable, though 100% readable is usually acceptable to the PACK instruction and subsequent decimal arithmetic instructions. The last paragraph in the decimal codes topic will explain why.
One additional instruction is typically used after the UNPK instruction to update the zoned decimal sign to make the zoned decimal number 100% readable. You can also used the same instruction, though with different data, to update the sign in the packed decimal data before you use the UNPK instruction. At various times in my career I've used both solutions. Hint: this instruction is not a "decimal" instruction.
Thanks for the response and apologies for posting the query in the wrong forum. I have registered myself in the beginners forum and waiting for the account to be activated.
In the meantime, I tried using the instruction that Garry has provided. I added the code after the UNPK instruction.
But I am getting an error during the compilation process.
** ASMA141E Bad character in operation code - UNPACK+1,X'FO'
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
monica1 wrote:
Thanks for the response and apologies for posting the query in the wrong forum. I have registered myself in the beginners forum and waiting for the account to be activated.
In the meantime, I tried using the instruction that Garry has provided. I added the code after the UNPK instruction.
But I am getting an error during the compilation process.
** ASMA141E Bad character in operation code - UNPACK+1,X'FO'
Could you let me know what might be the reason.
The query that started this topic, as well as this second query demonstrated an unwillingness to think or to use existing reference material. Since knowing where, in the wealth of available documentation that is now available, to go, my first response pointed out where to go rather than directly answer your query. It still depended on your ability to THINK about a problem. This second query reinforced this conclusion. I must admit I, too, as well as dneufarth made the same error.
I wrote this little program to try to recreate the error.
Code:
HEX CSECT
USING *,15
OI DATA+1,X'FO'
SR 15,15
BR 14
DATA DC P'55'
END HEX
When I ran it through HLASM I got this error message -
** ASMA148E Self-defining term lacks ending quote or has bad character - X'FO'
rather than the ASMA141E message.
Both dneufarth and I didn't bother to read the entire ASMA141E message to realize your statement was
UNPK+1,X'FO'
We both jumped to the X'FO' and analyzed it, rather than analyze the real problem.
Now let's look at X'FO'.
Arguably there are at least two possible issues here.
Your understanding of hexadecimal notation.
Hexadecimal notation has 16 unique digits: 0 through 9, and A through F are usually used to represent the additional 6 digits. So it would seem there is something wrong with FO.
The font (the way the characters are formed on screen or printed)
One nice thing about the font as printed by IBM 1403 printer is it was easy to distinguish between the letter O and the number 0. Seeing the O and 0 side by side it it is easy to see the difference, but seeing X'FO' it is rather to easy to see what should be a 0 is really O. Sadly I can't easily recreate this font here, though I have seen fairly good attempts elsewhere in the internet. The letter O was not a simple circle; rather it is was more like a small square. The number 0 had a single dot in the middle. The two IBM keypunch machines of the 1960s used a similar font in the characters it could print on the cards it punched.