>Where should one keep the keys?
>You can hand it over to Google or Microsoft or Amazon
>I guess...
You *could*, but I suggest you don't.
"Funny you should ask that." :-) Cloud object storage with IBM Cloud Hyper
Protect Crypto Services (Keep Your Own Key, FIPS 140-2 Level 4 HSMs) is a
Any one out there running TSSO (CBT File 404) under zOS 2.3?
As with many out there a client is trying to get out from under their
OEM software obligation. I have not used TSSO since early OS/390 2.10,
but up until then it ran like a charm, no issues, no worries.
However I have not used it
On 9/03/2021 12:42 am, Lionel B Dyck wrote:
It appears that on one of my z/OS 2.4 systems I don't have this ssh issue but
on another I do. The difference is that one has a /etc/ssh/zos_ssh_config file
and the one that fails does not. Updating the /etc/ssh/zos_ssh_config file
thus fixed the
On Mon, 8 Mar 2021 18:47:30 +, Farley, Peter x23353 wrote:
>Why wouldn't they be totally compatible? ...
>
This sort of thing depends on the utility. For example,
AMATERSE PARM=UNPACK refuses to deal with //SYSUT1 DD PATH=...
But I can fool it with:
//SYSUT1 DD
BSAM and QSAM with extended format require a level of DFSMSdfp that supports
it. EXCP with extended format requires application code to deal with it. The
same applies to EAV.
Even when striping is handled by the director, you would need the appropriate
CCWs to request it.
--
Shmuel (Seymour
I have been working with EF data sets as they can be encrypted.
My understanding is that the interface for EXCP for EF data sets is not
published.
Lennie Dymoke-Bradshaw
‘Dance like no one is watching. Encrypt like everyone is.’
-Original Message-
From: IBM Mainframe Discussion List On
Why wouldn't they be totally compatible? I would think that striping occurs at
a much lower level than QSAM (probably EXCP or lower? maybe "Media Manager"
level?) so one would expect that QSAM wouldn't even know it was happening.
More sophisticated utilities like SORT may be aware of
On Sun, 7 Mar 2021 15:42:33 -0600, Paul Gilmartin wrote:
>>...
>>Don't know about striped RAID. I suspect there's no software support
>>for the desirable parallel I/O.
>Are such data sets compatible with Classic utilities such as IEBGENER
> or Assembler programs using QSAM?
QSAM or BSAM are
On Mon, 8 Mar 2021 11:15:56 -0600, Nigel Morton wrote:
>Have you considered using extended format sequential striped data sets?
>
>Define using a data class with DSNTYPE set to require or request extended
>format; control the number of stripes (which are read in parallel) using a
>storage class
Have you considered using extended format sequential striped data sets?
Define using a data class with DSNTYPE set to require or request extended
format; control the number of stripes (which are read in parallel) using a
storage class with a non-zero sustained data rate attribute. Choosing the
You can hand it over to Google or Microsoft or Amazon I guess...
- KB
‐‐‐ Original Message ‐‐‐
On Monday, March 8, 2021 8:51 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 8 Mar 2021 16:12:36 +0800, Timothy Sipples wrote:
>
> > ... Physical
> >
On Mon, 8 Mar 2021 16:12:36 +0800, Timothy Sipples wrote:
>... Physical
>tape is really the only practical last line of defense against malware,
>ransomware, corruption, and other data destroying events.
>...
>However, encrypted cloud object storage, typically backed with physical
>tape
It appears that on one of my z/OS 2.4 systems I don't have this ssh issue but
on another I do. The difference is that one has a /etc/ssh/zos_ssh_config file
and the one that fails does not. Updating the /etc/ssh/zos_ssh_config file
thus fixed the problem:
Change
from: ChannelConvert shell
Rewinding this discussion a bit, to my knowledge there's only one locally
FICON-attached physical tape solution for z/OS from one vendor that's
still in active development. The current iteration is IBM TS7770+IBM
TS4500+IBM TS1150.
Physical tape is still extremely useful, even more useful than
14 matches
Mail list logo
