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
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
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
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
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:
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
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
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
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,
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
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
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
>
>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
13 matches
Mail list logo
