See the TSO command PARMLIB in TSO/E System Programming Command Reference
to view or update (implement) TSOKEYxx.
On Fri, Oct 23, 2020 at 10:05 PM Clark Morris wrote:
> [Default] On 23 Oct 2020 15:01:21 -0700, in bit.listserv.ibm-main
> sme...@gmu.edu (Seymour J Metz) wrote:
>
> >Did you bounce
[Default] On 23 Oct 2020 15:01:21 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:
>Did you bounce TSO after the change?
If I understood Sam's question, it was how do you change TCAS defaults
by using TSOKEYxx which means to me that he expects TSO to come up
after IPL with th
Did you bounce TSO after the change?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Sam
Golob [sbgo...@cbttape.org]
Sent: Friday, October 23, 2020 5:06 PM
To: IBM-MAIN@
Hi Folks,
The TSOKEYxx parmlib member is supposed to have a whole set of
parameters that can (supposedly) be changed for TCAS. I was not
successful in being able to change ANY of them using the TSOKEYxx
PARMLIB member. The defaults always came back, no matter how I changed
the TSOKEY00
Somebody needs to sit Charles down and explain what "retired" means.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Pierre,
I believe you are mistaken.
CSNB* calls are for symmetric keys.
CSND* calls are for asymmetric keys.
This was true long before support for AES keys was introduced.
Lennie Dymoke-Bradshaw
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Pierre Fichaud
Sent: 2
Its been a long time since I've used and defined master keys, the keys I've
used were transport keys, those keys were generated after the DES master key
was set using the ISPF CSF utility.
so my use and examples are probably not usable for you, sorry
On Fri, 23 Oct 2020 15:00:18 -0300, Isabel w
Cameron,
Hmm I may be missing the entire requirement but remember that IEBPTPCH just
puts the member name on just the header record. So Using INCLUDE alone on
the member name will not work. you also need INREC when=GROUP to push it
on to the member content.
The following shows the order of proce
Hello Carmen, I don't have problems with the job, but probably with the
syntax of my control card.
I successfully define it in the CKDS, but after running the program, the
reason code is ICSF 2738 (10040)
Thank you
On Fri, Oct 23, 2020 at 2:56 PM Carmen Vitullo wrote:
> I think this is still v
I think this is still valid
//KGUP EXEC PGM=CSFKGUP
//CSFCKDS DD DISP=SHR,DSN=CSF.CPU3.CSFCKDS
//CSFDIAG DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=133,BLKSIZE=13300)
//CSFKEYS DD SYSOUT=*,DCB=(RECFM=FB,LRECL=208,BLKSIZE=3328)
//CSFSTMNT DD SYSOUT=*,DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200)
//CSFIN
I add the label the CKDS, with the KGUP utility (in a sandbox), the user
who submit the job, needs permission to the profile in the csfkeys class.
My problem is with the syntax of the "add" command to add this register in
the ckds.
Thanks again!
On Fri, Oct 23, 2020 at 1:45 PM Farley, Peter x2335
Hello folks,
I put together a small process that runs an IEBPTPCH to generate a stream
from one of our JCL Libraries.
Then I ran a small DFSORT to pull out the combinations of JCL Member Name
and the PROC Names that are executed from the JOB.
Everything is fine.
I do not understand the high level f
OK, I can see permission being needed to save the key from the other side into
the CKDS (one does not want to let just anyone update CKDS), but does the
program / userid that just wants to USE the saved key also need permission just
to compute a hash with that key?
That's the part I would see a
Peter,
We are given a key from the other side to do the hash, and this key is that
we want to preserve
Thank you
On Fri, Oct 23, 2020 at 1:33 PM Farley, Peter x23353 <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> PMFJI here and perhaps I misunderstand the requirement, but requiring
Hello!
And Why the use of CSNBHMG asked me to define de AES-MK?
Thanks!
On Fri, Oct 23, 2020 at 1:17 PM Pierre Fichaud wrote:
> Hi,
> CSNB* calls are DES
> CSND* calls are AES.
> If you are using CSNBHMG you need the DES master key to be set.
> And the label use
PMFJI here and perhaps I misunderstand the requirement, but requiring ESF
permission to compute a hash makes no sense to me, even from the POV of a
paranoid liability attorney.
What possible technical justification is there (other than "the lawyers said we
needed it") is there for such a requir
Hi,
CSNB* calls are DES
CSND* calls are AES.
If you are using CSNBHMG you need the DES master key to be set.
And the label used in the call needs to be in the CKDS.
And you need permissions defined in RACF.
Regards, Pierre.
-
ICSF 2738 means that you are trying to use a DES key when only AES is
supported, or that you are trying an AES key when only DES is supported.
Check how you are making the call..
Joe
On Fri, Oct 23, 2020 at 9:59 AM Isabel wrote:
> Hello!
>
> I'm new to ICSF, and in my Installation they want to
These PTFs are against IBM's z/OSMF product, not the Linux Foundation's
OMP Zowe open source project https://www.zowe.org/
On 10/22/2020 5:29 AM, Mike Schwab wrote:
https://twitter.com/A_Hermelink/status/1319196681527754753?s=20
@mwalle
I'm looking at a list of recent z/OSMF performance APARs
Hello!
I'm new to ICSF, and in my Installation they want to use the following
callable service: CSNBHMG, and we have different problems. We are running
z/OS 2.2, Crypto Express 5 and FMID=HCR77B0
1) after executing the cobol program that invokes that service, it ended
with return code = 12 (C). A
... I think PDSE on LNKLST *may have*
secondary extents and it is NOT bad practise like in case of PDS.
A PDSE counts as having only one extent. That correlates to the DEB for
the opened concatenation having only one extent entry for a PDSE.
I conclude that the information about other extents
Why do you assume there is/should be other abend than x37?
Any request for new place in the dataset could end with such an abend.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 23.10.2020 o 15:15, Joel C. Ewing pisze:
Mike,
Did you miss the "assuming the PDSE has no free blocks and cannot be
ex
Mike,
Did you miss the "assuming the PDSE has no free blocks and cannot be
extended"?
I was just curious if the PDSE logic mimicked the PDS behavior of
making a distinction in the failure response for a full and
non-extendable PDSE depending on whether the no-more-space failure is
first detected
23 matches
Mail list logo
