We don't run ZFS support in its own address space any longer, it's in the OMVS address space now.
Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&[email protected] ------- Original Message ------- On Wednesday, May 10th, 2023 at 8:11 AM, Mark Jacobs <[email protected]> wrote: > How do you start OMVS SUB=MSTR? I'm not seeing any start command in parmlib. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&[email protected] > > > > > ------- Original Message ------- > On Wednesday, May 10th, 2023 at 7:58 AM, Allan Staller > [email protected] wrote: > > > > > Classification: Confidential > > > > OMVS can be started as SUB=MSTR or as a JES task. Che choice is up to the > > installation. > > Ditto for ZFS. > > > > What is really being implied is that if JES2 needs OMVS services, it should > > not provide those services until OMVS has initialized, > > > > Many other tasks do this (e.g. TSO). > > > > My USD $0.02 > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [email protected] On Behalf Of > > Pommier, Rex > > > > Sent: Tuesday, May 9, 2023 11:21 AM > > To: [email protected] > > Subject: Re: JES2 Submitlib Bootstrap problem > > > > [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.] > > > > I see a problem with this scenario. It appears to me that there is a call > > (not necessarily by Shmuel) to potentially have JES2 wait for OMVS to be up > > before it does its startup (or at least completes the startup). Due to a > > self-inflicted screw-up on one of our LPARs, OMVS decided it had to do a > > filesystem check on every filesystem on the system. This took a good half > > hour where it simply appeared our LPAR was hung. JES2 had come up and I was > > able to start a few address spaces that are dependent on JES so I could > > figure out what was going on. Had JES been waiting for OMVS we would have > > been completely in the dark on this issue. > > > > I could see there being communication between JES and OMVS so that when > > OMVS gets initialized it signals JES to redrive any failed zFS allocations, > > but don't force JES to wait until zFS is available. > > > > My $.02. > > > > Rex > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [email protected] On Behalf Of > > Seymour J Metz > > > > Sent: Tuesday, May 9, 2023 10:10 AM > > To: [email protected] > > Subject: [EXTERNAL] Re: JES2 Submitlib Bootstrap problem > > > > Yes, IBM absolutely should take startup sequence into account and should > > provide mechanisms to ensure that things occur in the proper order. This > > goes beyond OMVS. > > > > -- > > Shmuel (Seymour J.) Metz > > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!KjMRP1Ixj6eLE0Fj!oLVba7cIWA-HvwL4aaVssbMaEZeCG3m_dnLPJgpEL8DOiFs5DAJaoVf27kYVUZyYy_Nw7UxsOVp6sogwmA$ > > > > ________________________________________ > > From: IBM Mainframe Discussion List [[email protected]] on behalf of > > Paul Gilmartin [[email protected]] > > Sent: Tuesday, May 9, 2023 11:01 AM > > To: [email protected] > > Subject: Re: JES2 Submitlib Bootstrap problem > > > > On Tue, 9 May 2023 12:18:11 +0000, Mark Jacobs wrote: > > > > > I defined several submitlibs in my JES2PARM to use directories in a ZFS > > > filesystem. When I hotstart JES2, JES2 can find everything and is happy. > > > During IPL/JES2 startup it's not. It doesn't seem like OMVS is > > > initialized yet and so the file systems aren't accessible for JES2 to > > > resolve. I haven't fully analyzed the system log to confirm it yet, but > > > it seems like a reasonable assumption. Has anyone else run into this? > > > > WAD? z/OS UNIX appears to be a second-class citizen in that operations that > > require UNIX facilities are allowed to begin before UNIX is available, then > > simply fail. > > > > Should design give more attention to the order of startup operations? > > > > Should there be an implied WAIT (not explicit) for any operation which > > requires UNIX? Would that be likely to result in a deadlock? > > > > -- > > gil > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send email > > to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send email > > to [email protected] 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 [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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
