Discussion:
HWIBCPII
Add Reply
Barbara Nitz
2018-05-30 09:27:10 UTC
Reply
Permalink
Raw Message
<warning - long post>

We had the (admittedly not so) bright idea to accomate the request from application development to activate the HEAPCHK LE Option generally. We did this in conjunction with upgrading from 2.1 to 2.3.
As a result, the crappy design of HWIBCPII address space revealed itself. (It had been running without problems under 2.1 for quite a while.)
During IPL (and *waaaay before* JES2 was active) we got these messages:

IEC141I 013-C8,IGG0193K,IEESYSAS,HWIBCPII,CEEDUMP
IEC141I 013-C8,IGG0193K,IEESYSAS,HWIBCPII,SYSOUT
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET: BCPII.D146.T1123091.HWIBCPII

Why is this thing even coming up when it relies on JES2? Why doesn't it wait for JES2?!?

CEA0603I The z/OS Diagnostic Snapshot option failed.
z/OS component CEA is unavailable for processing this request.
Diagnostic data will be missing for the following incident with:
DUMP TITLE: JOBNAME HWIBCPII STEPNAME HWIBCPII USER 4087
DATE AND TIME: 05/26/2018 11:23:09
DUMP DATA SET NAME: BCPII.D146.T1123091.HWIBCPII
REASON: The CEA address space is unavailable.

We do NOT run z/OSMF and we do NOT have CEA configured. Which component automatically calls CEA and then screams that it is not available?
*Then* insult gets added to injury:

ICH408I USER(BCPII ) GROUP($STCGRP ) NAME(BCPII )
SYS1.MCAT.xxxxxx CL(DATASET ) VOL(AWECAT)
INSUFFICIENT ACCESS AUTHORITY
FROM SYS1.MCAT.xxxxxx (G)
ACCESS INTENT(UPDATE ) ACCESS ALLOWED(READ )
IKJ56893I DATA SET BCPII.D146.T1123091.HWIBCPII NOT ALLOCATED+

Of course not! We do not allow access to the master cat for every Tom, Dick and Harry to pollute the master cat with non-defined HLQs. The HLQ BCPII (which is equal to the protected STC userid HWIBCPII runs under) does not have an alias and is not allowed to allocate data sets. *That's* why the LE Option DYNDUMP clearly specifies a general HLQ named TDUMP for each and every transaction dump to get allocated under. IBM in their infinite wisdom have choosen to override the installation-set DYNDUMP LE Default (that only makes sense for actual TSO users, but NOT for LE-enabled STCs, namely to use the userid as HLQ) to enforce the IBM default for HLQs. For security reasons, no protected STC is allowed to allocate data sets under it's own userid, hence HLQ TDUMP to actually *find* all of those transaction dumps in one place.

IEA820I TRANSACTION DUMP REQUESTED BUT NOT TAKEN
AUTOMATIC ALLOCATION OF DUMP DATA SET FAILED
CEE3796I AN ATTEMPT TO DYNAMICALLY TAKE A DUMP WAS NOT SUCCESSFUL. 339
THE ERROR RETURN CODE WAS 00000008 AND THE REASON CODE WAS 00000026.
CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 00000001 344
WHILE RUNNING PROGRAM CEEBPCAL WHICH STARTS AT 0000F600
AT THE TIME OF INTERRUPT
CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 00000002 355
WHILE RUNNING PROGRAM CEEPIPI
AT THE TIME OF INTERRUPT
HWI018I THE BCPII COMMUNICATION RECOVERY HAS DETECTED AN UNEXPECTED
ERROR. SYSOUT MAY CONTAIN DIAGNOSTICS FOR THIS PROBLEM.
HWI008I BCPII FAILED TO CONNECT TO THE LOCAL CENTRAL PROCESSOR 367
COMPLEX (CPC). RC = 00000FFF, RSN = 00000000. BCPII INITIALIZATION
IS HALTED.

When we migrated to 2.3, we didn't have a clue what might be wrong with HWIBCPII, so after the system was up and running we just did a "start HWISTART". To our utter confusion, *now* it came up without a hitch.

We later found out why setting HEAPCK globally wasn't a good idea and have now turned it off again. When we reproduced this on our test system, we did an S HWISTART,SUB=MSTR on the assumption that the thing runs sub=mstr when it gets started. We got a dump (abend042 with a 'severe internal error' reason code) for our pains, so quite obviously it does not work under sub=mstr. Starting it under JES, *now* it waits for JES to initialize, probably because something global in the system recognizes that JES2 isn't there yet.

There are a number of things wrong here:
1. If HWIBCPII needs JES2 to function (and obviously it does), it just cannot do all the shenanigans detailed above and *has to* wait for JES2 to come up. If it cannot do that, then it MUST work under the master subsystem. The wishy-washy way it behaves now is not acceptable.
2. Since this is an LE-enabled application, it MUST be able to tolerate all and any LE options set in an installation. Given that it overrides a number of the installation-set LE Options, why doesn't it also override the HEAPCHK option to always be off?
3. No STC running with a protected user should ever be able to allocate data sets under its own userid (or so our auditors tell us). That why it is *bad* design to override the DYNDUMP option that names the HLQ for transaction dumps, especially when running in a system address space deeply entrenched in z/OS.

Thanks for letting me vent!

Regards, Barbara

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2018-05-30 15:57:26 UTC
Reply
Permalink
Raw Message
Post by Barbara Nitz
Why is this thing even coming up when it relies on JES2? Why doesn't it wait for JES2?!?
BCPii relies on JES2? That's news to me...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-05-30 17:54:05 UTC
Reply
Permalink
Raw Message
I don't know anything about this STC, but the first couple of messages
imply you have SYSOUT files in the JCL. Those require JES. AFAIK, any STC
waits for JES unless SUB=MSTR is specified, so don't do both.

sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2018-05-30 21:58:25 UTC
Reply
Permalink
Raw Message
HWIBCPII is one of those magical address spaces that is started by Abracadabra:

S IEESYSAS,PROG=HWIAMIN2

IBM supplied proc IEESYSAS is a weird animal with no real content. The actual STC name is determined by the startup program.

//IEESYSAS PROC PROG=IEFBR14
//IEFPROC EXEC PGM=&PROG
//* THE IEESYSAS PROCEDURE IS SPECIFIED IN THE
//* PARAMETER LIST TO IEEMB881 BY MVS COMPONENTS
//* STARTING FULL FUNCTION SYSTEM ADDRESS SPACES.

When the named STC starts up, it has nothing allocated other than what z/OS has chosen dynamically for that magical name. It runs SUB=MSTR, but you cannot specify SUB=MSTR. In our shop, HWIBCPII starts before (independent of) JES2, and continues running after JES2 shutdown.

Examples of other tasks started with IEESYSAS:

//SMSVSAM EXEC IEESYSAS,PROG=IDAVSJST
//IOSAS EXEC IEESYSAS,PROG=IOSVROUT
//CEA EXEC IEESYSAS,PROG=CEAINIT
//WLM EXEC IEESYSAS,PROG=IWMINJST

Despite the appearance of 'SYSOUT' in the original post, these tasks cannot use JES services to handle print output.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Wednesday, May 30, 2018 10:55 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: HWIBCPII

I don't know anything about this STC, but the first couple of messages imply you have SYSOUT files in the JCL. Those require JES. AFAIK, any STC waits for JES unless SUB=MSTR is specified, so don't do both.

sas


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-05-30 22:17:22 UTC
Reply
Permalink
Raw Message
The trouble with Abracadabra is getting it to work reliably.

sas
Post by Jesse 1 Robinson
S IEESYSAS,PROG=HWIAMIN2
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2018-05-31 02:48:22 UTC
Reply
Permalink
Raw Message
Post by Jesse 1 Robinson
S IEESYSAS,PROG=HWIAMIN2
Or by:

S HWISTART (which essentially does the same)
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Barbara Nitz
2018-06-04 05:07:13 UTC
Reply
Permalink
Raw Message
Post by Ed Jaffe
Post by Jesse 1 Robinson
S IEESYSAS,PROG=HWIAMIN2
S HWISTART (which essentially does the same)
Not quite. S HWISTART waits for JES2 to come up, it does NOT start HWIBCPII immediately. (Which is why I tried the sub=mstr that ended in equal disaster).

BCPII is LE-enabled, and the docs proudly point out that they use LE Services (and will override whatever an installation has set). Quite obviously IBM has never tested a transaction dump *before* JES2 was up. The LE transaction dump *requires* JES2, hence HWIBCPII *requires* JES2 (if only in special circumstances). Which is why I call this crappy design.

Barbara

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2018-06-04 15:14:27 UTC
Reply
Permalink
Raw Message
Post by Barbara Nitz
The LE transaction dump *requires* JES2, hence HWIBCPII *requires* JES2 (if only in special circumstances). Which is why I call this crappy design.
LE transaction dump requires JES2? That's news to me...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2018-06-04 17:30:02 UTC
Reply
Permalink
Raw Message
[Default] On 4 Jun 2018 08:14:27 -0700, in bit.listserv.ibm-main
Post by Ed Jaffe
Post by Barbara Nitz
The LE transaction dump *requires* JES2, hence HWIBCPII *requires* JES2 (if only in special circumstances). Which is why I call this crappy design.
LE transaction dump requires JES2? That's news to me...
CEEDUMP may default to SYSOUT=*. It's long enough since I dealt with
these things that I do;t know how it should be changed for SUB=MSTR.

Clark Morris

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2018-06-05 01:03:43 UTC
Reply
Permalink
Raw Message
Post by Clark Morris
CEEDUMP may default to SYSOUT=*. It's long enough since I dealt with
these things that I do;t know how it should be changed for SUB=MSTR.
If that's the case, then the fault lies with LE and not BCPii.

If the allocation for CEEDUMP fails, then the dump should be taken (for
example) with IEATDUMP.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Joel C. Ewing
2018-06-04 20:09:23 UTC
Reply
Permalink
Raw Message
Post by Clark Morris
[Default] On 4 Jun 2018 08:14:27 -0700, in bit.listserv.ibm-main
Post by Ed Jaffe
Post by Barbara Nitz
The LE transaction dump *requires* JES2, hence HWIBCPII *requires* JES2 (if only in special circumstances). Which is why I call this crappy design.
LE transaction dump requires JES2? That's news to me...
CEEDUMP may default to SYSOUT=*. It's long enough since I dealt with
these things that I do;t know how it should be changed for SUB=MSTR.
Clark Morris
The default dynamic allocation of CEEDUMP to SYSOUT=* was a [wise]
concession to existing COBOL shops for upward compatibility so
conversion to LE-enabled COBOL didn't require immediate mass changes to
many, many 1000's of instances of job step JCL to add new DD
statements.    All it takes to override is to provide an explicit
pre-allocation for CEEDUMP just in case a dump is needed -- so if
invoked from JCL, add a CEEDUMP DD  to send dumps to a data set if you
have a case where you don't want JES2 to be "required", or to send to a
different output class when "SYSOUT=*" is not appropriate for a dump. 

For us, output class "*" was for long-term archival -- not appropriate
for dumps -- but we didn't have any urgency to add CEEDUMP DDs  to COBOL
run-time JCL when LE was introduced, except in job streams where  large
dumps got unintentionally archived often enough to be annoying.
    Joel C Ewing
--
Joel C. Ewing, Bentonville, AR ***@acm.org

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Barbara Nitz
2018-06-05 04:58:10 UTC
Reply
Permalink
Raw Message
Ed,

please reread my first post!
Post by Ed Jaffe
If that's the case, then the fault lies with LE and not BCPii.
How is LE to know that it runs under an implicit sub=mstr? That is not how your standard Cobol/PL/I program runs.
What started this off was our general setting of HEAPCHK(ON) on request of application development. It seems that one LE enclave terminates which (with HEAPCHK on) wants to write a short 'ceedump' to JES2 spool with the heap statistics. When that fails, LE issues a U4087 (I think) and tries an IEATDUMP.
Post by Ed Jaffe
If the allocation for CEEDUMP fails, then the dump should be taken (for
example) with IEATDUMP.
*We* have an explicit LE statement DYNDUMP that directs *any* dump to HLQ TDUMP. BCPII has *chosen* to overwrite that setting by specifying part of the LE Default for DYNDUMP, which is the userid of the address space. STC users are not allowed to allocate data sets (RACF audit requirement), hence the general HLQ of TDUMP (instead of userid). Which HWIBCPII has overwritten.

Either HWIBCPII is LE-enabled (which I find very questionable for a system address space started via OS abracadabra), then it will have to set/override *all* options that require JES in one way or another or are otherwise harmful and not just a select few that are proudly documented in the books to be overwritten if allowed, *or* the address space should NOT be LE-enabled at all.

Barbara

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2018-06-05 17:26:10 UTC
Reply
Permalink
Raw Message
Post by Barbara Nitz
How is LE to know that it runs under an implicit sub=mstr?
LE should never know or care about that!

If LE tries to allocate/open CEEDUMP and that operation fails (in *any*
environment, not just SUB=MSTR), then it should fall back to another way
of taking the dump -- for example, IEATDUMP.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...