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
