You may be able to use BSAM to update a VB record in place, but you can't change the block size. Even if you use EXCP you would have the same problem. Why not use VSAM?
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <0000031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Friday, November 20, 2020 11:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: QSAM VB update in place Assuming the xSAM I/O routines provide a BLKSIZE-sized buffer, ISTM you could use BSAM to read blocks, deblock records yourself, and then if you want/need to change a record's length you can move the remaining records (after all you have the byte position and length of the "current" record in the block because you are deblocking it yourself) up or down the block area. Obviously checking is needed to prevent a record length increase from overflowing the block-sized buffer area. But that sort of RYO SAM record processing seems baroque to say the least. The application recovery issues if you do have a buffer overflow case would seem to be more trouble than the capability is worth. I tend to agree that use of VSAM for such an application requirement would be a better choice, if one is forced to use the "update in place" paradigm. Or even simpler, don't use "update in place" at all, but instead copy input to output changing the output record size as the application requires. KISS. Uses more disk space but far easier to code and maintain. Take a step back and look at the application requirement from an architectural level - do you *really* need "update in place"? Or are you trying to shoehorn a new facility or capability into an existing application design that doesn't easily support the new thing? If the latter, application design should change to meet the new requirement. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Joseph Reichman Sent: Friday, November 20, 2020 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: QSAM VB update in place Just looking at build and get pool it would seem you supply the buffer address AND you are still in LOCATE mode which seems to be the requirement for update in place It seems issuing the get pool When you issue get pool the buffer address Is placed in BUFCB of the dcb and the get or put will use that address Seems with getpool you supply the length so if your record size expands you give the size in getpool Now I haven’t tried this but this is the way I understand the doc > On Nov 20, 2020, at 10:06 AM, Charles Mills <charl...@mcn.org> wrote: > > How might that possibly work???? > > What would QSAM do? Slide all the following records forward??? > > This is why they invented VSAM. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ray Pearce > Sent: Friday, November 20, 2020 6:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: QSAM VB update in place > > Are you being serious Joe? > How on earth do you think you can change the size of a record *in place* > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joseph Reichman > Sent: 20 November 2020 14:16 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: QSAM VB update in place > > Hi > > I am trying to update a VB record in place The documentation says for this I > have to use locate mode meaning z/os supplies me the buffer address So I’m > assuming if I update in place I have to use z/os or DFSMS buffer address > > However what If I would like to make the record size larger I might get a > s0c4 possibly -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- 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
