Re: Rules for Zoned Overpunch
"IBM Mainframe Assembler List" wrote on 02/14/2022 03:00:31 PM: > >> - just EDMK it and place the sign(depending on the results of the > >> previous tests) where ever it needs to be. > > > >I can't do that because I'm using a generic, reusable routine to > >convert binary to zoned and it can't see the original record data. It > >only sees the data I pass to it in a 64-bit register. So the passed data > >has to already have the correct sign. > > I'm confused. Are you passing zoned data in a register? Or the > address of zoned data? Or perhaps a binary number? It is a generic, reusable routine I wrote to convert a binary number in a 64-bit register to zoned output with a floating left sign and option floating decimal point. It returns the result left-justified with or without the optional left zeros. So, internally (naturally), the routine must first convert the binary number to a 16-byte packed number before using EDMK to convert it into an up to a 31-digit zoned output with an external sign and optional explicit decimal point. But possibly what is confusing is that this thread of questioning is about zoned input which is only indirectly related to the zoned output of the routine I just mentioned. I have to parse the content of a file record and return the parsed data to the caller without the benefit of any language to interpret the format of that record. Thus, the caller passes me data definitions and I pass back the requested data in a format the caller can more easily handle -- which is only character data (numeric or otherwise). I have to handle the data going in the other direction, too. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Rules for Zoned Overpunch
On Mon, 14 Feb 2022 12:36:34 -0500, Dave Clark wrote: >"IBM Mainframe Assembler List" wrote on >02/14/2022 12:05:20 PM: >Why would I get S0C7 due to an invalid sign when I'm using PKA >(not PACK) which ignores the original sign altogether and forces a >standard positive sign on output? You wouldn't get a S0C7 because of a bad sign after PKA, but you could get a S0C7 because of bad digits. >> - just EDMK it and place the sign(depending on the results of the >> previous tests) where ever it needs to be. > >I can't do that because I'm using a generic, reusable routine to >convert binary to zoned and it can't see the original record data. It >only sees the data I pass to it in a 64-bit register. So the passed data >has to already have the correct sign. I'm confused. Are you passing zoned data in a register? Or the address of zoned data? Or perhaps a binary number? -- Tom Marchant
Re: Rules for Zoned Overpunch
Here is another table based scheme which combines sign validation, sign classification (i.e., the sign is negative or positive) and recognition of the preferred sign values. LLC R14,BYTE Fetch the rightmost byte * of the Zoned Decimal field. * SRL R14,4(0) Convert the Zone bits * to a table index. * LAR14,ZDSTBL(R14) * Fetch the corresponding ICM R14,B'0001',0(R14) * table value. * JZINVALID Br if the Zone is not a * valid Sign value. * JMNEGATIVE Br if the Zone indicates * a Negative value. * * Fall through when the Sign is considered Positive. * POSITIVE DC0H'0' TML R14,ZDSTPREF Test for the Preferred * Sign indicator if so * desired. * ... Deal with Positive values ... * J FINISH All done NEGATIVE DC0H'0' TML R14,ZDSTPREF Test for the Preferred * Sign indicator if so * desired. * ... Deal with Negative values ... * J FINISH All done * -- * * The following table is used to validate the 4-bit Zone field of * the rightmost byte of a Zoned Decimal value when interpreting * the Zone value as a Sign value. * * When a table entry is all binary zeros the corresponding Zone * value is not a valid Sign value. * * Preferred Sign values are also indicated. * * The leftmost bit of a table entry is used to indicate the Sign * (Negative or Positive) such that its value (one or zero, * respectively) can be used to set a corresponding Condition Code * when the entry is fetched using the Insert Characters Under Mask * instruction. * * -- ZDSTNEG EQU X'80'When one, the sign is * regarded as Negative. * Else, the sign is regarded * as Positive. * ZDSTPREF EQU X'40'When one, the sign is * regarded as the Preferred * sign. * *EQU X'20'*** Reserved *EQU X'10'*** Reserved *EQU X'08'*** Reserved *EQU X'04'*** Reserved *EQU X'02 *** Reserved * ZDSTVAL EQU X'01'When one, the sign is valid. * DC0D'0' ZDSTBL EQU *,16 DC10AL1(0) Zone values of x'0' * through x'9' are * invalid. * DCAL1(ZDSTVAL) A: Positive, Valid DCAL1(ZDSTNEG+ZDSTVAL) B: Negative, Valid * DCAL1(ZDSTPREF+ZDSTVAL)C: Positive, Preferred, * Valid. * DCAL1(ZDSTNEG+ZDSTPREF+ZDSTVAL) * D: Negative, Preferred, * Valid. * DCAL1(ZDSTVAL) E: Positive, Valid DCAL1(ZDSTVAL) F: Positive, Valid *
Re: Rules for Zoned Overpunch
"IBM Mainframe Assembler List" wrote on 02/14/2022 12:05:20 PM: > I would consider using TP to verify the signs and protect yourself from > S0C7 on the subsequent handling of the packed number Why would I get S0C7 due to an invalid sign when I'm using PKA (not PACK) which ignores the original sign altogether and forces a standard positive sign on output? > I would not do anything against the number (no MHI or so) Why not? > - just EDMK it and place the sign(depending on the results of the > previous tests) where ever it needs to be. I can't do that because I'm using a generic, reusable routine to convert binary to zoned and it can't see the original record data. It only sees the data I pass to it in a 64-bit register. So the passed data has to already have the correct sign. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Rules for Zoned Overpunch
Also, IBM COBOL for z/OS v6 does not generate a TP to check for IF NUMERIC. This is the generated code for an IF NUMERIC test at OPT(0),ARCH(10),NUMPROC(NOPFD): The COBOL code is: 01 work-areas. 05 out-field pic s9(3) packed-decimal. move x'125F' to work-areas. if out-field is numeric display 'numeric' else display 'not numeric' end-if. goback. The IS NUMERIC generated code: LA R6,240(,R13) # TS2=5 LA R4,236(,R13) # TS2=6 XR R2,R2 TRT 152(2,R9),184(R3) # OUT-FIELD ST R1,0(,R6) # STC R2,0(,R4) # BRC 13,L0005 TM 236(,R13),X'3F' # BRC 7,L0005 -Original Message- From: IBM Mainframe Assembler List On Behalf Of Schmitt, Michael Sent: Monday, February 14, 2022 11:12 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch Yes, IF NUMERIC will catch non-preferred signs when compiled with NUMPROC(PFD). So will the NUMCHECK option, which adds run-time checks -- it is like there's a "IF NOT NUMERIC DISPLAY A WARNING" on use of a numeric field. Where this came up a few weeks ago was with a program that was calling an assembler utility that I thought we could trust, so we had no reason to be testing its output fields. > Can you provide an example? Yes, but of what? An example case where the wrong (in COBOL's view) sign nybble will create an incorrect processing result? It is actually simple: COBOL wants to generate CLC & MVC instead of CP & ZAP when it can. FWIW, we started compiling with NUMPROC(PFD) in 2015. We do hit problems, but not enough to go back to the slower code. An example problem is when code is moving spaces to a packed-decimal field and expecting it to be processed like a zero. That works with NUMPROC(NOPFD) but not with preferred signs! -Original Message- From: IBM Mainframe Assembler List On Behalf Of Binyamin Dissen Sent: Monday, February 14, 2022 6:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch On Fri, 11 Feb 2022 18:40:42 + "Schmitt, Michael" wrote: :>What do you want to do if it is /not/ FACEBD? :>Also, while the machine instructions consider F to be positive, IBM COBOL since VS COBOL II really wants 3 signs: F, C, D, where F is UNSIGNED. So it does make a difference when a packed or zoned field is being returned from an assembler program; the value really should match how the COBOL program is expecting it. :>That is, if the COBOL program is expecting PIC S9(3) PACKED-DECIMAL but the value is x'123F', or the COBOL program expects PIC 9(3) PACKED-DECIMAL and the value is x'123C', that would be bad. Really bad. :>From a practical standpoint it would prevent the COBOL program from being able to generate maximally efficient NUMPROC(PFD) code -- you wouldn't be able to use that compile option. :>This is called "COBOL Preferred Signs", and started in 1992 or so. I would assume that by now the IF NUMERIC for a packed field would generate a TP, so I don't see why there would be an issue if a non-prefered sign is provided as a parameter or return value. Can you provide an example?
Re: Rules for Zoned Overpunch
Yes, IF NUMERIC will catch non-preferred signs when compiled with NUMPROC(PFD). So will the NUMCHECK option, which adds run-time checks -- it is like there's a "IF NOT NUMERIC DISPLAY A WARNING" on use of a numeric field. Where this came up a few weeks ago was with a program that was calling an assembler utility that I thought we could trust, so we had no reason to be testing its output fields. > Can you provide an example? Yes, but of what? An example case where the wrong (in COBOL's view) sign nybble will create an incorrect processing result? It is actually simple: COBOL wants to generate CLC & MVC instead of CP & ZAP when it can. FWIW, we started compiling with NUMPROC(PFD) in 2015. We do hit problems, but not enough to go back to the slower code. An example problem is when code is moving spaces to a packed-decimal field and expecting it to be processed like a zero. That works with NUMPROC(NOPFD) but not with preferred signs! -Original Message- From: IBM Mainframe Assembler List On Behalf Of Binyamin Dissen Sent: Monday, February 14, 2022 6:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch On Fri, 11 Feb 2022 18:40:42 + "Schmitt, Michael" wrote: :>What do you want to do if it is /not/ FACEBD? :>Also, while the machine instructions consider F to be positive, IBM COBOL since VS COBOL II really wants 3 signs: F, C, D, where F is UNSIGNED. So it does make a difference when a packed or zoned field is being returned from an assembler program; the value really should match how the COBOL program is expecting it. :>That is, if the COBOL program is expecting PIC S9(3) PACKED-DECIMAL but the value is x'123F', or the COBOL program expects PIC 9(3) PACKED-DECIMAL and the value is x'123C', that would be bad. Really bad. :>From a practical standpoint it would prevent the COBOL program from being able to generate maximally efficient NUMPROC(PFD) code -- you wouldn't be able to use that compile option. :>This is called "COBOL Preferred Signs", and started in 1992 or so. I would assume that by now the IF NUMERIC for a packed field would generate a TP, so I don't see why there would be an issue if a non-prefered sign is provided as a parameter or return value. Can you provide an example?
Re: Rules for Zoned Overpunch
Dave, I would consider using TP to verify the signs and protect yourself from S0C7 on the subsequent handling of the packed number also I would not do anything against the number (no MHI or so) - just EDMK it and place the sign(depending on the results of the previous tests) where ever it needs to be. Martin
Re: Rules for Zoned Overpunch
"IBM Mainframe Assembler List" wrote on 02/12/2022 10:11:13 PM: > You could PACK the field, or just the last byte (which is just a > nibble-swap), and CP to =P'0'. The cond. code tells you what you want to > know. I have to use PKA instead of PACK because the zoned data can be up to 31 bytes in length and PKA doesn't set the condition code. Yes, you said I could just PACK the last byte but I think I prefer bit testing similar to the following. > Or, you could use > IF TM,lastByte,B'',O > It's + F (or not signed, if you like that interpretation) > ELSEIF TM,lastByte,B'0001',O > It's - B or D > ELSE > It's + A, C, or E > ENDIF > Note that this is a pure sign check, i.e. 0 is not special. > > The last is more instructions, but I'd guess that it would perform the best > if that matters. In line with the above, I will consider zoned data that ends with anything less than x'A0' to be invalid and will just return it to the caller as it was in the record. Otherwise, I will PKA/CVBG it and then negate it (because PKA ignores overpunch signs and forces a packed x'.C' sign) if the original last byte passes the following test. IF 0(R3),(NO,TM),X'F0' IF WAS NEGATIVE AND 0(R3),(ON,TM),X'10' MGHI R2,-1NEGATE THE 64-BIT NUMBER ENDIF After that, I will convert it back to zoned data with a floating left sign and an optional decimal point using EDMK. I will use just two edit masks and dynamically place the optional decimal point in the second one. I will also dynamically place the significance byte depending upon whether I want to keep leading zeroes or not. MASK0DCx'402020202020202020202020202020202020202020202020202020- 20202020206040' MASK1DCx'402020202020202020202020202020202020202020202020202020- 20202020202060' Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Executing a ZAP Instruction
On Feb 14, 2022, at 06:31:53, Tom Marchant wrote: > > ... you cannot use ZAP (EXecuted or not) to pack character data. > Isn't that just the Pigeonhole Principle? -- gil
Re: Executing a ZAP Instruction
On Fri, 11 Feb 2022 18:12:04 -0500, Dave Clark wrote: >"IBM Mainframe Assembler List" wrote on >02/11/2022 06:00:02 PM: >> Yes, you can EXecute a ZAP instruction. But, you can't use it to PACK > > >Why not? ZAP and PACK are the exact same format instructions >(SS-b). Of course they are, and you can EX a PACK, but you cannot use ZAP (EXecuted or not) to pack character data. That's what I thought your OP was talking about. -- Tom Marchant
Re: Rules for Zoned Overpunch
On Fri, 11 Feb 2022 18:40:42 + "Schmitt, Michael" wrote: :>What do you want to do if it is /not/ FACEBD? :>Also, while the machine instructions consider F to be positive, IBM COBOL since VS COBOL II really wants 3 signs: F, C, D, where F is UNSIGNED. So it does make a difference when a packed or zoned field is being returned from an assembler program; the value really should match how the COBOL program is expecting it. :>That is, if the COBOL program is expecting PIC S9(3) PACKED-DECIMAL but the value is x'123F', or the COBOL program expects PIC 9(3) PACKED-DECIMAL and the value is x'123C', that would be bad. Really bad. :>From a practical standpoint it would prevent the COBOL program from being able to generate maximally efficient NUMPROC(PFD) code -- you wouldn't be able to use that compile option. :>This is called "COBOL Preferred Signs", and started in 1992 or so. I would assume that by now the IF NUMERIC for a packed field would generate a TP, so I don't see why there would be an issue if a non-prefered sign is provided as a parameter or return value. Can you provide an example? :>-Original Message- :>From: IBM Mainframe Assembler List On Behalf Of Dave Clark :>Sent: Friday, February 11, 2022 12:01 PM :>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU :>Subject: Rules for Zoned Overpunch :>I know that x'F1' and x'C1' are positive and that x'D1' is :>negative. But what if I find x'A1', x'B1', or x'E1' for overpunch values? :> What is the shortest way (in terms of assembler instructions) to validate :>these into just two classes -- positive and negative? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel
