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 < [email protected]> 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 <[email protected]> On Behalf > Of Michael Watkins > Sent: Friday, December 1, 2023 11:47 AM > To: [email protected] > 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 [email protected] 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN
