Re: SMP/E oddity?
On Tue, 29 Nov 2022 20:45:48 + "Kurt J. Quackenbush" wrote: :>> Yeah, this all makes sense. Basically, the idea of APPLY is to build the LMOD with everything that's been ACCEPTed or previously APPLYed to it. :>SMP/E has enough information to reconstruct it from scratch if needed, but will save itself the work of rebuilding the LMOD from the MODs if it doesn't have to do it. :>> You mention that the MODs are applied from PTFs; I assume that APARs are also reapplied if not SUPd (which they would be required to be if the PTF you're working with would clobber them). :>Yes, FUNCTIONs, PTFs, APARs, USERMODs, whatever SYSMOD last replaced a MOD (the MOD's RMID) can be used to obtain a usable copy of that MOD from the SMPPTS. :>> Does the same processing apply to RESTORE? Or does it always build from scratch? :>RESTORE does behave the same as APPLY in this respect. RESTORE no longer requires that other maintenance to the involved elements be ACCEPTed? It can rebuild the load modules using APPLYed-only elements? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Computers
Tom Brennan wrote: >I never knew each section of a computer had its own distinct sound. >https://www.youtube.com/watch?v=ukyHECjKDoQ Tsk. You don't have those sounds on your PC? Srsly, this was great! A classic. I laughed, I cried. I give it ten stars. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To share or not to share DASD
You are completely right, and thanks for setting things straight. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Computers
I never knew each section of a computer had its own distinct sound. https://www.youtube.com/watch?v=ukyHECjKDoQ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E oddity?
> Yeah, this all makes sense. Basically, the idea of APPLY is to build the LMOD > with everything that's been ACCEPTed or previously APPLYed to it. SMP/E has enough information to reconstruct it from scratch if needed, but will save itself the work of rebuilding the LMOD from the MODs if it doesn't have to do it. > You mention that the MODs are applied from PTFs; I assume that APARs are also > reapplied if not SUPd (which they would be required to be if the PTF you're > working with would clobber them). Yes, FUNCTIONs, PTFs, APARs, USERMODs, whatever SYSMOD last replaced a MOD (the MOD's RMID) can be used to obtain a usable copy of that MOD from the SMPPTS. > Does the same processing apply to RESTORE? Or does it always build from > scratch? RESTORE does behave the same as APPLY in this respect. Kurt Quackenbush IBM | z/OS SMP/E and z/OSMF Software Management | ku...@us.ibm.com Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
Yes, in OS/360, but if you use COPYMOD instead of COPY then IEBCOPY reblocks appropriately to optimize packing. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Leonard D Woren [ibm-main...@ldworen.net] Sent: Wednesday, November 23, 2022 7:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bytes in a 3390 track Long ago I had a theory regarding blksize=32K load module libraries that I could demonstrate on paper but never attempted to demonstrate for real due to the amount of work involved. Consider that the linkage editor writes however much program text as fits on the rest of the track. IEBCOPY to a new data set copies members in membername order, not physical order from the original data set. It is theoretically possible to construct a degenerate case where due to the above, the IEBCOPY'd data set will actually take _more_ space than the original! You could have two members originally linked to different areas of the original PDS, decently utilizing 32K blocks. Now you IEBCOPY the data set and those two members end up one following one another in the target, and the second member's 32K block doesn't fit after the first member's 32K block, and the short noise blocks in load modules come nowhere close to using up that space. So in certain degenerate cases, you could waste maybe 1/3 of the space when IEBCOPYing a blksize=32K load module library. I suspect that some number a bit below half track is optimum to allow for the small overhead blocks plus 2 long text blocks. OTOH, why isn't everybody using PDSEs instead of wasting brain power on this? /Leonard Mike Schwab wrote on 11/23/2022 10:22 AM: [...] > Load module PDSs have members with a symbol dictionary in text and > blocked together to start, then repeating a very short block then the > program machine code in multiples of 1K to the blocksize or fill the > rest of the track if less until the load module is complete. > > When adding or updating the data is added to the end of the dataset. > When updating or deleting a member the references to the space > previously used is removed but can’t be reused. Eventually you > compress the PDS in place. The program reads the directory, > determines where unreferenced space is, then moves up the next block > to the unreferenced space. The COPY command doesn’t reblock the data, > so if you have a 31K empty space but the next block is 32K, you don’t > use that space. COPYMOD does reblock, but may not be used very often. > > So, a research idea is to write a program that reads the C part of > each CKD record, and calculate a fake R255 for the Key/Blocksize that > could fill the track. K8/D256 would be the directory blocks, K0/Dx > would be text, K0/Dnk would be program code. Counts of each key / > block size in a dataset would give insight to that dataset or > collection of text datasets and collection of load module datasets. > > Experiments to help determine optimal blocksizes would be to create a > test library with 32K blocksize, copy with reblock into the test > library, analyze blocksizes, delete first member, compress in place, > reanalyze blocksize especially the unused space at end of track. > Repeat until empty. Reduce by 1K, repeat with copy with reblocking, > analyzing, deleting, compressing until empty. > > My predictions of what could be optimal is a 4K blocksize. And VSAM > and PDSE datasets usually use this physical block size. And might > have advantages in the I/O occurring in a single frame. > > > On Wed, Nov 23, 2022 at 11:35 AM Seymour J Metz wrote: >> No, sometimes a smaller block size is more efficient. Also, a 32K block >> size doesn't mean that all blocks are 32K; both the linkage editor and >> IEBCOPY can write short blocks to pad out a track. >> >> >> From: IBM Mainframe Discussion List on behalf of >> Paul Gorlinsky >> Sent: Wednesday, November 23, 2022 12:14 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Bytes in a 3390 track >> >> John, The simple view is that with DASD, the bigger the block as a multiple >> of the track size, the more data you can store on a track. >> >> It almost like an IBG on the older tapes. >> >> Best allocation or space calc is to use 1/2 track if possible, for QSAM, and >> PDSs. For PDSEs using 32760 is fine because I believe they like linear VSAM >> files with 4K blocks. >> >> Remember for DASD, the maximum block size ( physical record ) is 32760. But >> this means on a 3390 you waste about 24K per track. Where as, using >> something near 27998 or less, you will get 2 blocks per track with about 1% >> overhead. >> >> It looks like PDSEs have about 13% overhead per track assuming a 4K (PAGE) >> track record size ... BUT no compression needs.. >> >> For the most part, let the OS handle the allocation by using BLKSIZE=0 where >> you can. It will calc the
Re: Storage protection keys
That's a presentation on millicode; there is no connection to Java byte code, Pascal P-code or S/38 MI (TIMI on AS/400), -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Rob Schramm [rob.schr...@gmail.com] Sent: Monday, November 28, 2022 7:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage protection keys Cmg on the various codes https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Furl%3Fsa%3Dt%26source%3Dweb%26rct%3Dj%26url%3Dhttps%3A%2F%2Fwww.cmg.org%2Fwp-content%2Fuploads%2F2016%2F08%2Fthe-what-and-why-of-system-z-millicode.pdf%26ved%3D2ahUKEwiVgKrnkNL7AhUeQzABHV6nCAEQFnoECBMQAQ%26usg%3DAOvVaw1z9331tDaCUEnXojJZXGMGdata=05%7C01%7Csmetz3%40gmu.edu%7C17e1e56969eb45a063af08dad1a0de2a%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638052788060989131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=adcWkDaUqiTYQVedNVKdos0g8iW1L6nrChRik1xcF1A%3Dreserved=0 Rob Schramm On Fri, Nov 25, 2022, 11:30 Seymour J Metz wrote: > The MI is an object oriented language at a high level than Pascal P-code. > I don't know how it compares to JVM byte code. The key feature is that you > can only call a program object and that the objects are black box. > > You might want to read up on capability based machines and browse the > manuals at > http://secure-web.cisco.com/1o--OKvbhSScouqKttpp-jI7_7S66kA906lIF53mfpXLbMWBuRDNJvFWOu1B05bfpe5yULLeVHdK0f11nqZRSVPRLf73f4DPA3THbiRCgoYJ19jbL8fjCKQ4FDLXel46DEwaaXikiEV6VuNAcmHHZTvfL6tLkaBjKd1_QE8nrCGVPqQRxyYFVBdsgSjPF8jCaP6MDXIQuHlhF2iJF2m3uIlL5xv-3bsBLJDj4LyPHIb6W17sobWUM2fsPV89Gnf5hmrz3F0VFzee7NI7VHczy8F2FnYBLZ5uP_Al6B2gpQLYlyiFGy5A3fK12xP92lIeBg3Q_ArxPKP1Ig098yy0YEAJLmYA_BEE3ZcGSQ4YypMWtCwDfHVb2ogPYyV7HRn-3fMlGFbLb76RD07mcIcObh6fed8EulUzAI_2DWQi4c2M/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2Fsystem38%2F > and > http://secure-web.cisco.com/1GPy_6goTTQTpWoErpqPAXM2LGZXese8n6e3nhMXN6beorU8Z20ACfN-jMIHlG8NvPJMa01N-qnfdGpOvKR7JzPSZzjkXKlPFw3OETZcAm1RflxJlXeMM4EZj3xEK6hTSLaBAd7qRKNTgKwVGvFGZAGI1XGxXBxf_9_UezUm5OjlbsDKFM3Mm2IDKhVhn_pfY_M8WgsObwNOyygQ3mZxzvrB8TA9TWEUOFMsW1dVn_YZnmRewqnE4O7VqnqNY7UNYsoayjTO3i5GtWlr1w5pvdwpsayOUrDZijO4GstY3W_EBXKQWSr1Ayyo1JuusCx3b9TLJ3oumxRMyXIjMzTpjsIuFzmNmgoixVxoceRZohP9SE8gn_6YvRt9V8Gw9SEscKB8QASb0mHsXjkpjp_0HBaS3jj4WITjerS7rTZyZGBM/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2Fas400%2F > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Paul Gorlinsky [p...@atsmigrations.com] > Sent: Friday, November 25, 2022 11:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Storage protection keys > > Would you consider that the applications were more like P-Code ( > pseudo-code ) ... not that much different in principle to JAVA today ? > > -- > 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: To share or not to share DASD
This type of sysplex is called Basic by IBM. https://www.ibm.com/docs/en/zos-basic-skills?topic=sysplex-zos Doug On Tue, 29 Nov 2022 07:43:23 -0600, Dana Mitchell wrote: >On Mon, 28 Nov 2022 23:51:53 -0600, Brian Westerman > wrote: > >>You're incorrect, you don't need a coupling facility to share PDS/e, you can >>(and I do at several sites) use FICON CTC's just as well, and in fact it's a >>lot cheaper, >>(unless you already have a coupling facility installed in which case it would >>be silly to not use it). >> >>IBM does not require a CF to share PDS/e all the way down to the member >>level. Wherever you got the information you posted, it's incorrect or at >>best misleading. I >maintain several sites that have no coupling facility >>and sysplex sharing is no problem. It's not a "complete" sysplex, but I >>think people tend to refer to it as a "baby" >sysplex. GRS ring is not a >>problem, and you get a lot of the benefits of sysplex (shared consoles, >>command shipping, etc.) you just don't have the CF to handle it, >instead you >>use the FICON Cards as CTC's >> > >You both and the linked doc are correct. This is a true statement "Every >system that is sharing a PDSE must be a member of the sysplex and have the >sysplex coupling facility (XCF) active." > >But XCF does not require CF, Brian's COUPLExx members have PATHINs and >PATHOUTs specifying FICON CTCs, instead of STRNAMEs. > >Dana > >-- >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: To share or not to share DASD
On Mon, 28 Nov 2022 23:51:53 -0600, Brian Westerman wrote: >You're incorrect, you don't need a coupling facility to share PDS/e, you can >(and I do at several sites) use FICON CTC's just as well, and in fact it's a >lot cheaper, >(unless you already have a coupling facility installed in which case it would >be silly to not use it). > >IBM does not require a CF to share PDS/e all the way down to the member level. > Wherever you got the information you posted, it's incorrect or at best >misleading. I >maintain several sites that have no coupling facility and >sysplex sharing is no problem. It's not a "complete" sysplex, but I think >people tend to refer to it as a "baby" >sysplex. GRS ring is not a problem, >and you get a lot of the benefits of sysplex (shared consoles, command >shipping, etc.) you just don't have the CF to handle it, >instead you use the >FICON Cards as CTC's > You both and the linked doc are correct. This is a true statement "Every system that is sharing a PDSE must be a member of the sysplex and have the sysplex coupling facility (XCF) active." But XCF does not require CF, Brian's COUPLExx members have PATHINs and PATHOUTs specifying FICON CTCs, instead of STRNAMEs. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Hillgang reminder
Hillgang will be meeting in Herndon Virginia this time next week. Agenda, location, and (free) registration at https://www.vm.ibm.com/events/hill1222.pdf Great topics, speakers, networking, and breakfast (thanks Velocity). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
