I added that to the top of COMMNDxx. JES2 is also started there. In our sandbox 
it didn't work. I'd need to get the automation team to get involved to have it 
trap the OMVS is active message then start JES2. Unless some other engineering 
teams express an interest in SUBMITLIBs in a file system I'm not going to do 
anything else at this point. 

I'm still going to pursue the case with IBM though. 

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:14 AM, Allan Staller 
<[email protected]> wrote:


> Classification: Confidential
> 
> Issue the command in COMMNDxx or your System Automation product.
> 
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [email protected] On Behalf Of 
> Mark Jacobs
> 
> Sent: Wednesday, May 10, 2023 7:12 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.]
> 
> 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://urld/
> > efense.com%2Fv3%2F__http%3A%2F%2Fmason.gmu.edu%2F*smetz3__%3Bfg!!KjMRP
> > 1Ixj6eLE0Fj!oLVba7cIWA-HvwL4aaVssbMaEZeCG3m_dnLPJgpEL8DOiFs5DAJaoVf27k
> > YVUZyYy_Nw7UxsOVp6sogwmA%24&data=05%7C01%7Callan.staller%40HCL.COM%7Cb
> > 415b6f48fe746065c5808db514fd81b%7C189de737c93a4f5a8b686f4ca9941912%7C0
> > %7C0%7C638193175624293681%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2
> > n3vNh3L5fxsleOK2Cv6N8JNUGJ%2FrUJCmfa4FqFNZDc%3D&reserved=0
> > 
> > ________________________________________
> > 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
> 
> ----------------------------------------------------------------------
> 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

Reply via email to