Re: What is the SDATA option to include above the bar storage for a particular job?

[Barbara Nitz]

>What is the SDATA option to include above the bar storage for a particular
>job?

A while ago, I had asked the same question because my dump was missing 
above-the-bar storage that I expected. Someone (I think it was Peter Relson) 
said that the same keywords that govern above-the-line storage also apply to 
above-the-bar. In other words, RGN should give you private storage regardless 
of location. Same goes for common storage.

Regards, Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the SDATA option to include above the bar storage for a particular job?

[Peter Relson]

Answer: The same option that you would use for storage below the bar.

Storage above the bar is classified by the obtainer according to how it 
wants dumping to consider it.
IARV64 has DUMP=LIKERGN, DUMP=LIKELSQA, DUMP=LIKECSA, DUMP=LIKESQA

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Name those boxes

[Joe Monk]

The console is an IBM 1415-2, hard to tell, but looks like it is for a 7010
CPU system.

http://ed-thelen.org/comp-hist/IBM-ProdAnn/7010.pdf

Joe

On Mon, Aug 17, 2020 at 11:51 PM Ken Smith  wrote:

> The phone is a Western Electric model 500
> https://en.m.wikipedia.org/wiki/Model_500_telephone
>
> On Tue, Aug 18, 2020 at 12:32 AM Seymour J Metz  wrote:
>
> > There is no 2741 in the picture. The typewriter is part of the 1415.
> >
> >
> >
> >
> >
> > --
> >
> > Shmuel (Seymour J.) Metz
> >
> > http://mason.gmu.edu/~smetz3
> >
> >
> >
> >
> >
> > 
> >
> > From: IBM Mainframe Discussion List  on behalf
> > of Phil Smith III 
> >
> > Sent: Monday, August 17, 2020 10:07 PM
> >
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Subject: Name those boxes
> >
> >
> >
> >
> >
> https://secure-web.cisco.com/1wkescQogaCLX8ueoKv8kHzmBmghk3VYI8ArOTGMD8PbFT_AcfhqD2o0A9G3F6datv8ROLRHa2cqqkRALje2QbH79Tb0ldDn-Bpko56xBrZAMvTDM77nB1aUT1_X-Ru-H_gCDWXboEvJvGp66tNPt5DDOHVeuo1TfitH8KsbfeKGNtnmtA_ov9bBcb9djDmfmvbTy2ZB7T5mnmCDXwWQ6VMrvHIoXe2X0Ph4ZZJBs1gTIgtxKCAlxfiH6MktaiIATzElHIMReMi-izExYjyGfpqy80hU5EpKSeeAOpYZNhq9Q9gpR_mjikzaNse7d0BW8gS4RxFMoAnR5d-pIAvOE2IoImQGSivF4Poj_lHUTXICPU2riiI5VjMehFThb0X751iX66GpSN3G9EHDSbzmKiPPOdZ8yFiYBMYJdiaN3wEDSfECSo_AnEhSS5nRkYw3OrD2JgYwlVrogAz1nVpBbDw/https%3A%2F%2Fi.redd.it%2Fkd2ebwoovbh51.jpg
> >
> >
> >
> >
> >
> >
> >
> > Best guess so far: 1415, console etc. for 1410. For extra credit,
> identify
> > small box on desk, too (not the phone or the 2741).
> >
> >
> >
> >
> >
> > --
> >
> > 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

Re: GIMUNZIP error

[Allan Staller]

Please post the job log

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Tuesday, August 18, 2020 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: GIMUNZIP error

[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 have been trying to unzip a USS file and I keep getting the following:
GIM68200E ** PROCESSING FAILED FOR THE /bin/pax UNIX SYSTEM SERVICE COMMAND.
GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE Is this 
pointing to lack of space in my USS file system?
How do I resolve this?
thanks
Bill

--
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

Re: GIMUNZIP error

[Allan Staller]

Your target file is too small. I wanted to see if you were receiving the error 
on SMPWRK or  the dest file.

The hfs/zfs  that contains (/u/hdbswxg/smpnts/U0226/) needs to be cleaned 
up or expanded.
If a zfs zfsadm aggrow will suffice. Otherwist just follow the standard 
procedures o copy/expand a hfs.


HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Tuesday, August 18, 2020 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GIMUNZIP error

[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.]

 Top of Data **
ICH70001I HDBSWXG  LAST ACCESS AT 08:20:47 ON TUESDAY, AUGUST 18, 2020 IEFA111I 
HDBSWXG1 IS USING THE FOLLOWING JOB RELATED SETTINGS:
 SWA=BELOW,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB
IEF236I ALLOC. FOR HDBSWXG1 UNZIP
IGD101I SMS ALLOCATED TO DDNAME (SYSUT3  )
DSN (SYS20231.T083154.RA000.HDBSWXG1.R0503941)
STORCLAS (SCTEMP) MGMTCLAS () DATACLAS ()
VOL SER NOS= TEMP54
IGD101I SMS ALLOCATED TO DDNAME (SYSUT4  )
DSN (SYS20231.T083154.RA000.HDBSWXG1.R0503942)
STORCLAS (SCTEMP) MGMTCLAS () DATACLAS ()
VOL SER NOS= TEMP50
IGD103I SMS HFS FILE ALLOCATED TO DDNAME SMPJHOME IGD103I SMS HFS FILE 
ALLOCATED TO DDNAME SMPCPATH IEF237I JES2 ALLOCATED TO SMPOUT IEF237I JES2 
ALLOCATED TO SYSPRINT IGD103I SMS HFS FILE ALLOCATED TO DDNAME SMPDIR IEF237I 
JES2 ALLOCATED TO SYSIN IGD103I SMS HFS FILE ALLOCATED TO DDNAME SMP1 
IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMP1) FILENAME IS 
(/u/hdbswxg/smpnts/U0226/smpe2020231083155165398/GIMFAF.XML)
IEF142I HDBSWXG1 UNZIP - STEP WAS EXECUTED - COND CODE 0012
IGD105I SYS20231.T083154.RA000.HDBSWXG1.R0503941 DELETED,   DDNAME=SYSUT3
IGD105I SYS20231.T083154.RA000.HDBSWXG1.R0503942 DELETED,   DDNAME=SYSUT4
IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMPJHOME) FILENAME IS 
(/usr/lpp/java/J8.0/) IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMPCPATH) 
FILENAME IS (/usr/lpp/smp/classes/)
IEF285I   HDBSWXG.HDBSWXG1.J0059480.D102.? SYSOUT
IEF285I   HDBSWXG.HDBSWXG1.J0059480.D103.? SYSOUT
IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMPDIR  ) FILENAME IS 
(/u/hdbswxg/smpnts/U0226/)
IEF285I   HDBSWXG.HDBSWXG1.J0059480.D101.? SYSIN

-- SMF STEP STATS -
  ***
  *  NO. *  *  * TCB+SRB *  USED  *  DISK  *  TAPE  *
  ***
  *  *  *  * ****
  *   001* UNZIP* GIMUNZIP * 0.10*304 * 000* 000*
  ***
  ***

IEF373I STEP/UNZIP   /START 2020231.0831
IEF032I STEP/UNZIP   /STOP  2020231.0921
CPU: 0 HR  00 MIN  00.10 SECSRB: 0 HR  00 MIN  00.00 SEC
VIRT:   304K  SYS:   372K  EXT:  428K  SYS:11588K
ATB- REAL:  4056K  SLOTS: 0K
 VIRT- ALLOC:  11M SHRD:   0M

-- SMF JOB STATS --
  ***
  * SYS   JOBNAMESTEPS   ACCT INFO   CLASS  CPUTIME *
  * ID  TCB+SRB *
  ***
  * *  * *   *   *  *
  *T33N * HDBSWXG1 * 001 *000481P6H40* 0 *  0.10*
  ***

IEF375I  JOB/HDBSWXG1/START 2020231.0831 IEF033I  JOB/HDBSWXG1/STOP  
2020231.0921
CPU: 0 HR  00 MIN  00.10 SECSRB: 0 HR  00 MIN  00.00 SEC
 *** Bottom of Data 

--
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 

Re: GIMUNZIP error

[Bill Giannelli]

 Top of Data **
ICH70001I HDBSWXG  LAST ACCESS AT 08:20:47 ON TUESDAY, AUGUST 18, 2020 
IEFA111I HDBSWXG1 IS USING THE FOLLOWING JOB RELATED SETTINGS: 
 SWA=BELOW,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB 
IEF236I ALLOC. FOR HDBSWXG1 UNZIP  
IGD101I SMS ALLOCATED TO DDNAME (SYSUT3  ) 
DSN (SYS20231.T083154.RA000.HDBSWXG1.R0503941) 
STORCLAS (SCTEMP) MGMTCLAS () DATACLAS ()  
VOL SER NOS= TEMP54
IGD101I SMS ALLOCATED TO DDNAME (SYSUT4  ) 
DSN (SYS20231.T083154.RA000.HDBSWXG1.R0503942) 
STORCLAS (SCTEMP) MGMTCLAS () DATACLAS ()  
VOL SER NOS= TEMP50
IGD103I SMS HFS FILE ALLOCATED TO DDNAME SMPJHOME  
IGD103I SMS HFS FILE ALLOCATED TO DDNAME SMPCPATH  
IEF237I JES2 ALLOCATED TO SMPOUT   
IEF237I JES2 ALLOCATED TO SYSPRINT 
IGD103I SMS HFS FILE ALLOCATED TO DDNAME SMPDIR
IEF237I JES2 ALLOCATED TO SYSIN
IGD103I SMS HFS FILE ALLOCATED TO DDNAME SMP1
IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMP1)  
FILENAME IS (/u/hdbswxg/smpnts/U0226/smpe2020231083155165398/GIMFAF.XML) 
IEF142I HDBSWXG1 UNZIP - STEP WAS EXECUTED - COND CODE 0012  
IGD105I SYS20231.T083154.RA000.HDBSWXG1.R0503941 DELETED,   DDNAME=SYSUT3
IGD105I SYS20231.T083154.RA000.HDBSWXG1.R0503942 DELETED,   DDNAME=SYSUT4
IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMPJHOME)  
FILENAME IS (/usr/lpp/java/J8.0/)
IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMPCPATH)  
FILENAME IS (/usr/lpp/smp/classes/)  
IEF285I   HDBSWXG.HDBSWXG1.J0059480.D102.? SYSOUT
IEF285I   HDBSWXG.HDBSWXG1.J0059480.D103.? SYSOUT
IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMPDIR  )  
FILENAME IS (/u/hdbswxg/smpnts/U0226/)   
IEF285I   HDBSWXG.HDBSWXG1.J0059480.D101.? SYSIN 
 
-- SMF STEP STATS -  
  ***
  *  NO. *  *  * TCB+SRB *  USED  *  DISK  *  TAPE  *   
  ***   
  *  *  *  * ****   
  *   001* UNZIP* GIMUNZIP * 0.10*304 * 000* 000*   
  ***   
  ***   

IEF373I STEP/UNZIP   /START 2020231.0831
IEF032I STEP/UNZIP   /STOP  2020231.0921
CPU: 0 HR  00 MIN  00.10 SECSRB: 0 HR  00 MIN  00.00 SEC
VIRT:   304K  SYS:   372K  EXT:  428K  SYS:11588K   
ATB- REAL:  4056K  SLOTS: 0K
 VIRT- ALLOC:  11M SHRD:   0M   

-- SMF JOB STATS -- 
  ***   
  * SYS   JOBNAMESTEPS   ACCT INFO   CLASS  CPUTIME *   
  * ID  TCB+SRB *   
  ***   
  * *  * *   *   *  *   
  *T33N * HDBSWXG1 * 001 *000481P6H40* 0 *  0.10*   
  ***   

IEF375I  JOB/HDBSWXG1/START 2020231.0831
IEF033I  JOB/HDBSWXG1/STOP  2020231.0921
CPU: 0 HR  00 MIN  00.10 SECSRB: 0 HR  00 MIN  00.00 SEC
 *** Bottom of 

zCX Issues

[Michael Babcock]

We have a zCX instance up and running and have created a Docker ID 
(Docker admin ID, not a Docker User).  We are trying to pull an image 
from our internal docker repository but are getting a certificate 
error.    I have our internal corporate root cert (and intermediate 
cert) defined when I defined the zCX instance.


Can we specify a different location for our certs when signed into the 
Docker admin ID when using the Pull command?  Or am I missing something 
in the config.  There are no firewalls/proxies between our internal 
docker hub and the zCX instance


(I’ve scrubbed the server names)

The curl command works.

curl -vv -s https://our_server.com/v2/

But the docker pull command fails.

Error response from daemon: Get https://our_server.com/v2/ 
: x509: certificate signed by unknown authority


Anyone?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: GIMUNZIP error

[Paul Gilmartin]

On Tue, 18 Aug 2020 08:03:54 -0700, Lizette Koehler wrote:

>As I recall, the actual problem was shown in a separate output which was 
>written to the BPXPRINT dd name.
>You may need to search all of the output from the job to find the actual error.
>
GIMUNZIP is doing a discourtesy to the programmer by displaying
insufficient information.  The message in this case should show the
text returned by edcmtxt or equivalent API:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/edcmtxt.htm


>-Original Message-
>From: Bill Giannelli
>Sent: Tuesday, August 18, 2020 8:45 AM
>
>I have been trying to unzip a USS file and I keep getting the following:
>GIM68200E ** PROCESSING FAILED FOR THE /bin/pax UNIX SYSTEM SERVICE COMMAND.
>GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE Is this 
>pointing to lack of space in my USS file system?
>How do I resolve this?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

GIMUNZIP error

[Bill Giannelli]

I have been trying to unzip a USS file and I keep getting the following:
GIM68200E ** PROCESSING FAILED FOR THE /bin/pax UNIX SYSTEM SERVICE COMMAND.
GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE   
Is this pointing to lack of space in my USS file system?
How do I resolve this?
thanks
Bill 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: GIMUNZIP error

[Lizette Koehler]

As I recall, the actual problem was shown in a separate output which was 
written to the BPXPRINT dd name.

You may need to search all of the output from the job to find the actual error.

Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Tuesday, August 18, 2020 6:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GIMUNZIP error

Please post the job log

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Tuesday, August 18, 2020 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: GIMUNZIP error

[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 have been trying to unzip a USS file and I keep getting the following:
GIM68200E ** PROCESSING FAILED FOR THE /bin/pax UNIX SYSTEM SERVICE COMMAND.
GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE Is this 
pointing to lack of space in my USS file system?
How do I resolve this?
thanks
Bill

--
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

Re: Reminder: Don't "Forget" Your CFRMPOL Keywords

[Jesse 1 Robinson]

I'm also a bit puzzled by the situation Ed describes. We've run parallel 
sysplexes since the mid-90s. We have had two widely spaced CEC failures that 
took down all data LPARs plus ICFs on the failing CEC. (In both cases we had a 
second CEC that housed backup ICF LPARs.) In neither case was there any damage 
to the pair of CFRM couple data sets, which as Bill Neiman pointed out, contain 
'compiled' CFRM policies as well as a record of the last policy used. For me, 
the head scratcher is what happened to Ed's CPL data sets? The recovering data 
LPARs should have been able to locate the correct CFRM policy and load it into 
the recovered ICF(s). If CFRMPOL differs from the CPL data set indication, you 
are prompted at IPL to choose which one to use. 

A sysplex-wide 'cold start' occurs when both ICF(s) and couple data sets are 
empty. We actually experience that situation regularly when we first IPL a 
sysplex at our DR site. ICFs have been newly initialized, and the CPL data sets 
have been freshly formatted. That's where COUPLExx CFRMPOL comes into play. 
That keyword by the way is younger than sysplex itself. In our early experience 
with DR (global mirror for z/OS, or XRC), we simply IPLed with no active CFRM 
policy. We would logon and run a job to create a policy from mirrored source, 
then SETXCF switch to that policy, then start up remaining apps. That procedure 
was kyboshed by the advent of GRS star, which *requires* a supporting structure 
at IPL. No policy, no structure, no IPL. So CFRMPOL was introduced to allow 
specification in a cold start. Around the same time, the formatting utility 
IXCL1DSU was enhanced to allow pointing to a couple data set other than the 
currently active one. Before we IPL a DR sysplex, we run IXCL1DSU from the 
driving system to stuff a policy into the DR system's couple data set, which is 
named by CFRMPOL. 


.
.
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  On Behalf Of Ed 
Jaffe
Sent: Monday, August 17, 2020 9:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Reminder: Don't "Forget" Your CFRMPOL Keywords

CAUTION EXTERNAL EMAIL

On 8/17/2020 4:59 AM, Bill Neiman wrote:
> I'm a bit confused by this.  CFRMPOL is only relevant when you IPL with a 
> CFRM couple data set (CDS) that has never been used before, so there was no 
> previously-activated policy.  It's normally not necessary to update the 
> CFRMPOL statement when you update your CFRM policy, unless you're changing 
> *which* policy you're using.  Even then, it only matters if you come up with 
> a new CFRM CDS.  The CFRM CDS records which policy was last used, and that's 
> the policy that will be used if you are forced to perform a sysplex-wide IPL. 
>  There must be more to this story.

Take a look at software case TS004055963 and hardware PMH 59261,227,000 (and 
several other related PMHs automatically opened since).

We came up with new CFRM data sets using the CFRM policy specified in CFRMPOL. 
While up, we switched CFRM policies but did not update CFRMPOL in COUPLExx as 
we should have (and as my reminder admonishes others to do). We then 
experienced a CPC failure in the early AM on 8/15 that took down all LPARs and 
internal coupling facilities. When coming up after the "crash," all of our 
structures were at the old sizes. Turned out we were running the policy 
specified in CFRMPOL and not the policy we had switched to prior to the crash. 
That's when I started this "reminder"
thread.

I took my own advice and corrected CFRMPOL to reflect our current policy. Good 
thing I did because we had a second second crash of the same type at 9PM that 
same day. Coming back up after that crash, all structure size are as expected.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Name those boxes

[Timothy Sipples]

For a real challenge, try figuring out the original manufacturer(s) and 
model(s) of the chair, desk, cabinet, and floor tiles. :-)

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: zCX Issues

[Timothy Sipples]

You're probably getting that error message because Docker cannot validate 
the (public) TLS server certificate when trying to establish the HTTPS 
connection to your private registry. If that's the problem, to fix it 
you'll need to get the public server certificate, add it to your z/OS 
Container Extensions configuration (via the z/OSMF workflow), then restart 
your zCX instance(s).

If I'm correct, just follow the instructions in the redbook:

http://www.redbooks.ibm.com/redbooks/pdfs/sg248457.pdf

The private registry section is Chapter 6. Refer to Section 6.5, and 
particularly page 122 step 2(b), for the z/OSMF steps. Also please take 
note of the note at the top of page 123. Much of the rest of Chapter 6 is 
also likely helpful.

If you've tried all that already, please post a follow-up. You should also 
be able to open a problem incident (PMR) with IBM z/OS Support if you 
suspect a defect.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN