Re: QSAM VB update in place
W dniu 20.11.2020 o 18:01, Paul Gilmartin pisze: On Fri, 20 Nov 2020 16:47:58 +, Seymour J Metz wrote: However what If I would like to make the record size larger I might get a s0c4 possibly QSAM doesn't allow changing the record length and BSAM doesn't allow changing the block size What about RECFM=VBS, initially padding each block with a null segment, allowing limited insertion, expansion, and deletion? Can a VBS block consist entirely of a null segment? "Aint no rule saying a dog can't play basketball!" OK, who's using VBS? Of course except IFASMFDP. I don't say it is impossible, I say it is rarely used. As others have written, this is a use case for VSAM. ? Isn't that cheating? ESDS? KSDS? RRDS? ...? No, it isn't. VRRDS is the choice for such scenario. Of course Db2 table is better. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: QSAM VB update in place
Using BSAM , VBS and null segements might allow you to shorten records in some cases, but expanding records would still be a problem. Which VSAM organization to use would depend on wheth3er you also need to insert or delete records. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Friday, November 20, 2020 12:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: QSAM VB update in place On Fri, 20 Nov 2020 16:47:58 +, Seymour J Metz wrote: >> However what If I would like to make the record size larger I might get a >> s0c4 possibly >QSAM doesn't allow changing the record length and BSAM doesn't allow changing >the block size > What about RECFM=VBS, initially padding each block with a null segment, allowing limited insertion, expansion, and deletion? Can a VBS block consist entirely of a null segment? "Aint no rule saying a dog can't play basketball!" >As others have written, this is a use case for VSAM. ? Isn't that cheating? ESDS? KSDS? RRDS? ...? -- gil -- 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: QSAM VB update in place
Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman Sent: Friday, November 20, 2020 8:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: QSAM VB update in place This clearly shows why I get yelled at on IBMMAIN I did read the doc just not well enough -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: QSAM VB update in place
On Fri, 20 Nov 2020 16:47:58 +, Seymour J Metz wrote: >> However what If I would like to make the record size larger I might get a >> s0c4 possibly >QSAM doesn't allow changing the record length and BSAM doesn't allow changing >the block size > What about RECFM=VBS, initially padding each block with a null segment, allowing limited insertion, expansion, and deletion? Can a VBS block consist entirely of a null segment? "Aint no rule saying a dog can't play basketball!" >As others have written, this is a use case for VSAM. ? Isn't that cheating? ESDS? KSDS? RRDS? ...? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: QSAM VB update in place
Creating test data IRS uses VB have to test out the code. Thanks > On Nov 20, 2020, at 11:50 AM, Joseph Reichman 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 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 on behalf of >> Farley, Peter x23353 <031df298a9da-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 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 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 buff
Re: QSAM VB update in place
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 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 on behalf of > Farley, Peter x23353 <031df298a9da-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 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 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 e
Re: QSAM VB update in place
> However what If I would like to make the record size larger I might get a > s0c4 possibly QSAM doesn't allow changing the record length and BSAM doesn't allow changing the block size. As others have written, this is a use case for VSAM. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Friday, November 20, 2020 9:16 AM 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 -- 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: QSAM VB update in place
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 on behalf of Farley, Peter x23353 <031df298a9da-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 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 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
Re: QSAM VB update in place
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idad400/d4396.htm Sez When you update a data set in place ... - You cannot delete any record or change its length. - You cannot add new records. Seems mighty clear to me. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: QSAM VB update in place
I’m creating test data for filling season 2021 We USE VB records at the IRS Thank you > On Nov 20, 2020, at 11:08 AM, Farley, Peter x23353 > <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > > 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 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 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
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 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 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
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 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > This e-mail message has been scanned and cleared by Google Message Security > and the UNICOM Global security systems. This message is for the named > person's use only. If you receive this message in error, please delete it > and notify the sender. > > -- > 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: QSAM VB update in place
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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- 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: QSAM VB update in place
The doc says you can but you have to use locate mode I’ll look again > On Nov 20, 2020, at 9:21 AM, Ray Pearce wrote: > > 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > This e-mail message has been scanned and cleared by Google Message Security > and the UNICOM Global security systems. This message is for the named > person's use only. If you receive this message in error, please delete it > and notify the sender. > > -- > 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: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
