Re: DFSORT and zIIP
Different products mean different technical considerations and optimizations. It's just that simple. For DB2 Sort for z/OS, zIIP exploitation makes technical sense. For DFSORT -- except for exploiting zIIPs on behalf of DB2 utilities and in other ancillary ways -- it doesn't seem to make technical sense. Maybe in the future, as the technologies change and evolve, it will. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFsort and zIIP
Overloading zIIPs consists of 2 phases. 1. work is getting queued for the zIIP, delaying the work. 2. when queuing is getting to large, the CPs are asked to assist in processing zIIP work (if allowed by IEAOPT parameters) The first phase is not reported externally. The second phase is visible, because this CPU is reported as zIIP-eligible CPU. This CPU will also be charged as license CP MSUs. So when you have zIIP-elibible CPU, you know you have problems of the second category and you already had the problems of the first category before. Some DB2 problems due to zIIP work queuing were resolved by disabling the zIIP, at the cost of CP MSUs of course. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 19 July, 2016 19:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: DFsort and zIIP >You are correct that the ZIIP dispatcher is not as sophisticated as the >regular dispatcher. I dare to contradict, not intending to question you expertise. It is my understanding that there is only one dispatcher in MVS. It handles work on the CP WUQ as well as work on the zIIP WUQ. The reason for the wait time mechanism is explained in Init&Tuning Ref, IEAOPTxx. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FAMS?
On Tue, 19 Jul 2016 15:37:03 -0400, Steve Smith wrote: >The first rule of FAMS is you don't talk about FAMS. :-) > >I don't think that denying its existence is part of the contract, but I >can't say anything else about it. > Hmmm... If I IEBCOPY a PDSE to another PDSE, ISPF member list shows that the timestamps from SYSUT1 are replicated in SYSUT2. I believe this is quite deliberate. However, NFS shows for SYSUT2 the timestamps as the time of the IEBCOPY job step, neither the timestamps shown for SYSUT1 nor the timestamps shown by ISPF. This seems wrong. Is it APARable? (If I submit an SR I'll not talk about FAMS. It seems prudent to be disingenuous here.) Perhaps an RCF? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records... RDW corruption
2 threads going here. IBM is investigating. IBM has a dump of the bad block. Length is 31373. BDW good in the buffer. Bad when written. Ongoing. Jay Campbell IBM OS Support Section -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of retired mainframer Sent: Tuesday, July 19, 2016 7:44 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Reichman Joseph > Sent: Tuesday, July 19, 2016 11:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Bsam VS Qsam for VB records > > Thanks for all your help I really understand the problem thing is the > file is huge and I don’t know by what factor DFSMS blocked and if the > blocking is consistent meaning always by the same factor Since you already posted that you have no data class active and a null SMS configuration, it is unlikely that DFSMS has any effect on block size. If the data was written with QSAM, then QSAM performed the blocking (per the DCB parameters specified on the DD statement used to identify the output dataset) as well as constructing the RDWs and BDW. You also posted that the problem was with the BDW and not the RDWs. What do you think the problem is? How did you determine that? Can you post the first 8 bytes of the block in question (BDW+RDW, no proprietary data)? -- 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: Bsam VS Qsam for VB records
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Reichman Joseph > Sent: Tuesday, July 19, 2016 11:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Bsam VS Qsam for VB records > > Thanks for all your help I really understand the problem thing is the file is > huge and I don’t > know by what factor DFSMS blocked and if the blocking is consistent meaning > always by > the same factor Since you already posted that you have no data class active and a null SMS configuration, it is unlikely that DFSMS has any effect on block size. If the data was written with QSAM, then QSAM performed the blocking (per the DCB parameters specified on the DD statement used to identify the output dataset) as well as constructing the RDWs and BDW. You also posted that the problem was with the BDW and not the RDWs. What do you think the problem is? How did you determine that? Can you post the first 8 bytes of the block in question (BDW+RDW, no proprietary data)? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
Easy to do by accident: - a valid VB dataset - open and write DISP=MOD,RECFM=FB (erroneous JCL or program with hard-coded DCB) - open and read with explicit RECFM=VB in JCL or program - crash and burn Easy enough to do when hastily cobbling JCL together from different sources. You typically end up with EBCDIC characters where the RDW is supposed to be. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Woodger Sent: Tuesday, July 19, 2016 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Bsam VS Qsam for VB records I previously acknowledged that the data looks OK. No, it is not an attempt to "extend" a block. It is to write a lump of data which, once the "correction" has been done (else the data can't be read as a VB anyway) will appear to be a VB "block", but which will start with binary zeros. Someone had commented that they didn't know how a BDW with zero length could be created. It wasn't done in this case, but here's a way it could be done. Not by *really* writing a block with a zero BDW, but sticking in a lump of data which will later *look like* a block (very superficially) but will presumably cause something weird to ensue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Bsam VS Qsam for VB records
I previously acknowledged that the data looks OK. No, it is not an attempt to "extend" a block. It is to write a lump of data which, once the "correction" has been done (else the data can't be read as a VB anyway) will appear to be a VB "block", but which will start with binary zeros. Someone had commented that they didn't know how a BDW with zero length could be created. It wasn't done in this case, but here's a way it could be done. Not by *really* writing a block with a zero BDW, but sticking in a lump of data which will later *look like* a block (very superficially) but will presumably cause something weird to ensue. Requires deliberation, or accidental use of wrong LRECL/RECFM (other than expected) with DISP=MOD and then the "fix" (correctl LRECL/RECFM) with DISP=MOD and add at least one more record). A variation of the "corrupt a loadlib by writing a source to it". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
On Tue, 19 Jul 2016 16:14:20 -0500, Bill Woodger wrote: >DISP=MOD does lead to a way to accidentally (or deliberately, as an exercise) >create a "zero" BDW. With RECFM=F/FB/U and some LRECL, specified on the DD, >write a lump of data with two bytes of binary zeros. Then with DISP=MOD again, >and the "normal" RECFM/LRECL, write a good record. Then try to read the data. > I don't believe DISP=MOD will ever extend an existing block if that's what you were expecting; it will always start a new block. Tricky to do accidentally, but sometimes you find someone who errs, and then tries to "correct" without realising the full consequences. > That sort of thing should always be done with a copy of the data. But I believe the OP has explained that a dump of the disk file showed that BDW was valid but corrupted on input by ?SAM. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Bsam VS Qsam for VB records
DISP=MOD does lead to a way to accidentally (or deliberately, as an exercise) create a "zero" BDW. With RECFM=F/FB/U and some LRECL, specified on the DD, write a lump of data with two bytes of binary zeros. Then with DISP=MOD again, and the "normal" RECFM/LRECL, write a good record. Then try to read the data. Tricky to do accidentally, but sometimes you find someone who errs, and then tries to "correct" without realising the full consequences. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
Or perhaps not, given IBM's reply. And given that IBM is working on it, I would move on to other things and let IBM work on it. The answer is still not BSAM programming or zapping. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, July 19, 2016 12:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records IMHO the problem here is probably one of misunderstanding or misapplication (Dr. Merrill's pointing out of a JCL oddity, for example) and any zapping or BSAM programming is likely to turn it into a real problem of corrupted data on disk. The questions should be "how do we correct our error and read the data?" and not "how do we zap the data to make it fit our model of correct?" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FAMS?
The first rule of FAMS is you don't talk about FAMS. :-) I don't think that denying its existence is part of the contract, but I can't say anything else about it. sas On Tue, Jul 19, 2016 at 12:05 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 18 Jul 2016 23:05:44 -0400, Steve Smith wrote: > > >FAMS is a secret interface. IBM may or may not provide the > >documentation upon receipt of a signed NDA, and presumably, a "nominal" > fee. > > > I'm aghast! You mean IBM has (finally) started keeping timestamps on > (some) files but to see them a customer must sign an NDS and pay for > the privilege (or use NFS)? What century does IBM think this is, anyway!? > > Are you allowed even to tell me it's secret? I suppose that explains the > conspicuous silence here of IBM employees. I wonder whether the > meager information will be removed from future editions of the NFS > description. And from the APARs. > > > On Tue, 19 Jul 2016 07:39:00 -0400, Ken Smith wrote: > > >You probably knew this but if you can run under ISPF, batch or > interactive, > >use LMMSTATS. > > > I believe not. As an experiment, I created a couple PDS members with > IEBGENER, no ISPF involved. NFS shows timestamps consistent with > those in the job log and differing by 0.1995 seconds which I assume is > job step overhead. ISPF member list shows no stats whatever for those > members. Would LMMSTATS in a program show me any different? > If you believe so, I'll try an experiment, but I'm skeptical. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
IMHO the problem here is probably one of misunderstanding or misapplication (Dr. Merrill's pointing out of a JCL oddity, for example) and any zapping or BSAM programming is likely to turn it into a real problem of corrupted data on disk. The questions should be "how do we correct our error and read the data?" and not "how do we zap the data to make it fit our model of correct?" Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Blaicher, Christopher Y. Sent: Tuesday, July 19, 2016 12:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records The I/O ERROR message should have a CCHHR associated with it. Using the CCHHR you can use AMASPZAP to dump that record or all the records on that track. You can then examine the record in question and determine if the BDW is correct, BDW should equal the block length reported by AMASPZAP, or if an RDW is incorrect. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
On Tue, 19 Jul 2016 18:47:50 +, Reichman Joseph wrote: >Thanks for all your help I really understand the problem thing is the file is >huge and I don't know by what factor DFSMS blocked and if the blocking is >consistent meaning always by the same factor "Blocking factor" has little meaning for a VB file. The blocksize need not be a multiple of lrecl, and in most VB data sets the records are of varying lengths. As a consequence, the size of the blocks will usually be of varying lengths. If the data set was created with one block size and was subsequently written to (MOD) by a program that specified a different blocksize, the DSCB would have been updated to reflect the more recent blocksize, which may not be enough to read existing blocks on the data set. This is largely guesswork and supposition, based upon minimal information provided. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RDW corruption
IBM has a dump of the bad block. Length is 31373. BDW good in the buffer. Bad when written. Ongoing. Jay Campbell IBM OS Support Section -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Barry Merrill Sent: Tuesday, July 19, 2016 3:12 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: RDW corruption Our output is VB LRECL=31996 BLKSIZE=32000. > Using BUFL=32600 fixes our problem. It looks like your error is too small a BLKSIZE. The maximum BLKSIZE for VB or VBS is 32760, NOT your 32000. If BUFL=32600 then your use of BLKSIZE=32000 is short of the mark. To read ANY VB file, use RECFM=VB,LRECL=32756,BLKSIZE=32760. Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman Sent: Monday, July 18, 2016 2:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RDW corruption I know my boss assigned me this problem As an aside if I register my IRS e-mail on IBM-Main is there a way not get every e-mail I don't mind it in my personel e-mail But I have a lot of other stuff on my irs.gov e-mail > On Jul 18, 2016, at 3:21 PM, Campbell Jay wrote: > > Have a current SR open with IBM... 57827 082 000 > Our output is VB LRECL=31996 BLKSIZE=32000. > Using BUFL=32600 fixes our problem. > SR was opened to find out why that works. > > Jay Campbell > IBM OS Support Section > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] > On Behalf Of Joe Reichman > Sent: Monday, July 18, 2016 3:17 PM > To: IBM-MAIN@listserv.ua.edu > Subject: RDW corruption > > Hi, > > > > I have a program that generates a corrupted RDW The file is a VB file. > I coded a synad exit but it didn't take (it was never given control) > > > > When I go into ISPF and I do a max down I can see where ISPF can't > read the next record as I get "* * * I/O error detected, i/o terminated * * *" > > > > As there anything/exit I can do to capture this the program seems to go to > EOJ > > > -- > 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 -- 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: VTOC Listing utility with PDSE V2 Maxgen Info?
Catalog Recovery+ from Rocket Software will show this information with its EXPLORE command. It is a recently added feature. EXPLORE gathers dataset information from catalogs, VVDS, VTOC, and for PDS/PDSE, from the dataset itself, and compiles it all into a comprehensive extract file that can be reported on in many ways. Disclaimer: I work for Rocket, and as a matter of fact, wrote the PDSE support. I'm biased, but I say it's pretty good :-). That said, I agree that the lack of PDSE information in catalogs and VTOCs is unfortunate, as is the secrecy about the internal organization. sas On Tue, Jul 19, 2016 at 11:49 AM, Tom Conley wrote: > On 7/19/2016 11:35 AM, Dyck, Lionel B. , TRA wrote: > >> Is there a utility available out there that will generate a vtoc listing >> that includes pdse version info and also maxgen info ? >> >> Thanks >> >> -- >> Lionel B. Dyck (TRA Contractor) >> Mainframe Systems Programmer >> Enterprise Infrastructure Support (Station 200) (005OP6.3.10) >> VA OI&T Service Delivery & Engineering >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> > Nope, it ain't in the VTOC. The PDSE version and maxgen info is embedded > in the dataset, so you have to open it to determine the version. My > requirement to externalize the version indicator to the VTOC or catalog was > DOA. > > Regards, > Tom Conley > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RDW corruption
Our output is VB LRECL=31996 BLKSIZE=32000. > Using BUFL=32600 fixes our problem. It looks like your error is too small a BLKSIZE. The maximum BLKSIZE for VB or VBS is 32760, NOT your 32000. If BUFL=32600 then your use of BLKSIZE=32000 is short of the mark. To read ANY VB file, use RECFM=VB,LRECL=32756,BLKSIZE=32760. Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman Sent: Monday, July 18, 2016 2:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RDW corruption I know my boss assigned me this problem As an aside if I register my IRS e-mail on IBM-Main is there a way not get every e-mail I don't mind it in my personel e-mail But I have a lot of other stuff on my irs.gov e-mail > On Jul 18, 2016, at 3:21 PM, Campbell Jay wrote: > > Have a current SR open with IBM... 57827 082 000 > Our output is VB LRECL=31996 BLKSIZE=32000. > Using BUFL=32600 fixes our problem. > SR was opened to find out why that works. > > Jay Campbell > IBM OS Support Section > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] > On Behalf Of Joe Reichman > Sent: Monday, July 18, 2016 3:17 PM > To: IBM-MAIN@listserv.ua.edu > Subject: RDW corruption > > Hi, > > > > I have a program that generates a corrupted RDW The file is a VB file. > I coded a synad exit but it didn't take (it was never given control) > > > > When I go into ISPF and I do a max down I can see where ISPF can't read the next record as I get "* * * I/O error detected, i/o terminated * * *" > > > > As there anything/exit I can do to capture this the program seems to go to > EOJ > > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
The I/O ERROR message should have a CCHHR associated with it. Using the CCHHR you can use AMASPZAP to dump that record or all the records on that track. You can then examine the record in question and determine if the BDW is correct, BDW should equal the block length reported by AMASPZAP, or if an RDW is incorrect. The bigger question is what software created the file? You are stuck trying to read it, but what created it badly? Chris Blaicher Technical Architect Mainframe Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com www.syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: Tuesday, July 19, 2016 2:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records Thanks for all your help I really understand the problem thing is the file is huge and I don’t know by what factor DFSMS blocked and if the blocking is consistent meaning always by the same factor Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of John McKown Sent: Tuesday, July 19, 2016 2:25 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records On Tue, Jul 19, 2016 at 1:20 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > I've been following the various attempts to help you fix your broken > file with a block that has a zero BDW. How that ever happened is a > mystery you really ought to engage IBM to help solve, BUT . . . > > No one else seems to have suggested the "old time" solution to > recovering the file data - does your shop license DITTO? DITTO can > access AND MODIFY disk blocks directly, without programming. You can > display blocks in the file until you get to the one you want and then > update the BDW in that block based on the block length DITTO tells you it > read. > > If your shop does license DITTO the "disk modify" function is very > likely security protected (or darn well ought to be, since it can > really wreck things up if misused or abused), so you may need to > interface with your security team to get appropriate authority. > > There is a "batch" interface to DITTO as well as TSO capability, so > you could set it up as a batch job or try to accomplish it on the fly > from TSO. If it were me I would also try to make sure I have at least > one safe volume backup of the disk containing that file in case things > get messed up. Caveat emptor. > > HTH > > Peter > AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would be easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on disk. AMASPZAP can also print the data, in HEX. -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- 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 ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
Thanks for all your help I really understand the problem thing is the file is huge and I don’t know by what factor DFSMS blocked and if the blocking is consistent meaning always by the same factor Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of John McKown Sent: Tuesday, July 19, 2016 2:25 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records On Tue, Jul 19, 2016 at 1:20 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > I've been following the various attempts to help you fix your broken > file with a block that has a zero BDW. How that ever happened is a > mystery you really ought to engage IBM to help solve, BUT . . . > > No one else seems to have suggested the "old time" solution to > recovering the file data - does your shop license DITTO? DITTO can > access AND MODIFY disk blocks directly, without programming. You can > display blocks in the file until you get to the one you want and then > update the BDW in that block based on the block length DITTO tells you it > read. > > If your shop does license DITTO the "disk modify" function is very > likely security protected (or darn well ought to be, since it can > really wreck things up if misused or abused), so you may need to > interface with your security team to get appropriate authority. > > There is a "batch" interface to DITTO as well as TSO capability, so > you could set it up as a batch job or try to accomplish it on the fly > from TSO. If it were me I would also try to make sure I have at least > one safe volume backup of the disk containing that file in case things > get messed up. Caveat emptor. > > HTH > > Peter > AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would be easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on disk. AMASPZAP can also print the data, in HEX. -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- 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: Bsam VS Qsam for VB records
On Tue, 19 Jul 2016 13:24:37 -0500, John McKown wrote: >AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would >be easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on >disk. AMASPZAP can also print the data, in HEX. I'm baffled by the notion that the BDWs on disk are wrong, and can be corrected. Didn't Joe say that all I/O to the file has been using QSAM? If that is true, the BDW is the length of the block and to change it will likely cause errors. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
On Tue, 19 Jul 2016 13:24:37 -0500, John McKown wrote: > >AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would >be easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on >disk. AMASPZAP can also print the data, in HEX. > Rexx now deals with RECFM=U, at least as of 2.2. Don't know about 2.1. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Bsam VS Qsam for VB records
If you have confirmed it is on the disk (I assume you mean the BDW and RDW look OK) then it is being clobbered in code. If something is not correct immediately after doing a correct read (so assumption you have coded that correctly) then it is something for IBM. More likely is a program error after the read and before you notice it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
On Tue, Jul 19, 2016 at 1:20 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > I've been following the various attempts to help you fix your broken file > with a block that has a zero BDW. How that ever happened is a mystery you > really ought to engage IBM to help solve, BUT . . . > > No one else seems to have suggested the "old time" solution to recovering > the file data - does your shop license DITTO? DITTO can access AND MODIFY > disk blocks directly, without programming. You can display blocks in the > file until you get to the one you want and then update the BDW in that > block based on the block length DITTO tells you it read. > > If your shop does license DITTO the "disk modify" function is very likely > security protected (or darn well ought to be, since it can really wreck > things up if misused or abused), so you may need to interface with your > security team to get appropriate authority. > > There is a "batch" interface to DITTO as well as TSO capability, so you > could set it up as a batch job or try to accomplish it on the fly from > TSO. If it were me I would also try to make sure I have at least one safe > volume backup of the disk containing that file in case things get messed > up. Caveat emptor. > > HTH > > Peter > AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would be easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on disk. AMASPZAP can also print the data, in HEX. -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
I am in the process of running with RECFM=U (under TEST) I see that is shows both BDW and RDW Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Farley, Peter x23353 Sent: Tuesday, July 19, 2016 2:20 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records I've been following the various attempts to help you fix your broken file with a block that has a zero BDW. How that ever happened is a mystery you really ought to engage IBM to help solve, BUT . . . No one else seems to have suggested the "old time" solution to recovering the file data - does your shop license DITTO? DITTO can access AND MODIFY disk blocks directly, without programming. You can display blocks in the file until you get to the one you want and then update the BDW in that block based on the block length DITTO tells you it read. If your shop does license DITTO the "disk modify" function is very likely security protected (or darn well ought to be, since it can really wreck things up if misused or abused), so you may need to interface with your security team to get appropriate authority. There is a "batch" interface to DITTO as well as TSO capability, so you could set it up as a batch job or try to accomplish it on the fly from TSO. If it were me I would also try to make sure I have at least one safe volume backup of the disk containing that file in case things get messed up. Caveat emptor. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: Tuesday, July 19, 2016 1:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS code it doesn't seem RECFM=U would reveal that Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Bill Woodger Sent: Tuesday, July 19, 2016 1:13 PM To: IBM-MAIN@listserv.ua.edu Subject: Bsam VS Qsam for VB records With RECFM=U, you get the entire physical record presented to you. It has no "length" as far as the system is concerned, it is just an amorphous lump of data. For VB-as-U the first four bytes are the RDW of what was the block, the next four bytes the RDW of the first record, and you can find the start of the next record (next RDW) though some simple maths (adding). On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph wrote: > With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? > > Joe Reichman -- 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 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: Bsam VS Qsam for VB records
I've been following the various attempts to help you fix your broken file with a block that has a zero BDW. How that ever happened is a mystery you really ought to engage IBM to help solve, BUT . . . No one else seems to have suggested the "old time" solution to recovering the file data - does your shop license DITTO? DITTO can access AND MODIFY disk blocks directly, without programming. You can display blocks in the file until you get to the one you want and then update the BDW in that block based on the block length DITTO tells you it read. If your shop does license DITTO the "disk modify" function is very likely security protected (or darn well ought to be, since it can really wreck things up if misused or abused), so you may need to interface with your security team to get appropriate authority. There is a "batch" interface to DITTO as well as TSO capability, so you could set it up as a batch job or try to accomplish it on the fly from TSO. If it were me I would also try to make sure I have at least one safe volume backup of the disk containing that file in case things get messed up. Caveat emptor. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: Tuesday, July 19, 2016 1:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS code it doesn't seem RECFM=U would reveal that Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Bill Woodger Sent: Tuesday, July 19, 2016 1:13 PM To: IBM-MAIN@listserv.ua.edu Subject: Bsam VS Qsam for VB records With RECFM=U, you get the entire physical record presented to you. It has no "length" as far as the system is concerned, it is just an amorphous lump of data. For VB-as-U the first four bytes are the RDW of what was the block, the next four bytes the RDW of the first record, and you can find the start of the next record (next RDW) though some simple maths (adding). On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph wrote: > With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? > > Joe Reichman -- 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 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: Bsam VS Qsam for VB records
If you do not understand these things then writing a program with BSAM and/or RECFM=[something clever other than how the dataset was actually written] is not the way to do things -- except perhaps utterly as a learning exercise, not directly justified by an actual business requirement. If you want to see what is actually on the disk there are utilities that will show you that. I would guess IDCAMS DUMP with RECFM=U would be a good start, although I do not recall that I have ever actually done that, so I might be missing something. People have also suggested CBT tools IIRC. Even if you want to write a BSAM program for your own education or amusement, I would start with an existing dump utility so you can see what you will read with BSAM. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, July 19, 2016 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records One more time: if it is on the disk then RECFM=U will "reveal" it. What you got on disk is what you will get with READ. The BDW is not inside QSAM. It is (or is not) on the disk. QSAM *interprets* it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: Tuesday, July 19, 2016 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS code it doesn't seem RECFM=U would reveal that -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: DFsort and zIIP
>You are correct that the ZIIP dispatcher is not as sophisticated as the >regular dispatcher. I dare to contradict, not intending to question you expertise. It is my understanding that there is only one dispatcher in MVS. It handles work on the CP WUQ as well as work on the zIIP WUQ. The reason for the wait time mechanism is explained in Init&Tuning Ref, IEAOPTxx. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
One more time: if it is on the disk then RECFM=U will "reveal" it. What you got on disk is what you will get with READ. The BDW is not inside QSAM. It is (or is not) on the disk. QSAM *interprets* it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: Tuesday, July 19, 2016 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS code it doesn't seem RECFM=U would reveal that -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Default space allocation
So normally these defaults are used if not specified - Or you do not have DFSMS controlling through Dataclas. You may need to look at using a TSO Transmit/Receive exit to control it better. Since RECEIVE KNOWS how the dataset looked, it will use those values and not ALLOCxx. The default value for SPACE is a primary size equal to the size of the incoming data and a secondary size of approximately 25 percent of the primary. So the original dataset probably was allocated with 45,000 tracks. And so RECEIVE honored the size. Unless you specify the difference on the RECEIVE command. The user can include RLSE on the Receive RELEASE specifies unused space to be released when the receive operation is complete. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ikjc500/ikj2l2_RECEIVE_command_prompt_parameters1.htm (watch the wrap) how are they doing the RECEIVE? Interactively or via Batch Jobs? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Styles, Andy (SD EP zPlatform) > Sent: Tuesday, July 19, 2016 8:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Default space allocation > > Sure - but these are the settings: > > SPACE PRIMARY(10) > SECONDARY(10) > DIRECTORY(0) > MEASURE(TRK) > PRIM_ORG(ALX) > NORLSE > UNIT NAME(SYSALLDA) > > So I'm reading that as equivalent to SPACE=(TRK,(10,10)) by default, very > different to the 45K tracks we saw yesterday. We have no EXITxx members. > > Andy Styles > z/Series Systems Programmer > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: 19 July 2016 16:12 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Default space allocation > > -- This email has reached the Bank via an external source -- > > > That means you are taking defaults. So the Init and Tuning Reference will > provide more info > > ALLOCxx (allocation system defaults) > Use the ALLOCxx member of SYS1.PARMLIB to define installation defaults for: > > Unit names (dynamic allocation, unit-affinity-ignored, and redirection > from TAPE) > Space attributes > TIOT size > Handling allocation requests > Catalog error policies. > > These installation defaults for handling allocation requests can be overridden > by installation exit routines specified in the EXITxx parmlib member. For > information about the allocation exit routines, see z/OS MVS Installation > Exits. After IPL, use the SETALLOC command to change any of the defaults > (except for 2DGT_EXPDT). > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Styles, Andy (SD EP zPlatform) > > Sent: Tuesday, July 19, 2016 8:07 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Default space allocation > > > > I have, and it wasn't apparent in there that it would have the effect > > we've seen. > > > > > > Andy Styles > > z/Series Systems Programmer > > > > > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Lizette Koehler > > Sent: 19 July 2016 15:49 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Default space allocation > > > > -- This email has reached the Bank via an external source -- > > > > > > Have you checked out the ALLOCxx member of SYS1.PARMLIB (Or your version)? > > > > Lizette > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Styles, Andy (SD EP > > > zPlatform) > > > Sent: Tuesday, July 19, 2016 7:34 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Default space allocation > > > > > > Hi All, > > > > > > We've had a minor issue a few times over the past year or so. On our > > > GDPS control systems, we have a null SMS configuration - all > > > datasets are allocated with UNIT=SYSALLDA (I think I'm explaining > > > this right), otherwise you get SPECIFY DEVICE OR CANCEL. > > > > > > The issue we seem to have hit is that people using XMIT/RECEIVE seem > > > to allocate enormous datasets - one yesterday was 45K tracks, 1% > > > used, which used up nearly all the free space on the volume, and > > > caused another job to fail as it was unable to get the space it needed. > > > > > > I vaguely remember reading somewhere about default space allocation > > > being something along the lines of "whatever space remains on the volume". > > > > > > Does this ring any bells with anyone, or am I just dreaming it? Can > > > these parameters be changed, and if so, where? I've been hunting but > > > can't track it down. > > > > > > Many thanks, > > > > > > -- > > > Andy Styles > > > z/Series Systems Programmer -- For IBM-MAIN subscribe / signoff /
Re: Bsam VS Qsam for VB records
The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS code it doesn't seem RECFM=U would reveal that Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Bill Woodger Sent: Tuesday, July 19, 2016 1:13 PM To: IBM-MAIN@listserv.ua.edu Subject: Bsam VS Qsam for VB records With RECFM=U, you get the entire physical record presented to you. It has no "length" as far as the system is concerned, it is just an amorphous lump of data. For VB-as-U the first four bytes are the RDW of what was the block, the next four bytes the RDW of the first record, and you can find the start of the next record (next RDW) though some simple maths (adding). On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph wrote: > With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? > > Joe Reichman -- 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
Bsam VS Qsam for VB records
With RECFM=U, you get the entire physical record presented to you. It has no "length" as far as the system is concerned, it is just an amorphous lump of data. For VB-as-U the first four bytes are the RDW of what was the block, the next four bytes the RDW of the first record, and you can find the start of the next record (next RDW) though some simple maths (adding). On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph wrote: > With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? > > Joe Reichman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FW: Bsam VS Qsam for VB records
The original post had as noted below, two slashes, but the ListServer rejected with: Your message is being returned to you unprocessed because it looks like a LISTSERV command, rather than material intended for distribution to the members of the IBM-MAIN list. Please note that LISTSERV commands must always be sent to the LISTSERV address. If it was indeed a command you were attempting to issue, then send it again to lists...@listserv.ua.edu for execution. Otherwise, please accept our apologies and try to rewrite the message with a slightly different wording - for instance, change the first word of the message, enclose it in quotation marks, insert a line of dashes at the beginning of your message, etc. THIS-IS-SLASH-SLASH EXEC SAS THIS-IS-SLASH-SLASH DATAFILE DD DSN=WHATEVER,DISP=SHR THIS-IS-SLASH-SLASH SYSIN DD * DATA _NULL_; INFILE DATAFILE RECFM=U BLKSIZE=32760; INPUT; LIST; IF _N_ GT 10 THEN STOP; will print a nice hex dump of each of the first 10 block. Barry Merrilly yours, Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive technical questions: supp...@mxg.com Dallas, TX 75229 http://www.mxg.comadmin questions: ad...@mxg.com tel: 214 351 1966 fax: 214 350 3694 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, July 19, 2016 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records On Tue, Jul 19, 2016 at 10:15 AM, Reichman Joseph wrote: > With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? > Technically speaking, with RECFM=U there is not a BDW. There is just a bunch of bytes with no access method imposed interpretation. You must determine the number of bytes actually read by taking the number of bytes you requested to be read (the BLKSIZE basically) and subtract the CCW residual count to determine the number of bytes actually read. Luckily, IBM supplies an example. ref: http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idad400/len99.htm > > Joe Reichman > Joe Reichman > > IT Specialist > Master Files Division > New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex > M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 > Cell (917) 748-9693 > TOD M - F 7:30 am - 4:00 pm > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] > On Behalf Of John McKown > Sent: Tuesday, July 19, 2016 10:57 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: Bsam VS Qsam for VB records > > On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G < > curtis@austin.utexas.edu > > wrote: > > > On Jul 19, 2016, at 9:39 AM, Reichman Joseph > > > > wrote: > > > > > > I am not thinking of moving this in production it may help me > > > track down > > a problem > > > > If your motivation is to examine the physical blocks, why not read > > with QSAM specifying RECFM=U? > > > > That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then > use QSAM and "have fun". Or not, as the case may be. > > > > > > > -- > > Pew, Curtis G > > curtis@austin.utexas.edu > > ITS Systems/Core/Administrative Services > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > > > > -- > "Worry was nothing more than paying interest on a loan that a man may > never borrow" > > From: "Quest for the White Wind" by Alan Black > > Maranatha! <>< > John McKown > > -- > 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 > -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- 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: DFsort and zIIP
You are correct that the ZIIP dispatcher is not as sophisticated as the regular dispatcher. If a ZIIP request is made and no ZIIP engine is available the dispatcher will wait a period of time, see ZIIPAWMT parameter in IEAOPTxx, which if none is available by the end of that time, it will dispatch it on a GP engine rather than a ZIIP engine. This creates ZIIP_ON_CP time in your SMF data. Because of this wait time, especially if it is large, you can elongate the elapsed time of whatever is running trying to use the ZIIP engines. By default that time is 3.2ms. The trick is to know when you are getting held up too much by ZIIP dispatch and skip trying to use it. I cannot remember right now the ROT for ZIIP percent active, but you cannot redline a ZIIP engine the way you can a GP engine. Chris Blaicher Technical Architect Mainframe Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com www.syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, July 19, 2016 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFsort and zIIP There is one potential zIIP performance problem that we learned about as we moved to DB2 V10, which enabled more zIIP processing than was available in V9. The scenario went something like this. zIIP dispatching was not as sophisticated as GP dispatching. If available zIIPs got overloaded, DB2 performance could be severely impacted by a thrashing condition. We actually added another zIIP engine in advance of the V10 cutover. I have no idea what might have happened otherwise. Was a bullet really dodged or merely imagined? I don't believe that this issue had anything specifically to do with SORT. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Tuesday, July 19, 2016 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DFsort and zIIP The largest benefit is a financial one: you don't pay the zIIP MSUs. A performance benefit can come from the fact that the zIIP is always running at full speed, while your CP's can run at lower speeds. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: 19 July, 2016 16:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFsort and zIIP On Tue, 19 Jul 2016 08:26:45 +0200, Peter Hunkeler wrote: >>DFSORT can use zIIP on behalf of DB2 utilities, but not otherwise. >>Here's more information: > > >>At this time, IBM has no plan for enabling DFSORT to exploit the >>system z9 Integrated Information Processor (zIIP). IBM realizes >>DFSORT remains a prominent component of our customers' batch >>workloads. However, the added controls that would need to be >>implemented in order to maintain our high standards for performance, >>reliability and system integrity are not justified in view of >>estimations that there is a low offload potential and the value to >>clients may be marginal.[snip] > >I seem to remember that SyncSort offers an Add-On package that allows >certain SyncSort processing to be offloaded to zIIPs. The above >statement suggest that SyncSort's perfocmance is suffering from using >zIIPs (simplified and exagerated, I know). I understood "there is a low offload potential and the value to clients may be marginal" as meaning that there would not be much benefit in using zIIP. Not that it would be worse. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -
Re: FLASHCOPY QUESTION
Rex, Thanks for the explanation. So as not to clutter the board I will take this offline. On Tue, 7/19/16, Pommier, Rex wrote: Subject: Re: FLASHCOPY QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Tuesday, July 19, 2016, 9:14 AM Esmie, Let me give it a try. I think you're getting confused due to terminology and different views of the copies. From a z/OS point of view, both the examples you show are doing full volume copies of data from your IN to your OUT. Once the job is done, you have 2 full copies of the data, one on each volume. The difference is what's going on in the back-end disk array. In example 1, you have FCNC which from the back-end array, the only thing that happens is that a set of pointers (a track table) gets built but no data gets copied. The only time data gets physically copied from source to target is when either the source or target data track is changed. If the source data gets changed, a copy of the track gets put on the target before the source is updated. In case of the target getting updated, the changed data is written to the target. If, for example, in this scenario you are doing this copy with the intent of doing a DUMP of the target to tape, most of the data for the DUMP is actually coming from the SOURCE, because unless the data changed, the SOURCE is the only place the physical data resides. In example 2, FCINCREMENTAL does NOT mean do an incremental backup. FC/DFDSS does a full background copy of all the data from the source to the target. It still looks like it ran really fast to z/OS because as soon as the track table is built on the array, the array signals to z/OS the backup is done. However, the back end is still copying all the data to the target. Why use FCINCR then? Under normal FC processing, if you don't use FCNC, the background copy is initiated, and then once all the data is copied to the target, the relationship between source and target is terminated, and the 2 volumes are now stand-alone. If FCINCR is specified like in your example, the relationship remains in place with the track table now indicating which tracks have changed since the FC ran. If you then come along and run another COPY command with the same source and target, the array uses the track table and only updates the changed tracks, thus (potentially) significantly reducing the load on the array if there wasn't much change in the data. So in short, FCNC only copies changed tracks from the source to the target, but FCINCR forces a full back-end copy of all the data from source to target on initial setup. Note in the DFDSS manual is that FCNC and FCINCR are mutually exclusive. HTH, Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Tuesday, July 19, 2016 6:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: FLASHCOPY QUESTION Gentle Readers, I was wondering if any of you can clear up understating about FlashCopy. In the following example COPY INDYNAM(SYS012) OUTDYNAM(DCN00) CANCELERROR - PURGE ALLEXCP ALLDATA(*) OPT(4) ADMIN FCNOCOPY - DUMPCOND FR(REQ) DEBUG(FRMSG(DETAILED)) My understanding is that an Incremental copy is being performed because FCNOCPY is specified. My understanding of Incremental is that only the updated tracks are copied over to the target volume. Please correct me if I am wrong. Also, I have this example. Is this for a FULL FlashCopy of a volume? However, I am confused that the FCINCREMENTAL parm is specified which would indicate that this is an incremental copy COPY FULL INDYNAM(ZFSZ01) OUTDYNAM(ZWATP0) ALLE ALLD(*) - FASTREPLICATION(REQUIRED) FCINCREMENTAL DUMPCONDITIONING ADMIN PURGE Could someone clear up this for me? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu
Re: FAMS?
On Mon, 18 Jul 2016 23:05:44 -0400, Steve Smith wrote: >FAMS is a secret interface. IBM may or may not provide the >documentation upon receipt of a signed NDA, and presumably, a "nominal" fee. > I'm aghast! You mean IBM has (finally) started keeping timestamps on (some) files but to see them a customer must sign an NDS and pay for the privilege (or use NFS)? What century does IBM think this is, anyway!? Are you allowed even to tell me it's secret? I suppose that explains the conspicuous silence here of IBM employees. I wonder whether the meager information will be removed from future editions of the NFS description. And from the APARs. On Tue, 19 Jul 2016 07:39:00 -0400, Ken Smith wrote: >You probably knew this but if you can run under ISPF, batch or interactive, >use LMMSTATS. > I believe not. As an experiment, I created a couple PDS members with IEBGENER, no ISPF involved. NFS shows timestamps consistent with those in the job log and differing by 0.1995 seconds which I assume is job step overhead. ISPF member list shows no stats whatever for those members. Would LMMSTATS in a program show me any different? If you believe so, I'll try an experiment, but I'm skeptical. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Default space allocation
Sure - but these are the settings: SPACE PRIMARY(10) SECONDARY(10) DIRECTORY(0) MEASURE(TRK) PRIM_ORG(ALX) NORLSE UNIT NAME(SYSALLDA) So I'm reading that as equivalent to SPACE=(TRK,(10,10)) by default, very different to the 45K tracks we saw yesterday. We have no EXITxx members. Andy Styles z/Series Systems Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: 19 July 2016 16:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Default space allocation -- This email has reached the Bank via an external source -- That means you are taking defaults. So the Init and Tuning Reference will provide more info ALLOCxx (allocation system defaults) Use the ALLOCxx member of SYS1.PARMLIB to define installation defaults for: Unit names (dynamic allocation, unit-affinity-ignored, and redirection from TAPE) Space attributes TIOT size Handling allocation requests Catalog error policies. These installation defaults for handling allocation requests can be overridden by installation exit routines specified in the EXITxx parmlib member. For information about the allocation exit routines, see z/OS MVS Installation Exits. After IPL, use the SETALLOC command to change any of the defaults (except for 2DGT_EXPDT). Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Styles, Andy (SD EP zPlatform) > Sent: Tuesday, July 19, 2016 8:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Default space allocation > > I have, and it wasn't apparent in there that it would have the effect > we've seen. > > > Andy Styles > z/Series Systems Programmer > > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: 19 July 2016 15:49 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Default space allocation > > -- This email has reached the Bank via an external source -- > > > Have you checked out the ALLOCxx member of SYS1.PARMLIB (Or your version)? > > Lizette > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Styles, Andy (SD EP > > zPlatform) > > Sent: Tuesday, July 19, 2016 7:34 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Default space allocation > > > > Hi All, > > > > We've had a minor issue a few times over the past year or so. On our > > GDPS control systems, we have a null SMS configuration - all > > datasets are allocated with UNIT=SYSALLDA (I think I'm explaining > > this right), otherwise you get SPECIFY DEVICE OR CANCEL. > > > > The issue we seem to have hit is that people using XMIT/RECEIVE seem > > to allocate enormous datasets - one yesterday was 45K tracks, 1% > > used, which used up nearly all the free space on the volume, and > > caused another job to fail as it was unable to get the space it needed. > > > > I vaguely remember reading somewhere about default space allocation > > being something along the lines of "whatever space remains on the volume". > > > > Does this ring any bells with anyone, or am I just dreaming it? Can > > these parameters be changed, and if so, where? I've been hunting but > > can't track it down. > > > > Many thanks, > > > > -- > > Andy Styles > > z/Series Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. Telephone: 0345 603 1637 Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Cheltenham & Gloucester plc is authorised and regulated by the Financial Conduct Authority. Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings is a division of Lloyds Bank plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distri
Re: VTOC Listing utility with PDSE V2 Maxgen Info?
On 7/19/2016 11:35 AM, Dyck, Lionel B. , TRA wrote: Is there a utility available out there that will generate a vtoc listing that includes pdse version info and also maxgen info ? Thanks -- Lionel B. Dyck (TRA Contractor) Mainframe Systems Programmer Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service Delivery & Engineering -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Nope, it ain't in the VTOC. The PDSE version and maxgen info is embedded in the dataset, so you have to open it to determine the version. My requirement to externalize the version indicator to the VTOC or catalog was DOA. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFsort and zIIP
There is one potential zIIP performance problem that we learned about as we moved to DB2 V10, which enabled more zIIP processing than was available in V9. The scenario went something like this. zIIP dispatching was not as sophisticated as GP dispatching. If available zIIPs got overloaded, DB2 performance could be severely impacted by a thrashing condition. We actually added another zIIP engine in advance of the V10 cutover. I have no idea what might have happened otherwise. Was a bullet really dodged or merely imagined? I don't believe that this issue had anything specifically to do with SORT. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Tuesday, July 19, 2016 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DFsort and zIIP The largest benefit is a financial one: you don't pay the zIIP MSUs. A performance benefit can come from the fact that the zIIP is always running at full speed, while your CP's can run at lower speeds. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: 19 July, 2016 16:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFsort and zIIP On Tue, 19 Jul 2016 08:26:45 +0200, Peter Hunkeler wrote: >>DFSORT can use zIIP on behalf of DB2 utilities, but not otherwise. >>Here's more information: > > >>At this time, IBM has no plan for enabling DFSORT to exploit the >>system z9 Integrated Information Processor (zIIP). IBM realizes >>DFSORT remains a prominent component of our customers' batch >>workloads. However, the added controls that would need to be >>implemented in order to maintain our high standards for performance, >>reliability and system integrity are not justified in view of >>estimations that there is a low offload potential and the value to >>clients may be marginal.[snip] > >I seem to remember that SyncSort offers an Add-On package that allows >certain SyncSort processing to be offloaded to zIIPs. The above >statement suggest that SyncSort's perfocmance is suffering from using >zIIPs (simplified and exagerated, I know). I understood "there is a low offload potential and the value to clients may be marginal" as meaning that there would not be much benefit in using zIIP. Not that it would be worse. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
With RECFM=U what you see is what you get. You will receive whatever is on the disk in a physical block. (Let's skip what is really happening under the covers in modern DASD.) You will get whatever was written. If it is a well-formed block written by QSAM RECFM=VB, or written with BSAM or even EXCP by a competent programmer "emulating" well-formed RECFM=VB, then yes, you will get a BDW followed by one or more RDW+record, with BDW = sum of all RDWs plus 4. If something else was written you will get that. >From QSAM's point of view, yes RECFM=U is one record per block, or, depending >on which explanation you choose, no records and only blocks. Whether whoever wrote it viewed things differently is an unanswerable question. Whether they were that competent programmer is an unanswerable question. Whether you choose to view things differently is its own question. You might choose to "deblock" the data in any way you chose. You might write a "dump" program that dealt with the data one byte at a time, with no other structure. It is still hard for me to picture the question to which BSAM is the answer. In 1975, yes, I wrote a marvelous "database" system which used BSAM under the covers. In 2016 it's hard for me to picture. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: Tuesday, July 19, 2016 8:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VTOC Listing utility with PDSE V2 Maxgen Info?
Is there a utility available out there that will generate a vtoc listing that includes pdse version info and also maxgen info ? Thanks -- Lionel B. Dyck (TRA Contractor) Mainframe Systems Programmer Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service Delivery & Engineering -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
On Tue, Jul 19, 2016 at 10:15 AM, Reichman Joseph wrote: > With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? > Technically speaking, with RECFM=U there is not a BDW. There is just a bunch of bytes with no access method imposed interpretation. You must determine the number of bytes actually read by taking the number of bytes you requested to be read (the BLKSIZE basically) and subtract the CCW residual count to determine the number of bytes actually read. Luckily, IBM supplies an example. ref: http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idad400/len99.htm > > Joe Reichman > Joe Reichman > > IT Specialist > Master Files Division > New Carrollton Federal Building, B7-182 > OS:CTO:AD:CP:I:IB > Flex M,T,Th,F > Home office (240) 863 - 3965 > Office (240) 613-4350 > Cell (917) 748-9693 > TOD M - F 7:30 am - 4:00 pm > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On > Behalf Of John McKown > Sent: Tuesday, July 19, 2016 10:57 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: Bsam VS Qsam for VB records > > On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G < > curtis@austin.utexas.edu > > wrote: > > > On Jul 19, 2016, at 9:39 AM, Reichman Joseph > > wrote: > > > > > > I am not thinking of moving this in production it may help me track > > > down > > a problem > > > > If your motivation is to examine the physical blocks, why not read > > with QSAM specifying RECFM=U? > > > > That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use > QSAM and "have fun". Or not, as the case may be. > > > > > > > -- > > Pew, Curtis G > > curtis@austin.utexas.edu > > ITS Systems/Core/Administrative Services > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > "Worry was nothing more than paying interest on a loan that a man may > never borrow" > > From: "Quest for the White Wind" by Alan Black > > Maranatha! <>< > John McKown > > -- > 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 > -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
There is at least one TSO ZAP command on the CBT tape. It's very useful for examining DASD data. You don't actually need to alter any data; just look at it. The command is highly agnostic and will read pretty much any block. It won't tell you how an RDW got broken, but it can show the results in full-screen mode. It requires no programming. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: Tuesday, July 19, 2016 8:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Bsam VS Qsam for VB records With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of John McKown Sent: Tuesday, July 19, 2016 10:57 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G wrote: > On Jul 19, 2016, at 9:39 AM, Reichman Joseph > wrote: > > > > I am not thinking of moving this in production it may help me track > > down > a problem > > If your motivation is to examine the physical blocks, why not read > with QSAM specifying RECFM=U? > That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use QSAM and "have fun". Or not, as the case may be. > > -- > Pew, Curtis G > curtis@austin.utexas.edu > ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
Nothing. Data 1-LRECL, no RDW, no BDW. On Tue, Jul 19, 2016 at 10:15 AM, Reichman Joseph wrote: > With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? > > Joe Reichman > Joe Reichman > > IT Specialist > Master Files Division > New Carrollton Federal Building, B7-182 > OS:CTO:AD:CP:I:IB > Flex M,T,Th,F > Home office (240) 863 - 3965 > Office (240) 613-4350 > Cell (917) 748-9693 > TOD M - F 7:30 am - 4:00 pm > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On > Behalf Of John McKown > Sent: Tuesday, July 19, 2016 10:57 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: Bsam VS Qsam for VB records > > On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G > wrote: > >> On Jul 19, 2016, at 9:39 AM, Reichman Joseph >> wrote: >> > >> > I am not thinking of moving this in production it may help me track >> > down >> a problem >> >> If your motivation is to examine the physical blocks, why not read >> with QSAM specifying RECFM=U? >> > > That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use QSAM > and "have fun". Or not, as the case may be. > > > >> >> -- >> Pew, Curtis G >> curtis@austin.utexas.edu >> ITS Systems/Core/Administrative Services >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > > -- > "Worry was nothing more than paying interest on a loan that a man may never > borrow" > > From: "Quest for the White Wind" by Alan Black > > Maranatha! <>< > John McKown > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of John McKown Sent: Tuesday, July 19, 2016 10:57 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G wrote: > On Jul 19, 2016, at 9:39 AM, Reichman Joseph > wrote: > > > > I am not thinking of moving this in production it may help me track > > down > a problem > > If your motivation is to examine the physical blocks, why not read > with QSAM specifying RECFM=U? > That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use QSAM and "have fun". Or not, as the case may be. > > -- > Pew, Curtis G > curtis@austin.utexas.edu > ITS Systems/Core/Administrative Services > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- 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: Default space allocation
That means you are taking defaults. So the Init and Tuning Reference will provide more info ALLOCxx (allocation system defaults) Use the ALLOCxx member of SYS1.PARMLIB to define installation defaults for: Unit names (dynamic allocation, unit-affinity-ignored, and redirection from TAPE) Space attributes TIOT size Handling allocation requests Catalog error policies. These installation defaults for handling allocation requests can be overridden by installation exit routines specified in the EXITxx parmlib member. For information about the allocation exit routines, see z/OS MVS Installation Exits. After IPL, use the SETALLOC command to change any of the defaults (except for 2DGT_EXPDT). Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Styles, Andy (SD EP zPlatform) > Sent: Tuesday, July 19, 2016 8:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Default space allocation > > I have, and it wasn't apparent in there that it would have the effect we've > seen. > > > Andy Styles > z/Series Systems Programmer > > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: 19 July 2016 15:49 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Default space allocation > > -- This email has reached the Bank via an external source -- > > > Have you checked out the ALLOCxx member of SYS1.PARMLIB (Or your version)? > > Lizette > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Styles, Andy (SD EP zPlatform) > > Sent: Tuesday, July 19, 2016 7:34 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Default space allocation > > > > Hi All, > > > > We've had a minor issue a few times over the past year or so. On our > > GDPS control systems, we have a null SMS configuration - all datasets > > are allocated with UNIT=SYSALLDA (I think I'm explaining this right), > > otherwise you get SPECIFY DEVICE OR CANCEL. > > > > The issue we seem to have hit is that people using XMIT/RECEIVE seem > > to allocate enormous datasets - one yesterday was 45K tracks, 1% used, > > which used up nearly all the free space on the volume, and caused > > another job to fail as it was unable to get the space it needed. > > > > I vaguely remember reading somewhere about default space allocation > > being something along the lines of "whatever space remains on the volume". > > > > Does this ring any bells with anyone, or am I just dreaming it? Can > > these parameters be changed, and if so, where? I've been hunting but > > can't track it down. > > > > Many thanks, > > > > -- > > Andy Styles > > z/Series Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Default space allocation
I assume you meant ISMF; we don't have any data classes active on these systems. Andy Styles z/Series Systems Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: 19 July 2016 15:42 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Default space allocation -- This email has reached the Bank via an external source -- TSO ISPF I.4 DATACLAS column 8, 9, 10, 11(and 12 for PDS). On Tue, Jul 19, 2016 at 9:34 AM, Styles, Andy (SD EP zPlatform) <00d68f765d25-dmarc-requ...@listserv.ua.edu> wrote: > Hi All, > > We've had a minor issue a few times over the past year or so. On our GDPS > control systems, we have a null SMS configuration - all datasets are > allocated with UNIT=SYSALLDA (I think I'm explaining this right), otherwise > you get SPECIFY DEVICE OR CANCEL. > > The issue we seem to have hit is that people using XMIT/RECEIVE seem to > allocate enormous datasets - one yesterday was 45K tracks, 1% used, which > used up nearly all the free space on the volume, and caused another job to > fail as it was unable to get the space it needed. > > I vaguely remember reading somewhere about default space allocation being > something along the lines of "whatever space remains on the volume". > > Does this ring any bells with anyone, or am I just dreaming it? Can these > parameters be changed, and if so, where? I've been hunting but can't track it > down. > > Many thanks, > > -- > Andy Styles > z/Series Systems Programmer > > > Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 > 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. > Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V > 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. > Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. > Registered in Scotland no. SC327000. Telephone: 03457 801 801. > Cheltenham & Gloucester plc. Registered Office: Barnett Way, > Gloucester GL4 3RL. Registered in England and Wales 2299428. > Telephone: 0345 603 1637 > > Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential > Regulation Authority and regulated by the Financial Conduct Authority and > Prudential Regulation Authority. > > Cheltenham & Gloucester plc is authorised and regulated by the Financial > Conduct Authority. > > Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester > Savings is a division of Lloyds Bank plc. > > HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in > Scotland no. SC218813. > > This e-mail (including any attachments) is private and confidential and may > contain privileged material. If you have received this e-mail in error, > please notify the sender and delete it (including any attachments) > immediately. You must not copy, distribute, disclose or use any of the > information in it or any attachments. Telephone calls may be monitored or > recorded. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. Telephone: 0345 603 1637 Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Cheltenham & Gloucester plc is authorised and regulated by the Financial Conduct Authority. Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings is a division of Lloyds Bank plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. --
Re: Default space allocation
I have, and it wasn't apparent in there that it would have the effect we've seen. Andy Styles z/Series Systems Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: 19 July 2016 15:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Default space allocation -- This email has reached the Bank via an external source -- Have you checked out the ALLOCxx member of SYS1.PARMLIB (Or your version)? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Styles, Andy (SD EP zPlatform) > Sent: Tuesday, July 19, 2016 7:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Default space allocation > > Hi All, > > We've had a minor issue a few times over the past year or so. On our > GDPS control systems, we have a null SMS configuration - all datasets > are allocated with UNIT=SYSALLDA (I think I'm explaining this right), > otherwise you get SPECIFY DEVICE OR CANCEL. > > The issue we seem to have hit is that people using XMIT/RECEIVE seem > to allocate enormous datasets - one yesterday was 45K tracks, 1% used, > which used up nearly all the free space on the volume, and caused > another job to fail as it was unable to get the space it needed. > > I vaguely remember reading somewhere about default space allocation > being something along the lines of "whatever space remains on the volume". > > Does this ring any bells with anyone, or am I just dreaming it? Can > these parameters be changed, and if so, where? I've been hunting but > can't track it down. > > Many thanks, > > -- > Andy Styles > z/Series Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. Telephone: 0345 603 1637 Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Cheltenham & Gloucester plc is authorised and regulated by the Financial Conduct Authority. Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings is a division of Lloyds Bank plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
On Tue, Jul 19, 2016 at 9:32 AM, Reichman Joseph wrote: > As Far as I can see all the I/O we do here is qsam There was an issue > here as Jay Campbell pointed out where writing a VB record had a valid RDW > but the BDW was zeros. Using qsam I would have no idea what the BDW was as > the system takes care > > of that. I am assuming if you use BSAM you decide the number of records > that make up a block and each record is proceeded by a RDW and the block > which you write has cumulative BDW. > > Am I on the right track ? > Yes, you are; BDW == sum(individual RDWs) + 4. > > Joe Reichman > -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Exclusive ENQ on a TSO logon procedure
>As as aside on this, as I understand it, this only applies to data sets >allocated via JCL. That is, if you allocate a PROCLIB inside the JES2PARM >(see below), the DSNs listed do have, and keep, the normal allocation (SHR >as I recall when JES2 does the DYNALLOC). This is true but the description of SCHEDxx explicitly mentions that JES2 is honouring the DSI/NODSI setting when doing its dynalloc. >Also, if I remember correctly, when you specify NODSI, what actually >happens is that the data set _is_ enqueued when you do the START command, >but soon after (during the processing of the PPT entry?) the initiator will >release the ENQ. That is, if you have an STC defined with NODSI, but >something else has a DSN in the JCL "tied up" with a DISP=OLD type >allocation, then the START command will still get A "waiting on data sets" >message and will not be started until the DSN is available. Again true, but I did not mention it because (in normal situations) JES2's ENQs would have been released before any other job or TSO user can be started. Of course, if you ABEND JES2 and restart is, the situation is different. And it also does not help with $ADD PROC. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G wrote: > On Jul 19, 2016, at 9:39 AM, Reichman Joseph > wrote: > > > > I am not thinking of moving this in production it may help me track down > a problem > > If your motivation is to examine the physical blocks, why not read with > QSAM specifying RECFM=U? > That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use QSAM and "have fun". Or not, as the case may be. > > -- > Pew, Curtis G > curtis@austin.utexas.edu > ITS Systems/Core/Administrative Services > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
On Jul 19, 2016, at 9:39 AM, Reichman Joseph wrote: > > I am not thinking of moving this in production it may help me track down a > problem If your motivation is to examine the physical blocks, why not read with QSAM specifying RECFM=U? -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Default space allocation
Have you checked out the ALLOCxx member of SYS1.PARMLIB (Or your version)? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Styles, Andy (SD EP zPlatform) > Sent: Tuesday, July 19, 2016 7:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Default space allocation > > Hi All, > > We've had a minor issue a few times over the past year or so. On our GDPS > control systems, we have a null SMS configuration - all datasets are allocated > with UNIT=SYSALLDA (I think I'm explaining this right), otherwise you get > SPECIFY DEVICE OR CANCEL. > > The issue we seem to have hit is that people using XMIT/RECEIVE seem to > allocate enormous datasets - one yesterday was 45K tracks, 1% used, which used > up nearly all the free space on the volume, and caused another job to fail as > it was unable to get the space it needed. > > I vaguely remember reading somewhere about default space allocation being > something along the lines of "whatever space remains on the volume". > > Does this ring any bells with anyone, or am I just dreaming it? Can these > parameters be changed, and if so, where? I've been hunting but can't track it > down. > > Many thanks, > > -- > Andy Styles > z/Series Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
Agreed 100% with @Kees and @John. I would say "if you have to ask the question then you should not be using BSAM." I did not read the RDW thread but consider that if your block descriptor word is mucked up when using QSAM all you have to do is open a problem with IBM. If your block descriptor is screwed up with BSAM -- well, get out the old debugging hat, and good luck! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Tuesday, July 19, 2016 7:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records I wonder what application it is that justifies considering this. It is not the 80's anymore. And even with QSAM you have the BUFNO parameter. If you really want to go down to the details, consider EXCP (I did, 35 years ago). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: 19 July, 2016 16:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records IOW - unless you are very clever and you have a real need for I/O overlap performance, and you don't mind the maintenance programmer cussing you out, then I'd just go with QSAM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
I am not thinking of moving this in production it may help me track down a problem Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Tuesday, July 19, 2016 10:37 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records I wonder what application it is that justifies considering this. It is not the 80's anymore. And even with QSAM you have the BUFNO parameter. If you really want to go down to the details, consider EXCP (I did, 35 years ago). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: 19 July, 2016 16:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records IOW - unless you are very clever and you have a real need for I/O overlap performance, and you don't mind the maintenance programmer cussing you out, then I'd just go with QSAM. -- For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: DFsort and zIIP
The largest benefit is a financial one: you don't pay the zIIP MSUs. A performance benefit can come from the fact that the zIIP is always running at full speed, while your CP's can run at lower speeds. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: 19 July, 2016 16:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFsort and zIIP On Tue, 19 Jul 2016 08:26:45 +0200, Peter Hunkeler wrote: >>DFSORT can use zIIP on behalf of DB2 utilities, but not otherwise. Here's >>more information: > > >>At this time, IBM has no plan for enabling DFSORT to exploit the system z9 >>Integrated Information Processor (zIIP). IBM realizes DFSORT remains a >>prominent component of our customers' batch workloads. However, the >>added controls that would need to be implemented in order to maintain our >>high standards for performance, reliability and system integrity are not >>justified in view of estimations that there is a low offload potential and >>the value to clients may be marginal.[snip] > >I seem to remember that SyncSort offers an Add-On package that allows >certain SyncSort processing to be offloaded to zIIPs. The above statement >suggest that SyncSort's perfocmance is suffering from using zIIPs (simplified >and exagerated, I know). I understood "there is a low offload potential and the value to clients may be marginal" as meaning that there would not be much benefit in using zIIP. Not that it would be worse. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Default space allocation
TSO ISPF I.4 DATACLAS column 8, 9, 10, 11(and 12 for PDS). On Tue, Jul 19, 2016 at 9:34 AM, Styles, Andy (SD EP zPlatform) <00d68f765d25-dmarc-requ...@listserv.ua.edu> wrote: > Hi All, > > We've had a minor issue a few times over the past year or so. On our GDPS > control systems, we have a null SMS configuration - all datasets are > allocated with UNIT=SYSALLDA (I think I'm explaining this right), otherwise > you get SPECIFY DEVICE OR CANCEL. > > The issue we seem to have hit is that people using XMIT/RECEIVE seem to > allocate enormous datasets - one yesterday was 45K tracks, 1% used, which > used up nearly all the free space on the volume, and caused another job to > fail as it was unable to get the space it needed. > > I vaguely remember reading somewhere about default space allocation being > something along the lines of "whatever space remains on the volume". > > Does this ring any bells with anyone, or am I just dreaming it? Can these > parameters be changed, and if so, where? I've been hunting but can't track it > down. > > Many thanks, > > -- > Andy Styles > z/Series Systems Programmer > > > Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. > Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank > plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in > England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. > Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. > SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered > Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales > 2299428. Telephone: 0345 603 1637 > > Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential > Regulation Authority and regulated by the Financial Conduct Authority and > Prudential Regulation Authority. > > Cheltenham & Gloucester plc is authorised and regulated by the Financial > Conduct Authority. > > Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester > Savings is a division of Lloyds Bank plc. > > HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in > Scotland no. SC218813. > > This e-mail (including any attachments) is private and confidential and may > contain privileged material. If you have received this e-mail in error, > please notify the sender and delete it (including any attachments) > immediately. You must not copy, distribute, disclose or use any of the > information in it or any attachments. Telephone calls may be monitored or > recorded. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
That’s what I meant Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Tuesday, July 19, 2016 10:39 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records Cumulative RDW's+4 (first beginners error). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: 19 July, 2016 16:33 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records As Far as I can see all the I/O we do here is qsam There was an issue here as Jay Campbell pointed out where writing a VB record had a valid RDW but the BDW was zeros. Using qsam I would have no idea what the BDW was as the system takes care of that. I am assuming if you use BSAM you decide the number of records that make up a block and each record is proceeded by a RDW and the block which you write has cumulative BDW. Am I on the right track ? Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of John McKown Sent: Tuesday, July 19, 2016 10:24 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records On Tue, Jul 19, 2016 at 9:02 AM, Reichman Joseph wrote: > Hi, > > Would anyone know the plus and or minus for using BSAM as opposed to > QSAM for VB records. It seems with BSAM there is more control e.g. > specifying the BDW as well as the RDW. Wondering about performance. > > I am guessing if you know what you are doing BSAM would be faster. If > anyone could point me to examples using BSAM would appreciated. As I > have mainly used QSAM specifying the RDW > > Thanks > > Joe Reichman > In general (VB or FB), QSAM is much easier to program. The access method just hands you individual records. But you pay for this in that you cannot do I/O overlap yourself. With BSAM, you do a READ. But the _block_ is not available to you (for certain sure) until you do a CHECK. But this allows you to test the I/O ECB and "do something else" if it has not been POST'd yet. A type of "useful polling" loop. Also, if you are reading multiple files, you can do a ECBLIST and wait for any one of the I/Os to complete instead of doing the I/O serially. Again performance. The problem is that _your code_ must de-block the individual records. For VB, you should probably determine the number of byte read in the block (they aren't necessarily all the same size, you know) and check that the value in the BDW agrees with this number. And the code to do this is non-obvious because what you end up doing is knowing how many bytes you asked for and the I/O control block tells you the residual byte count - not the byte read but more like "you asked to read some bytes and there were were not enough in the block - the block was short by ? bytes). So the number of bytes read is the number of bytes you requested in the READ (not given back to you - you must remember) minus the "residual byte" count which is returned. IOW - unless you are very clever and you have a real need for I/O overlap performance, and you don't mind the maintenance programmer cussing you out, then I'd just go with QSAM. -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its sub
Re: Bsam VS Qsam for VB records
Cumulative RDW's+4 (first beginners error). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: 19 July, 2016 16:33 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records As Far as I can see all the I/O we do here is qsam There was an issue here as Jay Campbell pointed out where writing a VB record had a valid RDW but the BDW was zeros. Using qsam I would have no idea what the BDW was as the system takes care of that. I am assuming if you use BSAM you decide the number of records that make up a block and each record is proceeded by a RDW and the block which you write has cumulative BDW. Am I on the right track ? Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of John McKown Sent: Tuesday, July 19, 2016 10:24 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records On Tue, Jul 19, 2016 at 9:02 AM, Reichman Joseph wrote: > Hi, > > Would anyone know the plus and or minus for using BSAM as opposed to > QSAM for VB records. It seems with BSAM there is more control e.g. > specifying the BDW as well as the RDW. Wondering about performance. > > I am guessing if you know what you are doing BSAM would be faster. If > anyone could point me to examples using BSAM would appreciated. As I > have mainly used QSAM specifying the RDW > > Thanks > > Joe Reichman > In general (VB or FB), QSAM is much easier to program. The access method just hands you individual records. But you pay for this in that you cannot do I/O overlap yourself. With BSAM, you do a READ. But the _block_ is not available to you (for certain sure) until you do a CHECK. But this allows you to test the I/O ECB and "do something else" if it has not been POST'd yet. A type of "useful polling" loop. Also, if you are reading multiple files, you can do a ECBLIST and wait for any one of the I/Os to complete instead of doing the I/O serially. Again performance. The problem is that _your code_ must de-block the individual records. For VB, you should probably determine the number of byte read in the block (they aren't necessarily all the same size, you know) and check that the value in the BDW agrees with this number. And the code to do this is non-obvious because what you end up doing is knowing how many bytes you asked for and the I/O control block tells you the residual byte count - not the byte read but more like "you asked to read some bytes and there were were not enough in the block - the block was short by ? bytes). So the number of bytes read is the number of bytes you requested in the READ (not given back to you - you must remember) minus the "residual byte" count which is returned. IOW - unless you are very clever and you have a real need for I/O overlap performance, and you don't mind the maintenance programmer cussing you out, then I'd just go with QSAM. -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscri
Re: DFsort and zIIP
On Tue, 19 Jul 2016 08:26:45 +0200, Peter Hunkeler wrote: >>DFSORT can use zIIP on behalf of DB2 utilities, but not otherwise. Here's >>more information: > > >>At this time, IBM has no plan for enabling DFSORT to exploit the system z9 >>Integrated Information Processor (zIIP). IBM realizes DFSORT remains a >>prominent component of our customers' batch workloads. However, the >>added controls that would need to be implemented in order to maintain our >>high standards for performance, reliability and system integrity are not >>justified in view of estimations that there is a low offload potential and >>the value to clients may be marginal.[snip] > >I seem to remember that SyncSort offers an Add-On package that allows >certain SyncSort processing to be offloaded to zIIPs. The above statement >suggest that SyncSort's perfocmance is suffering from using zIIPs (simplified >and exagerated, I know). I understood "there is a low offload potential and the value to clients may be marginal" as meaning that there would not be much benefit in using zIIP. Not that it would be worse. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
I wonder what application it is that justifies considering this. It is not the 80's anymore. And even with QSAM you have the BUFNO parameter. If you really want to go down to the details, consider EXCP (I did, 35 years ago). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: 19 July, 2016 16:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records IOW - unless you are very clever and you have a real need for I/O overlap performance, and you don't mind the maintenance programmer cussing you out, then I'd just go with QSAM. -- For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Default space allocation
Hi All, We've had a minor issue a few times over the past year or so. On our GDPS control systems, we have a null SMS configuration - all datasets are allocated with UNIT=SYSALLDA (I think I'm explaining this right), otherwise you get SPECIFY DEVICE OR CANCEL. The issue we seem to have hit is that people using XMIT/RECEIVE seem to allocate enormous datasets - one yesterday was 45K tracks, 1% used, which used up nearly all the free space on the volume, and caused another job to fail as it was unable to get the space it needed. I vaguely remember reading somewhere about default space allocation being something along the lines of "whatever space remains on the volume". Does this ring any bells with anyone, or am I just dreaming it? Can these parameters be changed, and if so, where? I've been hunting but can't track it down. Many thanks, -- Andy Styles z/Series Systems Programmer Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. Telephone: 0345 603 1637 Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Cheltenham & Gloucester plc is authorised and regulated by the Financial Conduct Authority. Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings is a division of Lloyds Bank plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bsam VS Qsam for VB records
As Far as I can see all the I/O we do here is qsam There was an issue here as Jay Campbell pointed out where writing a VB record had a valid RDW but the BDW was zeros. Using qsam I would have no idea what the BDW was as the system takes care of that. I am assuming if you use BSAM you decide the number of records that make up a block and each record is proceeded by a RDW and the block which you write has cumulative BDW. Am I on the right track ? Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of John McKown Sent: Tuesday, July 19, 2016 10:24 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Bsam VS Qsam for VB records On Tue, Jul 19, 2016 at 9:02 AM, Reichman Joseph wrote: > Hi, > > Would anyone know the plus and or minus for using BSAM as opposed to > QSAM for VB records. It seems with BSAM there is more control e.g. > specifying the BDW as well as the RDW. Wondering about performance. > > I am guessing if you know what you are doing BSAM would be faster. If > anyone could point me to examples using BSAM would appreciated. As I > have mainly used QSAM specifying the RDW > > Thanks > > Joe Reichman > In general (VB or FB), QSAM is much easier to program. The access method just hands you individual records. But you pay for this in that you cannot do I/O overlap yourself. With BSAM, you do a READ. But the _block_ is not available to you (for certain sure) until you do a CHECK. But this allows you to test the I/O ECB and "do something else" if it has not been POST'd yet. A type of "useful polling" loop. Also, if you are reading multiple files, you can do a ECBLIST and wait for any one of the I/Os to complete instead of doing the I/O serially. Again performance. The problem is that _your code_ must de-block the individual records. For VB, you should probably determine the number of byte read in the block (they aren't necessarily all the same size, you know) and check that the value in the BDW agrees with this number. And the code to do this is non-obvious because what you end up doing is knowing how many bytes you asked for and the I/O control block tells you the residual byte count - not the byte read but more like "you asked to read some bytes and there were were not enough in the block - the block was short by ? bytes). So the number of bytes read is the number of bytes you requested in the READ (not given back to you - you must remember) minus the "residual byte" count which is returned. IOW - unless you are very clever and you have a real need for I/O overlap performance, and you don't mind the maintenance programmer cussing you out, then I'd just go with QSAM. -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- 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: Bsam VS Qsam for VB records
On Tue, Jul 19, 2016 at 9:02 AM, Reichman Joseph wrote: > Hi, > > Would anyone know the plus and or minus for using BSAM as opposed to QSAM > for VB records. It seems with BSAM there is more control e.g. specifying > the BDW as well as the RDW. Wondering about performance. > > I am guessing if you know what you are doing BSAM would be faster. If > anyone could point me to examples using BSAM would appreciated. As I have > mainly used QSAM specifying the RDW > > Thanks > > Joe Reichman > In general (VB or FB), QSAM is much easier to program. The access method just hands you individual records. But you pay for this in that you cannot do I/O overlap yourself. With BSAM, you do a READ. But the _block_ is not available to you (for certain sure) until you do a CHECK. But this allows you to test the I/O ECB and "do something else" if it has not been POST'd yet. A type of "useful polling" loop. Also, if you are reading multiple files, you can do a ECBLIST and wait for any one of the I/Os to complete instead of doing the I/O serially. Again performance. The problem is that _your code_ must de-block the individual records. For VB, you should probably determine the number of byte read in the block (they aren't necessarily all the same size, you know) and check that the value in the BDW agrees with this number. And the code to do this is non-obvious because what you end up doing is knowing how many bytes you asked for and the I/O control block tells you the residual byte count - not the byte read but more like "you asked to read some bytes and there were were not enough in the block - the block was short by ? bytes). So the number of bytes read is the number of bytes you requested in the READ (not given back to you - you must remember) minus the "residual byte" count which is returned. IOW - unless you are very clever and you have a real need for I/O overlap performance, and you don't mind the maintenance programmer cussing you out, then I'd just go with QSAM. -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Bsam VS Qsam for VB records
Hi, Would anyone know the plus and or minus for using BSAM as opposed to QSAM for VB records. It seems with BSAM there is more control e.g. specifying the BDW as well as the RDW. Wondering about performance. I am guessing if you know what you are doing BSAM would be faster. If anyone could point me to examples using BSAM would appreciated. As I have mainly used QSAM specifying the RDW Thanks Joe Reichman Joe Reichman IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F 7:30 am - 4:00 pm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFsort and zIIP
IBM markets DB2SORT, which is Syncsort/MFX with modifications to specifically work with and enhance sorting performed for DB2 Utilities and offloads portions of its processing to z/IIP engines when possible. Syncsort/MFX also offloads portions of its processing to z/IIP engines. Syncsort ZPSAVER offloads significant portions of its processing to z/IIP engines. I am not aware of any of these products' "performance suffering from using zIIPs" in either billable TCB time or elapsed time. Many years of research and development have gone into creating these products and I am proud to have been a small part of it. Chris Blaicher Technical Architect Mainframe Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com www.syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, July 19, 2016 2:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: DFsort and zIIP >DFSORT can use zIIP on behalf of DB2 utilities, but not otherwise. >Here's more information: > >At this time, IBM has no plan for enabling DFSORT to exploit the system >z9 Integrated Information Processor (zIIP). IBM realizes DFSORT >remains a prominent component of our customers' batch workloads. >However, the added controls that would need to be implemented in order >to maintain our high standards for performance, reliability and system >integrity are not justified in view of estimations that there is a low >offload potential and the value to clients may be marginal.[snip] Interesting statement. I seem to remember that SyncSort offers an Add-On package that allows certain SyncSort processing to be offloaded to zIIPs. The above statement suggest that SyncSort's perfocmance is suffering from using zIIPs (simplified and exagerated, I know). Also "IBM Sort for DB2 for z/OS" (can't remember the exact name), is offloading to zIIPs, if I remember correctly. This procuct is based on SyncSort code as far as I understand. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FLASHCOPY QUESTION
Esmie, Let me give it a try. I think you're getting confused due to terminology and different views of the copies. From a z/OS point of view, both the examples you show are doing full volume copies of data from your IN to your OUT. Once the job is done, you have 2 full copies of the data, one on each volume. The difference is what's going on in the back-end disk array. In example 1, you have FCNC which from the back-end array, the only thing that happens is that a set of pointers (a track table) gets built but no data gets copied. The only time data gets physically copied from source to target is when either the source or target data track is changed. If the source data gets changed, a copy of the track gets put on the target before the source is updated. In case of the target getting updated, the changed data is written to the target. If, for example, in this scenario you are doing this copy with the intent of doing a DUMP of the target to tape, most of the data for the DUMP is actually coming from the SOURCE, because unless the data changed, the SOURCE is the only place the physical data resides. In example 2, FCINCREMENTAL does NOT mean do an incremental backup. FC/DFDSS does a full background copy of all the data from the source to the target. It still looks like it ran really fast to z/OS because as soon as the track table is built on the array, the array signals to z/OS the backup is done. However, the back end is still copying all the data to the target. Why use FCINCR then? Under normal FC processing, if you don't use FCNC, the background copy is initiated, and then once all the data is copied to the target, the relationship between source and target is terminated, and the 2 volumes are now stand-alone. If FCINCR is specified like in your example, the relationship remains in place with the track table now indicating which tracks have changed since the FC ran. If you then come along and run another COPY command with the same source and target, the array uses the track table and only updates the changed tracks, thus (potentially) significantly reducing the load on the array if there wasn't much change in the data. So in short, FCNC only copies changed tracks from the source to the target, but FCINCR forces a full back-end copy of all the data from source to target on initial setup. Note in the DFDSS manual is that FCNC and FCINCR are mutually exclusive. HTH, Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Tuesday, July 19, 2016 6:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: FLASHCOPY QUESTION Gentle Readers, I was wondering if any of you can clear up understating about FlashCopy. In the following example COPY INDYNAM(SYS012) OUTDYNAM(DCN00) CANCELERROR - PURGE ALLEXCP ALLDATA(*) OPT(4) ADMIN FCNOCOPY - DUMPCOND FR(REQ) DEBUG(FRMSG(DETAILED)) My understanding is that an Incremental copy is being performed because FCNOCPY is specified. My understanding of Incremental is that only the updated tracks are copied over to the target volume. Please correct me if I am wrong. Also, I have this example. Is this for a FULL FlashCopy of a volume? However, I am confused that the FCINCREMENTAL parm is specified which would indicate that this is an incremental copy COPY FULL INDYNAM(ZFSZ01) OUTDYNAM(ZWATP0) ALLE ALLD(*) - FASTREPLICATION(REQUIRED) FCINCREMENTAL DUMPCONDITIONING ADMIN PURGE Could someone clear up this for me? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Job Search
My organization has just posted a CICS sysprog job (below). There's good support for Telecommunting here and if you've got solid skills working remote should not be a deal breaker. Problem is the pay is well below market rates. We have several unfilled positions zOS/DB2/CICS/automation but cannot attract experienced people. Good luck! Ken Smith Comptroller (taxes) for State of Maryland Annapolis MD http://www.jobaps.com/MD/sup/BulPreview.asp?R1=16&R2=004476&R3=0002 On Mon, Jul 18, 2016 at 8:39 AM, william janulin < 008d52e04f2e-dmarc-requ...@listserv.ua.edu> wrote: > Joe can be difficult to reach at times. You can also contacvt, which I > have done because I am in the market as well, Chris Evans. I believe his > moniker is ch...@spci.net. I am seeking any remote sysprog work, either > zVM, zVSE, zOS or all of the above. > Bill J. > > > On Sunday, July 17, 2016 11:49 PM, Tom Conley < > pinnc...@rochester.rr.com> wrote: > > > On 7/17/2016 5:38 AM, Richards, Robert B. wrote: > > Rob, > > > > Try contacting Joe Gallaher at Systems Programming Consultants, Inc. > (SPCI). He attends most SHARE conferences and would be my first stop if I > were looking. > > Plus, I've known him for over 35 years. :-) > > > > His email is quite simple: j...@spci.net > > > > Bob > > > > I'll second that, Joe is the best. I also use dice.com. > > Regards, > Tom Conley > > -- > 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: Exclusive ENQ on a TSO logon procedure
On Tue, Jul 19, 2016 at 6:50 AM, Peter Hunkeler wrote: > > >If a user logs on, it is JES2 that reads the logonproc from PROCLIB, > which it already has allocated (as you >mentioned). Kind of a chicken and > egg problem: how can a user logon without having read the logonproc? > >Kees. > > > >Oh yeah..You are right.. . That explains why User C was able to log on . > Thank you Kees ... > > > JES2 is usually defined with NODSI in the PPT (SCHEDxx) and does not hold > an ENQ on the data sets it has allocated. > As as aside on this, as I understand it, this only applies to data sets allocated via JCL. That is, if you allocate a PROCLIB inside the JES2PARM (see below), the DSNs listed do have, and keep, the normal allocation (SHR as I recall when JES2 does the DYNALLOC). Example portion of JES2PARM: PROCLIB(PROC02) DD(1)=(DSN=SYS4.MDOFPROC), DD(2)=(DSN=SYS1.PROCLIB), DD(3)=(DSN=SYS2.PROCLIB), DD(4)=(DSN=SYS1.LI.PROCLIB) Also, if I remember correctly, when you specify NODSI, what actually happens is that the data set _is_ enqueued when you do the START command, but soon after (during the processing of the PPT entry?) the initiator will release the ENQ. That is, if you have an STC defined with NODSI, but something else has a DSN in the JCL "tied up" with a DISP=OLD type allocation, then the START command will still get A "waiting on data sets" message and will not be started until the DSN is available. > > > -- > Peter Hunkeler > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FLASHCOPY QUESTION
Gentle Readers, I was wondering if any of you can clear up understating about FlashCopy. In the following example COPY INDYNAM(SYS012) OUTDYNAM(DCN00) CANCELERROR - PURGE ALLEXCP ALLDATA(*) OPT(4) ADMIN FCNOCOPY - DUMPCOND FR(REQ) DEBUG(FRMSG(DETAILED)) My understanding is that an Incremental copy is being performed because FCNOCPY is specified. My understanding of Incremental is that only the updated tracks are copied over to the target volume. Please correct me if I am wrong. Also, I have this example. Is this for a FULL FlashCopy of a volume? However, I am confused that the FCINCREMENTAL parm is specified which would indicate that this is an incremental copy COPY FULL INDYNAM(ZFSZ01) OUTDYNAM(ZWATP0) ALLE ALLD(*) - FASTREPLICATION(REQUIRED) FCINCREMENTAL DUMPCONDITIONING ADMIN PURGE Could someone clear up this for me? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Exclusive ENQ on a TSO logon procedure
>If a user logs on, it is JES2 that reads the logonproc from PROCLIB, which it >already has allocated (as you >mentioned). Kind of a chicken and egg problem: >how can a user logon without having read the logonproc? >Kees. > >Oh yeah..You are right.. . That explains why User C was able to log on . Thank >you Kees ... JES2 is usually defined with NODSI in the PPT (SCHEDxx) and does not hold an ENQ on the data sets it has allocated. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FAMS?
You probably knew this but if you can run under ISPF, batch or interactive, use LMMSTATS. Otherwise found this on the format of the PDS directory: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54mc00/ispmc28.htm Ken On Mon, Jul 18, 2016 at 12:18 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > After my questions in a couple fora went unanswered, I looked further > into NFS documentation: > > z/OS Network File System Guide and Reference > SC26-7417-13 > > ... File time stamps in UNIX format are part of the attributes required > by the NFS protocol for NFS client/server communication. ... > > 2. MVS maintains the PDSE member create/change time stamp (mtime) in > the > PDSE AX cell. The Server uses a FileAccessMethodService (FAMS) > call ... > > A Google search for FAMS returns the NFS reference, a SHARE presentation, > a RFE, > and several APARs. > > Where is this thing documented? It should be useful. > > Also, from the NFS Guide: > > ... The server uses the following main time stamp sources to generate > UNIX time stamps for MVS z/OS conventional (legacy) file systems: > > DSCB (data set control block) > Master Catalog data set attribute extension (AX) cell > PDSE member attribute extension (AX) cell > ISPF member statistics > TOD (current time_of_day on the server side). > > Rube Goldberg. > > -- 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: SMFPRMxx
>I'm trying to determine if they are actually being called/used. If you have the exits defined then they're going to be called, for the events for which they are defined. The displays can tell you the names of the exit routines associated with the exit. It does not give any information about whether or not the exit is called. If you truly want to know if an exit routine is getting control, you could use a SLIP trap (one at a time) to capture some data upon entry to the exit routine (DISPLAY PROG,EXIT can tell you the exit routine address). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on a TSO logon procedure
If a user logs on, it is JES2 that reads the logonproc from PROCLIB, which it already has allocated (as you mentioned). Kind of a chicken and egg problem: how can a user logon without having read the logonproc? Kees. Oh yeah..You are right.. . That explains why User C was able to log on . Thank you Kees ... Roger Steyn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on a TSO logon procedure
If a user logs on, it is JES2 that reads the logonproc from PROCLIB, which it already has allocated (as you mentioned). Kind of a chicken and egg problem: how can a user logon without having read the logonproc? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roger Steyn Sent: 19 July, 2016 11:25 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Exclusive ENQ on a TSO logon procedure There is a big difference between a job allocating a proclib with DISP=OLD and a user editing a logonproc with ISPF. The job with DISP=OLD blocks the entire proclib. ISPF issues an ENQ with DISP=SHR on the proclib and issues its own ENQ on the member with DISP=OLD. This way the library is available for other task with DISP=SHR, but the member (logonproc) is exclusively in use by the ISPF user. This works this way for decades already. Well ... Let me put the scenario a bit more clear a) User A goes and edits the logon procedure in ISPF and doesn't come out of edit mode . b) User B submits a Job with SYS1.PROCLIB containing the logon proc with DISP=OLD Then the job waits for an exclusive access for SYS1.PROCLIB which never gets satisfied as the proclib is already allocated with DISP=SHR by many things including JES2 - This is normal Now , my understanding is - At this point , if a USER C tries to logon to the system using the same logon procedure in SYS1.PROCLIB , he shouldn't be able to as GRS has another Exclusive ENQ request waiting from the job submitted by User B . Shouldn't that be honored before allowing others to access the proclib irrespective of DISP=SHR ? TIA Roger Steyn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on a TSO logon procedure
There is a big difference between a job allocating a proclib with DISP=OLD and a user editing a logonproc with ISPF. The job with DISP=OLD blocks the entire proclib. ISPF issues an ENQ with DISP=SHR on the proclib and issues its own ENQ on the member with DISP=OLD. This way the library is available for other task with DISP=SHR, but the member (logonproc) is exclusively in use by the ISPF user. This works this way for decades already. Well ... Let me put the scenario a bit more clear a) User A goes and edits the logon procedure in ISPF and doesn't come out of edit mode . b) User B submits a Job with SYS1.PROCLIB containing the logon proc with DISP=OLD Then the job waits for an exclusive access for SYS1.PROCLIB which never gets satisfied as the proclib is already allocated with DISP=SHR by many things including JES2 - This is normal Now , my understanding is - At this point , if a USER C tries to logon to the system using the same logon procedure in SYS1.PROCLIB , he shouldn't be able to as GRS has another Exclusive ENQ request waiting from the job submitted by User B . Shouldn't that be honored before allowing others to access the proclib irrespective of DISP=SHR ? TIA Roger Steyn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on a TSO logon procedure
There is a big difference between a job allocating a proclib with DISP=OLD and a user editing a logonproc with ISPF. The job with DISP=OLD blocks the entire proclib. ISPF issues an ENQ with DISP=SHR on the proclib and issues its own ENQ on the member with DISP=OLD. This way the library is available for other task with DISP=SHR, but the member (logonproc) is exclusively in use by the ISPF user. This works this way for decades already. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roger Steyn Sent: 19 July, 2016 10:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Exclusive ENQ on a TSO logon procedure Greetings , Can somebody tell me what if a proclib containing a TSO logon procedure has got a DISP=OLD in a user submitted JCL or if somebody opens a logon procedure in ISPF edit mode and keep it that way for few hours. Will the rest of the users be able to log on using the same logon procedure while the ENQ is on ? Well , this is on z/os 2.1 and i was surprised to see the enq doesn't hold anybody from logging on using the same logon procedure while there is an exclusive ENQ . Does anyone know if this is a new feature in z/os 2.1 ? I am aware of the dynamic ENQ downgrade within a JCL having multiple steps . But the job which had a DISP=OLD in my system had only one step and it was hanging because someone had opened the logon proc in edit mode and forgot to come out of the session . TIA Roger Steyn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Exclusive ENQ on a TSO logon procedure
Greetings , Can somebody tell me what if a proclib containing a TSO logon procedure has got a DISP=OLD in a user submitted JCL or if somebody opens a logon procedure in ISPF edit mode and keep it that way for few hours. Will the rest of the users be able to log on using the same logon procedure while the ENQ is on ? Well , this is on z/os 2.1 and i was surprised to see the enq doesn't hold anybody from logging on using the same logon procedure while there is an exclusive ENQ . Does anyone know if this is a new feature in z/os 2.1 ? I am aware of the dynamic ENQ downgrade within a JCL having multiple steps . But the job which had a DISP=OLD in my system had only one step and it was hanging because someone had opened the logon proc in edit mode and forgot to come out of the session . TIA Roger Steyn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Node.js for z/OS: Emerging Now
How exciting. It's good to see IBM putting code on Github. I was aware that IBM were porting libuv so it was no suprise to see them working on V8 on the road to Node. A z/OS port of V8 sure makes porting code that depends on it a hell of a lot easier, for example - MongoDB. On 18/07/2016 9:35 PM, Timothy Sipples wrote: I've seen some questions in IBM-MAIN (and elsewhere) about availability of Node.js for z/OS. The latest version of Node.js is just starting to emerge on z/OS, and that's great news of course. For the latest information (as of July 14, 2016, at least), please take a look at Michael Dawson's article here: https://developer.ibm.com/node/2016/07/14/linuxone-ppc-aix-and-zos-support-in-the-node-js-community/ If you're wondering what Node.js is, this Wikipedia article explains the basics: https://en.wikipedia.org/wiki/Node.js Node.js was introduced some time ago for Linux on z and LinuxONE and (of course) continues to be updated and enhanced. IBM's builds are available for download here: https://developer.ibm.com/node/sdk/ Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- 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