Re: VSAM Relative Record Number
That's more than I was willing to guaranty about the VSE documentation, hence my "The house is white on this side" answer. I could tell you what z/OS DFSMS Macro Instructions for Data Sets and z/OS DFSMS Using Data Sets say, but how much if anything applies to vse, I don't know. -- 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: Thursday, March 10, 2022 2:18 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: VSAM Relative Record Number "IBM Mainframe Assembler List" wrote on 03/10/2022 02:04:21 PM: > At least for z/OS it's documented. I can't speak for z/VSE. Well, I had spent three hours reading the manual up one side and down the other, that I have, and hadn't found that piece of information. After seeing your response, above, I went reading again. This time I found just a single sentence at the very end of the description for the ARG operand. "When records are sequentially inserted into, or retrieved from, a relative-record file, VSE/VSAM returns the assigned relative-record number in the ARG field (as a four-byte binary number)." It is awful easy to miss that phrase "and retrieved from." So, since it specifically calls out relative record files and relative record numbers, does that mean VSAM does NOT also return key values to the argument buffer when sequentially reading a key-sequence file? Yes, I know it is available in the record itself and I can experiment to find out if it is also at the ARG location. ;-) 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: VSAM Relative Record Number
"IBM Mainframe Assembler List" wrote on 03/10/2022 02:04:21 PM: > At least for z/OS it's documented. I can't speak for z/VSE. Well, I had spent three hours reading the manual up one side and down the other, that I have, and hadn't found that piece of information. After seeing your response, above, I went reading again. This time I found just a single sentence at the very end of the description for the ARG operand. "When records are sequentially inserted into, or retrieved from, a relative-record file, VSE/VSAM returns the assigned relative-record number in the ARG field (as a four-byte binary number)." It is awful easy to miss that phrase "and retrieved from." So, since it specifically calls out relative record files and relative record numbers, does that mean VSAM does NOT also return key values to the argument buffer when sequentially reading a key-sequence file? Yes, I know it is available in the record itself and I can experiment to find out if it is also at the ARG location. ;-) 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: VSAM Relative Record Number
At least for z/OS it's documented. I can't speak for z/VSE. -- 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: Thursday, March 10, 2022 1:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: VSAM Relative Record Number "IBM Mainframe Assembler List" wrote on 03/10/2022 01:39:09 PM: > That's better asked on, e.g., IBM-MAIN, since it's not really an > assembler question. You should specify ARG= in the RPL, or fill it > in dynamically. Thanks. I already had an argument buffer for the RPL and I do use it for direct processing. I didn't think it had anything to do with sequential processing, though. But, I decided to experiment and "discovered" that VSAM places the RRN back in the RPL argument buffer for the last record read. 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: VSAM Relative Record Number
"IBM Mainframe Assembler List" wrote on 03/10/2022 01:39:09 PM: > That's better asked on, e.g., IBM-MAIN, since it's not really an > assembler question. You should specify ARG= in the RPL, or fill it > in dynamically. Thanks. I already had an argument buffer for the RPL and I do use it for direct processing. I didn't think it had anything to do with sequential processing, though. But, I decided to experiment and "discovered" that VSAM places the RRN back in the RPL argument buffer for the last record read. 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: VSAM Relative Record Number
That's better asked on, e.g., IBM-MAIN, since it's not really an assembler question. You should specify ARG= in the RPL, or fill it in dynamically. -- 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: Thursday, March 10, 2022 1:02 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: VSAM Relative Record Number In assembler... When you do a sequential read of a KSDS file, you can get the key just read from the record just read and you can get its RBA from the RPL. But when you do a sequential read of an RRDS file, where do you get the RRN for the record just read? 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: Edit Masks
Have you considered executing an EXECuted MVC of character zeroes over the edited data? Or a CLI, MVI loop on the edited data? On 2022-03-10 1:12 p.m., Steve Smith wrote: There's really nothing that can beat trying it out. Moving the Sig Start earlier is usually all you need; except it has what I consider to be the perverse effect of starting significance with the following digit. Which makes it impossible to include the first leading zero naturally (because SoS picks up a digit, and suppresses it if 0). Sometimes using C'0' as the pad works out; sometimes, you have to coerce the input field to be longer than (1 more digits) than you want to display. sas On Thu, Mar 10, 2022 at 12:23 PM Charles Mills wrote: Dave, you raise a good point. ED is powerful but tricky. You would have to read the PoOp very carefully. Sorry to wimp out here, but it has been a long time for me. I fear you are correct: that ED will happily use the significance starter as a fill byte, with unhappy results. For the "no blank fill" case you may have to ZAP the data to a larger field, or use UNPK and OI. 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.
Re: Edit Masks
There's really nothing that can beat trying it out. Moving the Sig Start earlier is usually all you need; except it has what I consider to be the perverse effect of starting significance with the following digit. Which makes it impossible to include the first leading zero naturally (because SoS picks up a digit, and suppresses it if 0). Sometimes using C'0' as the pad works out; sometimes, you have to coerce the input field to be longer than (1 more digits) than you want to display. sas On Thu, Mar 10, 2022 at 12:23 PM Charles Mills wrote: > Dave, you raise a good point. ED is powerful but tricky. You would have to > read the PoOp very carefully. Sorry to wimp out here, but it has been a > long > time for me. I fear you are correct: that ED will happily use the > significance starter as a fill byte, with unhappy results. For the "no > blank > fill" case you may have to ZAP the data to a larger field, or use UNPK and > OI. > > Charles > >
VSAM Relative Record Number
In assembler... When you do a sequential read of a KSDS file, you can get the key just read from the record just read and you can get its RBA from the RPL. But when you do a sequential read of an RRDS file, where do you get the RRN for the record just read? 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: Edit Masks
Dave, you raise a good point. ED is powerful but tricky. You would have to read the PoOp very carefully. Sorry to wimp out here, but it has been a long time for me. I fear you are correct: that ED will happily use the significance starter as a fill byte, with unhappy results. For the "no blank fill" case you may have to ZAP the data to a larger field, or use UNPK and OI. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Thursday, March 10, 2022 9:17 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Edit Masks "IBM Mainframe Assembler List" wrote on 03/10/2022 12:00:07 PM: > Or move the significance starter earlier, I think. I would need to > look up the details. But if, as in the following case, the significance starter is already the first of the 5 digits then moving it any earlier would mean that ED would try to read another numeric digit -- which would be the sign nibble and would cause problems. Yes? Or are you saying that you would make the fill byte be the significance starter? Does that work? x'40212020202060' 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: Edit Masks
"IBM Mainframe Assembler List" wrote on 03/10/2022 12:00:07 PM: > Or move the significance starter earlier, I think. I would need to > look up the details. But if, as in the following case, the significance starter is already the first of the 5 digits then moving it any earlier would mean that ED would try to read another numeric digit -- which would be the sign nibble and would cause problems. Yes? Or are you saying that you would make the fill byte be the significance starter? Does that work? x'40212020202060' 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: Edit Masks
Or move the significance starter earlier, I think. I would need to look up the details. What I have done when using ED/EDMK -- and it has been a while -- is get pencil and paper and "play computer" one digit at a time, following along in the PoOp. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Hobart Spitz Sent: Thursday, March 10, 2022 7:01 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Edit Masks That would work. However, unless you're planning to have decimal positions later or change between leading zeros and leading blanks, you can drop ED and the mask and just use UNPK. Using ED in your case is just making more work for yourself. OREXXMan Q: What do you call the residence of the ungulate with the largest antlers? A: A moose pad. :-D Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. REXX is the new C. On Thu, Mar 10, 2022 at 8:47 AM Dave Clark wrote: > If I have a 3-byte packed decimal field (and let's say 0 decimals > for simplicity), I might normally go with the following edit mask if I > didn't want to retain leading zeros but leave one zero for a value of > zero. > > x'40202020212060' > > But if I wanted to retain leading zeros, would you simply change > the fill byte to x'F0'? ...or would you do something else? > > 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: Edit Masks
On Thu, 10 Mar 2022 09:01:21 -0600 Hobart Spitz wrote: :>That would work. However, unless you're planning to have decimal positions :>later or change between leading zeros and leading blanks, you can drop ED :>and the mask and just use UNPK. Using ED in your case is just making more :>work for yourself. UNPK may give strange results if the positive sign is preferred. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel
Re: Edit Masks
"IBM Mainframe Assembler List" wrote on 03/10/2022 10:01:21 AM: > That would work. However, unless you're planning to have decimal positions > later or change between leading zeros and leading blanks, you can drop ED > and the mask and just use UNPK. Using ED in your case is just making more > work for yourself. Yes, this is in a routine that can handle all of the following: sign retention, or none; variable number of leading zeroes, or none; variable number of decimal positions (up to 15), or none; and, variable number of digits from 1 to 31. 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: Edit Masks
That would work. However, unless you're planning to have decimal positions later or change between leading zeros and leading blanks, you can drop ED and the mask and just use UNPK. Using ED in your case is just making more work for yourself. OREXXMan Q: What do you call the residence of the ungulate with the largest antlers? A: A moose pad. :-D Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. REXX is the new C. On Thu, Mar 10, 2022 at 8:47 AM Dave Clark wrote: > If I have a 3-byte packed decimal field (and let's say 0 decimals > for simplicity), I might normally go with the following edit mask if I > didn't want to retain leading zeros but leave one zero for a value of > zero. > > x'40202020212060' > > But if I wanted to retain leading zeros, would you simply change > the fill byte to x'F0'? ...or would you do something else? > > 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. > > * >
Edit Masks
If I have a 3-byte packed decimal field (and let's say 0 decimals for simplicity), I might normally go with the following edit mask if I didn't want to retain leading zeros but leave one zero for a value of zero. x'40202020212060' But if I wanted to retain leading zeros, would you simply change the fill byte to x'F0'? ...or would you do something else? 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. *
