Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Processing Packed Decimal Data: Format, Instructions, and Conversions - Prof. Edward Boswo, Study notes of Programming Languages

An in-depth explanation of packed decimal data processing on ibm system/360. It covers packed decimal constants, moving data using mvc and zap instructions, packed decimal instructions (zap, ap, cp), and conversions between packed decimal and zoned decimal formats. It also discusses handling packed decimal input and output using pack, unpk, and ed instructions.

Typology: Study notes

Pre 2010

Uploaded on 08/04/2009

koofers-user-tsj
koofers-user-tsj 🇺🇸

10 documents

1 / 34

Toggle sidebar

Related documents


Partial preview of the text

Download Processing Packed Decimal Data: Format, Instructions, and Conversions - Prof. Edward Boswo and more Study notes Programming Languages in PDF only on Docsity! Processing Packed Decimal Data The IBM System/360 is the outgrowth of two earlier product lines: the 704/709/7090 series and the 702/705/7080 series. The IBM 704/709/7090 series was a line of computers designed to support scientific research. This line supported binary arithmetic. ** The IBM 702/705/7080 series was designed to support commercial data processing. This line supported packed decimal arithmetic. The System/360 line was designed to bring these two lines together and implement a single architecture. For this reason, it had to support both decimal and binary arithmetic. ** NOTE: The IBM 704 series had a 36–bit instruction word in the following format. 3 bits 15 bits 3 bits 15 bits Prefix Decrement Tag Address LISP was developed on a 704 in 1958. Think of the following: CAR Contents of the Address Part of the Register CDR Contents of the Decrement Part of the Register Packed Decimal Format Arithmetic is done on data in one of two formats: packed decimal or binary. Here, we discuss the packed decimal format, beginning with packed decimal constants. A packed decimal constant is a signed integer, with between 1 and 31 digits (inclusive). The number of digits is always odd, with a 0 being prefixed to a constant of even length. A sign “half byte” or hexadecimal digit is appended to the representation. The common sign–representing hexadecimal digits are as follows: C non–negative D negative F non–negative, seen in the results of a PACK instruction. If a DC (Define Constant) declarative is used to initialize storage with a packed decimal value, one may use the length attribute. Possibly the only good use for this would be to produce a right–adjusted value with a number of leading zeroes. For example DC PL6’1234’ becomes 00 00 00 01 23 4C Remember that each of these bytes holds two hexadecimal digits, not the value indicated in decimal, so 23 is stored as 0010 0011 and 4C as 0100 1100. Packed Decimal: Moving Data There are two instructions that might be used to move packed decimal data from one memory location to another. MVC S1,S2 Copy characters from location S2 to location S1 ZAP S1,S2 Copy the numeric value from location S2 to location S1. Each of the two instructions can lead to truncation if the length of the receiving area, S1, is less than the source memory area, S2. If the lengths of the receiving field and the sending field are equal, either instruction can be used and produce correct results. The real reason for preferring the ZAP instruction for moving packed decimal data comes when the length of the receiving field is larger than that of the sending field. The ZAP instruction copies the contents of the sending field right to left and then pads the receiving field with zeroes, producing a correct result. The MVC instruction will copy extra bytes if the receiving field is longer than the sending field. Whatever is copied is likely not to be what is desired. Bottom line: Use the ZAP instruction to move packed decimal data, and be sure to avoid truncation. Packed Decimal Data: ZAP, AP, CP, and SP We have three instructions with similar format. ZAP S1,S2 Zero S1 and add packed S2 (This is the move discussed above) AP S1,S2 Add packed S2 to S1 CP S1,S2 Compare S1 to S2, assuming the packed decimal format. SP S1,S2 Subtract packed S2 from S1. These are of the form OP D1(L1,B1),D2(L2,B2), which provide a 4–bit number representing the length for each of the two operands. Type Bytes Form 1 2 3 4 5 6 SS(2) 6 D1(L1,B1),D2(L2,B2) OP L1 L2 B1 D1 D1D1 B2 D2 D2D2 The first byte contains the operation code, say X‘FA’ for AP or X‘F9’ for CP. The second byte contains two hexadecimal digits, each representing an operand length. Each of L1 and L2 encodes one less than the length of the associated operand. This allows 4 bits to encode the numbers 1 through 16, and disallows arguments of 0 length. The next four bytes contain two addresses in base register/displacement format. Packed Decimal Data: Additional Considerations For all three instructions, the second operand must be a valid packed field terminated with a valid sign. The usual values are ‘C’, ‘D’, and occasionally ‘F’. For AP and SP, the first operand must be a valid packed field terminated with a valid sign. For ZAP, the only consideration is that the destination field be large enough. If either the sending field or the destination field (AP and SP) have just been created by a PACK instruction, the sign half–byte may be represented by 0xF. This is changed by the processing to 0xC or 0xD as necessary. Some textbook hint that using ZAP to transfer a packed decimal number with 0xF as the sign half–byte will convert that to 0xC. Any packed decimal value with a sign half–byte of D (for negative) is considered to sort less than any packed decimal value with a sign half–byte of C or F (positive). Condition Codes Each of the ZAP, AP, and SP instructions will set the condition codes. As a result, one may execute conditional branches based on these operations. The branches are: BZ Branch Zero BNZ Branch Not Zero BM Branch if negative BNM Branch if not negative BP Brach if positive BNP Branch if not positive BO Branch on overflow BNO Branch if overflow has not occurred. An overflow will occur if the receiving field is not large enough to accept the result. My guess is that leading zeroes are not considered in this; so that the seven digit packed decimal number 0000123 can be moved to a field accepting four digit packed numbers. Comparing Packed Decimal Values The CP (Compare Packed) instruction is used to compare packed decimal values. This sets the condition codes that can be used in a conditional branch instruction, as just discussed. Is there any reason to compare and not then have a conditional branch? In some sense, the CLC (Compare Character) instruction is similar and may be used to compare packed decimal data. However, this use is dangerous, as the CLC does not allow for many of the standards of standard algebra. Consider the two values 123C (representing +123) and 123D (representing –123). CP will correctly state that 123D < 123C; indeed –123 is less than +123. CLC will state that 123D > 123C, as 12 = 12, but 3D > 3C. Remember that these are being compared as sequences of characters without numeric values. Consider the two values 123C (representing +123) and 123F (also representing +123). CP will correctly state that 123C = 123F; as 123 = 123. CLC will state that 123F > 123C, as 12 = 12, but 3F > 3C. Consider the two values 125C (representing +123) and 12345C (representing +12345). CP will work correctly, noting that 12345 > 00125. CLC will compare character by character. As ‘5’ > ‘3’, it will conclude that 125 > 12345. PACK We now focus on conversions of decimal data between the two formats that may be used to represent them: 1. The EBCDIC character encoding used for input and output. 2. The packed decimal format used for decimal arithmetic. The PACK instruction can be used to convert data from zoned format into the packed decimal format. For the moment, we shall not cover zoned decimal format. The standard discussion of the PACK instruction focuses on positive numbers. Consider the input data string “9876”. Represented in EBCDIC, the string would be F9 F8 F7 F6. One would expect this to pack to the three byte value 09 87 6C. In fact, it packs to a variant of positive format 09 87 6F. This value will be converted to the more standard representation when it is first used by a packed decimal instruction. NOTE: What about the input sequence “–123”, which is represented by the EBCDIC string 60F1F2F3. It should pack to 123D, but it does not. The PACK instruction is not designed to handle a leading “–” Another Look at This Input The important part of the data declaration for the input is as follows. RECORDIN DS 0CL80 80 CHARACTER CARD IMAGE DIGITS DS CL5 FIRST FIVE COLUMNS ARE INPUT Here is the properly formatted input, viewed in columns. Reading from right to left: Column 5 is the units column Column 4 is the tens column Column 3 is the hundreds column, etc. Note that each digit is properly placed; the first line is really 00001. One Error: Assuming Free–Formatted Input Here is some input from the same program. It did not work. 1 3 13 17 Here is the way that the input was interpreted. To me this looks like 10000 + 30000 + 13000 + 17000. The Output for the Erroneous Input I had expected the above input to give a sum of 70000. It did not. Here is the actual output. All we get is the print echo of the first line input. ***PROGRAM FOUR CSU SPRING 2009 *********** 1 Here is the code loop for the processing routine. B10DOIT MVC DATAPR,RECORDIN FILL THE PRINT AREA PUT PRINTER,PRINT START THE PRINT PACK PACKIN,DIGITSIN CONVERT INPUT TO DECIMAL AP PACKSUM,PACKIN ADD IT UP BR R8 RETURN FROM SUBROUTINE What is the problem. Each of the first two lines worked. It is either the PACK or the AP instruction that fails. Printing Packed Data In order to print packed decimal data, it must be converted back to a string of EBCDIC characters. The unpack command, UNPK, appears to convert data in Packed Decimal format to EBCDIC format, actually converts to Zoned Decimal format. UNPK almost converts to EBCDIC. It has an unfortunate side effect, due to the simplicity of its implementation, which is a direct conversion to Zoned format. The problem occurs when handling the sign code, “C” or “D” in the Packed Decimal format. This occurs in the rightmost byte of a packed decimal value. Consider the decimal number 47, represented in binary in register R4. CVD R4,PACKOUT produces the packed decimal 047C. This is correct. When this is unpacked it should become F0 F4 F7 Unpack just swaps the sign half byte: F0 F4 C7. This prints as 04G, because 0xC7 is the EBCDIC code for the letter ‘G’. We have to correct the zone part of the last byte. Printing Packed Data (Part 2) Here is the code that works for five digit numbers. It is written as a subroutine, that is called as BALR R8,NUMOUT. NUMOUT CP QTYPACK, =P‘0’ BNM NOTNEG MVI QTYOUT+5,C‘-’ PLACE SIGN AT QTYOUT+5 NOTNEG UNPK QTYOUT,QTYPACK PRODUCE FORMATTED NUMBER MVZ QTYOUT+4(1),=X’F0’ MOVE 1 BYTE * TO ADDRESS QTYOUT+4 BR 8 RETURN ADDRESS IN REGISTER 8 QTYPACK DS PL3 HOLDS FIVE DIGITS IN THREE BYTES QTYOUT DS 0CL6 DIGITS DS CL5 THE FIVE DIGITS DC CL1’ ’ THE SIGN Again, the expression QTYOUT+4 is an address, not a value. If QTYOUT holds C‘01234’, then QTYOUT+4 holds C ‘4’. Unpacking and Editing Packed Decimal Data Each of the UNPK (Unpack) and the ED (Edit) instruction will convert packed decimal data into a form suitable for printing. The ED instruction seems to be the more useful. In addition to producing the correct print representation of all digits, it allows for the standard output formats. The use of the ED instruction is a two–step process. 1. Define an edit pattern to represent the punctuation, sign, and handling of leading zeroes that is required. Use the MVC instruction to move this into the output position. 2. Use the ED instruction to overwrite the output position ** with the output string that will be formatted as specified by the edit pattern. Here is an example. Note that there are a number of length constraints, specifically that the length of the edit pattern match the length of the output area. ** NOTE: The first character in the edit pattern is a fill character. It is not overwritten. The Fill Character The leftmost hexadecimal byte in the output area before the execution of the instruction begins represents the fill character to use when replacing non–significant leading zeroes. Two standard values are: 0x40 a blank ‘ ’ 0x5C an asterisk ‘*’ Often used in check printing. Consider the three digit number 172, stored internally as 172C. For now, assume that the field from which it will be printed allows for five digits. With a fill character of 0x40 (blank), this would normally be printed as 172. We force significance to cause either 0172 or 00172 to be printed. For this number, with a fill character of 0x40, our options would be one of the three following. 172 0172 00172 With a fill character of 0x5C, we might have one of the three following. **172 *0172 00172 The Edit Word: Encountering Significance Here are some of the commonly used edit characters. Note that it is more convenient to represent these by their hexadecimal EBCDIC. One key idea is the encounter of significance. The instruction generates digits for possible printing from left (most significant) to right (least significant). Two events cause this encounter: 1) a non–zero digit is generated, and 2) a digit is encountered that is associated with the 0x21 edit pattern. As noted above, the first character is the fill character. The other codes are 0x20 Digit selector. This represents a digit to be printed, unless it happens to be a leading non–significant zero. In that case, the fill character is printed. 0x21 Digit selector and significance starter. This not only represents a digit to be printed, but it also forces significance. Each digit to the right will be printed, even if a leading zero. Note: Unless one is careful, ED might result in an output field that is all blanks. For printing integer values, one might seriously consider ending the edit pattern (word) with the values 0x2120. Significance is forced after the next–to–last digit, forcing at least one digit to be printed. The Edit Word: Formatting the Output Part of the function of the ED command is to allow standard formatting of the output, including decimal points and commas. Handling of negative numbers is a bit strange. Here are the standard formatting patterns. 0x4B The decimal point. If significance has been encountered, the decimal point is printed. Otherwise, the fill character is printed. 0x6B The comma. If significance has been encountered, the comma is printed. Otherwise, the fill character is printed. 0x60 The minus sign, “–”. This is used in an unexpected way. The standard for use of the minus sign arises from conventions found in commercial use. The minus sign is placed at the end of the number. Thus the three digit positive number 172 would be printed as 172 and the three digit negative number –172 would be printed as 172–. The edit pattern for this output (ignoring the significance issue) would be as follows: 0x4020202060. The fill character is a blank. There are three digits followed by a sign field, which is printed as either “–” or the fill character. ED: A More Complete Example We now show the complete code for producing a printable output from the seven digit packed number considered above. We shall use “*” as a fill character. Note that the output will be eleven EBCDIC characters. Here is the code. PRINTAMT MVC AMNTPR,EDITWD ED AMTPR,AMTPACK * EDITWD DC X‘5C20206B2021204B202060’ * AMTPACK DS PL4 FOUR BYTES TO STORE SEVEN DIGITS. * AMTOUT DS 0CL12 TWELVE EBCDIC CHARACTERS DOLLAR DC C‘$’ THE DOLLAR SIGN AMTPR DS CL11 THE FORMATTED PRINT OUTPUT ED: Another Example Using an Edit Pattern This example is adapted from the textbook. Suppose that we have the following. The packed value to be printed is represented by DC PL3‘7’ This is represented as 00 00 7C. The edit pattern, when placed in the output area beginning at byte address 90, is as shown below. Address 90 91 92 93 94 95 96 97 Code 40 20 21 20 4B 20 20 60 Note the structure here: 3 digits to the left of the decimal (at least one will be printed), the decimal point, and two digits to the right of the decimal. This might lead one to expect something like “000.07” to be printed. We now follow the discussion on pages 181 and 182 of the textbook and note a discrepancy in the books description. We shall see what to make of this. ED: First Two Digits At address 90 the contents are 0x40, assumed to be the fill character. This location is not altered. Address 90 91 92 93 94 95 96 97 Code 40 20 21 20 4B 20 20 60 At address 91 the contents 0x20 is a digit selector. The first digit of the packed amount is examined. It is a 0. 00007C ED replaces the 0x20 with the fill character, 0x40. Address 90 91 92 93 94 95 96 97 Code 40 40 21 20 4B 20 20 60 At address 92 the contents 0x21 is a digit selector and a significance forcer for what follows. The second digit 00007C of the packed amount is of the packed amount is examined. It is a 0. ED replaces the 0x21 with the fill character, 0x40. Address 90 91 92 93 94 95 96 97 Code 40 40 40 20 4B 20 20 60
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved