Re: JES3plus & TDMF
-DS QD,VOL=A01P01,UCB IEE459I 06.45.24 DEVSERV QDASD 687 UNIT VOLSER SCUTYPE DEVTYPE CYL SSID SCU-SERIAL DEV-SERIAL EFC 049A8 A01P01 2107986 2107900 10017 4900 0175-KAD51 0175-KAD51 *OK UCB AT V026FA5B0 0088FF8C49A8 00E4C3C2 3030200F006FA589 00010100C1F0F1D7 F0F110A20001 026FA3B002898608 0012 UCB PREFIX AT V028FB200 000D9040 000116E8 289C16A9FF0002FF 27282B2C2E2F3435 01080A01 01C2BEA0 UCB COMMON EXTENSION AT V026FA588 094020AA0008 028FB2000131 00FD44D4 026FA5401B00 1 DEVICE(S) MET THE SELECTION CRITERIA 0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING The UCBJ3DV flag is the high-order byte of the UCB common extension. X'00' denotes the volume is not managed by JES3. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Watkins Sent: Friday, December 1, 2023 12:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES3plus & TDMF CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. Thanks! Looking through 'DS QD,VOL=vv,UCB' now. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Friday, December 1, 2023 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES3plus & TDMF CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. Those three APARs are over 20 years old and were fixed in 2001, so yes they're on. Have you looked at the DS QD command with the UCB option to display the UCB, Prefix and Common Extension? Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com On Friday, December 1st, 2023 at 12:46 PM, Michael Watkins <032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote: > Apologies for the double listing to anyone who's also seen this on the JES3-L > LISTSERV. > > The government agency that employs me has three z/OS LPARs (V2R5) running on > a z15 server. The lone mainframe storage subsystem is a non-replicated, > channel-attached DS8886. This has never been a JES2 installation and Phoenix > Software's JES3plus is now installed. While the JES3 initialization deck has > DEVICE statements for all tape drives, it has not contained a DEVICE > statement for a DASD address in over a decade. In other words, DASD > allocation is not managed by JES3. > > The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to > migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can > move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD > volumes where the coupling facility resides without issues. A co-worker > insists that all of the LPARs must be brought down, separately, so that each > LPAR's 'sensitive' volumes can be moved from another LPAR. > > IBM documents state: 'JES3 considerations: In order to ensure that JES3 > system defined volumes will migrate (not required for a Point-In-Time > migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and > OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and > therefore, will allow the swapping of volumes. Important: All systems sharing > devices where JES3 manages the devices must be involved in the TDMF session > running. This ensures that all JES3 internal tables are properly updated. > Failure to do so will cause unpredictable results. It is recommended that the > user check the UCB for the following bit prior to copying volumes in a JES3 > environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF > will migrate the volume(s) with no errors. If the bit is on, TDMF will make > the appropriate calls to JES3 to notify JES3 of the volume redirection > needed.' > > Since the DASD volumes at this installation are not managed by JES3, I don't > think these APARs are an issue. However, to assuage my co-worker's fears, I'd > like to see whether the corresponding PTFs have been applied. Unfortunately, > I cannot find the PTFs that correspond to any of them. > > Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? > > Also, I'm not sure how to display the UCBs involved to verify that the > UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you > can provide on would be appreciated, particularly on how to use either > UCBSCAN or UCBLOOK macros. > > > -
Re: JES3plus & TDMF
On 12/1/2023 9:46 AM, Michael Watkins wrote: Since the DASD volumes at this installation are not managed by JES3, I don’t think these APARs are an issue. However, to assuage my co-worker’s fears, I’d like to see whether the corresponding PTFs have been applied. Unfortunately, I cannot find the PTFs that correspond to any of them. If you scan the JES3 or JES3plus source code for those APAR numbers, you will find the code is there -- implemented way back in 1996 and 1997. But you're right, unless the DASD is JES3-managed, they do not apply. xxxMDSB: * OW23271 HJS6604 961030 PS0MC: OS 2.4.0 @WA23271 02400432 * OW28457 HJS6605 970828 PS0MC: OS 2.5.0 @WA28457 02400433 xxxIPSET: * OW28455 HJS6605 970902 PS0MC : OS 2.5.0 *@WA28455 01016003 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES3plus & TDMF
We just created new paging volumes, PAGEAD them, updated IPL member, PAGEDEL the old volumes. On Fri, Dec 1, 2023 at 12:32 PM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > From the APAR numbers, they are ancient and most likely do not apply to > ans z/OS system (OS 390 or earlier perhaps). > That coed is undoubtedly in the JES3 and Jes3/Plus base. I would not worry > about them. > > One other thing. TDMF can move inactive page datasets. It will refuse to > touch an in-use page dataset. > > The last time I did a DASD migration, I defined temporary page datasets > and used pageadd/pagdel commands to move the paging activity. > After the original page datasets had been moved, I repeated the process to > go back to the original page datasets. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Michael Watkins > Sent: Friday, December 1, 2023 11:47 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: JES3plus & TDMF > > [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.] > > Apologies for the double listing to anyone who's also seen this on the > JES3-L LISTSERV. > > The government agency that employs me has three z/OS LPARs (V2R5) running > on a z15 server. The lone mainframe storage subsystem is a non-replicated, > channel-attached DS8886. This has never been a JES2 installation and > Phoenix Software’s JES3plus is now installed. While the JES3 initialization > deck has DEVICE statements for all tape drives, it has not contained a > DEVICE statement for a DASD address in over a decade. In other words, DASD > allocation is not managed by JES3. > > The DS8886 will soon be replaced by a DS8950F. TDMF software will be used > to migrate the contents of the DS8886 to the DS8950F. I believe that TDMF > can move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the > DASD volumes where the coupling facility resides without issues. A > co-worker insists that all of the LPARs must be brought down, separately, > so that each LPAR’s ‘sensitive’ volumes can be moved from another LPAR. > > IBM documents state: ‘JES3 considerations: In order to ensure that JES3 > system defined volumes will migrate (not required for a Point-In-Time > migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and > OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS > and therefore, will allow the swapping of volumes. Important: All systems > sharing devices where JES3 manages the devices must be involved in the TDMF > session running. This ensures that all JES3 internal tables are properly > updated. Failure to do so will cause unpredictable results. It is > recommended that the user check the UCB for the following bit prior to > copying volumes in a JES3 environment: UCBJ3DV - device is defined to JES3. > If the bit is off, TDMF will migrate the volume(s) with no errors. If the > bit is on, TDMF will make the appropriate calls to JES3 to notify JES3 of > the volume redirection needed.’ > > Since the DASD volumes at this installation are not managed by JES3, I > don’t think these APARs are an issue. However, to assuage my co-worker’s > fears, I’d like to see whether the corresponding PTFs have been applied. > Unfortunately, I cannot find the PTFs that correspond to any of them. > > Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? > > Also, I’m not sure how to display the UCBs involved to verify that the > UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help > you can provide on would be appreciated, particularly on how to use either > UCBSCAN or UCBLOOK macros. > > > -- > 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 o
Re: JES3plus & TDMF
Classification: Confidential From the APAR numbers, they are ancient and most likely do not apply to ans z/OS system (OS 390 or earlier perhaps). That coed is undoubtedly in the JES3 and Jes3/Plus base. I would not worry about them. One other thing. TDMF can move inactive page datasets. It will refuse to touch an in-use page dataset. The last time I did a DASD migration, I defined temporary page datasets and used pageadd/pagdel commands to move the paging activity. After the original page datasets had been moved, I repeated the process to go back to the original page datasets. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Watkins Sent: Friday, December 1, 2023 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES3plus & TDMF [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.] Apologies for the double listing to anyone who's also seen this on the JES3-L LISTSERV. The government agency that employs me has three z/OS LPARs (V2R5) running on a z15 server. The lone mainframe storage subsystem is a non-replicated, channel-attached DS8886. This has never been a JES2 installation and Phoenix Software’s JES3plus is now installed. While the JES3 initialization deck has DEVICE statements for all tape drives, it has not contained a DEVICE statement for a DASD address in over a decade. In other words, DASD allocation is not managed by JES3. The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD volumes where the coupling facility resides without issues. A co-worker insists that all of the LPARs must be brought down, separately, so that each LPAR’s ‘sensitive’ volumes can be moved from another LPAR. IBM documents state: ‘JES3 considerations: In order to ensure that JES3 system defined volumes will migrate (not required for a Point-In-Time migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and therefore, will allow the swapping of volumes. Important: All systems sharing devices where JES3 manages the devices must be involved in the TDMF session running. This ensures that all JES3 internal tables are properly updated. Failure to do so will cause unpredictable results. It is recommended that the user check the UCB for the following bit prior to copying volumes in a JES3 environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF will migrate the volume(s) with no errors. If the bit is on, TDMF will make the appropriate calls to JES3 to notify JES3 of the volume redirection needed.’ Since the DASD volumes at this installation are not managed by JES3, I don’t think these APARs are an issue. However, to assuage my co-worker’s fears, I’d like to see whether the corresponding PTFs have been applied. Unfortunately, I cannot find the PTFs that correspond to any of them. Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? Also, I’m not sure how to display the UCBs involved to verify that the UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you can provide on would be appreciated, particularly on how to use either UCBSCAN or UCBLOOK macros. -- 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 / arc
Re: JES3plus & TDMF
Thanks! Looking through 'DS QD,VOL=vv,UCB' now. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Friday, December 1, 2023 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES3plus & TDMF CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. Those three APARs are over 20 years old and were fixed in 2001, so yes they're on. Have you looked at the DS QD command with the UCB option to display the UCB, Prefix and Common Extension? Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com On Friday, December 1st, 2023 at 12:46 PM, Michael Watkins <032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote: > Apologies for the double listing to anyone who's also seen this on the JES3-L > LISTSERV. > > The government agency that employs me has three z/OS LPARs (V2R5) running on > a z15 server. The lone mainframe storage subsystem is a non-replicated, > channel-attached DS8886. This has never been a JES2 installation and Phoenix > Software's JES3plus is now installed. While the JES3 initialization deck has > DEVICE statements for all tape drives, it has not contained a DEVICE > statement for a DASD address in over a decade. In other words, DASD > allocation is not managed by JES3. > > The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to > migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can > move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD > volumes where the coupling facility resides without issues. A co-worker > insists that all of the LPARs must be brought down, separately, so that each > LPAR's 'sensitive' volumes can be moved from another LPAR. > > IBM documents state: 'JES3 considerations: In order to ensure that JES3 > system defined volumes will migrate (not required for a Point-In-Time > migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and > OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and > therefore, will allow the swapping of volumes. Important: All systems sharing > devices where JES3 manages the devices must be involved in the TDMF session > running. This ensures that all JES3 internal tables are properly updated. > Failure to do so will cause unpredictable results. It is recommended that the > user check the UCB for the following bit prior to copying volumes in a JES3 > environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF > will migrate the volume(s) with no errors. If the bit is on, TDMF will make > the appropriate calls to JES3 to notify JES3 of the volume redirection > needed.' > > Since the DASD volumes at this installation are not managed by JES3, I don't > think these APARs are an issue. However, to assuage my co-worker's fears, I'd > like to see whether the corresponding PTFs have been applied. Unfortunately, > I cannot find the PTFs that correspond to any of them. > > Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? > > Also, I'm not sure how to display the UCBs involved to verify that the > UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you > can provide on would be appreciated, particularly on how to use either > UCBSCAN or UCBLOOK macros. > > > -- > 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: JES3plus & TDMF
Those three APARs are over 20 years old and were fixed in 2001, so yes they're on. Have you looked at the DS QD command with the UCB option to display the UCB, Prefix and Common Extension? Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com On Friday, December 1st, 2023 at 12:46 PM, Michael Watkins <032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote: > Apologies for the double listing to anyone who's also seen this on the JES3-L > LISTSERV. > > The government agency that employs me has three z/OS LPARs (V2R5) running on > a z15 server. The lone mainframe storage subsystem is a non-replicated, > channel-attached DS8886. This has never been a JES2 installation and Phoenix > Software’s JES3plus is now installed. While the JES3 initialization deck has > DEVICE statements for all tape drives, it has not contained a DEVICE > statement for a DASD address in over a decade. In other words, DASD > allocation is not managed by JES3. > > The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to > migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can > move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD > volumes where the coupling facility resides without issues. A co-worker > insists that all of the LPARs must be brought down, separately, so that each > LPAR’s ‘sensitive’ volumes can be moved from another LPAR. > > IBM documents state: ‘JES3 considerations: In order to ensure that JES3 > system defined volumes will migrate (not required for a Point-In-Time > migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and > OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and > therefore, will allow the swapping of volumes. Important: All systems sharing > devices where JES3 manages the devices must be involved in the TDMF session > running. This ensures that all JES3 internal tables are properly updated. > Failure to do so will cause unpredictable results. It is recommended that the > user check the UCB for the following bit prior to copying volumes in a JES3 > environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF > will migrate the volume(s) with no errors. If the bit is on, TDMF will make > the appropriate calls to JES3 to notify JES3 of the volume redirection > needed.’ > > Since the DASD volumes at this installation are not managed by JES3, I don’t > think these APARs are an issue. However, to assuage my co-worker’s fears, I’d > like to see whether the corresponding PTFs have been applied. Unfortunately, > I cannot find the PTFs that correspond to any of them. > > Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? > > Also, I’m not sure how to display the UCBs involved to verify that the > UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you > can provide on would be appreciated, particularly on how to use either > UCBSCAN or UCBLOOK macros. > > > -- > 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
JES3plus & TDMF
Apologies for the double listing to anyone who's also seen this on the JES3-L LISTSERV. The government agency that employs me has three z/OS LPARs (V2R5) running on a z15 server. The lone mainframe storage subsystem is a non-replicated, channel-attached DS8886. This has never been a JES2 installation and Phoenix Software’s JES3plus is now installed. While the JES3 initialization deck has DEVICE statements for all tape drives, it has not contained a DEVICE statement for a DASD address in over a decade. In other words, DASD allocation is not managed by JES3. The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD volumes where the coupling facility resides without issues. A co-worker insists that all of the LPARs must be brought down, separately, so that each LPAR’s ‘sensitive’ volumes can be moved from another LPAR. IBM documents state: ‘JES3 considerations: In order to ensure that JES3 system defined volumes will migrate (not required for a Point-In-Time migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and therefore, will allow the swapping of volumes. Important: All systems sharing devices where JES3 manages the devices must be involved in the TDMF session running. This ensures that all JES3 internal tables are properly updated. Failure to do so will cause unpredictable results. It is recommended that the user check the UCB for the following bit prior to copying volumes in a JES3 environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF will migrate the volume(s) with no errors. If the bit is on, TDMF will make the appropriate calls to JES3 to notify JES3 of the volume redirection needed.’ Since the DASD volumes at this installation are not managed by JES3, I don’t think these APARs are an issue. However, to assuage my co-worker’s fears, I’d like to see whether the corresponding PTFs have been applied. Unfortunately, I cannot find the PTFs that correspond to any of them. Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? Also, I’m not sure how to display the UCBs involved to verify that the UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you can provide on would be appreciated, particularly on how to use either UCBSCAN or UCBLOOK macros. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
