Re: To share or not to share DASD
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 If you don't have the $$s to spend on a CF, buying a couple FICON cards from a reseller (or even eBay) is a very inexpensive way to achieve GRS support (and thus PDS/e sharing). Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage protection keys
Cmg on the various codes https://www.google.com/url?sa=t=web=j=https://www.cmg.org/wp-content/uploads/2016/08/the-what-and-why-of-system-z-millicode.pdf=2ahUKEwiVgKrnkNL7AhUeQzABHV6nCAEQFnoECBMQAQ=AOvVaw1z9331tDaCUEnXojJZXGMG 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://bitsavers.org/pdf/ibm/system38/ and > http://bitsavers.org/pdf/ibm/as400/. > > > -- > 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
Re: To share or not to share DASD
I vote with Brian. Rob On Mon, Nov 28, 2022, 16:34 Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > PDSE sharing is only supported within a Sysplex. XCF signalling is > required to maintain > integrity. When you say that PDSEs can be fully shared, I think you are > referring to > Extended Sharing, not Normal Sharing. Following is from > > https://www.ibm.com/docs/en/zos/2.4.0?topic=neps-specifying-extended-pdse-sharing-in-multiple-system-environment > but it has been this way for a very long time. > > > In a multiple-system environment, the system programmer uses > PDSESHARING(EXTENDED) > to share PDSEs at the member level. A system programmer must specify > PDSESHARING(EXTENDED) in the IGDSMSxx member in the SYS1.PARMLIB on each > system in the sysplex. Every system that is sharing a PDSE must be a > member of the > sysplex and have the sysplex coupling facility (XCF) active. > > > People have violated these rules and gotten away with it, but that does > not mean > that it is safe to do so. > > -- > Tom Marchant > > On Fri, 25 Nov 2022 20:00:42 -0600, Brian Westerman < > brian_wester...@syzygyinc.com> wrote: > > >The GRS ring (not star) for a small site with 3 LPARs should have no > problem with > >any slowdowns, and it will allow you to run fully shared PDS/e, catalogs, > etc. > > -- > 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: Origin of the name of sample programs DSNTEP2/4?
OK, so you are suggesting "DSN" as the prefix, "T" for Test or Training in the fourth position, something else for the fifth character (or maybe Tx as a 2-character meaning of some kind in 4 and 5), and A/C/P for the language in the sixth position. I can see that as a reasonable explanation. Would be nice if IBM revealed their naming convention somewhere, like maybe in the sample library itself? Thanks for your insight. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bernd Oppolzer Sent: Monday, November 28, 2022 5:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Origin of the name of sample programs DSNTEP2/4? Hello Peter, IMO, the P in the name DSNTEP2 is because it is written in PL/1. There are some other sample programs like DSNTIAD and DSNTIAUL, which are written in ASSEMBLER, that's why IMO the 6th letter depends on the programming language. DSNTIAUL is heavily used at my customer's site to do unloads of SQL results for archiving and testcase construction purposes. BTW, I wrote a replacement for DSNTEP2 and DSNTIAUL, which does the same as the two programs do and much more, but I wrote it in C. It also runs on the non-mainframe platforms and there exists a version for Oracle, as well. And because it also supports Load (not only Unload, like DSNTIAUL), it can be used to transfer data between all flavors of DB2 and Oracle, on all platforms :-) This is great for everyone who wants to do ETL jobs on sites with a mix of DB2 and Oracle databases. If you want to know more, call me offline. Kind regards Bernd Am 28.11.2022 um 23:37 schrieb Farley, Peter: > Cross posted to IBM-MAIN. > > I asked this question earlier today over on DB2-L (the one run by IDB2UG), > but it later occurred to me that someone here might also know the answer to > my question. > > Peter > > _ > From: Farley, Peter > Sent: Monday, November 28, 2022 3:08 PM > To: idb2ug-d...@connectedcommunity.org > Subject: Origin of the name of sample programs DSNTEP2/4? > > > Just a question of curiosity - Does anyone know where the names for the DB2 > PLI sample programs DSNTEP2 and DSNTEP4 came from? Is it as simple as (DB2 > prefix DSN) + (TEst Program 2/4)? > > Also, if anyone is interested I have a modified copy of DSNTEP2 that > implements full PARM/PARMDD processing (up to the PARMDD max of 32760) for > all "functional comment" overrides and a new SYSDATA option that writes all > SELECT output to a new file with just one record per returned row and a > single instance of the column headings (suitable for post-processing into CSV > or other formats). Write to me **privately** please (pjfarley3 at earthlink > dot net) and not to this list or to this work email address if you are > interested. > > I would contribute the changes to CBTTAPE.ORG but the original DSNTEP2 code > is copyrighted by IBM. > > Peter -- 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: Origin of the name of sample programs DSNTEP2/4?
Hello Peter, IMO, the P in the name DSNTEP2 is because it is written in PL/1. There are some other sample programs like DSNTIAD and DSNTIAUL, which are written in ASSEMBLER, that's why IMO the 6th letter depends on the programming language. DSNTIAUL is heavily used at my customer's site to do unloads of SQL results for archiving and testcase construction purposes. BTW, I wrote a replacement for DSNTEP2 and DSNTIAUL, which does the same as the two programs do and much more, but I wrote it in C. It also runs on the non-mainframe platforms and there exists a version for Oracle, as well. And because it also supports Load (not only Unload, like DSNTIAUL), it can be used to transfer data between all flavors of DB2 and Oracle, on all platforms :-) This is great for everyone who wants to do ETL jobs on sites with a mix of DB2 and Oracle databases. If you want to know more, call me offline. Kind regards Bernd Am 28.11.2022 um 23:37 schrieb Farley, Peter: Cross posted to IBM-MAIN. I asked this question earlier today over on DB2-L (the one run by IDB2UG), but it later occurred to me that someone here might also know the answer to my question. Peter _ From: Farley, Peter Sent: Monday, November 28, 2022 3:08 PM To: idb2ug-d...@connectedcommunity.org Subject: Origin of the name of sample programs DSNTEP2/4? Just a question of curiosity - Does anyone know where the names for the DB2 PLI sample programs DSNTEP2 and DSNTEP4 came from? Is it as simple as (DB2 prefix DSN) + (TEst Program 2/4)? Also, if anyone is interested I have a modified copy of DSNTEP2 that implements full PARM/PARMDD processing (up to the PARMDD max of 32760) for all "functional comment" overrides and a new SYSDATA option that writes all SELECT output to a new file with just one record per returned row and a single instance of the column headings (suitable for post-processing into CSV or other formats). Write to me **privately** please (pjfarley3 at earthlink dot net) and not to this list or to this work email address if you are interested. I would contribute the changes to CBTTAPE.ORG but the original DSNTEP2 code is copyrighted by IBM. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Origin of the name of sample programs DSNTEP2/4?
Cross posted to IBM-MAIN. I asked this question earlier today over on DB2-L (the one run by IDB2UG), but it later occurred to me that someone here might also know the answer to my question. Peter _ From: Farley, Peter Sent: Monday, November 28, 2022 3:08 PM To: idb2ug-d...@connectedcommunity.org Subject: Origin of the name of sample programs DSNTEP2/4? Just a question of curiosity - Does anyone know where the names for the DB2 PLI sample programs DSNTEP2 and DSNTEP4 came from? Is it as simple as (DB2 prefix DSN) + (TEst Program 2/4)? Also, if anyone is interested I have a modified copy of DSNTEP2 that implements full PARM/PARMDD processing (up to the PARMDD max of 32760) for all "functional comment" overrides and a new SYSDATA option that writes all SELECT output to a new file with just one record per returned row and a single instance of the column headings (suitable for post-processing into CSV or other formats). Write to me **privately** please (pjfarley3 at earthlink dot net) and not to this list or to this work email address if you are interested. I would contribute the changes to CBTTAPE.ORG but the original DSNTEP2 code is copyrighted by IBM. Peter -- 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: Bytes in a 3390 track
On Wed, 23 Nov 2022 16:56:42 -0800, Leonard D Woren wrote: >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, Except that IEBCOPY also knows about splitting TXT records, and it will do so to maximize track usage. -- Tom Marchant -- 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
PDSE sharing is only supported within a Sysplex. XCF signalling is required to maintain integrity. When you say that PDSEs can be fully shared, I think you are referring to Extended Sharing, not Normal Sharing. Following is from https://www.ibm.com/docs/en/zos/2.4.0?topic=neps-specifying-extended-pdse-sharing-in-multiple-system-environment but it has been this way for a very long time. In a multiple-system environment, the system programmer uses PDSESHARING(EXTENDED) to share PDSEs at the member level. A system programmer must specify PDSESHARING(EXTENDED) in the IGDSMSxx member in the SYS1.PARMLIB on each system in the sysplex. Every system that is sharing a PDSE must be a member of the sysplex and have the sysplex coupling facility (XCF) active. People have violated these rules and gotten away with it, but that does not mean that it is safe to do so. -- Tom Marchant On Fri, 25 Nov 2022 20:00:42 -0600, Brian Westerman wrote: >The GRS ring (not star) for a small site with 3 LPARs should have no problem >with >any slowdowns, and it will allow you to run fully shared PDS/e, catalogs, etc. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whether MSGFLD handle IOS050I,SUP(NO) in MPFLST.
During normal activity the processing of the IOS050I message will be governed by the MPFLSTxx setting which in your case means it will not be suppressed. If Message Flood Automation detects that the IOS050I is part of a flood then the MSGLFDxx settings will take effect - in your case the message would be deleted. Peter Fatzinger z/OS Core Design & Development -- 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). Does the same processing apply to RESTORE? Or does it always build from scratch? On Mon, Nov 28, 2022 at 9:21 AM Kurt J. Quackenbush wrote: > During APPLY processing SMP/E may or may not include the existing load > module when replacing MODs. If the load module does not actually exist in > the target library, or if the LMOD entry has any CALLLIBS subentries, then > the load module is constructed from scratch, including all of the MODs > defined for that LMOD, but not including the existing load module. If the > load module exists in the target library and if the LMOD entry does not > have any CALLLIBS subentries, then the existing load module from the target > library is included, along with the MODs from the PTFs being applied. > > When building a load module from scratch, one or more of the MODs are > replaced/added by PTFs being applied, but SMP/E searches for the other MODs > using the logic documented here: > https://www.ibm.com/docs/en/zos/2.5.0?topic=commands-building-load-modules > Briefly, in this order, SMP/E gets the MODs from the target libraries if > it can find a usable copy, or from the DLIBs if the correct service level > has been accepted, or from PTFs in the SMPPTS. > > 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 > -- Jay Maynard -- 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?
During APPLY processing SMP/E may or may not include the existing load module when replacing MODs. If the load module does not actually exist in the target library, or if the LMOD entry has any CALLLIBS subentries, then the load module is constructed from scratch, including all of the MODs defined for that LMOD, but not including the existing load module. If the load module exists in the target library and if the LMOD entry does not have any CALLLIBS subentries, then the existing load module from the target library is included, along with the MODs from the PTFs being applied. When building a load module from scratch, one or more of the MODs are replaced/added by PTFs being applied, but SMP/E searches for the other MODs using the logic documented here: https://www.ibm.com/docs/en/zos/2.5.0?topic=commands-building-load-modules Briefly, in this order, SMP/E gets the MODs from the target libraries if it can find a usable copy, or from the DLIBs if the correct service level has been accepted, or from PTFs in the SMPPTS. 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: To share or not to share DASD
Classification: Confidential I would share devices at the physical level (all devices can be brought online to any LPAR) I would not share those devices at the logical level (all devices are offline where not normally used). HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ituriel do Neto Sent: Friday, November 25, 2022 6:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: To share or not to share DASD [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hi, In the past, i used to work for a tiny shop with the same distribution you indicated. Only three Lpars and no Sysplex, no GRS. At that time, we choose to make all disks available to all Lpars, but there was a segregation of Production, Development, and Sysprog volumes done by VOLSER. I don't remember the details anymore, but shared disks were labeled as SHR*, Production and development disks as PRD* and DEV*, and of course SYSRES, Page, spool, etc... At IPL time, a small program was executed, searching all volumes and issuing V OFFLINE to those that do not belong to the appropriated Lpar. This program used wildcard masks to select what should remain ONLINE. And, of course, MVS commands were protected in RACF, so only authorized userids can VARY ONLINE a volume. It worked well for us, in this reality. Best Regards Ituriel do Nascimento Neto z/OS System Programmer Em sexta-feira, 25 de novembro de 2022 02:38:47 BRT, Joel C. Ewing escreveu: But its not just a case of whether you trust they will not intentionally damage something, but the ease of accidentally causing integrity problems by not knowing when others have touched catalogs, volumes, or datasets on DASD that is physically shared but not known to be shared by the Operating System. If many people are involved, the coordination procedures involved to prevent damage, assuming such procedures are even feasible, are a disaster waiting to happen. If volumes are SMS, all datasets must be cataloged and the associated catalogs must be accessed from any system that accesses those datasets. If the systems are not in a relationship that enables proper catalog sharing, access and possible modification of the catalog from multiple systems causes the cached versions of catalog data to become out of sync with actual content on the drive when the catalog is altered from a different system, and there is a high probability the catalog will become corrupted on all systems. Auditors are justified in being concerned whether independent RACF databases on multiple systems will always be in sync to properly protect production datasets from unintentional access or unauthorized access if test LPARs share access to production volumes. There should always be multiple barriers to doing something bad because accidents happen -- like forgetting to change a production dataset name in what was intended to be test JCL. There are just two many bad things that can happen if you try to share things that are only designed for sharing within a sysplex. The only relatively safe way to do this across independent LPARs is non-concurrently: have a set of volumes and a catalog for HLQ's of just the datasets on those volumes that is also located on one of those volumes, and only have those volumes on-line to one system at a time and close, and deallocate all datasets and the catalog on those volumes before taking them offline to move them to a different system. A much simpler and safer solution is to not share DASD volumes across LPARs not in the same sysplex, to maintain a unique copy of datasets on systems where they are needed, and to use a high-speed communication link between the LPARs to transmit datasets from one system to another when there is a need to resync those datasets from a production LPAR. Joel C Ewing On 11/24/22 21:38, Farley, Peter wrote: > Not necessarily true in a software development environment where all members > of the team need to share all their data everywhere. "Zero trust" is > anathema in a development environment. > > If you don't trust me then fire me. It's cleaner that way. > > Shakespeare was *almost* right. First get rid of all the auditors, *then* > get rid of all the lawyers. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Lennie Dymoke-Bradshaw > Sent: Thursday, November 24, 2022 5:24 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: To share or not to share DASD > > If you were asking in a security context, I would advise against it in nearly > all cases. > Auditors will not like that a system's data can be accessed without reference > to the RACF (or ACF2, or TSS) system that is supposed to protect it. > > Lennie Dymoke-Bradshaw > > -Original Message- > From: IBM Mainframe
