Re: VSAM: Why MAXLRECL?
Write the records to thee total size(including reserved). Example. 500 bytes of data and 500 bytes "reserved" If the record written is 1000 bytes long, but you are only using the 1st 500 bytes, up to 500 bytes of additional information could be added to the record, without having to alter the physical dataset. Are you suggesting to actually write the records to be the size including the "reserved" data, or to write the records of the size currently needed but have MAXLRECL defined so that records larger than are currently used can be written in the future? I was thinking the latter, but I want to clarify what you are suggesting. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM: Why MAXLRECL?
Are you suggesting to actually write the records to be the size including the "reserved" data, or to write the records of the size currently needed but have MAXLRECL defined so that records larger than are currently used can be written in the future? I was thinking the latter, but I want to clarify what you are suggesting. Thanks! Frank From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Allan Staller <allan.stal...@hcl.com> Sent: Thursday, January 12, 2017 6:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM: Why MAXLRECL? In IBM parlance this is a "reserved" field. Define the LREcL to the max needed Double that Add 10% This is the LRECL you define. Go back to the original LRECL and define what you need. Define the remainder as "reserved for future use". In that way, you only have to change the record defintions, not the file. HTH, Since the logging is only for troubleshooting purposes I decided to simply live with truncation of the end of the messages. But had the MAXLRECL for this file already been 32761, or some similar fairly large number I simply would have changed the program that logs the messages to not truncate at 500 bytes. My point is, it seems to me that MAXLRECL is a fairly "artificial limit", unless there is a actually a good reason that you'd want a MAXLRECL that is at least close to the, well, maximum record length. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM: Why MAXLRECL?
In IBM parlance this is a "reserved" field. Define the LREcL to the max needed Double that Add 10% This is the LRECL you define. Go back to the original LRECL and define what you need. Define the remainder as "reserved for future use". In that way, you only have to change the record defintions, not the file. HTH, Since the logging is only for troubleshooting purposes I decided to simply live with truncation of the end of the messages. But had the MAXLRECL for this file already been 32761, or some similar fairly large number I simply would have changed the program that logs the messages to not truncate at 500 bytes. My point is, it seems to me that MAXLRECL is a fairly "artificial limit", unless there is a actually a good reason that you'd want a MAXLRECL that is at least close to the, well, maximum record length. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM: Why MAXLRECL?
W dniu 2017-01-11 o 22:30, Frank Swarbrick pisze: Is there a downside to always defining VSAM files with a MAXLRECL of 32761, which seems to be the largest value for this parm for an UNSPANNED dataset? Besides CISZ and other performance issues there is another big issue: the application. Let's say you application ABC is designe to process records up to 3000B. Obviously you can use longer MAXRECL (the same for PS VB), but imagine someone inserted longer record. How? Using another application or utility. What application ABC will do? Probably just fail. When? When it get longer record. It can be during (end of) batch, or anytime - it depends. So, treat MAXLRECL as a protection. My €0.02 -- Radoslaw Skorupka Lodz, Poland --- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.955.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM: Why MAXLRECL?
With the paucity of information in your original post it definitely seemed an... odd... idea. I hate being "near" limits. To give an example, you have found something that says your can have 32761 for your data in VSAM (before extending yourself), and yet you can't have that amount of data for plain QSAM. Hit that limit, and next thing "rats we can't copy those bigguns, and rats immediately we need an extra byte for the log because of public holidays in Tanganiyka". Buffers, CI-Size, perhaps freespace, index levels - but you have a log file, so those are less of an issue. Personally I'd go with multiple-physical-one-logical and stick at your around-about 500-bytes. "Key" on each record, sequence number, just write out as many as you need (how many you need is known at the time, and there are no issues with intermixture, and even if there were, you have the information within the data to put things back together - (unlike "spanned" records)). Consider going fixed-length, ESDS. I assume that you are writing though a sub-program, and going for "write it quick, it's a log-record after all"? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM: Why MAXLRECL?
Why? As I said, in order to allow for "expansion" of the length of records without a requirement to take the file offline in order to alter it. Does no one else run in to this issue? We generally have 'filler' space defined, but sometimes even that gets used up and you still have to 'expand' the record length. From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of CM Poncelet <ad...@poncelet-adsl.demon.co.uk> Sent: Wednesday, January 11, 2017 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM: Why MAXLRECL? No problem provided you define 32K LSR pools (from memory, 3) in CICS and monitor their (E)DSA usage. But why define MAXLRECL=32760 at all? On 11/01/2017 22:53, Greg Dyck wrote: > On 1/11/2017 3:30 PM, Frank Swarbrick wrote: >> Is there a downside to always defining VSAM files with a MAXLRECL of >> 32761, which seems to be the largest value for this parm for an >> UNSPANNED dataset? > > I believe it will force your CI size to be 32K which is not something I > would want to do unless it was necessary. The CI size impacts the > amount of virtual storage that is allocated for buffers and the I/O > transfer times for each CI that must be read or written. > > Regards, > Greg > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM: Why MAXLRECL?
No problem provided you define 32K LSR pools (from memory, 3) in CICS and monitor their (E)DSA usage. But why define MAXLRECL=32760 at all? On 11/01/2017 22:53, Greg Dyck wrote: > On 1/11/2017 3:30 PM, Frank Swarbrick wrote: >> Is there a downside to always defining VSAM files with a MAXLRECL of >> 32761, which seems to be the largest value for this parm for an >> UNSPANNED dataset? > > I believe it will force your CI size to be 32K which is not something I > would want to do unless it was necessary. The CI size impacts the > amount of virtual storage that is allocated for buffers and the I/O > transfer times for each CI that must be read or written. > > Regards, > Greg > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM: Why MAXLRECL?
Haha, maybe so, but we generally use VSAM for "non-business" related type data. Configuration files, logs, and the like. It doesn't happen often enough that we'd want to use DB2 to solve the issue. It only happens enough to bug me when it does happen. :-) For example, in the particular case I'm looking at we have a log file that was defined with MAXLRECL of 500, but we are now implementing an enhancement to the messages being logged (specifically, EMV card support at our ATMs) where the messages are now almost always more than 500 bytes long. Since the logging is only for troubleshooting purposes I decided to simply live with truncation of the end of the messages. But had the MAXLRECL for this file already been 32761, or some similar fairly large number I simply would have changed the program that logs the messages to not truncate at 500 bytes. My point is, it seems to me that MAXLRECL is a fairly "artificial limit", unless there is a actually a good reason that you'd want a MAXLRECL that is at least close to the, well, maximum record length. Frank From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Lizette Koehler <stars...@mindspring.com> Sent: Wednesday, January 11, 2017 3:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM: Why MAXLRECL? Sounds like you need a DB2/IMS database rather than a VSAM database. However, does the record length change that much that this is a frequent process of expanding the records? IMO, I do not see a reason it would not work. How would that solve your issue? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Frank Swarbrick > Sent: Wednesday, January 11, 2017 2:31 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: VSAM: Why MAXLRECL? > > Is there a downside to always defining VSAM files with a MAXLRECL of 32761, > which seems to be the largest value for this parm for an UNSPANNED dataset? > > > I always hate having to do a backup/delete/define when adding new data to a > file. Especially for a file defined to a CICS region that is up pretty much > 24/7! > > > Frank > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM: Why MAXLRECL?
On 1/11/2017 3:30 PM, Frank Swarbrick wrote: Is there a downside to always defining VSAM files with a MAXLRECL of 32761, which seems to be the largest value for this parm for an UNSPANNED dataset? I believe it will force your CI size to be 32K which is not something I would want to do unless it was necessary. The CI size impacts the amount of virtual storage that is allocated for buffers and the I/O transfer times for each CI that must be read or written. Regards, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM: Why MAXLRECL?
Sounds like you need a DB2/IMS database rather than a VSAM database. However, does the record length change that much that this is a frequent process of expanding the records? IMO, I do not see a reason it would not work. How would that solve your issue? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Frank Swarbrick > Sent: Wednesday, January 11, 2017 2:31 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: VSAM: Why MAXLRECL? > > Is there a downside to always defining VSAM files with a MAXLRECL of 32761, > which seems to be the largest value for this parm for an UNSPANNED dataset? > > > I always hate having to do a backup/delete/define when adding new data to a > file. Especially for a file defined to a CICS region that is up pretty much > 24/7! > > > Frank > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
