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: 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
Re: Rules for Zoned Overpunch
Do you simply want to translate all valid zones into one of two cannonical zones, or do you also want to detect invalid zones? I.e., do you want to flag zones of 0-9 as errors. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Dave Clark [dlcl...@winsupplyinc.com] Sent: Friday, February 11, 2022 1:00 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? Sincerely, Dave Clark -- 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 2/13/2022 7:37 AM, Seymour J Metz wrote: That translates, but it doesn't validate. Drop the NILL and use a 16 byte literal: =C'?? - - ' I was under the impression he did not care about invalid values and was merely looking for a quick way of handling positive vs negative. As such, the '?' characters are just placeholders. If he actually wants full validation of the sign nybble, then I agree the 16-byte literal is best. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Rules for Zoned Overpunch
That translates, but it doesn't validate. Drop the NILL and use a 16 byte literal: =C'?? - - ' -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Ed Jaffe [edja...@phoenixsoftware.com] Sent: Saturday, February 12, 2022 11:24 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch On 2/11/2022 10:00 AM, Dave Clark wrote: > 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? Shortest? Who knows? | LLC Rx,LASTBYTE Get last byte | SRL Rx,4Isolate sign.. | NILL Rx,X'0007' ..to last 3 bits | LARx,=C'?? - - '(Rx) Point to sign char | MVC SIGNCHAR,0(Rx) Set appropriate sign or '?' -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1_OEgQsf85ao7kV0oTkK3GqxzrHRkTBSUi6W17JdVqH5h7Tu5AXcTaiPX1hggXsNWCy_xqAoeKvuDpARDnfRxZ94zQLwl4FoDmO3_Q8DZHY8zq3PH5Raph0xK5LujOn9hPskrZez7XHhS1GDMq60ha8KSzkj-n1Vm5GFf5sa8LEkxXxhOj171MVqjRKYbd8M_1oC5lrJ5u1cwLr24d62gfHJJwdd4Kys0cY-SRy4MpHNOsn9krZrKZG-_3HGEwZ0sF_MTUN13aV14bD-pp7O1n64Xc42VGyKWkYu3mUPI_V1sJ1Mc9OwHKlJA0gZordldoqeSK-_ihg8FRx6JHvZQqejvzGrAhoYrFqUMYJsbWilMU6qsFEk_L50bc4HXps5ZWT13mXrsjYVtEg1R_vFaTj8ib-DkuH8Yz3TOwHV5oaVv1sKTHY5ajis8_nkYpwcg/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Rules for Zoned Overpunch
And CVB/CVD/CLC/BC isn't a bigger sledge hammer? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Robin Vowels [robi...@dodo.com.au] Sent: Sunday, February 13, 2022 12:10 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch On 2022-02-13 12:21, Seymour J Metz wrote: > Why not CVB/LTR/BC? Nice suggestion, but it's a huge sledgehammer! > > Shmuel (Seymour J.) Metz > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] > on behalf of Paul Gilmartin > [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] > Sent: Friday, February 11, 2022 1:14 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Rules for Zoned Overpunch > > On Feb 11, 2022, at 11:00:58, Dave Clark wrote: >> >>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? >> > How about CVB then CVD, then compare the result to the original? > > -- > gil
Re: Rules for Zoned Overpunch
Regardless of pathlength or bytes for instructions - I like this most Maybe add a comment to show that F becomes 7 and so on and that invalid signs (0 thru 9 in left nibble) become ? Am 13.02.22 um 05:24 schrieb Ed Jaffe: Shortest? Who knows? | LLC Rx,LASTBYTE Get last byte | SRL Rx,4 Isolate sign.. | NILL Rx,X'0007' ..to last 3 bits | LA Rx,=C'?? - - '(Rx) Point to sign char | MVC SIGNCHAR,0(Rx) Set appropriate sign or '?' Martin
Re: Rules for Zoned Overpunch
On 2022-02-13 12:21, Seymour J Metz wrote: Why not CVB/LTR/BC? Nice suggestion, but it's a huge sledgehammer! Shmuel (Seymour J.) Metz From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Friday, February 11, 2022 1:14 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch On Feb 11, 2022, at 11:00:58, Dave Clark wrote: 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? How about CVB then CVD, then compare the result to the original? -- gil
Re: Rules for Zoned Overpunch
On 2/11/2022 10:00 AM, Dave Clark wrote: 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? Shortest? Who knows? | LLC Rx,LASTBYTE Get last byte | SRL Rx,4 Isolate sign.. | NILL Rx,X'0007' ..to last 3 bits | LA Rx,=C'?? - - '(Rx) Point to sign char | MVC SIGNCHAR,0(Rx) Set appropriate sign or '?' -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Rules for Zoned Overpunch
You could use TRT to test the last byte, after some tedious coding of the table. N.B. I mean using the table codes to identify +/0/-/invalid; not just the 0/non-0 typical use. 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. You could also use AP =P'0', which returns the same cond. code, but also normalizes the sign... but only in your test field, of course. 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. sas On Fri, Feb 11, 2022 at 1:01 PM Dave Clark wrote: > 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? > >
Re: Rules for Zoned Overpunch
On Feb 12, 2022, at 18:47:45, Seymour J Metz wrote: > > I read "validate these into just two classes" as validate that the zone - not > 0-9 and transform A-F appropriately into either C or D. > How about Compare Packed to a packed zero? But doesn't "just two classes" overlook a third class, that number which is neither positive nor negative? > > From: Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] > Sent: Saturday, February 12, 2022 8:40 PM > > On Feb 12, 2022, at 18:21:59, Seymour J Metz wrote: >> >> Why not CVB/LTR/BC? >> > It appears that the OP wants to "validate"; detect and > report the non-modal sign codes. > >> >> >> On Feb 11, 2022, at 11:00:58, Dave Clark wrote: >>> >>> 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? -- gil
Re: Rules for Zoned Overpunch
I read "validate these into just two classes" as validate that the zone - not 0-9 and transform A-F appropriately into either C or D. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Saturday, February 12, 2022 8:40 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch On Feb 12, 2022, at 18:21:59, Seymour J Metz wrote: > > Why not CVB/LTR/BC? > It appears that the OP wants to "validate"; detect and report the non-modal sign codes. If the original is zoned it might require: PACK; CVB; CVD; UNPK; CLC > > From: Paul Gilmartin > Sent: Friday, February 11, 2022 1:14 PM > > On Feb 11, 2022, at 11:00:58, Dave Clark wrote: >> >> 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? >> > How about CVB then CVD, then compare the result to the original? -- gil
Re: Rules for Zoned Overpunch
On Feb 12, 2022, at 18:21:59, Seymour J Metz wrote: > > Why not CVB/LTR/BC? > It appears that the OP wants to "validate"; detect and report the non-modal sign codes. If the original is zoned it might require: PACK; CVB; CVD; UNPK; CLC > > From: Paul Gilmartin > Sent: Friday, February 11, 2022 1:14 PM > > On Feb 11, 2022, at 11:00:58, Dave Clark wrote: >> >> 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? >> > How about CVB then CVD, then compare the result to the original? -- gil
Re: Rules for Zoned Overpunch
Why not CVB/LTR/BC? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Friday, February 11, 2022 1:14 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch On Feb 11, 2022, at 11:00:58, Dave Clark wrote: > >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? > How about CVB then CVD, then compare the result to the original? -- gil
Re: Rules for Zoned Overpunch
- Original Message - From: "Dave Clark" To: Sent: Saturday, February 12, 2022 5:00 AM 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? Only 11 and 13 represent negative values; the remainder represent positive values. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Rules for Zoned Overpunch
For the decimal point, one normally just has different edit patterns for each different number of positions to the right of the decimal point. And usually the edit pattern will set the significance indicator to the left of the decimal point so the decimal portion is zero-filled. On 2022-02-11 5:05 p.m., Charles Mills wrote: I am talking off the top of my head here. I have not used PACK and friends in years. Yes, there are length limitations. Pack is limited to 16 bytes and EDIT to 256 bytes of output. I am not familiar with PKA. CVB is not real relevant. Forget I said that. Well, it would help answer your sign question. I *think* you could pack the last few bytes of your input into a doubleword (no problem if the entire field is longer than that) and then CVB it and test the sign of the register. I *think* CVB handles all those oddball "overpunch" sign specifications. ZAP sets the CC based on the sign also, right? Yes, PACK and EDIT/EDMK handle implied decimals. For EDIT/EDMK you can tell it where to insert a real decimal point. IIRC it sets the CC so you know the sign of what you just edited. This is EXACTLY the chore that EDIT is designed for. Look at COBOL zoned decimal pictures. Now translate that in your head into a hardware instruction. That's EDIT. EDMK is one of those instructions where you have to read the PoOp about three times, but what it does is give you an address in R1 (?) that tells you where a floating minus sign or currency symbol needs to go. Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, February 11, 2022 11:51 AM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch "IBM Mainframe Assembler List" wrote on 02/11/2022 02:24:38 PM: Doesn't PACK + CVB + EDMK pretty much just do this for you? Well, in the first place I am allowing the incoming zoned-decimal field to be up to 31 bytes. PACK won't handle that -- although that is not insurmountable with PKA. But I'm also allowing the zone-decimal field to have an implied decimal with from 0 to 15 places. I don't think PACK + CVB + EDMK handle decimal digits for me plus inserting the decimal point in the proper place -- correct me if I am wrong. Sincerely, Dave Clark
Re: Rules for Zoned Overpunch
I am talking off the top of my head here. I have not used PACK and friends in years. Yes, there are length limitations. Pack is limited to 16 bytes and EDIT to 256 bytes of output. I am not familiar with PKA. CVB is not real relevant. Forget I said that. Well, it would help answer your sign question. I *think* you could pack the last few bytes of your input into a doubleword (no problem if the entire field is longer than that) and then CVB it and test the sign of the register. I *think* CVB handles all those oddball "overpunch" sign specifications. ZAP sets the CC based on the sign also, right? Yes, PACK and EDIT/EDMK handle implied decimals. For EDIT/EDMK you can tell it where to insert a real decimal point. IIRC it sets the CC so you know the sign of what you just edited. This is EXACTLY the chore that EDIT is designed for. Look at COBOL zoned decimal pictures. Now translate that in your head into a hardware instruction. That's EDIT. EDMK is one of those instructions where you have to read the PoOp about three times, but what it does is give you an address in R1 (?) that tells you where a floating minus sign or currency symbol needs to go. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, February 11, 2022 11:51 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch "IBM Mainframe Assembler List" wrote on 02/11/2022 02:24:38 PM: > Doesn't PACK + CVB + EDMK pretty much just do this for you? Well, in the first place I am allowing the incoming zoned-decimal field to be up to 31 bytes. PACK won't handle that -- although that is not insurmountable with PKA. But I'm also allowing the zone-decimal field to have an implied decimal with from 0 to 15 places. I don't think PACK + CVB + EDMK handle decimal digits for me plus inserting the decimal point in the proper place -- correct me if I am wrong. 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
"IBM Mainframe Assembler List" wrote on 02/11/2022 02:24:38 PM: > Doesn't PACK + CVB + EDMK pretty much just do this for you? Well, in the first place I am allowing the incoming zoned-decimal field to be up to 31 bytes. PACK won't handle that -- although that is not insurmountable with PKA. But I'm also allowing the zone-decimal field to have an implied decimal with from 0 to 15 places. I don't think PACK + CVB + EDMK handle decimal digits for me plus inserting the decimal point in the proper place -- correct me if I am wrong. 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
Doesn't PACK + CVB + EDMK pretty much just do this for you? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, February 11, 2022 11:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch "IBM Mainframe Assembler List" wrote on 02/11/2022 01:40:42 PM: > What do you want to do if it is /not/ FACEBD? I'm asking this question because I have to turn an ostensibly zoned-decimal field with an internal right sign (an "overpunch") into a string of digits with an external left sign. I did finally find statements on the Internet which indicate that B and D zones are considered negative while A, C, E, and F zones are considered positive. Thus, for "positive" numbers I will just leave the external sign off but for "negative" numbers I have to prefix the string of digits with the dash character. So, I'm looking for the shortest way to validate whether the last byte in the zoned-decimal field has a B or D zone and consider all other zones to be positive. At that point I plan to just force the zone to an F and position an external left negative sign if needed. Therefore, I don't really care if the last byte has an invalid zone or not. The data is normally generated by an RPG or COBOL program. So if invalid data is otherwise being forced into a zoned-decimal field then I'll just have to let the pieces fall where they may.
Re: Rules for Zoned Overpunch
"IBM Mainframe Assembler List" wrote on 02/11/2022 01:40:42 PM: > What do you want to do if it is /not/ FACEBD? I'm asking this question because I have to turn an ostensibly zoned-decimal field with an internal right sign (an "overpunch") into a string of digits with an external left sign. I did finally find statements on the Internet which indicate that B and D zones are considered negative while A, C, E, and F zones are considered positive. Thus, for "positive" numbers I will just leave the external sign off but for "negative" numbers I have to prefix the string of digits with the dash character. So, I'm looking for the shortest way to validate whether the last byte in the zoned-decimal field has a B or D zone and consider all other zones to be positive. At that point I plan to just force the zone to an F and position an external left negative sign if needed. Therefore, I don't really care if the last byte has an invalid zone or not. The data is normally generated by an RPG or COBOL program. So if invalid data is otherwise being forced into a zoned-decimal field then I'll just have to let the pieces fall where they may. 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
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. -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? Sincerely, Dave Clark -- 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 Feb 11, 2022, at 11:00:58, Dave Clark wrote: > >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? > How about CVB then CVD, then compare the result to the original? -- gil
