On 12/8/2022 5:48 PM, Mark Jacobs wrote:
Looks like the answer is no to your question.
-----
Although, FENCE=(ACTIVE=YES,VOLUMES=nnn) indicates that JES2 will fence to nnn volumes in
most cases more than one nnn volume can be used in certain situations such as when spool
volumes fill or if the job obtains spool space on different systems as it goes through
different phases. JES2 will allocate space from a subsequent volume(s) when, and if, the
"nnn" volumes become full. At that time, JES2 will allocate track groups from
the next available volume based on any other criteria that you have defined.
-----
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
Yeah, that's for fencing which is why I think the SYSAFF *may* do the
same sort of thing.
------- Original Message -------
On Thursday, December 8th, 2022 at 5:18 PM, Michael Babcock
<bigironp...@gmail.com> wrote:
Has anyone used the SPOOL statement in JES2PARM to set affinity to a
particular LPAR for spool? Apparently, you set spool volumes A, B, C, D
to have affinity with PROD and set E, F, G, H to have affinity with
DEV. This seems to have the effect of "fencing" DEV to certain spool
volumes. I can issue $TSPOOL(A,B,C,D),SYSAFF=-DEV to remove DEV from
those 4 spool volumes and $TSPOOL(E,F,G,H),SYSAFF=-PROD. I can then add
the SPOOL statement to the JES2 INIT deck.
This would seem to have the effect of separating DEV's spool from PROD's
spool. I suspect though, that if DEV's spool volumes become full, JES2
will use space from PROD's volumes (I have no basis to back that up, but
it feels right to me, given how fencing works).
On 12/8/2022 1:53 PM, Carmen Vitullo wrote:
I've been there before with management on issues similar, but like any
child - they'll quickly move on, oh look a squirrel' and this will
give you time to get automation setup correctly and you can test with
a lower threshold and provide the results to them if they ask, IF THEY
ASK :)
JMHO
Carmen
On 12/8/2022 1:45 PM, Michael Babcock wrote:
We have CA-OPS and have put things in place but management isn’t
mainframe
literate and may be adamant about splitting. Up to me, I would
move on
to something more pressing.
Thanks for the responses.
On Thu, Dec 8, 2022 at 1:24 PM Allan Staller <
00000387911dea17-dmarc-requ...@listserv.ua.edu> wrote:
Classification: Confidential
Rather than split the spool, (no cold start required IIRC, it might be
more prudent to limit the amount of output a job can create.
Look up $ESTLNCT(?) in the JES2 manual; Set an appropriate Count and
specify option 2.
When the job exceeds the defined limit (more or less), the job will
abend
w/S722.
HTH,
-----Original Message-----
From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
Behalf
Of Michael Babcock
Sent: Thursday, December 8, 2022 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Split JES2 MAS
[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 have a 3 system plex, with two of those systems, DEV and PROD, in a
JES2 MAS. We had an incident recently where a development job got
into
a loop and used up all spool. This in turn, caused our PROD system to
come to, basically, a screeching halt.
Management wants to investigate removing PROD from the MAS.
Beyond the obvious cons below, what else am I missing? Will a cold
start
be required?
CONS:
1. No longer monitor production jobs from DEV 2. User's will need to
logon to production to check on production jobs 3. Significant
changes to
desk procedures 4. May require changes to production jobs and/or CA7
(convert from SYSAFF to ROUTE XEQ)
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
