Re: Executing a ZAP Instruction
Actually, if the target field is always 16 bytes, you can do ZAP_IT ZAP PWORK16(16),0(0,r1) That eliminates the need for the first LHI -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Saturday, 12 February 2022 00:45 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Executing a ZAP Instruction "IBM Mainframe Assembler List" wrote on 02/11/2022 05:27:48 PM: > ZAP has L1/L2 so you want to load your EX register with (L1 * 16) + L2 > (where L1 and L2 are base 0, and a shift might be a better choice than an > actual multiply). Thanks, we'll see how this works. ;-) ZAP_IT ZAP PWORK16(0),0(0,R1) (SEE EXECUTE INSTRUCTION BELOW) ...snip... LHI R2,15*16 SET LENGTH OF WORK FIELD L R3,FLD_LENG SET LENGTH OF VAR DATA SHI R3,1 DECREMENT FOR EXECUTE AR R2,R3 COMBINE THE TWO EX R2,ZAP_IT MOVE VAR DATA TO WORK FIELD 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. * -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Executing a ZAP Instruction
From: "Dave Clark" Sent: Saturday, February 12, 2022 9:44 AM "IBM Mainframe Assembler List" wrote on 02/11/2022 05:27:48 PM: Thanks, we'll see how this works. ;-) ZAP_IT ZAP PWORK16(0),0(0,R1) (SEE EXECUTE INSTRUCTION BELOW) ...snip... LHI R2,15*16 SET LENGTH OF WORK FIELD L R3,FLD_LENG SET LENGTH OF VAR DATA SHI R3,1 DECREMENT FOR EXECUTE AR R2,R3 COMBINE THE TWO EX R2,ZAP_IT MOVE VAR DATA TO WORK FIELD Better is L R3,FLD_LENG LA R3,240(0,R3) BCTR 3,0 EX R3,ZAP_IT or even ICR3,FIELD_BYTE LA R3,239(0,R3) EX R3,ZAP_IT If the first operand has fixed length (15), that length can be encoded in the subject instruction, so you would need only ICR3,FIELD-BYTE BCTR R3,0 EX R3,ZAP_IT In any case, safest to test FIELD_BYTE or FLD_LENG for zero, prior to subtraction of 1. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Executing a ZAP Instruction
- Original Message - From: "Charles Mills" Sent: Saturday, February 12, 2022 9:27 AM EX is independent of the format of the target instruction. You can EX anything (except EX). It just plugs that second byte of the target instruction. You can EX an LR and vary which registers get copied. ZAP has L1/L2 so you want to load your EX register with (L1 * 16) + L2 (where L1 and L2 are base 0, What? and a shift might be a better choice than an actual multiply). Shift is always better than multiply. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Executing a ZAP Instruction
- Original Message - From: "Dave Clark" To: Sent: Saturday, February 12, 2022 9:03 AM How do (can?) you EXecute a ZAP instruction? I have a packed number in plain character format that can vary in length from 1 to 16 bytes. I need to move that into a 16-byte formal packed work field You do? It isn't necessary. The first operand of UNPK can be of any length. The second operand (the packed decimal number) is extended with zeros as necessary, before the UNPK conversion. in order to make the variable-length character data into recognizable packed-decimal data. The normal EXecute (ORs but effectively) replaces bits 8 to 15 of the target instruction with bits 56 to 63 of general register R1. But a ZAP instruction has an L1 field in bits 8 to 11 of the instruction and an L2 field in bits 12 to 15 of the instruction. Does that mean ZAP can't be EXecuted? Do I have to clear and align my variable-length character data in my 16-byte packed work field myself? Or is it feasible to manipulate the content of general register R1 so that bits 56 to 63 contain the correct L1 and L2 values? 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. * --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
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: Executing a ZAP Instruction
I presume you are pointing out that ZAP does NOT actually PACK anything that it is given*... of course one can EX the UNPK instruction. *duh I say, but some might be surprised I suppose. On Fri, 11 Feb 2022 at 18:00, Tom Marchant < 00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: > On Fri, 11 Feb 2022 17:03:09 -0500, Dave Clark > wrote: > > > Does that mean ZAP can't be EXecuted? > > Yes, you can EXecute a ZAP instruction. But, you can't use it to PACK > > -- > Tom Marchant >
Re: Executing a ZAP Instruction
Before the advent of the COMPARE AND TRAP type instructions, we all use to use EX Rnn,* to force a S0C3 abend for "this should never happen" conditions. But with baseless code, if you change EX Rnn,* to EXRL Rnn,* then you may not get your expected S0C3 when Rnn is a register other than zero. The low order nybble of the second byte of EXRL is zero indicating an EXRL instruction, if you modify it then it becomes some other X'C0' instruction! Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Friday, February 11, 2022 17:27 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Executing a ZAP Instruction Meaning what? You can't EX a PACK instruction? Are you absolutely certain of that? I think you can EX anything except an EX/EXR. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant Sent: Friday, February 11, 2022 3:00 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Executing a ZAP Instruction On Fri, 11 Feb 2022 17:03:09 -0500, Dave Clark wrote: > Does that mean ZAP can't be EXecuted? Yes, you can EXecute a ZAP instruction. But, you can't use it to PACK -- Tom Marchant
Re: Executing a ZAP Instruction
Meaning what? You can't EX a PACK instruction? Are you absolutely certain of that? I think you can EX anything except an EX/EXR. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant Sent: Friday, February 11, 2022 3:00 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Executing a ZAP Instruction On Fri, 11 Feb 2022 17:03:09 -0500, Dave Clark wrote: > Does that mean ZAP can't be EXecuted? Yes, you can EXecute a ZAP instruction. But, you can't use it to PACK -- Tom Marchant
Re: Executing a ZAP Instruction
"IBM Mainframe Assembler List" wrote on 02/11/2022 06:13:52 PM: > As others have mentioned, you can roll both the L1 and L2 into the reg > you are using to OR into the ZAP instruction. > > But, remember, this is an OR, not a store. If one of your lengths is a > constant, while the other is a variable, then you only need to fill one > of the lengths into the reg. Yep, I was just thinking exactly that... I don't need to combine the lengths because L1 is always the same and the OR part of EX won't touch it. 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: Executing a ZAP Instruction
As others have mentioned, you can roll both the L1 and L2 into the reg you are using to OR into the ZAP instruction. But, remember, this is an OR, not a store. If one of your lengths is a constant, while the other is a variable, then you only need to fill one of the lengths into the reg. This example from Dave works if both are variable: ZAP_IT ZAP PWORK16(0),0(0,R1) ...snip... LHI R2,15*16 SET LENGTH OF WORK FIELD L R3,FLD_LENG SET LENGTH OF VAR DATA SHI R3,1 DECREMENT FOR EXECUTE AR R2,R3COMBINE THE TWO EX R2,ZAP_ITMOVE VAR DATA TO WORK FIELD This is an example where you only need to adjust the sending field length: ZAP_IT ZAP PWORK16(16),0(0,R1) ...snip... LH R2,SEND_LENGTH SET LENGTH OF WORK FIELD SHI R3,1 DECREMENT FOR EXECUTE EX R2,ZAP_ITMOVE VAR DATA TO WORK FIELD This is an example where you only need to adjust the receiving field: ZAP_IT ZAP PWORK16(0),0(16,R1) ...snip... LH R2,RECV_LENGTH SET LENGTH OF WORK FIELD SHI R3,1 DECREMENT FOR EXECUTE SLA R2,4 SHIFT TO CORRECT SPOT EX R2,ZAP_ITMOVE VAR DATA TO WORK FIELD Tony Thigpen Dave Clark wrote on 2/11/22 17:03: How do (can?) you EXecute a ZAP instruction? I have a packed number in plain character format that can vary in length from 1 to 16 bytes. I need to move that into a 16-byte formal packed work field in order to make the variable-length character data into recognizable packed-decimal data. The normal EXecute (ORs but effectively) replaces bits 8 to 15 of the target instruction with bits 56 to 63 of general register R1. But a ZAP instruction has an L1 field in bits 8 to 11 of the instruction and an L2 field in bits 12 to 15 of the instruction. Does that mean ZAP can't be EXecuted? Do I have to clear and align my variable-length character data in my 16-byte packed work field myself? Or is it feasible to manipulate the content of general register R1 so that bits 56 to 63 contain the correct L1 and L2 values? 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
"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). 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 Fri, 11 Feb 2022 17:03:09 -0500, Dave Clark wrote: > Does that mean ZAP can't be EXecuted? Yes, you can EXecute a ZAP instruction. But, you can't use it to PACK -- Tom Marchant
Re: Executing a ZAP Instruction
"IBM Mainframe Assembler List" wrote on 02/11/2022 05:27:48 PM: > ZAP has L1/L2 so you want to load your EX register with (L1 * 16) + L2 > (where L1 and L2 are base 0, and a shift might be a better choice than an > actual multiply). Thanks, we'll see how this works. ;-) ZAP_IT ZAP PWORK16(0),0(0,R1) (SEE EXECUTE INSTRUCTION BELOW) ...snip... LHI R2,15*16 SET LENGTH OF WORK FIELD L R3,FLD_LENG SET LENGTH OF VAR DATA SHI R3,1 DECREMENT FOR EXECUTE AR R2,R3 COMBINE THE TWO EX R2,ZAP_IT MOVE VAR DATA TO WORK FIELD 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: Executing a ZAP Instruction
EX is independent of the format of the target instruction. You can EX anything (except EX). It just plugs that second byte of the target instruction. You can EX an LR and vary which registers get copied. ZAP has L1/L2 so you want to load your EX register with (L1 * 16) + L2 (where L1 and L2 are base 0, and a shift might be a better choice than an actual multiply). Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, February 11, 2022 2:03 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Executing a ZAP Instruction How do (can?) you EXecute a ZAP instruction? I have a packed number in plain character format that can vary in length from 1 to 16 bytes. I need to move that into a 16-byte formal packed work field in order to make the variable-length character data into recognizable packed-decimal data. The normal EXecute (ORs but effectively) replaces bits 8 to 15 of the target instruction with bits 56 to 63 of general register R1. But a ZAP instruction has an L1 field in bits 8 to 11 of the instruction and an L2 field in bits 12 to 15 of the instruction. Does that mean ZAP can't be EXecuted? Do I have to clear and align my variable-length character data in my 16-byte packed work field myself? Or is it feasible to manipulate the content of general register R1 so that bits 56 to 63 contain the correct L1 and L2 values? 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
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. *
Executing a ZAP Instruction
How do (can?) you EXecute a ZAP instruction? I have a packed number in plain character format that can vary in length from 1 to 16 bytes. I need to move that into a 16-byte formal packed work field in order to make the variable-length character data into recognizable packed-decimal data. The normal EXecute (ORs but effectively) replaces bits 8 to 15 of the target instruction with bits 56 to 63 of general register R1. But a ZAP instruction has an L1 field in bits 8 to 11 of the instruction and an L2 field in bits 12 to 15 of the instruction. Does that mean ZAP can't be EXecuted? Do I have to clear and align my variable-length character data in my 16-byte packed work field myself? Or is it feasible to manipulate the content of general register R1 so that bits 56 to 63 contain the correct L1 and L2 values? 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: Branch-and-Link nomenclature question
The notion of whether some of these linkage instructions could be thought of as "save" and "then branch" is interesting and hasn't changed since the introduction of the S/360. The fundamental concept is that as a part of normal instruction sequencing, the addressing information found in the PSW is updated as part of the instruction fetch and decode process (the instruction length code is used to adjust the instruction address portion of the PSW). For the RR format of these instructions when the "R2" operand is non-zero, the information contained in the "R2" operand is used to compute updated addressing information to be placed into the PSW. The addressing information currently contained in the PSW (this is the "link" information) is placed into the GPR designated by the "R1" operand prior to conditionally (when the "R2" operand is non-zero) replacing the addressing information in the PSW with the computed addressing information (this is the "branch" information). At the completion of the instruction the newly formed PSW is used. Specifying the same non-zero values for the "R1" and "R2" operands on BALR or BASR takes advantage of this concept. I have seen linkage assist services which work in this manner (frequently with the aid of a macro): - GPR 15 is loaded with the address of a function to be called. - GPR 14 is loaded with the address of the linkage assist service. - The linkage assist service is invoked via BASR R14,R14. - The linkage assist service deals with maintaining a "stack" of Save Areas (used to save/restore caller registers and other useful information), loads GPR 14 with the address of the service which unwinds the stack (to effect the "return" to the original caller), and transfers control to the target function whose address was contained in GPR 15 at entry to the linkage assist service. - Upon its completion, the called function "returns" to the address contained in GPR 14 at its entry (which transfers control to the stack unwinding service which, in turn, ultimately transfers control to the original caller). I have no idea if CICS does this kind of stuff. Quoting from the description of the BAL and BALR instructions as found in the September 1968 edition of the S/360 Principles of Operation: "The branch address is determined before the link information is stored." The z/Architecture Principles of Operation essentially states the same thing about BAL, BALR, BAS, BASR: "The branch address is computed before general register R1 is changed." And this is in the description of BASSM: "The new value for the PSW is computed before general register R1 is changed."
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
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: Hexadecimal display using vector instructions
I finally got a chance to walk thru these with XDC. Brilliant work! I guess I'm going to have to find some time to learn how to do some vectoring myself. These routines are a big help. Thank-you! sas On Tue, Feb 1, 2022 at 6:10 PM Ngan, Robert (DXC Luxoft) < robert.n...@dxc.com> wrote: > I originally just coded the obvious VUPKZ/MVI/TR like a UNPK/MVI/TR or > UNPKA/MVI/TR instruction sequence, but found the performance was within 10% > for all three variations. It looks like most of the time is spent in the > TR instruction. So, we need to eliminate the TR, and I came up with two > ways to do hexadecimal display conversion using the vector facility without > TR: > > VECTOR UNPACK LOGICAL > VLVR03,WorkXL16Load quadword source > VLVR06,=C'0123456789ABCDEF' "Translate" table > VREPIB VR05,X'000F'Initialize AND mask > *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -* > VUPLLB VR07,VR03 Pad each byte in LOW doublewordX > ... with a null byte on the left > VSLD VR02,VR07,VR07,4 Shift out high order nybble > VNVR04,VR02,VR05 Mask out L.O. source nybbles inX > ... H.O. vector register nybbles > VOVR08,VR04,VR07 Merge high/low nybble bytes > VPERM VR01,VR06,VR06,VR08 Translate to hexadecimal digits > *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -* > VUPLHB VR07,VR03 Pad each byte in HIGH doubleword X > ... with a null byte on the left > VSLD VR02,VR07,VR07,4 Shift out high order nybble > VNVR04,VR02,VR05 Mask out L.O. source nybbles inX > ... H.O. vector register nybbles > VOVR08,VR04,VR07 Merge high/low nybble bytes > VPERM VR00,VR06,VR06,VR08 Translate to hexadecimal digits > *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -* > VSTM VR00,VR01,WorkCL32 Store 32 hex digits > VECTOR MERGE > VLVR12,WorkXL16 Load quadword source > VLVR15,=C'0123456789ABCDEF' "Translate" table > VERLLB VR14,VR12,4 Swap high/low nybbles within bytes > VPERM VR13,VR15,VR15,VR12 Translate LOW nybbles to hex digits > VPERM VR11,VR15,VR15,VR14 Translate HIGH nybbles to hex digits > VMRHB VR09,VR11,VR13 Merge H.O. 16 hexadecimal digits > VMRLB VR10,VR11,VR13 Merge L.O. 16 hexadecimal digits > VSTEG VR09,WorkCL8a,0 Spread out hex digits, 8 per per store > VSTEG VR09,WorkCL8b,1 ... > VSTEG VR10,WorkCL8c,0 ... > VSTEG VR10,WorkCL8d,1 ... > > Both versions of the vector code run 5-20 time faster than your classical > UNPK/MVI/TR (5-20 nSec vs. 90-100 nSec on a z15 T02). > The UNPACK LOGICAL does 8 bytes at a time, so you can shorten the code if > you're converting no more than 8 bytes. > The MERGE code always does all 16 bytes, but second (low) MERGE is not > required if not converting more than 8 bytes. > > In MERGE example, I'm using multiple VSTEG's instead of a VSTM to spread > the output across 4 separate fields for legibility. > This code will convert 16 bytes at a time, unlike UNPKA and VUPKZ which > are restricted to a maximum of 15 bytes. And there's no "extra" byte to > clean up on the target side, or to worry about accessibility to on the > source side. > > A big thanks to Dan Greiner for his extremely helpful PowerPoints > explaining how the vector instructions work. But I still have no idea how > we'd use half of those instructions in general coding. The VPERM > instruction seems to be a (all register) TRANSLATE against a 32-byte table > (in two vector registers), looking at only the L.O. 5 bits of each byte. I > only needed to look at the bottom 4-bits, and achieved that by using the > same register for both halves of the translate table. > It's probably too complicate to hand-code, but useful if you have > hexadecimal display macro you can generate it from. > > Robert Ngan > DXC Luxoft >
