Re: HWIBCPII
Please pardon me for jumping in, but FWIW: In our environment (zOS V2.2) we start HWIBCPII before JES2 after an IPL. One of the first messages that BCPII issued is: HWI015I BCPII IS WAITING FOR THE PRIMARY SUBSYSTEM TO BECOME ACTIVE TO ALLOW THE BCPII COMMUNICATION RECOVERY ENVIRONMENT TO BE ESTABLISHED. Explanation BCPii is waiting for the BCPii communication recovery environment to be established to handle unexpected errors during communication processing using the z/OS Language Environment. While BCPii is waiting for the primary subsystem to become active, if a severe error occurs while processing a BCPii communications request and a CEEDUMP is requested, one will not be taken. The CEEDUMP processing of BCPii requires the primary subsystem to be active to write the dump to SYSOUT. Hth Tony -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, June 05, 2018 1:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HWIBCPII On 6/4/2018 9:58 PM, Barbara Nitz wrote: > 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 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
Re: HWIBCPII
On 6/4/2018 9:58 PM, Barbara Nitz wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
Ed, please reread my first post! >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. >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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
On 6/4/2018 10:29 AM, Clark Morris wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
On 06/04/2018 12:29 PM, Clark Morris wrote: > [Default] On 4 Jun 2018 08:14:27 -0700, in bit.listserv.ibm-main > edja...@phoenixsoftware.com (Ed Jaffe) wrote: > >> On 6/3/2018 10:07 PM, Barbara Nitz wrote: >> >>> 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 jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
[Default] On 4 Jun 2018 08:14:27 -0700, in bit.listserv.ibm-main edja...@phoenixsoftware.com (Ed Jaffe) wrote: >On 6/3/2018 10:07 PM, Barbara Nitz wrote: > >> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
On 6/3/2018 10:07 PM, Barbara Nitz wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
>> HWIBCPII is one of those magical address spaces that is started by >> Abracadabra: >> >> S IEESYSAS,PROG=HWIAMIN2 > >Or by: > >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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
On 5/30/2018 2:59 PM, Jesse 1 Robinson wrote: HWIBCPII is one of those magical address spaces that is started by Abracadabra: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
The trouble with Abracadabra is getting it to work reliably. sas On Wed, May 30, 2018 at 5:59 PM, Jesse 1 Robinson wrote: > HWIBCPII is one of those magical address spaces that is started by > Abracadabra: > >S IEESYSAS,PROG=HWIAMIN2 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
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= //* 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 //IOSASEXEC 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Wednesday, May 30, 2018 10:55 AM To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
On 5/30/2018 2:28 AM, Barbara Nitz wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HWIBCPII
Well thought out! And agreed. Maybe John Eels can take it up with the appropriate development groups. Atta Girl! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz Sent: Wednesday, May 30, 2018 4:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HWIBCPII 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 *wy 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.xx CL(DATASET ) VOL(AWECAT) INSUFFICIENT ACCESS AUTHORITY FROM SYS1.MCAT.xx (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 0008 AND THE REASON CODE WAS 0026. CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 0001 344 WHILE RUNNING PROGRAM CEEBPCAL WHICH STARTS AT F600 AT THE TIME OF INTERRUPT CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 0002 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 = 0FFF, RSN = . 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 audito
HWIBCPII
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 *wy 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.xx CL(DATASET ) VOL(AWECAT) INSUFFICIENT ACCESS AUTHORITY FROM SYS1.MCAT.xx (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 0008 AND THE REASON CODE WAS 0026. CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 0001 344 WHILE RUNNING PROGRAM CEEBPCAL WHICH STARTS AT F600 AT THE TIME OF INTERRUPT CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 0002 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 = 0FFF, RSN = . 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 S
