Creating test data IRS uses VB have to test out the code. Thanks
> On Nov 20, 2020, at 11:50 AM, Joseph Reichman <[email protected]> wrote: > > 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
