Re: Two Processors and One IODF
To get the IODF across... what you'd need to do depends on who manages DR at the other side: if it's you, setup an email job on your primary system to email you the IOCP when a new config is activated. If it's IBM or some such, setup an email job on your primary system to email the vendor/partner the IOCP when a new config is activated. - KB ‐‐‐ Original Message ‐‐‐ On Saturday, July 11, 2020 10:51 AM, kekronbekron <02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > The trouble with using same CU and units at both sites is ... unnecessary > risk of varying/initializing a unit on the wrong side. Could be a major > whoopsie. > Best to use a few ranges on this side, and a few ranges on the other, so it's > very easy to know what's where. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Friday, July 10, 2020 11:49 PM, Michael Babcock bigironp...@gmail.com > wrote: > > > > We are in the process of bringing DR back in-house and have a new > > z15-T02 in our new facility (our current "home" machine is a z14-ZR1). > > I want to be able to manage both processors from a single IODF. I'd > > like to have the same CHPIDs, CUs, and Device addresses both at home and > > in our DR machine. I have the new processor defined in our current > > IODF and have used the CHPID mapping tool to map the PCHIDs to CHPIDs. > > I have tested adding devices with the same address to both processors > > and that seems to work (as long as I define the CUs to both processors > > first. I tested adding a range of 16 tape drives). > > My questions are this: > > 1. Is this something we even want to do (same IODF, same device addresses)? > > 2. What's the best way to move the IODF at home to the DR machine? > > 3. Are there any gotchas we need to watch out for? > > 4. We have IBM DS8886s and are using Metro Global Mirror Multi-Target > > w/Practice. Any concerns here? > > 5. Am I crazy for even entertaining this idea? > > 6. Any alternatives I need to consider? > > > > 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: Two Processors and One IODF
The trouble with using same CU and units at both sites is ... unnecessary risk of varying/initializing a unit on the wrong side. Could be a major whoopsie. Best to use a few ranges on this side, and a few ranges on the other, so it's very easy to know what's where. - KB ‐‐‐ Original Message ‐‐‐ On Friday, July 10, 2020 11:49 PM, Michael Babcock wrote: > We are in the process of bringing DR back in-house and have a new > z15-T02 in our new facility (our current "home" machine is a z14-ZR1). > I want to be able to manage both processors from a single IODF. I'd > like to have the same CHPIDs, CUs, and Device addresses both at home and > in our DR machine. I have the new processor defined in our current > IODF and have used the CHPID mapping tool to map the PCHIDs to CHPIDs. > I have tested adding devices with the same address to both processors > and that seems to work (as long as I define the CUs to both processors > first. I tested adding a range of 16 tape drives). > > My questions are this: > > 1. Is this something we even want to do (same IODF, same device addresses)? > > 2. What's the best way to move the IODF at home to the DR machine? > > 3. Are there any gotchas we need to watch out for? > > 4. We have IBM DS8886s and are using Metro Global Mirror Multi-Target > w/Practice. Any concerns here? > > 5. Am I crazy for even entertaining this idea? > > 6. Any alternatives I need to consider? > > -- > > 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: Any interest in PSD I/O for REXX?
Hi, Seymour, I just saw this thread ... Have you looked at using the Subsystem Interface for this? Take a look at GPSAM by Howard Gilbert at Yale ... on the CBT tapes. You might only need to issue DYNALLOC with the SUBSYS= parameter specified, to point to the desired DSN and member name ...? Just a thought ... All the best, Mark S. Waterbury -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HCD graphics report format
What is it MOD-3 support? LOGMODE is important. Once you get it up and cookin' one of the options is convert to PS. Seems like poa annua trivialis but you can feed that data into Auto-CAD and use a plotter to amaze the PHB's. In a message dated 7/10/2020 10:07:20 PM Central Standard Time, pinnc...@rochester.rr.com writes: You will need GDDM, and a TN3270 emulator capable of displaying host graphics. It's cool when it works, but you will have to scroll up, down, right, left to see your whole layout. A huge screen would help. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Silly ISMF question
I think you need to clear the "Storage Group Name" and "CDS Name" fields when switching back from SMS to physical list. The field help for option 1 says those fields must be cleared. (put cursor on the 1 and hit F1). I checked this on an internal test system and recreated both the symptom of the volumes missing from the list, and a full list with those fields cleared. Hope this resolves it. David Shackelford IBM DFSMS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
The posted data shows only one alias. Did you truncate the listing? As long as both alaii point to the same ucat, I am mystified. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bruce Lightsey Sent: Friday, July 10, 2020 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] [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.] So - READY listcat alias all cat(catalog.vmvsmca) LISTING FROM CATALOG -- CATALOG.VMVSMCA ALIAS - AC HISTORY RELEASE2 CREATION2017.186 ENCRYPTIONDATA DATA SET ENCRYPTION-(NO) ASSOCIATIONS USERCAT--CATALOG.VDSK204 I selected a couple of dozen aliases and verified that the datasets created - such as AC.PROD.PH.P37806.D2020191 (created yesterday) - are cataloged to the expected usercat. The ones I checked all seem to be correct. There are also a few aliases and 2 usercats that need to go away since those applications have been moved away and the z/OS version decommissioned. Different issue but it is interesting what one can learn by poking around in places where one doesn't normally venture. -Original Message- Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.its.ms.gov%2F&data=02%7C01%7Callan.staller%40HCL.COM%7C9118cecdce22436255eb08d82501bf0c%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637300036728656871&sdata=opcVhAyPCU8OabZMZbhWxBpRhYC7CZsyxyQ8UA0LHQA%3D&reserved=0 DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Friday, July 10, 2020 12:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] You used an syntactically correct, but functionally incorrect version of the listcat command. The version you need is LIST ALIAS ALL CAT(mcatname). Verify the association in this catalog with the association on the system you can "see" the dataset. HTH, BTW. If there is any discrepancy, it may take a fair amount of work to resolve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Two Processors and One IODF
Comments/opinions interspersed -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Babcock Sent: Friday, July 10, 2020 1:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Two Processors and One IODF [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.] We are in the process of bringing DR back in-house and have a new z15-T02 in our new facility (our current "home" machine is a z14-ZR1). I want to be able to manage both processors from a single IODF. I'd like to have the same CHPIDs, CUs, and Device addresses both at home and in our DR machine. I have the new processor defined in our current IODF and have used the CHPID mapping tool to map the PCHIDs to CHPIDs. I have tested adding devices with the same address to both processors and that seems to work (as long as I define the CUs to both processors first. I tested adding a range of 16 tape drives). My questions are this: 1. Is this something we even want to do (same IODF, same device addresses)? --> The more alike your 2 machines are the less chance for error. This can be done with 1 IODF, but is not required. See #2 2. What's the best way to move the IODF at home to the DR machine? --> I use 2 series of IODF's 01-04 for the production image 91-94 for the DR image. Corresponding to the IODF. IODF changes are made in parallel to both copies. The IODF is moved from local to DR by a flash copy of the IODF volume. 3. Are there any gotchas we need to watch out for? --> Can't think of any except to remember to keep both configurations "in sync" 4. We have IBM DS8886s and are using Metro Global Mirror Multi-Target w/Practice. Any concerns here? -->No opinion. 5. Am I crazy for even entertaining this idea? --> Nope. Makes sense to me 6. Any alternatives I need to consider? --> Others may offer some. I am of a very similar mindset to yours. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HCD graphics report format
HCM provides a very usable pictorial view of an IODF. No graphics software required. We now use HCM exclusively for IO config management. You get way more than a picture. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Conley Sent: Friday, July 10, 2020 6:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: HCD graphics report format CAUTION EXTERNAL EMAIL On 7/10/2020 8:04 PM, Steve Horein wrote: > I think you need GDDM. > > On Fri, Jul 10, 2020 at 5:32 PM Pew, Curtis G > > wrote: > >> I was doing some updates in HCD and noticed the graphics report >> function, so I tried it. The output looks like input to groff or some >> such. Does anyone know what I would need to use to transform it into >> something human-viewable? My google-fu hasn’t worked so far. >> >> >> -- >> Pew, Curtis G >> curtis@austin.utexas.edu >> Curtis, You will need GDDM, and a TN3270 emulator capable of displaying host graphics. It's cool when it works, but you will have to scroll up, down, right, left to see your whole layout. A huge screen would help. 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: HCD graphics report format
On 7/10/2020 8:04 PM, Steve Horein wrote: I think you need GDDM. On Fri, Jul 10, 2020 at 5:32 PM Pew, Curtis G wrote: I was doing some updates in HCD and noticed the graphics report function, so I tried it. The output looks like input to groff or some such. Does anyone know what I would need to use to transform it into something human-viewable? My google-fu hasn’t worked so far. -- Pew, Curtis G curtis@austin.utexas.edu Curtis, You will need GDDM, and a TN3270 emulator capable of displaying host graphics. It's cool when it works, but you will have to scroll up, down, right, left to see your whole layout. A huge screen would help. 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: PDS/e Encryption
I opened a ticket with IBM PDS/e support on this. They're talking with SMS to see if anything can be done. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Friday, July 10, 2020 9:01 AM, Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > In this case we're not encrypting for the purpose of securing the execution > of program objects, we need to have those datasets encrypted on our backup > tapes. Our virtual tape technology solution doesn't support encrypting of > data on the virtual tape, just on the backend storage, which isn't sufficient > for our needs. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > On Friday, July 10, 2020 8:53 AM, Edgington, Jerry > jerry.edging...@westernsouthernlife.com wrote: > > > Mark, > > Are the PDS/e contain load modules?? If so, there is a way to secure the > > load modules, instead of the PDS/e, include COBOL. > > Jerry > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > > Mark Jacobs > > Sent: Friday, July 10, 2020 8:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: PDS/e Encryption > > This message was sent from an external source outside of Western & > > Southern's network. Do not click links or open attachments unless you > > recognize the sender and know the contents are safe. > > We have a requirement to encrypt a certain class of mainframe data. While > > looking at doing so for PDS/e datasets (available with z/OS 2.4 and with > > PTFs on 2,2 and 2.3), I've run into a quandary. Storing program objects in > > an encrypted PDS/e isn't supported. > > I'm looking at the read-only ACS variables to see if I can ascertain > > whether a PDS/e will be storing program objects so I can bypass assigning > > our encryption dataclas, and there's nothing obvious for me to use. > > Has anyone come up with a solution for this? > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.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 > > -- > > 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: HCD graphics report format
I think you need GDDM. On Fri, Jul 10, 2020 at 5:32 PM Pew, Curtis G wrote: > I was doing some updates in HCD and noticed the graphics report function, > so I tried it. The output looks like input to groff or some such. Does > anyone know what I would need to use to transform it into something > human-viewable? My google-fu hasn’t worked so far. > > > -- > Pew, Curtis G > curtis@austin.utexas.edu > > > > > > > -- > 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: Confirm or deny existence of old masking password?
This is guesswork. If you allow lowercase passwords, the ubiquitous uppercase translation from password entry to RACF verification is bypassed. I would look at system option 5.1 in the RACF dialog. Look for a statement like this: MIXED CASE PASSWORD SUPPORT IS NOT IN EFFECT This option causes user entered password to translate to uppercase. If it says something like 'is in effect', then uppercase translation is not in effect, so if user enters lowercase, that will get passed ASIS to RACF and fail verification. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Friday, July 10, 2020 1:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Confirm or deny existence of old masking password? CAUTION EXTERNAL EMAIL I believed hat all our passwords were at least DES. Recenly upgraded sandbox z/OS 2.1 to z/OS 2.3. Now getting: IRR013I VERIFICATION FAILED. INVALID PASSWORD GIVEN. For an job submitted via an STC with userid and password on the JOB card. Works fine in z/OS 2.1 Is there some way I can confirm that z/OS 2.3 is failing this because the password is sill a "masking" password? Cross-posted RACF-L and IBM-MAIN Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
HCD graphics report format
I was doing some updates in HCD and noticed the graphics report function, so I tried it. The output looks like input to groff or some such. Does anyone know what I would need to use to transform it into something human-viewable? My google-fu hasn’t worked so far. -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confirm or deny existence of old masking password?
I believed hat all our passwords were at least DES. Recenly upgraded sandbox z/OS 2.1 to z/OS 2.3. Now getting: IRR013I VERIFICATION FAILED. INVALID PASSWORD GIVEN. For an job submitted via an STC with userid and password on the JOB card. Works fine in z/OS 2.1 Is there some way I can confirm that z/OS 2.3 is failing this because the password is sill a "masking" password? Cross-posted RACF-L and IBM-MAIN Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL EMAIL: Two Processors and One IODF
This is a perfectly reasonable goal. We've done it as well for decades. When we merged two IODFs (one per data center), we faced the issue of duplicate device addresses, which had evolved because, with two separate IO configs (even pre-IODF), it didn't matter much. With a single IODF, most devices *must* have unique addresses, especially DASD and tape. We had to readdress some devices in order to avoid duplicates. Consoles do not have to be unique because you connect them to some LPARs and not to others. So in both data centers, we have a console defined as 01234, but 'it' represents two different physical devices. No conflict. With DASD and tape, however, you should address every one uniquely. I highly recommend combining IODFs. You get a single representation of your entire enterprise. We used to have a problem keeping multiple IO configs in synch. With a single IODF, no problem. As to moving an IODF, we maintain a single IODF on one system and use a built-in migration process in HCD to send it to others LPARs. Every system uses an identical copy with the same name. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jerry Whitteridge Sent: Friday, July 10, 2020 11:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: EXTERNAL EMAIL: Two Processors and One IODF CAUTION EXTERNAL EMAIL We maintain 3 processors and a CF across 2 datacenters in the same IODF. If you want to be able to see a complete view of all of your devices and connections across all of your raised floor it’s the only way to do so I believe. It also allows us to maintain our DR configuration in sync with everything else. Jerry Whitteridge Manager Mainframe Systems & HP Non-Stop Albertsons Companies -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Babcock Sent: Friday, July 10, 2020 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL EMAIL: Two Processors and One IODF We are in the process of bringing DR back in-house and have a new z15-T02 in our new facility (our current "home" machine is a z14-ZR1). I want to be able to manage both processors from a single IODF. I'd like to have the same CHPIDs, CUs, and Device addresses both at home and in our DR machine. I have the new processor defined in our current IODF and have used the CHPID mapping tool to map the PCHIDs to CHPIDs. I have tested adding devices with the same address to both processors and that seems to work (as long as I define the CUs to both processors first. I tested adding a range of 16 tape drives). My questions are this: 1. Is this something we even want to do (same IODF, same device addresses)? 2. What's the best way to move the IODF at home to the DR machine? 3. Are there any gotchas we need to watch out for? 4. We have IBM DS8886s and are using Metro Global Mirror Multi-Target w/Practice. Any concerns here? 5. Am I crazy for even entertaining this idea? 6. Any alternatives I need to consider? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
So - READY listcat alias all cat(catalog.vmvsmca) LISTING FROM CATALOG -- CATALOG.VMVSMCA ALIAS - AC HISTORY RELEASE2 CREATION2017.186 ENCRYPTIONDATA DATA SET ENCRYPTION-(NO) ASSOCIATIONS USERCAT--CATALOG.VDSK204 I selected a couple of dozen aliases and verified that the datasets created - such as AC.PROD.PH.P37806.D2020191 (created yesterday) - are cataloged to the expected usercat. The ones I checked all seem to be correct. There are also a few aliases and 2 usercats that need to go away since those applications have been moved away and the z/OS version decommissioned. Different issue but it is interesting what one can learn by poking around in places where one doesn't normally venture. -Original Message- Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | www.its.ms.gov DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Friday, July 10, 2020 12:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] You used an syntactically correct, but functionally incorrect version of the listcat command. The version you need is LIST ALIAS ALL CAT(mcatname). Verify the association in this catalog with the association on the system you can "see" the dataset. HTH, BTW. If there is any discrepancy, it may take a fair amount of work to resolve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL EMAIL: Two Processors and One IODF
We maintain 3 processors and a CF across 2 datacenters in the same IODF. If you want to be able to see a complete view of all of your devices and connections across all of your raised floor it’s the only way to do so I believe. It also allows us to maintain our DR configuration in sync with everything else. Jerry Whitteridge Manager Mainframe Systems & HP Non-Stop Albertsons Companies -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Babcock Sent: Friday, July 10, 2020 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL EMAIL: Two Processors and One IODF We are in the process of bringing DR back in-house and have a new z15-T02 in our new facility (our current "home" machine is a z14-ZR1). I want to be able to manage both processors from a single IODF. I'd like to have the same CHPIDs, CUs, and Device addresses both at home and in our DR machine. I have the new processor defined in our current IODF and have used the CHPID mapping tool to map the PCHIDs to CHPIDs. I have tested adding devices with the same address to both processors and that seems to work (as long as I define the CUs to both processors first. I tested adding a range of 16 tape drives). My questions are this: 1. Is this something we even want to do (same IODF, same device addresses)? 2. What's the best way to move the IODF at home to the DR machine? 3. Are there any gotchas we need to watch out for? 4. We have IBM DS8886s and are using Metro Global Mirror Multi-Target w/Practice. Any concerns here? 5. Am I crazy for even entertaining this idea? 6. Any alternatives I need to consider? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Two Processors and One IODF
We are in the process of bringing DR back in-house and have a new z15-T02 in our new facility (our current "home" machine is a z14-ZR1). I want to be able to manage both processors from a single IODF. I'd like to have the same CHPIDs, CUs, and Device addresses both at home and in our DR machine. I have the new processor defined in our current IODF and have used the CHPID mapping tool to map the PCHIDs to CHPIDs. I have tested adding devices with the same address to both processors and that seems to work (as long as I define the CUs to both processors first. I tested adding a range of 16 tape drives). My questions are this: 1. Is this something we even want to do (same IODF, same device addresses)? 2. What's the best way to move the IODF at home to the DR machine? 3. Are there any gotchas we need to watch out for? 4. We have IBM DS8886s and are using Metro Global Mirror Multi-Target w/Practice. Any concerns here? 5. Am I crazy for even entertaining this idea? 6. Any alternatives I need to consider? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
digicert urgent action
This just came out on July 8th, if you have an EV certs, they will be revoked on July 11th https://knowledge.digicert.com/alerts/DigiCert-ICA-Replacement DigiCert ICA Replacement URGENT Description DigiCert has identified an issue where some of our intermediate CAs (ICAs) were not listed as part of our most recent WebTrust EV audit. To resolve the issue, we are replacing the affected ICAs for EV only. OV and DV certificates are unaffected by these changes. Solution We are taking precautionary measures, and retiring and replacing these ICAs for EV certificates: We are retiring these ICAs: • DigiCert Global CA G2 • GeoTrust TLS RSA CA G1 • Secure Site CA • Thawte TLS RSA CA G1 • Cybertrust Japan Secure Server ECC CA • DigiCert Global CA G3 • GeoTrust TLS ECC CA G1 • Thawte TLS ECC CA G1 • NCC Group Secure Server CA G3 • Aetna Inc. Secure CA2 • DigiCert SHA2 High Assurance Server CA • NCC Group Secure Server CA G2 • Plex Devices High Assurance CA2 • TERENA SSL High Assurance CA 3 Our retired ICAs will be replaced with new ICAs: • DigiCert EV RSA CA G2 • GeoTrust EV RSA CA G2 • Thawte EV RSA CA G2 Who does this affect? This change affects customers who have issued EV certificates using these chains from: • CertCentral • Symantec • Thawte • GeoTrust This also affects customers: • with CA over-rides • who have pinned to a ICA that has been identified for retirement Please Note: Although there is no security threat, we are required by the EV Guidelines to revoke your EV certificates by July 11, 2020 at 12 pm MDT (July 11, 18:00 UTC). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Free Mainframe Stuff 2020: Reply Here with Nominations
We have people using our free WLM to HTML tool pretty much every day: https://www.pivotor.com/wlm2html.html There is also a free tier to our Pivotor performance reporting service as well: https://www.pivotor.com/freeTier.html We also do free cursory performance reviews and of course do regular free webinars as well. Scott Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
You used an syntactically correct, but functionally incorrect version of the listcat command. The version you need is LIST ALIAS ALL CAT(mcatname). Verify the association in this catalog with the association on the system you can "see" the dataset. HTH, BTW. If there is any discrepancy, it may take a fair amount of work to resolve, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bruce Lightsey Sent: Friday, July 10, 2020 11:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] [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.] A lot of entries come back : READY listcat alias all LISTING FROM CATALOG -- CATALOG.VMVSMCA ALIAS - AC HISTORY RELEASE2 CREATION2017.186 ENCRYPTIONDATA DATA SET ENCRYPTION-(NO) ASSOCIATIONS USERCAT--CATALOG.VDSK204 . . . The master catalog is vmvsmca and there seem to be about 8 - 10 usercats for the various aliases. -Original Message- Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.its.ms.gov%2F&data=02%7C01%7Callan.staller%40HCL.COM%7C884f9d4056b441c9c35508d824eba008%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637299941733466921&sdata=OsTlIwzVoADWiiz32cZBIv1kcV8DI%2BmZ0S4KSq0tzs8%3D&reserved=0 DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Friday, July 10, 2020 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] Try IDCAMS command LISTCAT ALIAS ALL. If you try it under TSO then you need to do PROFILE NOPREFIX first. https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fpages%2Fidcams-listc-alias-all-under-tso&data=02%7C01%7Callan.staller%40HCL.COM%7C884f9d4056b441c9c35508d824eba008%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637299941733466921&sdata=Ml2cXlqhGGsX%2Ffj%2BAGLbqhywGcTFSu%2Bkvt1PNKo6U%2BI%3D&reserved=0 On Fri, Jul 10, 2020 at 3:22 PM Bruce Lightsey wrote: > > Slight (or major) correction Kirk - datasets cataloged in the master catalog > return correctly. Any dataset in any user catalog is "not found". > > I can, for example, find the SYS1.CPU1.VTAMLST dataset that is cataloged in > the master catalog CATALOG.VMVSMCA but I cannot find CCITS.DATACOM.R12.MSG015 > in catalog CATALOG.VSYS023 or PH.PROD.PR731P.RW.P0703.FILE08 in catalog > CATALOG.VDSK204 or any other dataset cataloged in any user catalog. > > > > > Bruce Lightsey > Database Manager > MS Department of Information Technology Services > 601-432-8144 | > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.i > ts.ms.gov%2F&data=02%7C01%7Callan.staller%40HCL.COM%7C884f9d4056b4 > 41c9c35508d824eba008%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C6372 > 99941733466921&sdata=OsTlIwzVoADWiiz32cZBIv1kcV8DI%2BmZ0S4KSq0tzs8 > %3D&reserved=0 > > DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or > entity to whom they are addressed. If you have received this email in > error please notify the system manager. This message contains > confidential information and is intended only for the individual > named. If you are not the named addressee you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately > by e-mail if you have received this e-mail by mistake and delete this > e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action > in reliance on the contents of this information is strictly prohibited > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Kirk Wolf > Sent: Friday, July 10, 2020 9:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: potential catalog search error - shown by IGGCSI00 > [EXTERNAL] > > On Thu
Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
Or, if not, I would hope the OP would be getting a zillion "unauthorized" messages from people trying to update the master catalog. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bruce Lightsey Sent: Friday, July 10, 2020 11:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] If not, I would presume that the catalogs that are in daily use would show errors - or the new datasets would be cataloged to the master instead of the usercats Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | www.its.ms.gov DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gorham, Steve Sent: Friday, July 10, 2020 10:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] Are the usercats still connected? Steve Gorham steve.gor...@ssa.gov -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, July 10, 2020 11:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] Are the ALIASs blown? On 2020-07-10 11:22, Bruce Lightsey wrote: > Slight (or major) correction Kirk - datasets cataloged in the master catalog > return correctly. Any dataset in any user catalog is "not found". > > I can, for example, find the SYS1.CPU1.VTAMLST dataset that is cataloged in > the master catalog CATALOG.VMVSMCA but I cannot find CCITS.DATACOM.R12.MSG015 > in catalog CATALOG.VSYS023 or PH.PROD.PR731P.RW.P0703.FILE08 in catalog > CATALOG.VDSK204 or any other dataset cataloged in any user catalog. > > > > > Bruce Lightsey > Database Manager > MS Department of Information Technology Services > 601-432-8144 | > https://protect2.fireeye.com/v1/url?k=15a42de1-49321b02-15a40496-0cc47 > adc5fec-dbcfd351dd864ace&q=1&e=5acc5257-4765-4ff2-b631-7610e1f02fc1&u= > https%3A%2F%2Fapc01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%2 > 53A%252F%252Fwww.its.ms.gov%252F%26amp%3Bdata%3D02%257C01%257C%257Cc20 > ba429ef0e4517255f08d824e51736%257C84df9e7fe9f640afb435%257 > C1%257C0%257C637299913653415409%26amp%3Bsdata%3DhVbYEVxYZ%252BY7xqxrth > C6GkLCreItpCz08GDmgOZXO5U%253D%26amp%3Breserved%3D0 > > DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or > entity to whom they are addressed. If you have received this email in > error please notify the system manager. This message contains > confidential information and is intended only for the individual > named. If you are not the named addressee you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately > by e-mail if you have received this e-mail by mistake and delete this > e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action > in reliance on the contents of this information is strictly prohibited > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Kirk Wolf > Sent: Friday, July 10, 2020 9:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: potential catalog search error - shown by IGGCSI00 > [EXTERNAL] > > On Thu, Jul 9, 2020 at 4:14 PM Feller, Paul < > 02fc94e14c43-dmarc-requ...@listserv.ua.edu> wrote: > >> This all sounds like similar behavior of the option in 3.4 called >> "Include Additional Qualifiers". If you don't set the option on you >> have to wild card your dataset list. With the option set on you >> don't have to use wild card to get a dataset list. >> >> All the code I've ever written using IGGCSI00 I've had to use wild >> cards to get the list of datasets I wanted. In the manual they talk >> about how the use of wild cards or no wild cards will affect the output from >> IGGCSI00. >> >> >> I'm not sure what you are referring to in the IGGCSI00 documentation. >> The > first paragraph says: > > > *"The generic filter key can be a fully-qualified entry name, in which case > one entry is returned, or the generic filter key can contain "wild cards" > so thatmultiple
Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
If not, I would presume that the catalogs that are in daily use would show errors - or the new datasets would be cataloged to the master instead of the usercats Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | www.its.ms.gov DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gorham, Steve Sent: Friday, July 10, 2020 10:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] Are the usercats still connected? Steve Gorham steve.gor...@ssa.gov -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, July 10, 2020 11:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] Are the ALIASs blown? On 2020-07-10 11:22, Bruce Lightsey wrote: > Slight (or major) correction Kirk - datasets cataloged in the master catalog > return correctly. Any dataset in any user catalog is "not found". > > I can, for example, find the SYS1.CPU1.VTAMLST dataset that is cataloged in > the master catalog CATALOG.VMVSMCA but I cannot find CCITS.DATACOM.R12.MSG015 > in catalog CATALOG.VSYS023 or PH.PROD.PR731P.RW.P0703.FILE08 in catalog > CATALOG.VDSK204 or any other dataset cataloged in any user catalog. > > > > > Bruce Lightsey > Database Manager > MS Department of Information Technology Services > 601-432-8144 | > https://protect2.fireeye.com/v1/url?k=15a42de1-49321b02-15a40496-0cc47 > adc5fec-dbcfd351dd864ace&q=1&e=5acc5257-4765-4ff2-b631-7610e1f02fc1&u= > https%3A%2F%2Fapc01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%2 > 53A%252F%252Fwww.its.ms.gov%252F%26amp%3Bdata%3D02%257C01%257C%257Cc20 > ba429ef0e4517255f08d824e51736%257C84df9e7fe9f640afb435%257 > C1%257C0%257C637299913653415409%26amp%3Bsdata%3DhVbYEVxYZ%252BY7xqxrth > C6GkLCreItpCz08GDmgOZXO5U%253D%26amp%3Breserved%3D0 > > DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or > entity to whom they are addressed. If you have received this email in > error please notify the system manager. This message contains > confidential information and is intended only for the individual > named. If you are not the named addressee you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately > by e-mail if you have received this e-mail by mistake and delete this > e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action > in reliance on the contents of this information is strictly prohibited > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Kirk Wolf > Sent: Friday, July 10, 2020 9:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: potential catalog search error - shown by IGGCSI00 > [EXTERNAL] > > On Thu, Jul 9, 2020 at 4:14 PM Feller, Paul < > 02fc94e14c43-dmarc-requ...@listserv.ua.edu> wrote: > >> This all sounds like similar behavior of the option in 3.4 called >> "Include Additional Qualifiers". If you don't set the option on you >> have to wild card your dataset list. With the option set on you >> don't have to use wild card to get a dataset list. >> >> All the code I've ever written using IGGCSI00 I've had to use wild >> cards to get the list of datasets I wanted. In the manual they talk >> about how the use of wild cards or no wild cards will affect the output from >> IGGCSI00. >> >> >> I'm not sure what you are referring to in the IGGCSI00 documentation. >> The > first paragraph says: > > > *"The generic filter key can be a fully-qualified entry name, in which case > one entry is returned, or the generic filter key can contain "wild cards" > so thatmultiple entries can be selected on a single invocation."* > > You can verify proper behavior with the following use of IBM's sample > REXX > program: > > READY > exec 'sys1.samplib(iggcsirx)' > ENTER FILTER KEY > MYHLQ.DSN > > On *one* of Bruce's LPARs, this fails for *any* dataset, even those cataloged > in the master catalog. > > > Kirk Wolf > Dovetailed Technologies > https:/
Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
A lot of entries come back : READY listcat alias all LISTING FROM CATALOG -- CATALOG.VMVSMCA ALIAS - AC HISTORY RELEASE2 CREATION2017.186 ENCRYPTIONDATA DATA SET ENCRYPTION-(NO) ASSOCIATIONS USERCAT--CATALOG.VDSK204 . . . The master catalog is vmvsmca and there seem to be about 8 - 10 usercats for the various aliases. -Original Message- Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | www.its.ms.gov DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Friday, July 10, 2020 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] Try IDCAMS command LISTCAT ALIAS ALL. If you try it under TSO then you need to do PROFILE NOPREFIX first. https://www.ibm.com/support/pages/idcams-listc-alias-all-under-tso On Fri, Jul 10, 2020 at 3:22 PM Bruce Lightsey wrote: > > Slight (or major) correction Kirk - datasets cataloged in the master catalog > return correctly. Any dataset in any user catalog is "not found". > > I can, for example, find the SYS1.CPU1.VTAMLST dataset that is cataloged in > the master catalog CATALOG.VMVSMCA but I cannot find CCITS.DATACOM.R12.MSG015 > in catalog CATALOG.VSYS023 or PH.PROD.PR731P.RW.P0703.FILE08 in catalog > CATALOG.VDSK204 or any other dataset cataloged in any user catalog. > > > > > Bruce Lightsey > Database Manager > MS Department of Information Technology Services > 601-432-8144 | www.its.ms.gov > > DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or > entity to whom they are addressed. If you have received this email in > error please notify the system manager. This message contains > confidential information and is intended only for the individual > named. If you are not the named addressee you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately > by e-mail if you have received this e-mail by mistake and delete this > e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action > in reliance on the contents of this information is strictly prohibited > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Kirk Wolf > Sent: Friday, July 10, 2020 9:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: potential catalog search error - shown by IGGCSI00 > [EXTERNAL] > > On Thu, Jul 9, 2020 at 4:14 PM Feller, Paul < > 02fc94e14c43-dmarc-requ...@listserv.ua.edu> wrote: > > > This all sounds like similar behavior of the option in 3.4 called > > "Include Additional Qualifiers". If you don't set the option on you > > have to wild card your dataset list. With the option set on you > > don't have to use wild card to get a dataset list. > > > > All the code I've ever written using IGGCSI00 I've had to use wild > > cards to get the list of datasets I wanted. In the manual they talk > > about how the use of wild cards or no wild cards will affect the output > > from IGGCSI00. > > > > > > I'm not sure what you are referring to in the IGGCSI00 documentation. > > The > first paragraph says: > > > *"The generic filter key can be a fully-qualified entry name, in which case > one entry is returned, or the generic filter key can contain "wild cards" > so thatmultiple entries can be selected on a single invocation."* > > You can verify proper behavior with the following use of IBM's sample > REXX > program: > > READY > exec 'sys1.samplib(iggcsirx)' > ENTER FILTER KEY > MYHLQ.DSN > > On *one* of Bruce's LPARs, this fails for *any* dataset, even those cataloged
Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
Are the usercats still connected? Steve Gorham steve.gor...@ssa.gov -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, July 10, 2020 11:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] Are the ALIASs blown? On 2020-07-10 11:22, Bruce Lightsey wrote: > Slight (or major) correction Kirk - datasets cataloged in the master catalog > return correctly. Any dataset in any user catalog is "not found". > > I can, for example, find the SYS1.CPU1.VTAMLST dataset that is cataloged in > the master catalog CATALOG.VMVSMCA but I cannot find CCITS.DATACOM.R12.MSG015 > in catalog CATALOG.VSYS023 or PH.PROD.PR731P.RW.P0703.FILE08 in catalog > CATALOG.VDSK204 or any other dataset cataloged in any user catalog. > > > > > Bruce Lightsey > Database Manager > MS Department of Information Technology Services > 601-432-8144 | > https://protect2.fireeye.com/v1/url?k=15a42de1-49321b02-15a40496-0cc47 > adc5fec-dbcfd351dd864ace&q=1&e=5acc5257-4765-4ff2-b631-7610e1f02fc1&u= > https%3A%2F%2Fapc01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%2 > 53A%252F%252Fwww.its.ms.gov%252F%26amp%3Bdata%3D02%257C01%257C%257Cc20 > ba429ef0e4517255f08d824e51736%257C84df9e7fe9f640afb435%257 > C1%257C0%257C637299913653415409%26amp%3Bsdata%3DhVbYEVxYZ%252BY7xqxrth > C6GkLCreItpCz08GDmgOZXO5U%253D%26amp%3Breserved%3D0 > > DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or > entity to whom they are addressed. If you have received this email in > error please notify the system manager. This message contains > confidential information and is intended only for the individual > named. If you are not the named addressee you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately > by e-mail if you have received this e-mail by mistake and delete this > e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action > in reliance on the contents of this information is strictly prohibited > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Kirk Wolf > Sent: Friday, July 10, 2020 9:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: potential catalog search error - shown by IGGCSI00 > [EXTERNAL] > > On Thu, Jul 9, 2020 at 4:14 PM Feller, Paul < > 02fc94e14c43-dmarc-requ...@listserv.ua.edu> wrote: > >> This all sounds like similar behavior of the option in 3.4 called >> "Include Additional Qualifiers". If you don't set the option on you >> have to wild card your dataset list. With the option set on you >> don't have to use wild card to get a dataset list. >> >> All the code I've ever written using IGGCSI00 I've had to use wild >> cards to get the list of datasets I wanted. In the manual they talk >> about how the use of wild cards or no wild cards will affect the output from >> IGGCSI00. >> >> >> I'm not sure what you are referring to in the IGGCSI00 documentation. >> The > first paragraph says: > > > *"The generic filter key can be a fully-qualified entry name, in which case > one entry is returned, or the generic filter key can contain "wild cards" > so thatmultiple entries can be selected on a single invocation."* > > You can verify proper behavior with the following use of IBM's sample > REXX > program: > > READY > exec 'sys1.samplib(iggcsirx)' > ENTER FILTER KEY > MYHLQ.DSN > > On *one* of Bruce's LPARs, this fails for *any* dataset, even those cataloged > in the master catalog. > > > Kirk Wolf > Dovetailed Technologies > https://protect2.fireeye.com/v1/url?k=db9d1eb3-870b2850-db9d37c4-0cc47 > adc5fec-1856bda486748206&q=1&e=5acc5257-4765-4ff2-b631-7610e1f02fc1&u= > https%3A%2F%2Fapc01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%2 > 53A%252F%252Fdovetail.com%252F%26amp%3Bdata%3D02%257C01%257C%257Cc20ba > 429ef0e4517255f08d824e51736%257C84df9e7fe9f640afb435%257C1 > %257C0%257C637299913653425397%26amp%3Bsdata%3DzK86Os3rOOOqCLn6m3F7F1NT > IO0j6stji3GcBkfWOZI%253D%26amp%3Breserved%3D0 > > Thanks.. >> Paul Feller >> GTS Mainframe Technical Support >> > -- > 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
Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
Are the ALIASs blown? On 2020-07-10 11:22, Bruce Lightsey wrote: Slight (or major) correction Kirk - datasets cataloged in the master catalog return correctly. Any dataset in any user catalog is "not found". I can, for example, find the SYS1.CPU1.VTAMLST dataset that is cataloged in the master catalog CATALOG.VMVSMCA but I cannot find CCITS.DATACOM.R12.MSG015 in catalog CATALOG.VSYS023 or PH.PROD.PR731P.RW.P0703.FILE08 in catalog CATALOG.VDSK204 or any other dataset cataloged in any user catalog. Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.its.ms.gov%2F&data=02%7C01%7C%7Cc20ba429ef0e4517255f08d824e51736%7C84df9e7fe9f640afb435%7C1%7C0%7C637299913653415409&sdata=hVbYEVxYZ%2BY7xqxrthC6GkLCreItpCz08GDmgOZXO5U%3D&reserved=0 DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Wolf Sent: Friday, July 10, 2020 9:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] On Thu, Jul 9, 2020 at 4:14 PM Feller, Paul < 02fc94e14c43-dmarc-requ...@listserv.ua.edu> wrote: This all sounds like similar behavior of the option in 3.4 called "Include Additional Qualifiers". If you don't set the option on you have to wild card your dataset list. With the option set on you don't have to use wild card to get a dataset list. All the code I've ever written using IGGCSI00 I've had to use wild cards to get the list of datasets I wanted. In the manual they talk about how the use of wild cards or no wild cards will affect the output from IGGCSI00. I'm not sure what you are referring to in the IGGCSI00 documentation. The first paragraph says: *"The generic filter key can be a fully-qualified entry name, in which case one entry is returned, or the generic filter key can contain "wild cards" so thatmultiple entries can be selected on a single invocation."* You can verify proper behavior with the following use of IBM's sample REXX program: READY exec 'sys1.samplib(iggcsirx)' ENTER FILTER KEY MYHLQ.DSN On *one* of Bruce's LPARs, this fails for *any* dataset, even those cataloged in the master catalog. Kirk Wolf Dovetailed Technologies https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdovetail.com%2F&data=02%7C01%7C%7Cc20ba429ef0e4517255f08d824e51736%7C84df9e7fe9f640afb435%7C1%7C0%7C637299913653425397&sdata=zK86Os3rOOOqCLn6m3F7F1NTIO0j6stji3GcBkfWOZI%3D&reserved=0 Thanks.. Paul Feller GTS Mainframe Technical Support -- 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: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
Try IDCAMS command LISTCAT ALIAS ALL. If you try it under TSO then you need to do PROFILE NOPREFIX first. https://www.ibm.com/support/pages/idcams-listc-alias-all-under-tso On Fri, Jul 10, 2020 at 3:22 PM Bruce Lightsey wrote: > > Slight (or major) correction Kirk - datasets cataloged in the master catalog > return correctly. Any dataset in any user catalog is "not found". > > I can, for example, find the SYS1.CPU1.VTAMLST dataset that is cataloged in > the master catalog CATALOG.VMVSMCA but I cannot find CCITS.DATACOM.R12.MSG015 > in catalog CATALOG.VSYS023 or PH.PROD.PR731P.RW.P0703.FILE08 in catalog > CATALOG.VDSK204 or any other dataset cataloged in any user catalog. > > > > > Bruce Lightsey > Database Manager > MS Department of Information Technology Services > 601-432-8144 | www.its.ms.gov > > DISCLAIMER: This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the system > manager. This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and delete > this e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Kirk Wolf > Sent: Friday, July 10, 2020 9:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] > > On Thu, Jul 9, 2020 at 4:14 PM Feller, Paul < > 02fc94e14c43-dmarc-requ...@listserv.ua.edu> wrote: > > > This all sounds like similar behavior of the option in 3.4 called > > "Include Additional Qualifiers". If you don't set the option on you > > have to wild card your dataset list. With the option set on you don't > > have to use wild card to get a dataset list. > > > > All the code I've ever written using IGGCSI00 I've had to use wild > > cards to get the list of datasets I wanted. In the manual they talk > > about how the use of wild cards or no wild cards will affect the output > > from IGGCSI00. > > > > > > I'm not sure what you are referring to in the IGGCSI00 documentation. > > The > first paragraph says: > > > *"The generic filter key can be a fully-qualified entry name, in which case > one entry is returned, or the generic filter key can contain "wild cards" > so thatmultiple entries can be selected on a single invocation."* > > You can verify proper behavior with the following use of IBM's sample REXX > program: > > READY > exec 'sys1.samplib(iggcsirx)' > ENTER FILTER KEY > MYHLQ.DSN > > On *one* of Bruce's LPARs, this fails for *any* dataset, even those cataloged > in the master catalog. > > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > Thanks.. > > > > Paul Feller > > GTS Mainframe Technical Support > > > > -- > 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: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
Slight (or major) correction Kirk - datasets cataloged in the master catalog return correctly. Any dataset in any user catalog is "not found". I can, for example, find the SYS1.CPU1.VTAMLST dataset that is cataloged in the master catalog CATALOG.VMVSMCA but I cannot find CCITS.DATACOM.R12.MSG015 in catalog CATALOG.VSYS023 or PH.PROD.PR731P.RW.P0703.FILE08 in catalog CATALOG.VDSK204 or any other dataset cataloged in any user catalog. Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | www.its.ms.gov DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Wolf Sent: Friday, July 10, 2020 9:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL] On Thu, Jul 9, 2020 at 4:14 PM Feller, Paul < 02fc94e14c43-dmarc-requ...@listserv.ua.edu> wrote: > This all sounds like similar behavior of the option in 3.4 called > "Include Additional Qualifiers". If you don't set the option on you > have to wild card your dataset list. With the option set on you don't > have to use wild card to get a dataset list. > > All the code I've ever written using IGGCSI00 I've had to use wild > cards to get the list of datasets I wanted. In the manual they talk > about how the use of wild cards or no wild cards will affect the output from > IGGCSI00. > > > I'm not sure what you are referring to in the IGGCSI00 documentation. > The first paragraph says: *"The generic filter key can be a fully-qualified entry name, in which case one entry is returned, or the generic filter key can contain "wild cards" so thatmultiple entries can be selected on a single invocation."* You can verify proper behavior with the following use of IBM's sample REXX program: READY exec 'sys1.samplib(iggcsirx)' ENTER FILTER KEY MYHLQ.DSN On *one* of Bruce's LPARs, this fails for *any* dataset, even those cataloged in the master catalog. Kirk Wolf Dovetailed Technologies http://dovetail.com Thanks.. > > Paul Feller > GTS Mainframe Technical Support > -- 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: PDS/e Encryption
Fast/easy: Encrypt/decrypt a copy of the original dataset for backup purposes. Slow/hard: Code up ICSF calls to encrypt the info. Expensive: Upgrade VTS to support encryption. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Friday, July 10, 2020 8:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/e Encryption [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.] In this case we're not encrypting for the purpose of securing the execution of program objects, we need to have those datasets encrypted on our backup tapes. Our virtual tape technology solution doesn't support encrypting of data on the virtual tape, just on the backend storage, which isn't sufficient for our needs. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com&data=02%7C01%7Callan.staller%40HCL.COM%7Ce01cd7dd95e046ab624508d824d16e95%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637299829228155328&sdata=18wbMPuvsiN6GlS8nyFyPJKM8zYRj2wJqGxXDmtbiEw%3D&reserved=0 ‐‐‐ Original Message ‐‐‐ On Friday, July 10, 2020 8:53 AM, Edgington, Jerry wrote: > Mark, > > Are the PDS/e contain load modules?? If so, there is a way to secure the load > modules, instead of the PDS/e, include COBOL. > > Jerry > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Mark Jacobs > Sent: Friday, July 10, 2020 8:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: PDS/e Encryption > > This message was sent from an external source outside of Western & Southern's > network. Do not click links or open attachments unless you recognize the > sender and know the contents are safe. > > We have a requirement to encrypt a certain class of mainframe data. While > looking at doing so for PDS/e datasets (available with z/OS 2.4 and with PTFs > on 2,2 and 2.3), I've run into a quandary. Storing program objects in an > encrypted PDS/e isn't supported. > > I'm looking at the read-only ACS variables to see if I can ascertain whether > a PDS/e will be storing program objects so I can bypass assigning our > encryption dataclas, and there's nothing obvious for me to use. > > Has anyone come up with a solution for this? > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi. > protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40proton > mail.com&data=02%7C01%7Callan.staller%40HCL.COM%7Ce01cd7dd95e046ab > 624508d824d16e95%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63729982 > 9228165317&sdata=cX%2BAFa2R%2F%2Fx%2FdHlCemtozmof9t9qHHafkZ109gnm9 > xA%3D&reserved=0 > > -- > -- > -- > -- > -- > -- > -- > -- > -- > > > 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 ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opini
HCD CBDA383I Error
Good day, we are running zos 2.2. I'm working in HCD to change devices 3390 to 3390B to begin implementing PAV. From the I/O Device List panel (CBDPDVF1) I can over type the device 3390 to 3390B but when I hit enter to make the change I get the following error below. E CBDA383I Length of the value for parameter READ-ONLY for device 4000 is larger than permitted by the UDT CBDES002. Any help or direction is appreciated. Thanks Matt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: potential catalog search error - shown by IGGCSI00 [EXTERNAL]
On Thu, Jul 9, 2020 at 4:14 PM Feller, Paul < 02fc94e14c43-dmarc-requ...@listserv.ua.edu> wrote: > This all sounds like similar behavior of the option in 3.4 called "Include > Additional Qualifiers". If you don't set the option on you have to wild > card your dataset list. With the option set on you don't have to use wild > card to get a dataset list. > > All the code I've ever written using IGGCSI00 I've had to use wild cards > to get the list of datasets I wanted. In the manual they talk about how > the use of wild cards or no wild cards will affect the output from IGGCSI00. > > > I'm not sure what you are referring to in the IGGCSI00 documentation. The first paragraph says: *"The generic filter key can be a fully-qualified entry name, in which case one entry is returned, or the generic filter key can contain "wild cards" so thatmultiple entries can be selected on a single invocation."* You can verify proper behavior with the following use of IBM's sample REXX program: READY exec 'sys1.samplib(iggcsirx)' ENTER FILTER KEY MYHLQ.DSN On *one* of Bruce's LPARs, this fails for *any* dataset, even those cataloged in the master catalog. Kirk Wolf Dovetailed Technologies http://dovetail.com Thanks.. > > Paul Feller > GTS Mainframe Technical Support > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any interest in PSD I/O for REXX?
It would be even nicer if the re where an ACB inrface that supported a concatenation of PDS, PDSE and Unix directoried. There was a Share requirement a few decades ago, but nothing happened. I wrote the existing code to be compatible with PL/i i/O; since REXX doesn't have a concept of buffered versus unbuffered I/O, I would be free to use READ/WRITE/CHECK exclusively for a REXX version. So the question is whether there is a gain in efficiency using QSAM and, if so, whether it is enough to worry about. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Kirk Wolf Sent: Friday, July 10, 2020 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any interest in PSD I/O for REXX? It would be nice if there were a "supported system interface" for mixing BPAM and QSAM this way. Dual DCB approach isn't great either. Given then, isn't it best just to use BPAM/BSAM? On Thu, Jul 9, 2020 at 11:41 PM Seymour J Metz wrote: > The QSAM fiddling is what makes GET/PUT work with multiple members. I'm > fairly confident that with z/OS versions of IGGIOBEX , IGGICQE and > possibly SAMB the existing code would work in z/OS, but that would only be > for PDS. > > Refitting the code for enterprise PL/I would require knowledge of how > files are passed and mappings for th DCLB and FCB, but all of the > interfaces that I would need to do it for REXX are well documented. So my > questions are whether there is enough interest to justify doing it and > whether efficiency is important enough to justify using QSAM with games or > whether to just do the whole thing with BPAM. If the latter, it might be > asier to just add a write routine to the existing read routine on the > CBTTAPE. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Steve Smith [sasd...@gmail.com] > Sent: Thursday, July 9, 2020 10:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Any interest in PSD I/O for REXX? > > I think you'd be disappointed in FAMS, I still don't think it would help. > We all wonder why it's a secret, because there ain't that much to it. > IEBCOPY and the LISTDSI command pretty much expose all there is. > > After looking at your old program, I'd give it at least 50-50 odds for > working with PDSEs. I think your worst case would be to abandon QSAM > fiddling and just provide GET/PUT functions. You could probably make that > much more seamless in REXX than in PL/I. > > sas > > > On Mon, Jul 6, 2020 at 10:40 PM Seymour J Metz wrote: > > > My STOWBLDL routine at http://mason.gmu.edu/~smetz3/source/STOWBLDL.ASM > > has code to quiesce a QSAM DCB before going to a new member and reprime > > buffering afterward; this requires dealing with fields in the SAM-E IOB > > extension and the SAM-E Interrupt Control Block. I assume that I would > need > > FAMS to do the equivalent for PDSE. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > -- > 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: Any interest in PSD I/O for REXX?
It would be nice if there were a "supported system interface" for mixing BPAM and QSAM this way. Dual DCB approach isn't great either. Given then, isn't it best just to use BPAM/BSAM? On Thu, Jul 9, 2020 at 11:41 PM Seymour J Metz wrote: > The QSAM fiddling is what makes GET/PUT work with multiple members. I'm > fairly confident that with z/OS versions of IGGIOBEX , IGGICQE and > possibly SAMB the existing code would work in z/OS, but that would only be > for PDS. > > Refitting the code for enterprise PL/I would require knowledge of how > files are passed and mappings for th DCLB and FCB, but all of the > interfaces that I would need to do it for REXX are well documented. So my > questions are whether there is enough interest to justify doing it and > whether efficiency is important enough to justify using QSAM with games or > whether to just do the whole thing with BPAM. If the latter, it might be > asier to just add a write routine to the existing read routine on the > CBTTAPE. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Steve Smith [sasd...@gmail.com] > Sent: Thursday, July 9, 2020 10:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Any interest in PSD I/O for REXX? > > I think you'd be disappointed in FAMS, I still don't think it would help. > We all wonder why it's a secret, because there ain't that much to it. > IEBCOPY and the LISTDSI command pretty much expose all there is. > > After looking at your old program, I'd give it at least 50-50 odds for > working with PDSEs. I think your worst case would be to abandon QSAM > fiddling and just provide GET/PUT functions. You could probably make that > much more seamless in REXX than in PL/I. > > sas > > > On Mon, Jul 6, 2020 at 10:40 PM Seymour J Metz wrote: > > > My STOWBLDL routine at http://mason.gmu.edu/~smetz3/source/STOWBLDL.ASM > > has code to quiesce a QSAM DCB before going to a new member and reprime > > buffering afterward; this requires dealing with fields in the SAM-E IOB > > extension and the SAM-E Interrupt Control Block. I assume that I would > need > > FAMS to do the equivalent for PDSE. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > -- > 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: potential catalog search error - shown by IGGCSI00
Thanks for all of the input - I am leaning toward an issue with the Master Catalog. CCTSD02 is my TSO ID and the alias is defined the same on each of the LPARs (so far as I can tell - I'm not an expert on that). All users on the "problem" LPAR are experiencing the same symptoms but, fortunately, only a very few are trying SFTP at the moment and most of that is a "put" which works fine. No dataset can be retrieved via SFTP with a "get" no matter which user catalog it is in or who the user is. This process worked fine until we IPLed at time change with some maintenance applied to the z/OS 2.2. I don't know what was touched there or what may have affected the master catalog - that is why the sysprog and IBM are involved. Since the other LPAR on this box works "correctly" and presumably has the same maintenance applied - it is our test/dev system that gets all patches a few weeks ahead of production - I have to feel that something got tweaked unintentionally. Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | www.its.ms.gov DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, July 9, 2020 5:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: potential catalog search error - shown by IGGCSI00 How is CCTSD02 defined in each master catalog? Are you using MLA? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bruce Lightsey [bruce.light...@its.ms.gov] Sent: Thursday, July 9, 2020 4:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: potential catalog search error - shown by IGGCSI00 While I’m waiting on my sysprog and IBM to finish scratching their heads I thought I’d ask if anyone had run into and corrected a similar situation. And many thanks to Kirk Wolf for patiently helping isolate where the issue seems to be. Situation : On one particular LPAR I cannot retrieve a dataset via SFTP and also cannot find the specific dataset with sys1.samplib(iggcsirx). I used Co:Z SFTP to “put” the dataset to the LPAR; I can use regular FTP to “get” the dataset; I can edit the dataset in ISPF; from my Windows workstation using SFTP I can see the dataset when I issue the “ls” command but when I “get” the dataset I get a “dataset not found” error. Same result when using Filezilla – when connecting to FTP I can “put” and “get” with no difficulty but when using SFTP I can “put”, see the dataset in the listing on the mainframe, but I can’t “get” the dataset. Frustrating ! On TSO with the sys1.samplib(iggcsirx) REXX using the specific name as the filter key - CCTSD02.TRIM.TXT - yields nothing but wild-carding the filter key - CCTSD02.TRIM.TXT.** - returns the catalog information as expected. I have verified that this is the same behavior for any dataset on the LPAR – you must wild-card the name in order to get the catalog info returned. There is also a user-started SAP process integration task using plain FTP and IGGCSI00 that fails unless the dataset name is wild-carded On a second LPAR on the same CEC that shares the user catalogs, the REXX returns the catalog information in both scenarios ( with and without the wild-card ). This makes me think that there is something uniquely set/broken on my problem LPAR but I am at a loss as to where to look now. On a second box with multiple z/OS 2.2 and 2.3 LPARS, the REXX also works as expected with and without the wild-card. Any ideas ? Thanks, Bruce Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | www.its.ms.gov DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this
Re: PDS/e Encryption
In this case we're not encrypting for the purpose of securing the execution of program objects, we need to have those datasets encrypted on our backup tapes. Our virtual tape technology solution doesn't support encrypting of data on the virtual tape, just on the backend storage, which isn't sufficient for our needs. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Friday, July 10, 2020 8:53 AM, Edgington, Jerry wrote: > Mark, > > Are the PDS/e contain load modules?? If so, there is a way to secure the load > modules, instead of the PDS/e, include COBOL. > > Jerry > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Mark Jacobs > Sent: Friday, July 10, 2020 8:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: PDS/e Encryption > > This message was sent from an external source outside of Western & Southern's > network. Do not click links or open attachments unless you recognize the > sender and know the contents are safe. > > We have a requirement to encrypt a certain class of mainframe data. While > looking at doing so for PDS/e datasets (available with z/OS 2.4 and with PTFs > on 2,2 and 2.3), I've run into a quandary. Storing program objects in an > encrypted PDS/e isn't supported. > > I'm looking at the read-only ACS variables to see if I can ascertain whether > a PDS/e will be storing program objects so I can bypass assigning our > encryption dataclas, and there's nothing obvious for me to use. > > Has anyone come up with a solution for this? > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/e Encryption
Mark, Are the PDS/e contain load modules?? If so, there is a way to secure the load modules, instead of the PDS/e, include COBOL. Jerry -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Friday, July 10, 2020 8:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PDS/e Encryption This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. We have a requirement to encrypt a certain class of mainframe data. While looking at doing so for PDS/e datasets (available with z/OS 2.4 and with PTFs on 2,2 and 2.3), I've run into a quandary. Storing program objects in an encrypted PDS/e isn't supported. I'm looking at the read-only ACS variables to see if I can ascertain whether a PDS/e will be storing program objects so I can bypass assigning our encryption dataclas, and there's nothing obvious for me to use. Has anyone come up with a solution for this? Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.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
PDS/e Encryption
We have a requirement to encrypt a certain class of mainframe data. While looking at doing so for PDS/e datasets (available with z/OS 2.4 and with PTFs on 2,2 and 2.3), I've run into a quandary. Storing program objects in an encrypted PDS/e isn't supported. I'm looking at the read-only ACS variables to see if I can ascertain whether a PDS/e will be storing program objects so I can bypass assigning our encryption dataclas, and there's nothing obvious for me to use. Has anyone come up with a solution for this? Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] COBOL 6.3 compiler options question
Thanks, Tom! Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Ross Sent: Thursday, July 9, 2020 8:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] COBOL 6.3 compiler options question >Can somebody give me a definitive definition of the NOJTC and JTC >compiler = options in 6.3? I'm not seeing it in the COBOL reference or >any COBOL manu= al for that matter, yet it shows up on the option list >when we compile a pr= >ogram: > >NOFLAGSTD =20 > HGPR(PRESERVE) =20 >NOINITCHECK =20 >NOINITIAL =20 > INLINE =20 > INTDATE(ANSI) =20 >NOJTC =20 > LANGUAGE(EN)=20 > LINECOUNT(60) =20 Rex, et al, Sorry about that! JTC is an option that we are working on and not ready to ship, but we accidentally externalized JTC in the listing. If you apply the latest maintenance to your compiler it will go away! Cheers, TomR >> COBOL is the Language of the Future! << -- 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: IBM 2828-G01
That's what I get for searching based on machine, Joe. Good catch! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Friday, July 10, 2020 8:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM 2828-G01 z/OS 2.4 is supported... z/OS® V2R4 is supported on the following IBM Z® servers: - IBM® z15™ (z15) - IBM z14™ (z14) - IBM z14® ZR1 - IBM z13® (z13®) - IBM z13s®™ (z13s) - IBM zEnterprise® EC12 (zEC12) - IBM zEnterprise BC12 (zBC12) https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zb100/osproc.htm https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zb100/hdwreqs.htm On Fri, Jul 10, 2020 at 6:55 AM Richards, Robert B. < 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > A quick Google search indicates z/OS 2.1 and z/VM 6.2 depending on > features. > > There are multiple hits for IBM pages > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of CarlosM Martinez > Sent: Friday, July 10, 2020 7:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IBM 2828-G01 > > Does anyone know the latest release of Z/VM , Z/OS and Z/VSE that can > run on a IBM 2828-G01 > > Was there a page IBM had at one time? > > > > Thank you, > > > > Carlos Martinez > > > > SUNY Downstate > > > -- > 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: IBM 2828-G01
z/OS 2.4 is supported... z/OS® V2R4 is supported on the following IBM Z® servers: - IBM® z15™ (z15) - IBM z14™ (z14) - IBM z14® ZR1 - IBM z13® (z13®) - IBM z13s®™ (z13s) - IBM zEnterprise® EC12 (zEC12) - IBM zEnterprise BC12 (zBC12) https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zb100/osproc.htm https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zb100/hdwreqs.htm On Fri, Jul 10, 2020 at 6:55 AM Richards, Robert B. < 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > A quick Google search indicates z/OS 2.1 and z/VM 6.2 depending on > features. > > There are multiple hits for IBM pages > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of CarlosM Martinez > Sent: Friday, July 10, 2020 7:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IBM 2828-G01 > > Does anyone know the latest release of Z/VM , Z/OS and Z/VSE that can run > on a IBM 2828-G01 > > Was there a page IBM had at one time? > > > > Thank you, > > > > Carlos Martinez > > > > SUNY Downstate > > > -- > 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: IBM 2828-G01
A quick Google search indicates z/OS 2.1 and z/VM 6.2 depending on features. There are multiple hits for IBM pages -Original Message- From: IBM Mainframe Discussion List On Behalf Of CarlosM Martinez Sent: Friday, July 10, 2020 7:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM 2828-G01 Does anyone know the latest release of Z/VM , Z/OS and Z/VSE that can run on a IBM 2828-G01 Was there a page IBM had at one time? Thank you, Carlos Martinez SUNY Downstate -- 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: IHS NTLM authentication
On Thu, 9 Jul 2020 12:57:39 +0800, Timothy Sipples wrote: >How many worms? How many TLS client certificates do you expect you'll need >for this purpose? Much, much more than a few. And for a rather moving target. We tend to have quite a bit of turnover in the service desk department, unfortunately. > >Especially if the answer is "more than a few," how about using the z/OS >PKI Services? If it were me, yes, we would go for that. But... Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IHS NTLM authentication
On Wed, 8 Jul 2020 07:59:39 -0600, Grant Taylor wrote: >Discussing NTLM makes me think that you might be in an environment with >Active Directory, which means Kerberos. Not yet, actually. But then I would need to implement Kerberos on mainframe, because my problem is that I need to authenticate (and authorize) against RACF, not AD... Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM 2828-G01
Does anyone know the latest release of Z/VM , Z/OS and Z/VSE that can run on a IBM 2828-G01 Was there a page IBM had at one time? Thank you, Carlos Martinez SUNY Downstate -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
