This clearly shows why I get yelled at on IBMMAIN I did read the doc just not well enough
Thank you Charles > On Nov 20, 2020, at 11:38 AM, Seymour J Metz <[email protected]> wrote: > > 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 <[email protected]> on behalf of > Farley, Peter x23353 <[email protected]> > Sent: Friday, November 20, 2020 11:07 AM > To: [email protected] > 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 <[email protected]> On Behalf Of > Joseph Reichman > Sent: Friday, November 20, 2020 10:24 AM > To: [email protected] > 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 <[email protected]> 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:[email protected]] On >> Behalf Of Ray Pearce >> Sent: Friday, November 20, 2020 6:21 AM >> To: [email protected] >> 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:[email protected]] On >> Behalf Of Joseph Reichman >> Sent: 20 November 2020 14:16 >> To: [email protected] >> 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 [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
