Future meeting

[Neale Ferguson]

We've been doing some planning to get a post-COVID Hillgang meeting happening 
(Hillgang is the DC/VA/MD local user group for z/VM and Linux on z). 

Before we look at reserving space I have a simple survey to see what your 
meeting preference(s) are. Please go to https://www.surveymonkey.com/r/NWSX6LW 
and submit your preference.

Neale


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

Re: zEDC compression on z13 and z15

[Michael Oujesky]

Might you have a LISTCAT ALL for these two files?  I't would be good 
to get more detailed information on the compression.  Rather looks 
like zEDC did not get used on both of these.



At 03:40 PM 7/22/2021, PINION, RICHARD W. wrote:

z13 created dataset LISTC & DCB,

STATISTICS 

  USER-DATA-SIZE27761896449 
COMP-USER-DATA-SIZE2689053885

  SIZES-VALID(YES)

Management class . . : MC1GEND Allocated cylinders : 3,170
Storage class  . . . : STANDARDAllocated extents . : 1
 Volume serial . . . : TL0018
 Device type . . . . : 3390
Data class . . . . . : COMP
 Organization  . . . : PS Current Utilization
 Record format . . . : VB  Used cylinders  . . : 3,170
 Record length . . . : 23552   Used extents  . . . : 1
 Block size  . . . . : 23556
 1st extent cylinders: 3170
 Secondary cylinders : 250Dates
 Data set name type  : EXTENDEDCreation date . . . : 2021/07/01
   Referenced date . . : 2021/07/22
   Expiration date . . : ***None***
 SMS Compressible  . : YES
 Extended Attributes   NO

z15 created dataset LISTC & DCB

STATISTICS 

  USER-DATA-SIZE27761896449 
COMP-USER-DATA-SIZE3629379499

  SIZES-VALID(YES)


Management class . . : MC1GEND Allocated cylinders : 4,279
Storage class  . . . : STANDARDAllocated extents . : 11
 Volume serial . . . : PL0024 +
 Device type . . . . : 3390
Data class . . . . . : COMP
 Organization  . . . : PS Current Utilization
 Record format . . . : VB  Used cylinders  . . : 4,279
 Record length . . . : 23552   Used extents  . . . : 11
 Block size  . . . . : 23556
 1st extent cylinders: 150
 Secondary cylinders : 99 Dates
 Data set name type  : EXTENDEDCreation date . . . : 2021/07/22
   Referenced date . . : 2021/07/22
   Expiration date . . : ***None***
 SMS Compressible  . : YES
 Extended 
Attributes   NO 



-Original Message-
From: IBM Mainframe Discussion List  On 
Behalf Of Chuck Kreiter

Sent: Thursday, July 22, 2021 4:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC compression on z13 and z15

[External Email. Exercise caution when clicking links or opening attachments.]

We went from z14 to z15's and didn't notice any difference in compression.
I would be curious to see listcat of both showing the user data size 
and the comp data size as well as the dataset DCB attributes.


-Original Message-
From: IBM Mainframe Discussion List 
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of PINION, RICHARD W.

Sent: Thursday, July 22, 2021 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zEDC compression on z13 and z15

We migrated from a z13 to a z15 this past weekend.  We are running 
z/OS 2.2, z/OS 2.2 on the z13, and the same z/OS 2.2 on the 
z15.  z15 maintenance was applied to z/OS 2.2, and activated a 
couple of months ago.  We are using the same SMS configuration on 
the z15 as the z13, and that includes the zEDC compression Data Class.


I restored a dataset that was created on the z13 using zEDC 
compression, and needed to make a copy of the dataset on the z15.  I 
was surprised to see an almost 20,000 track difference between the 
z13 created dataset, and the z15 created dataset.  I used the same 
SMS Data Class to make the z15 version of the dataset.



Enter "/" to select actionTracks %Used

Z13.CREATED.DATA.SET 4755099
Z15.CREATED.DATA.SET 64555  100


SMS allocation messages for the z15 created dataset follows.

IGD17070I DATA SET Z15.CREATED.DATA.SET
ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S).
IGD17160I DATA SET Z15.CREATED.DATA.SET
IS ELIGIBLE FOR COMPRESSION
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2  )
DSN (Z15.CREATED.DATA.SET)
STORCLAS (STANDARD) MGMTCLAS (DE180DAY) DATACLAS (COMP)
VOL SER NOS= TL0018


I have not looked into the TCB/SRB I/O numbers of the
z13 creating job to compare against the z15 job.

Anyone have an idea as to why such a dramatic difference?

Confidentiality notice:
This e-mail message, including any attachments, may contain legally 
privileged and/or confidential information. If you are not the 
intended recipient(s), or the employee or agent responsible for 
delivery of this message to the intended recipient(s), you are 
hereby notified that any dissemination, distribution, or copying of 
this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and 
delete this e-mail message from your computer.


--
For IBM-MAIN subscribe / 

Re: How should I send file to another sysplex securely.

[Charles Mills]

Agreed. By "roll your own" I was referring to

>1)  Create an asymmetric public + private key pair on the destination 
>system.
>2)  Transfer the destination system's public key to the source system.
>3)  Create a symmetric key on the source system.

Etc.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Grant Taylor
Sent: Thursday, July 22, 2021 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How should I send file to another sysplex securely.

On 7/22/21 2:58 PM, Charles Mills wrote:
> I would say in no event does the OP want to "roll his own" or "cobble 
> something together out of bits and pieces."

I think we have different ideas of what "roll your own" means.

Personally, I don't believe that running some standard commands (at 
least from a unix perspective), transferring two files, and running some 
closely related commands to be "rolling your own".

At least not any more than creating JCL is "roll your own".

> This problem is what FTP does for a living.

Agreed.

> An investment in secure FTP is an investment in the future, not just 
> this one problem.

Yes.

Though, sometimes such an /investment/ means a LOT more work, especially 
if something is going to be persistent and need to adhere to corporate 
security policies / scans / etc.

Often, especially for one off cases, doing a little bit more work 
manually is the simpler and faster of the solutions.

> Oh! In Step 3 below, add to the sentence "... using a secure 
> cryptographic-quality random-number generator."

Agreed.

I expect that any contemporary / patched operating system to 
sufficiently address this concern.  Especially when following vendor 
best practices regarding cryptographic utilities that they provide.

> Again, you don't want to roll your own on this. Wy too many traps 
> for the unwary.

See above.  There is a big difference in putting some commands in JCL vs 
coding your own cryptographic algorithms, including the math and keying 
algorithms.  There is an apt saying for that "friends don't let friends 
create their own cryptographic algorithms".  Friends help friends use 
well established cryptographic algorithms in the proper way.



-- 
Grant. . . .
unix || die

--
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: zEDC compression on z13 and z15

[Jim Mulder]

https://www.ibm.com/support/pages/system/files/inline-files/zOS_Support_for_z15.pdf

See page 43 in this presentation.
Do you have the PTF for APAR OA56143 installed?

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on 
07/22/2021 03:55:28 PM:

> From: "PINION, RICHARD W." 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 07/22/2021 08:16 PM
> Subject: zEDC compression on z13 and z15
> Sent by: "IBM Mainframe Discussion List" 
> 
> We migrated from a z13 to a z15 this past weekend.  We are running z/OS 
2.2,
> z/OS 2.2 on the z13, and the same z/OS 2.2 on the z15.  z15 maintenance 
was
> applied to z/OS 2.2, and activated a couple of months ago.  We are 
> using the same
> SMS configuration on the z15 as the z13, and that includes the zEDC 
> compression
> Data Class.
> 
> I restored a dataset that was created on the z13 using zEDC 
> compression, and needed
> to make a copy of the dataset on the z15.  I was surprised to see an
> almost 20,000
> track difference between the z13 created dataset, and the z15 
> created dataset.  I
> used the same SMS Data Class to make the z15 version of the dataset.
> 
> 
> Enter "/" to select actionTracks %Used
> 
> Z13.CREATED.DATA.SET 4755099
> Z15.CREATED.DATA.SET 64555  100
> 
> 
> SMS allocation messages for the z15 created dataset follows.
> 
> IGD17070I DATA SET Z15.CREATED.DATA.SET
> ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S).
> IGD17160I DATA SET Z15.CREATED.DATA.SET
> IS ELIGIBLE FOR COMPRESSION
> IGD101I SMS ALLOCATED TO DDNAME (SYSUT2  )
> DSN (Z15.CREATED.DATA.SET)
> STORCLAS (STANDARD) MGMTCLAS (DE180DAY) DATACLAS (COMP)
> VOL SER NOS= TL0018
> 
> 
> I have not looked into the TCB/SRB I/O numbers of the
> z13 creating job to compare against the z15 job.
> 
> Anyone have an idea as to why such a dramatic difference?
> 
> Confidentiality notice: 
> This e-mail message, including any attachments, may contain legally 
> privileged and/or confidential information. If you are not the 
> intended recipient(s), or the employee or agent responsible for 
> delivery of this message to the intended recipient(s), you are 
> hereby notified that any dissemination, distribution, or copying of 
> this e-mail message is strictly prohibited. If you have received 
> this message in error, please immediately notify the sender and 
> delete this e-mail message from your computer.
> 
> --
> 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: How should I send file to another sysplex securely.

[Mike Schwab]

Since a lot of chips a manufactured in China, a device could be
sending China your data, which is why Huawei is being banned from
communications networks.

On Thu, Jul 22, 2021 at 7:09 PM Charles Mills  wrote:
>
> Guys, this is the problem with inventing your own solution.
>
> Public keys are, well, public. You can transfer them over an insecure medium. 
> You can put them on your Web site. You can announce them over the PA. The TLS 
> protocol transfers public keys over the communication link before it is 
> trusted.
>
> > If the OP can't safely get a public [key] copied between LPARs / CECs in a 
> > trusted network
>
> The new fashion in fact is to NOT trust internal networks. You really don't 
> know how far an intruder may have intruded, so you should assume every 
> communication channel is insecure. In the new era of cloud and partners and 
> bring your own device, exactly what is an internal and what is an external 
> network? (This new paradigm is called "Zero Trust." 
> https://csrc.nist.gov/publications/detail/sp/800-207/final. I have a 
> presentation on Zero Trust coming up courtesy of New Era, but we don't have a 
> date yet. A good month or so out.)
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Grant Taylor
> Sent: Thursday, July 22, 2021 4:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How should I send file to another sysplex securely.
>
> On 7/22/21 3:17 PM, Paul Gilmartin wrote:
> > It lacks authentication and does not prevent MITM attacks:
>
> I think we might be talking about two slightly, but distinctly,
> different scenarios.
>
> I took the OP's statement to be talking about needing to move data from
> one LPAR / CEC on the left side of the room to another LPAR / CEC on the
> right side of the room.  Wherein the room and the network are trusted; a
> la. internal company network.
>
> What's more is I was anticipating the OP to be performing all of the
> steps.  As such, the OP could validate that the public key copied from
> the destination system to the source system was in fact one in the same.
>   Be it byte for byte comparison of hex output, or comparison of
> cryptographic hashes, or even IND$FILE transfers from the destination
> system to the source system via the common workstation / terminal emulator.
>
> Aside:  If the OP needs to do the transfer in conjunction with a fellow
> SYSOP from elsewhere in the world, they can get on the phone with each
> other (or use some other out of band communications method that they
> trust) to confirm public key.
>
> Further aside:  If the OP can't safely get a public copied between LPARs
> / CECs in a trusted network, then s/he has bigger problems.  If
> interlopers are messing with such a transfer, ... that's a *LOT* bigger
> problem.  Problems big enough that asking for help on a mailing list is
> quite likely not sufficient.
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> 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



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: How should I send file to another sysplex securely.

[Charles Mills]

Guys, this is the problem with inventing your own solution.

Public keys are, well, public. You can transfer them over an insecure medium. 
You can put them on your Web site. You can announce them over the PA. The TLS 
protocol transfers public keys over the communication link before it is trusted.

> If the OP can't safely get a public [key] copied between LPARs / CECs in a 
> trusted network

The new fashion in fact is to NOT trust internal networks. You really don't 
know how far an intruder may have intruded, so you should assume every 
communication channel is insecure. In the new era of cloud and partners and 
bring your own device, exactly what is an internal and what is an external 
network? (This new paradigm is called "Zero Trust." 
https://csrc.nist.gov/publications/detail/sp/800-207/final. I have a 
presentation on Zero Trust coming up courtesy of New Era, but we don't have a 
date yet. A good month or so out.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Grant Taylor
Sent: Thursday, July 22, 2021 4:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How should I send file to another sysplex securely.

On 7/22/21 3:17 PM, Paul Gilmartin wrote:
> It lacks authentication and does not prevent MITM attacks:

I think we might be talking about two slightly, but distinctly, 
different scenarios.

I took the OP's statement to be talking about needing to move data from 
one LPAR / CEC on the left side of the room to another LPAR / CEC on the 
right side of the room.  Wherein the room and the network are trusted; a 
la. internal company network.

What's more is I was anticipating the OP to be performing all of the 
steps.  As such, the OP could validate that the public key copied from 
the destination system to the source system was in fact one in the same. 
  Be it byte for byte comparison of hex output, or comparison of 
cryptographic hashes, or even IND$FILE transfers from the destination 
system to the source system via the common workstation / terminal emulator.

Aside:  If the OP needs to do the transfer in conjunction with a fellow 
SYSOP from elsewhere in the world, they can get on the phone with each 
other (or use some other out of band communications method that they 
trust) to confirm public key.

Further aside:  If the OP can't safely get a public copied between LPARs 
/ CECs in a trusted network, then s/he has bigger problems.  If 
interlopers are messing with such a transfer, ... that's a *LOT* bigger 
problem.  Problems big enough that asking for help on a mailing list is 
quite likely not sufficient.



-- 
Grant. . . .
unix || die

--
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: How should I send file to another sysplex securely.

[Grant Taylor]

On 7/22/21 5:42 PM, Lennie Dymoke-Bradshaw wrote:
There is a document by Philippe Richard of IBM France which documents 
this problem and demonstrates how to resolve it using a set of REXX 
routines written by Eysha Powers.


It is entitled "Transporting AES encrypted data keys from one z/OS host 
to another". As far as I can see it has no manual number.


This looks like it (at a quick glance).

https://www.ibm.com/support/pages/system/files/inline-files/Transporting_AES_DATA_keys_new.pdf

$ReadingList++



--
Grant. . . .
unix || die

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

Re: How should I send file to another sysplex securely.

[Grant Taylor]

On 7/22/21 2:58 PM, Charles Mills wrote:
I would say in no event does the OP want to "roll his own" or "cobble 
something together out of bits and pieces."


I think we have different ideas of what "roll your own" means.

Personally, I don't believe that running some standard commands (at 
least from a unix perspective), transferring two files, and running some 
closely related commands to be "rolling your own".


At least not any more than creating JCL is "roll your own".


This problem is what FTP does for a living.


Agreed.

An investment in secure FTP is an investment in the future, not just 
this one problem.


Yes.

Though, sometimes such an /investment/ means a LOT more work, especially 
if something is going to be persistent and need to adhere to corporate 
security policies / scans / etc.


Often, especially for one off cases, doing a little bit more work 
manually is the simpler and faster of the solutions.


Oh! In Step 3 below, add to the sentence "... using a secure 
cryptographic-quality random-number generator."


Agreed.

I expect that any contemporary / patched operating system to 
sufficiently address this concern.  Especially when following vendor 
best practices regarding cryptographic utilities that they provide.


Again, you don't want to roll your own on this. Wy too many traps 
for the unwary.


See above.  There is a big difference in putting some commands in JCL vs 
coding your own cryptographic algorithms, including the math and keying 
algorithms.  There is an apt saying for that "friends don't let friends 
create their own cryptographic algorithms".  Friends help friends use 
well established cryptographic algorithms in the proper way.




--
Grant. . . .
unix || die

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

Re: How should I send file to another sysplex securely.

[Grant Taylor]

On 7/22/21 3:17 PM, Paul Gilmartin wrote:

It lacks authentication and does not prevent MITM attacks:


I think we might be talking about two slightly, but distinctly, 
different scenarios.


I took the OP's statement to be talking about needing to move data from 
one LPAR / CEC on the left side of the room to another LPAR / CEC on the 
right side of the room.  Wherein the room and the network are trusted; a 
la. internal company network.


What's more is I was anticipating the OP to be performing all of the 
steps.  As such, the OP could validate that the public key copied from 
the destination system to the source system was in fact one in the same. 
 Be it byte for byte comparison of hex output, or comparison of 
cryptographic hashes, or even IND$FILE transfers from the destination 
system to the source system via the common workstation / terminal emulator.


Aside:  If the OP needs to do the transfer in conjunction with a fellow 
SYSOP from elsewhere in the world, they can get on the phone with each 
other (or use some other out of band communications method that they 
trust) to confirm public key.


Further aside:  If the OP can't safely get a public copied between LPARs 
/ CECs in a trusted network, then s/he has bigger problems.  If 
interlopers are messing with such a transfer, ... that's a *LOT* bigger 
problem.  Problems big enough that asking for help on a mailing list is 
quite likely not sufficient.




--
Grant. . . .
unix || die

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

Re: How should I send file to another sysplex securely.

[Lennie Dymoke-Bradshaw]

Colin,

There is a document by Philippe Richard of IBM France which documents this 
problem and demonstrates how to resolve it using a set of REXX routines written 
by Eysha Powers. 

It is entitled "Transporting AES encrypted data keys from one z/OS host to 
another". As far as I can see it has no manual number. If you cannot find it 
from Philippe Richard, then I can send you a copy. The method makes use of 
standard ICSF calls to use EC keys to have the same AES data key installed into 
two distinct z/OS systems in a secure manner.

Once that key is installed in both systems, the data can be securely 
transferred in either direction.


Lennie Dymoke-Bradshaw
https://rsclweb.com 
‘Dance like no one is watching. Encrypt like everyone is.’


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: 22 July 2021 15:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How should I send file to another sysplex securely.

I was wondering the best way customers send sensitive data between z/OS images.
I was thinking about exporting one's private certificates.

   1. I can create a dataset of the private certificates on system 1 and
   have it encrypted.   I can send it to the other system.   How can I decrypt
   it on the remote system as it needs shared certificates?  It seems a
   chicken and egg problem
   2. I can put a password on the file through JCL and use FTPS to send
   it.   This could easily be broken

This is hypothetical, but I would be interested in how to do it.

Colin Paice

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

Knowledge center PDFs

[James Cradesh]

I am able to serve multiple vendor's pdf books via Library Server. Since LS is 
going away I got the KC up and running but I can't seem to get it to serve up 
any books other than knowledge center content.  Can anyone point me in the 
right direction?

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

Re: How should I send file to another sysplex securely.

[Charles Mills]

@Gil, works better than that. Watch my presentation  referenced earlier.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, July 22, 2021 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How should I send file to another sysplex securely.

On Thu, 22 Jul 2021 14:05:31 -0600, Grant Taylor wrote:

>On 7/22/21 12:49 PM, Mike Hochee wrote:
>>...
>There is also a hybrid approach in which a symmetric key is used to
>encrypt / decrypt the data and asymmetric keys to protect the first key.
>  --  My understanding is that symmetric encryption is multiple orders
>of magnitude faster than asymmetric encryption.
> 
This is routinely, almost  universally, done for asymmetric encryption.
It lacks authentication and does not prevent MITM attacks:

o An intruder can masquerade as the sender and supply forged data.

o An intruder can masquerade as the recipient and intercept sensitive data.

o Or both, if you're lucky.

I believe (I'm mostly guessing) that a Certificate Authority provides
authentication in a repository of public keys but, "Quis custodiet ipsos
custodes?"  Computers come with a table of recognized CAs and their
public keys embedded in the OS.  This amounts to making the computer
vendors the ultimate Certificate authorities.

https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

Or, the CAs could announce their public keys on NewsMax or Twitter.

>1)  Create an asymmetric public + private key pair on the destination
>system.
>2)  Transfer the destination system's public key to the source system.
>3)  Create a symmetric key on the source system.
>4)  Use the source system's symmetric key to encrypt the data.
>5)  Use the destination system's asymmetric public key to encrypt the
>source system's symmetric key.
>6)  Transfer both the encrypted data and the encrypted symmetric key
>from the source system to the destination system.
>7)  Use the destination system's asymmetric private key to decrypt the
>source system's symmetric key.
>8)  Use the decrypted source system's symmetric key to decrypt the data.
>...
>n)  PROFIT!!!
>
>The data and the symmetric key protecting it are only unencrypted on the
>source and destination system.

-- gil

--
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: How should I send file to another sysplex securely.

[Paul Gilmartin]

On Thu, 22 Jul 2021 14:05:31 -0600, Grant Taylor wrote:

>On 7/22/21 12:49 PM, Mike Hochee wrote:
>>...
>There is also a hybrid approach in which a symmetric key is used to
>encrypt / decrypt the data and asymmetric keys to protect the first key.
>  --  My understanding is that symmetric encryption is multiple orders
>of magnitude faster than asymmetric encryption.
> 
This is routinely, almost  universally, done for asymmetric encryption.
It lacks authentication and does not prevent MITM attacks:

o An intruder can masquerade as the sender and supply forged data.

o An intruder can masquerade as the recipient and intercept sensitive data.

o Or both, if you're lucky.

I believe (I'm mostly guessing) that a Certificate Authority provides
authentication in a repository of public keys but, "Quis custodiet ipsos
custodes?"  Computers come with a table of recognized CAs and their
public keys embedded in the OS.  This amounts to making the computer
vendors the ultimate Certificate authorities.

https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

Or, the CAs could announce their public keys on NewsMax or Twitter.

>1)  Create an asymmetric public + private key pair on the destination
>system.
>2)  Transfer the destination system's public key to the source system.
>3)  Create a symmetric key on the source system.
>4)  Use the source system's symmetric key to encrypt the data.
>5)  Use the destination system's asymmetric public key to encrypt the
>source system's symmetric key.
>6)  Transfer both the encrypted data and the encrypted symmetric key
>from the source system to the destination system.
>7)  Use the destination system's asymmetric private key to decrypt the
>source system's symmetric key.
>8)  Use the decrypted source system's symmetric key to decrypt the data.
>...
>n)  PROFIT!!!
>
>The data and the symmetric key protecting it are only unencrypted on the
>source and destination system.

-- gil

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

Re: zEDC compression on z13 and z15

[Ed Jaffe]

On 7/22/2021 2:02 PM, Ed Jaffe wrote:


You should issue D PCIE and check for Status=ALLC.


Of course, that applies to the z13 only...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://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: zEDC compression on z13 and z15

[Ed Jaffe]

On 7/22/2021 1:54 PM, PINION, RICHARD W. wrote:

Also, I checked IFAPRDxx to make sure, zEDC is enabled, after the IPL from
this weekend.

-D PROD,state,all
  IFA111I 15.47.44 PROD DISPLAY 490
  S OWNERNAME FEATURE  VERSION  ID
E IBM CORP Z/OSZEDC* .* .*  5650-ZOS


You should issue D PCIE and check for Status=ALLC.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://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: How should I send file to another sysplex securely.

[Charles Mills]

@Mike, thanks for the kind words.

@Grant, yes, exactly, "pure" public key is way too slow to use for a 
significant file. The only practical approach is what you call "hybrid."

I would say in no event does the OP want to "roll his own" or "cobble something 
together out of bits and pieces."

This problem is what FTP does for a living. Either SFTP ("SSH FTP") which I am 
not real familiar with but I know works like a champ, or FTPS (FTP over TLS) 
which I am very familiar with. The two are totally different options; they do 
not interoperate. A client for one does not talk to a server for the other.

You need a secure (SFTP or FTPS) server at one end (sending or receiving, your 
choice) and some configuration at the other end. An investment in secure FTP is 
an investment in the future, not just this one problem.

You should be able to find lots of SHARE sessions and so forth on "how to 
install and configure and use a secure FTP server." There is help on this forum 
if necessary.

Oh! In Step 3 below, add to the sentence "... using a secure 
cryptographic-quality random-number generator." Again, you don't want to roll 
your own on this. Wy too many traps for the unwary.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Grant Taylor
Sent: Thursday, July 22, 2021 1:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How should I send file to another sysplex securely.

On 7/22/21 12:49 PM, Mike Hochee wrote:
> With private key (aka symmetric ) the same key is used to encrypt and 
> decrypt, and the key must be securely shared among business partners 
> (a vulnerability).  Pervasive or z/OS data set encryption uses private 
> key encryption.
> 
> With public key model (aka asymmetric) a key pair is generated 
> and the keys are mathematically related, this enables the secure 
> sharing of a public key with another organization. Public key 
> cryptography is quite elegant IMO and solves your chicken/egg 
> issue.

There is also a hybrid approach in which a symmetric key is used to 
encrypt / decrypt the data and asymmetric keys to protect the first key. 
  --  My understanding is that symmetric encryption is multiple orders 
of magnitude faster than asymmetric encryption.

1)  Create an asymmetric public + private key pair on the destination 
system.
2)  Transfer the destination system's public key to the source system.
3)  Create a symmetric key on the source system.
4)  Use the source system's symmetric key to encrypt the data.
5)  Use the destination system's asymmetric public key to encrypt the 
source system's symmetric key.
6)  Transfer both the encrypted data and the encrypted symmetric key 
from the source system to the destination system.
7)  Use the destination system's asymmetric private key to decrypt the 
source system's symmetric key.
8)  Use the decrypted source system's symmetric key to decrypt the data.
...
n)  PROFIT!!!

The data and the symmetric key protecting it are only unencrypted on the 
source and destination system.



-- 
Grant. . . .
unix || die

--
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: zEDC compression on z13 and z15

[PINION, RICHARD W.]

Also, I've check our SMS Data Class definition.  We have

ZP The system will not fail the allocation request but rather 
   create either a tailored compressed data set if the zEDC   
   function is not supported by the system or create a
   non-compressed extended format data set if the minimum 
   allocation amount requirement is not met.  

As, a test, I created a duplicate of that Data Class, and changed the
value to ZR.  The allocation as compressed was successful.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
PINION, RICHARD W.
Sent: Thursday, July 22, 2021 4:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC compression on z13 and z15

[External Email. Exercise caution when clicking links or opening attachments.]

OK, I've created another dataset that is single volume, same size.

General Data   Current Allocation
 Management class . . : DE180DAYAllocated cylinders : 4,279
 Storage class  . . . : STANDARDAllocated extents . : 5
  Volume serial . . . : TL0018
  Device type . . . . : 3390
 Data class . . . . . : COMP
  Organization  . . . : PS Current Utilization
  Record format . . . : VB  Used cylinders  . . : 4,279
  Record length . . . : 23552   Used extents  . . . : 5
  Block size  . . . . : 32760
  1st extent cylinders: 4000
  Secondary cylinders : 100Dates
  Data set name type  : EXTENDEDCreation date . . . : 2021/07/22
Referenced date . . : 2021/07/22
Expiration date . . : ***None***
  SMS Compressible  . : YES
  Extended Attributes   NO

Also, I checked IFAPRDxx to make sure, zEDC is enabled, after the IPL from this 
weekend.

-D PROD,state,all
 IFA111I 15.47.44 PROD DISPLAY 490
 S OWNERNAME FEATURE  VERSION  ID
E IBM CORP Z/OSZEDC* .* .*  5650-ZOS

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Thursday, July 22, 2021 4:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC compression on z13 and z15

[External Email. Exercise caution when clicking links or opening attachments.]

The z15 data set is multi-volume?

On 7/22/2021 1:40 PM, PINION, RICHARD W. wrote:
> z15 created dataset LISTC & DCB
>
> STATISTICS
>USER-DATA-SIZE27761896449 
> COMP-USER-DATA-SIZE3629379499
>SIZES-VALID(YES)
>
> Management class . . : MC1GEND Allocated cylinders : 4,279
> Storage class  . . . : STANDARDAllocated extents . : 11
>   Volume serial . . . : PL0024 +
>   Device type . . . . : 3390

--

Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!HnnddUIWDII9UQ!EfhKWkq6_Iwt9tHw_SPWs_FcFyNKIS5aN8PP0ynYjU1UarZ29iSpnp2NOh2X2kUX4Cs$



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 Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


--
For IBM-MAIN subscribe / signoff / 

Re: zEDC compression on z13 and z15

[PINION, RICHARD W.]

OK, I've created another dataset that is single volume, same size.

General Data   Current Allocation  
 Management class . . : DE180DAYAllocated cylinders : 4,279
 Storage class  . . . : STANDARDAllocated extents . : 5
  Volume serial . . . : TL0018 
  Device type . . . . : 3390   
 Data class . . . . . : COMP   
  Organization  . . . : PS Current Utilization 
  Record format . . . : VB  Used cylinders  . . : 4,279
  Record length . . . : 23552   Used extents  . . . : 5
  Block size  . . . . : 32760  
  1st extent cylinders: 4000   
  Secondary cylinders : 100Dates   
  Data set name type  : EXTENDEDCreation date . . . : 2021/07/22   
Referenced date . . : 2021/07/22   
Expiration date . . : ***None***   
  SMS Compressible  . : YES
  Extended Attributes   NO 

Also, I checked IFAPRDxx to make sure, zEDC is enabled, after the IPL from
this weekend.

-D PROD,state,all 
 IFA111I 15.47.44 PROD DISPLAY 490
 S OWNERNAME FEATURE  VERSION  ID 
E IBM CORP Z/OSZEDC* .* .*  5650-ZOS

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Thursday, July 22, 2021 4:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC compression on z13 and z15

[External Email. Exercise caution when clicking links or opening attachments.]

The z15 data set is multi-volume?

On 7/22/2021 1:40 PM, PINION, RICHARD W. wrote:
> z15 created dataset LISTC & DCB
>
> STATISTICS
>USER-DATA-SIZE27761896449 
> COMP-USER-DATA-SIZE3629379499
>SIZES-VALID(YES)
>
> Management class . . : MC1GEND Allocated cylinders : 4,279
> Storage class  . . . : STANDARDAllocated extents . : 11
>   Volume serial . . . : PL0024 +
>   Device type . . . . : 3390

--

Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!HnnddUIWDII9UQ!EfhKWkq6_Iwt9tHw_SPWs_FcFyNKIS5aN8PP0ynYjU1UarZ29iSpnp2NOh2X2kUX4Cs$



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
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

GDPS Manuals Link

[fred glenlake]

Hi List,

I am unsuccessfully trying to locate the hiding spot of the GDPS Manuals for 
V4R1 so I can download a few.   If anyone can share the link of where I could 
download them please.

Sent from Outlook

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

Re: zEDC compression on z13 and z15

[Ed Jaffe]

The z15 data set is multi-volume?

On 7/22/2021 1:40 PM, PINION, RICHARD W. wrote:

z15 created dataset LISTC & DCB

STATISTICS
   USER-DATA-SIZE27761896449 
COMP-USER-DATA-SIZE3629379499
   SIZES-VALID(YES)

Management class . . : MC1GEND Allocated cylinders : 4,279
Storage class  . . . : STANDARDAllocated extents . : 11
  Volume serial . . . : PL0024 +
  Device type . . . . : 3390


--

Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://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: zEDC compression on z13 and z15

[PINION, RICHARD W.]

Yes, the z13 had zEDC cards, enabled, and being used. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Thursday, July 22, 2021 4:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC compression on z13 and z15

[External Email. Exercise caution when clicking links or opening attachments.]

Just a dumb question: Did your z13 have zEDC cards installed? They were 
optional on the z13, but zEDC compression is included on the z15.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Chuck Kreiter
Sent: Thursday, July 22, 2021 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC compression on z13 and z15

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

We went from z14 to z15's and didn't notice any difference in compression.
I would be curious to see listcat of both showing the user data size and the 
comp data size as well as the dataset DCB attributes.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of PINION, RICHARD W.
Sent: Thursday, July 22, 2021 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zEDC compression on z13 and z15

We migrated from a z13 to a z15 this past weekend.  We are running z/OS 2.2, 
z/OS 2.2 on the z13, and the same z/OS 2.2 on the z15.  z15 maintenance was 
applied to z/OS 2.2, and activated a couple of months ago.  We are using the 
same SMS configuration on the z15 as the z13, and that includes the zEDC 
compression Data Class.

I restored a dataset that was created on the z13 using zEDC compression, and 
needed to make a copy of the dataset on the z15.  I was surprised to see an 
almost 20,000 track difference between the z13 created dataset, and the z15 
created dataset.  I used the same SMS Data Class to make the z15 version of the 
dataset.


Enter "/" to select actionTracks %Used

Z13.CREATED.DATA.SET 4755099
Z15.CREATED.DATA.SET 64555  100


SMS allocation messages for the z15 created dataset follows.

IGD17070I DATA SET Z15.CREATED.DATA.SET
ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S).
IGD17160I DATA SET Z15.CREATED.DATA.SET
IS ELIGIBLE FOR COMPRESSION
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2  )
DSN (Z15.CREATED.DATA.SET)
STORCLAS (STANDARD) MGMTCLAS (DE180DAY) DATACLAS (COMP)
VOL SER NOS= TL0018


I have not looked into the TCB/SRB I/O numbers of the
z13 creating job to compare against the z15 job.

Anyone have an idea as to why such a dramatic difference?

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
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: zEDC compression on z13 and z15

[PINION, RICHARD W.]

z13 created dataset LISTC & DCB,

STATISTICS  

  USER-DATA-SIZE27761896449 
COMP-USER-DATA-SIZE2689053885   
  SIZES-VALID(YES)

Management class . . : MC1GEND Allocated cylinders : 3,170 
Storage class  . . . : STANDARDAllocated extents . : 1 
 Volume serial . . . : TL0018  
 Device type . . . . : 3390
Data class . . . . . : COMP
 Organization  . . . : PS Current Utilization  
 Record format . . . : VB  Used cylinders  . . : 3,170 
 Record length . . . : 23552   Used extents  . . . : 1 
 Block size  . . . . : 23556   
 1st extent cylinders: 3170
 Secondary cylinders : 250Dates
 Data set name type  : EXTENDEDCreation date . . . : 2021/07/01
   Referenced date . . : 2021/07/22
   Expiration date . . : ***None***
 SMS Compressible  . : YES 
 Extended Attributes   NO  

z15 created dataset LISTC & DCB

STATISTICS  
   
  USER-DATA-SIZE27761896449 
COMP-USER-DATA-SIZE3629379499  
  SIZES-VALID(YES)  


Management class . . : MC1GEND Allocated cylinders : 4,279
Storage class  . . . : STANDARDAllocated extents . : 11   
 Volume serial . . . : PL0024 +   
 Device type . . . . : 3390   
Data class . . . . . : COMP   
 Organization  . . . : PS Current Utilization 
 Record format . . . : VB  Used cylinders  . . : 4,279
 Record length . . . : 23552   Used extents  . . . : 11   
 Block size  . . . . : 23556  
 1st extent cylinders: 150
 Secondary cylinders : 99 Dates   
 Data set name type  : EXTENDEDCreation date . . . : 2021/07/22   
   Referenced date . . : 2021/07/22   
   Expiration date . . : ***None***   
 SMS Compressible  . : YES
 Extended Attributes   NO   

 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Chuck Kreiter
Sent: Thursday, July 22, 2021 4:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC compression on z13 and z15

[External Email. Exercise caution when clicking links or opening attachments.]

We went from z14 to z15's and didn't notice any difference in compression.
I would be curious to see listcat of both showing the user data size and the 
comp data size as well as the dataset DCB attributes.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of PINION, RICHARD W.
Sent: Thursday, July 22, 2021 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zEDC compression on z13 and z15

We migrated from a z13 to a z15 this past weekend.  We are running z/OS 2.2, 
z/OS 2.2 on the z13, and the same z/OS 2.2 on the z15.  z15 maintenance was 
applied to z/OS 2.2, and activated a couple of months ago.  We are using the 
same SMS configuration on the z15 as the z13, and that includes the zEDC 
compression Data Class.

I restored a dataset that was created on the z13 using zEDC compression, and 
needed to make a copy of the dataset on the z15.  I was surprised to see an 
almost 20,000 track difference between the z13 created dataset, and the z15 
created dataset.  I used the same SMS Data Class to make the z15 version of the 
dataset.


Enter "/" to select actionTracks %Used

Z13.CREATED.DATA.SET 4755099
Z15.CREATED.DATA.SET 64555  100


SMS allocation messages for the z15 created dataset follows.

IGD17070I DATA SET Z15.CREATED.DATA.SET
ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S).
IGD17160I DATA SET Z15.CREATED.DATA.SET
IS ELIGIBLE FOR COMPRESSION
IGD101I SMS ALLOCATED TO 

Re: zEDC compression on z13 and z15

[Michael Watkins]

Just a dumb question: Did your z13 have zEDC cards installed? They were 
optional on the z13, but zEDC compression is included on the z15.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Chuck Kreiter
Sent: Thursday, July 22, 2021 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC compression on z13 and z15

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

We went from z14 to z15's and didn't notice any difference in compression.
I would be curious to see listcat of both showing the user data size and the 
comp data size as well as the dataset DCB attributes.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of PINION, RICHARD W.
Sent: Thursday, July 22, 2021 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zEDC compression on z13 and z15

We migrated from a z13 to a z15 this past weekend.  We are running z/OS 2.2, 
z/OS 2.2 on the z13, and the same z/OS 2.2 on the z15.  z15 maintenance was 
applied to z/OS 2.2, and activated a couple of months ago.  We are using the 
same SMS configuration on the z15 as the z13, and that includes the zEDC 
compression Data Class.

I restored a dataset that was created on the z13 using zEDC compression, and 
needed to make a copy of the dataset on the z15.  I was surprised to see an 
almost 20,000 track difference between the z13 created dataset, and the z15 
created dataset.  I used the same SMS Data Class to make the z15 version of the 
dataset.


Enter "/" to select actionTracks %Used

Z13.CREATED.DATA.SET 4755099
Z15.CREATED.DATA.SET 64555  100


SMS allocation messages for the z15 created dataset follows.

IGD17070I DATA SET Z15.CREATED.DATA.SET
ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S).
IGD17160I DATA SET Z15.CREATED.DATA.SET
IS ELIGIBLE FOR COMPRESSION
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2  )
DSN (Z15.CREATED.DATA.SET)
STORCLAS (STANDARD) MGMTCLAS (DE180DAY) DATACLAS (COMP)
VOL SER NOS= TL0018


I have not looked into the TCB/SRB I/O numbers of the
z13 creating job to compare against the z15 job.

Anyone have an idea as to why such a dramatic difference?

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
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: zEDC compression on z13 and z15

[Chuck Kreiter]

We went from z14 to z15's and didn't notice any difference in compression.
I would be curious to see listcat of both showing the user data size and the
comp data size as well as the dataset DCB attributes.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of PINION, RICHARD W.
Sent: Thursday, July 22, 2021 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zEDC compression on z13 and z15

We migrated from a z13 to a z15 this past weekend.  We are running z/OS 2.2,
z/OS 2.2 on the z13, and the same z/OS 2.2 on the z15.  z15 maintenance was
applied to z/OS 2.2, and activated a couple of months ago.  We are using the
same SMS configuration on the z15 as the z13, and that includes the zEDC
compression Data Class.

I restored a dataset that was created on the z13 using zEDC compression, and
needed to make a copy of the dataset on the z15.  I was surprised to see an
almost 20,000 track difference between the z13 created dataset, and the z15
created dataset.  I used the same SMS Data Class to make the z15 version of
the dataset.


Enter "/" to select actionTracks %Used

Z13.CREATED.DATA.SET 4755099
Z15.CREATED.DATA.SET 64555  100


SMS allocation messages for the z15 created dataset follows.

IGD17070I DATA SET Z15.CREATED.DATA.SET
ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S).
IGD17160I DATA SET Z15.CREATED.DATA.SET
IS ELIGIBLE FOR COMPRESSION
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2  )
DSN (Z15.CREATED.DATA.SET)
STORCLAS (STANDARD) MGMTCLAS (DE180DAY) DATACLAS (COMP)
VOL SER NOS= TL0018


I have not looked into the TCB/SRB I/O numbers of the
z13 creating job to compare against the z15 job.

Anyone have an idea as to why such a dramatic difference?

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally
privileged and/or confidential information. If you are not the intended
recipient(s), or the employee or agent responsible for delivery of this
message to the intended recipient(s), you are hereby notified that any
dissemination, distribution, or copying of this e-mail message is strictly
prohibited. If you have received this message in error, please immediately
notify the sender and delete this e-mail message from your computer.

--
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: How should I send file to another sysplex securely.

[Grant Taylor]

On 7/22/21 12:49 PM, Mike Hochee wrote:
With private key (aka symmetric ) the same key is used to encrypt and 
decrypt, and the key must be securely shared among business partners 
(a vulnerability).  Pervasive or z/OS data set encryption uses private 
key encryption.


With public key model (aka asymmetric) a key pair is generated 
and the keys are mathematically related, this enables the secure 
sharing of a public key with another organization. Public key 
cryptography is quite elegant IMO and solves your chicken/egg 
issue.


There is also a hybrid approach in which a symmetric key is used to 
encrypt / decrypt the data and asymmetric keys to protect the first key. 
 --  My understanding is that symmetric encryption is multiple orders 
of magnitude faster than asymmetric encryption.


1)  Create an asymmetric public + private key pair on the destination 
system.

2)  Transfer the destination system's public key to the source system.
3)  Create a symmetric key on the source system.
4)  Use the source system's symmetric key to encrypt the data.
5)  Use the destination system's asymmetric public key to encrypt the 
source system's symmetric key.
6)  Transfer both the encrypted data and the encrypted symmetric key 
from the source system to the destination system.
7)  Use the destination system's asymmetric private key to decrypt the 
source system's symmetric key.

8)  Use the decrypted source system's symmetric key to decrypt the data.
...
n)  PROFIT!!!

The data and the symmetric key protecting it are only unencrypted on the 
source and destination system.




--
Grant. . . .
unix || die

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

zEDC compression on z13 and z15

[PINION, RICHARD W.]

We migrated from a z13 to a z15 this past weekend.  We are running z/OS 2.2,
z/OS 2.2 on the z13, and the same z/OS 2.2 on the z15.  z15 maintenance was
applied to z/OS 2.2, and activated a couple of months ago.  We are using the 
same
SMS configuration on the z15 as the z13, and that includes the zEDC compression
Data Class.

I restored a dataset that was created on the z13 using zEDC compression, and 
needed
to make a copy of the dataset on the z15.  I was surprised to see an almost 
20,000
track difference between the z13 created dataset, and the z15 created dataset.  
I
used the same SMS Data Class to make the z15 version of the dataset.


Enter "/" to select actionTracks %Used

Z13.CREATED.DATA.SET 4755099
Z15.CREATED.DATA.SET 64555  100


SMS allocation messages for the z15 created dataset follows.

IGD17070I DATA SET Z15.CREATED.DATA.SET
ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S).
IGD17160I DATA SET Z15.CREATED.DATA.SET
IS ELIGIBLE FOR COMPRESSION
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2  )
DSN (Z15.CREATED.DATA.SET)
STORCLAS (STANDARD) MGMTCLAS (DE180DAY) DATACLAS (COMP)
VOL SER NOS= TL0018


I have not looked into the TCB/SRB I/O numbers of the
z13 creating job to compare against the z15 job.

Anyone have an idea as to why such a dramatic difference?

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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

Re: How should I send file to another sysplex securely.

[Mike Hochee]

Hi Colin, 

Best way probably varies depending on the use case, but basically you have two 
choices; public or private key cryptography. With private key (aka symmetric ) 
the same key is used to encrypt and decrypt, and the key must be securely 
shared among business partners (a vulnerability).  Pervasive or z/OS data set 
encryption uses private key encryption. 

With public key model (aka asymmetric) a key pair is generated and the keys are 
mathematically related, this enables the secure sharing of a public key with 
another organization. Public key cryptography is quite elegant IMO and solves 
your chicken/egg issue. There are many more  moving parts (see the latest draft 
of RFC 4880 for a look under the OPGP hood) , but most implementations do a 
good job of hiding  extraneous stuff. OpenPGP and OpenSSL are crypto systems 
based on the public key model. Secure email systems are typically use one of 
these.  A decent public key intro lives here 
https://en.wikipedia.org/wiki/Public-key_cryptography . Charles Mills gave an 
xlnt presentation which included coverage of the public key model in Oct 
2020...  https://www.newera-info.com/CM1.html 

HTH, 
Mike  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Colin Paice
Sent: Thursday, July 22, 2021 10:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How should I send file to another sysplex securely.

Caution! This message was sent from outside your organization.

I was wondering the best way customers send sensitive data between z/OS images.
I was thinking about exporting one's private certificates.

   1. I can create a dataset of the private certificates on system 1 and
   have it encrypted.   I can send it to the other system.   How can I decrypt
   it on the remote system as it needs shared certificates?  It seems a
   chicken and egg problem
   2. I can put a password on the file through JCL and use FTPS to send
   it.   This could easily be broken

This is hypothetical, but I would be interested in how to do it.

Colin Paice

--
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: [EXTERNAL] Re: How should I send file to another sysplex securely.

[Paul Gilmartin]

On Thu, 22 Jul 2021 14:19:41 +, Horne, Jim wrote:

>Why wouldn't you just write a batch job to invoke SFTP?  It is z/OS to z/OS 
>and can handle almost all files, as far as I know
> 
Like most of the suggestions so far, this begs the question of transferring the 
key.

For "almost all files" you need either Dovetailed of flattening with TSO 
TRANSMIT.

Does sftp support anything similar to Diffie-Hellman key exchange?  That would 
still
leave the problem of authentication.

o Sneakernet?

o Cloud?  Still the authentication question.

-- gil

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

Re: Serverpac installs January 2022 and beyond - Requests

[Gibney, Dave]

My last several Serverpac installs had very few issues. Most were 
self-inflicted. Like the time I failed to order the optional regulated 
encryption. Or this last time, when do to poor timing, I had to start with a 
z/OS 2.3 archive, then add Java 

For at least the last 3, implementation in production was a non-event. Which is 
as it should be.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Brennan
> Sent: Thursday, July 22, 2021 7:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
> 
> "seems everyone has a better way"
> 
> I think you hit on the root of the problem.  With Windows and Linux
> installs, everyone (generally) does things the same exact way, including
> filenames and directory locations.  They don't have the problems we have
> with mainframe installs.
> 
> On 7/22/2021 7:19 AM, Carmen Vitullo wrote:
> > I think I IPL'd the CPAC system that was built from the ServerPac once
> > in my career, it was the company/dept's standard and we had a small LPAR
> > built just for that reason. Documentation was provided, IPLing the CPAC
> > system was only done to proceed with the ServerPac install.
> >
> >   moving on from that company I moved to a different process, seems
> > everyone has a better way, for me building the target sysres and zfs
> > file systems, running some IVP tests and build my new master catalog,
> > and IPL that system on my sandbox system.
> >
> > I have a documented process to copy/migrate the new version or maint to
> > production that works well even for someone who's not a z/os sysprog.
> >
> > Carmen
> >
> >
> > On 7/21/2021 1:19 PM, Tom Brennan wrote:
> >> Same with me when I ran ServerPac installs - I never IPL'd using the
> >> datasets provided by the installer such as catalogs, RACF, spool, SMF,
> >> page, etc.  I never understood IBM's reason for doing that, and also
> >> never understood the reason for running the system validation jobs on
> >> the vanilla system.  What was much more important for us was IPLing
> >> the new res pack on a sandbox system with our own system datasets,
> >> parms, and usermods - and then solve any issues that may come up.
> >>
> >> So those IBM-supplied system datasets were never used, and although I
> >> could not delete them using the CPP dialog, I would always set them to
> >> 1 track or 1 cylinder before running the alloc job - just to save space.
> >>
> >> It just made little sense to me to prove the vanilla system from IBM
> >> works correctly.  Of course it does, otherwise why would they send it
> >> to me?
> >>
> >> On 7/20/2021 10:23 PM, Gibney, Dave wrote:
> >>> I don't know how it would work with zOSMF, but I don't worry about
> >>> the dataset sizes of my SMPE target datasets. Because I never IPL
> >>> using them.
> >>> I copy to new SYSRES, FDR and ADRDSSU dataset copies to single
> >>> extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put
> >>> maintenance into a running system
> >>
> >> --
> >> 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: Serverpac installs January 2022 and beyond - Requests

[Shaffer, Terri]

Its interesting, because I don’t have any products that give me extra extents 
except what SMS does for me space wise, and I have never increased my dataset 
size allocations.

That being said, my cloning process copies my res volume and ZFS datasets to 
new volumes and resets extents to current used, which is why I never used the 
software deployment and NEVER will in z/OSMF.

I also DEFRAG my RES volumes after an apply and with my 2 - MOD-27, have always 
had enough room, for my 2.2, 2.3 and 2.4 and hopefully for 2.5.  My z/OS 2.2, 
will be replaced in the SYSPLEX.

I apply around 1000 PTF each time, I do RSU upgrades normally twice a year over 
the life of a z/OS release and can say I might have had 10 datasets/ZFS 
expansion, I needed to expand during an APPLY.

This is the least of my concerns/issues for the serverpac.

I think, to say the Saved Config is out of date, is short sided and in 20 years 
I have always used it since serverpac gave me the MERGE and UPGRADE option.  
Fixed anything new to the Serverpac order and was ready to install in a short 
time.This saves SO MUCH TIME with installation as all I have to do verify, 
make very few updates and install.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Marna WALLE
Sent: Tuesday, July 20, 2021 12:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

External Email


Hi Terri,
When adding an Software Instance that you already have (say, z/OS V2.4), you 
are telling z/OSMF the CSI and zones to use.  Those DDDEFs, presumably, will be 
correct with the data set names, volumes, and paths.  Those DDDEFs will be used 
as a model on the incoming z/OS CSI DDDEFs.  That will save you hundreds of 
customizations to do for z/OS V2.5 and beyond.  I've seen many ServerPac saved 
configurations that are stale, and the CSI DDDEFs are the correct and current 
values.  Meaning, that the ServerPac saved configuration can "drift" out of 
accuracy over time, but the CSI DDDEFs had better not. That is what I mean by 
saving time.  Especially when you are basing on a known, accurate, SMP/E 
configuration.

For the shipped configuration data sets (like CPAC.*):  if you add those data 
sets to that Software Instance, then those data sets can be modelled too.  If 
you choose not to, the worst thing is that the 16 CPAC data sets shipped with 
z/OS V2.5, can be modified *en masse* within the z/OSMF interface.  Since they 
are all shipped with a HLQ of CPAC, it is very easy to filter, select, move, 
rename them as a group.  With the z/OS V2.5 Software Instance, they then become 
known and can be modelled with future z/OS Portable Software Instances.

For the catalog:  depending on what catalog options you want - new master cat, 
existing master cat and the data set names you select - the existing structure 
you have on your driving system can be used and detected, should you wish to 
use it.  If you want a new master cat, you will need to supply the name and the 
temporary catalog alias of your choice (aka SSA), just like in the old 
ServerPac.  If you want all your data sets to begin with "ZOSV25", and you have 
that existing HLQ alias going to an existing usercat today, no problem, that 
will be used.  If you want to create a new master catalog, and use "MYSSA" as 
the temporary catalog alias, you'll need to supply that, just like in the old 
ServerPac.  The catalog structure, I see, is similar to how the old ServerPac 
did it.  Although, there is a lot more flexibility, because you can rename any 
data set, and put it in any catalog you want, with only VSAM (including zFS) 
forced to be cataloged.  The old ServerPac had lots of restrictions on what 
could be renamed, and where it had to be cataloged.

-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie

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

 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 

This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: Serverpac installs January 2022 and beyond - Requests

[Carmen Vitullo]

ah YUP!

I was going to add, when I did a short jaunt with IGS, most of the IBM 
sysprog's never heard of ServerPac and most never provided or worked 
with a custompac install.


The clients systems are built based on what the client needs, sometime 
just the base system, sometimes the base+OEM products, that info is 
provided to another IBM service that builds the system, then restored to 
the clients systems using Tx and Dx volumes. so the customer is 
not really involved.


  Curious where z/osmf will participate, if at all in these scenario's

unfortunately and somewhat fortunate for me I've worked at a lot of 
different sites, only when I was 'THE GUY" did the install process stay 
the same from company to company. :)


I think, with anything else new, z/osmf once embarrassed, installing the 
OS and products will be somewhat like 'those' platforms.




Carmen


On 7/22/2021 9:38 AM, Tom Brennan wrote:

"seems everyone has a better way"

I think you hit on the root of the problem.  With Windows and Linux 
installs, everyone (generally) does things the same exact way, 
including filenames and directory locations.  They don't have the 
problems we have with mainframe installs.


On 7/22/2021 7:19 AM, Carmen Vitullo wrote:
I think I IPL'd the CPAC system that was built from the ServerPac 
once in my career, it was the company/dept's standard and we had a 
small LPAR built just for that reason. Documentation was provided, 
IPLing the CPAC system was only done to proceed with the ServerPac 
install.


  moving on from that company I moved to a different process, seems 
everyone has a better way, for me building the target sysres and zfs 
file systems, running some IVP tests and build my new master catalog, 
and IPL that system on my sandbox system.


I have a documented process to copy/migrate the new version or maint 
to production that works well even for someone who's not a z/os sysprog.


Carmen


On 7/21/2021 1:19 PM, Tom Brennan wrote:
Same with me when I ran ServerPac installs - I never IPL'd using the 
datasets provided by the installer such as catalogs, RACF, spool, 
SMF, page, etc.  I never understood IBM's reason for doing that, and 
also never understood the reason for running the system validation 
jobs on the vanilla system.  What was much more important for us was 
IPLing the new res pack on a sandbox system with our own system 
datasets, parms, and usermods - and then solve any issues that may 
come up.


So those IBM-supplied system datasets were never used, and although 
I could not delete them using the CPP dialog, I would always set 
them to 1 track or 1 cylinder before running the alloc job - just to 
save space.


It just made little sense to me to prove the vanilla system from IBM 
works correctly.  Of course it does, otherwise why would they send 
it to me?


On 7/20/2021 10:23 PM, Gibney, Dave wrote:
I don't know how it would work with zOSMF, but I don't worry about 
the dataset sizes of my SMPE target datasets. Because I never IPL 
using them.
I copy to new SYSRES, FDR and ADRDSSU dataset copies to single 
extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put 
maintenance into a running system


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


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


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

Re: Serverpac installs January 2022 and beyond - Requests

[Tom Brennan]

"seems everyone has a better way"

I think you hit on the root of the problem.  With Windows and Linux 
installs, everyone (generally) does things the same exact way, including 
filenames and directory locations.  They don't have the problems we have 
with mainframe installs.


On 7/22/2021 7:19 AM, Carmen Vitullo wrote:
I think I IPL'd the CPAC system that was built from the ServerPac once 
in my career, it was the company/dept's standard and we had a small LPAR 
built just for that reason. Documentation was provided, IPLing the CPAC 
system was only done to proceed with the ServerPac install.


  moving on from that company I moved to a different process, seems 
everyone has a better way, for me building the target sysres and zfs 
file systems, running some IVP tests and build my new master catalog, 
and IPL that system on my sandbox system.


I have a documented process to copy/migrate the new version or maint to 
production that works well even for someone who's not a z/os sysprog.


Carmen


On 7/21/2021 1:19 PM, Tom Brennan wrote:
Same with me when I ran ServerPac installs - I never IPL'd using the 
datasets provided by the installer such as catalogs, RACF, spool, SMF, 
page, etc.  I never understood IBM's reason for doing that, and also 
never understood the reason for running the system validation jobs on 
the vanilla system.  What was much more important for us was IPLing 
the new res pack on a sandbox system with our own system datasets, 
parms, and usermods - and then solve any issues that may come up.


So those IBM-supplied system datasets were never used, and although I 
could not delete them using the CPP dialog, I would always set them to 
1 track or 1 cylinder before running the alloc job - just to save space.


It just made little sense to me to prove the vanilla system from IBM 
works correctly.  Of course it does, otherwise why would they send it 
to me?


On 7/20/2021 10:23 PM, Gibney, Dave wrote:
I don't know how it would work with zOSMF, but I don't worry about 
the dataset sizes of my SMPE target datasets. Because I never IPL 
using them.
I copy to new SYSRES, FDR and ADRDSSU dataset copies to single 
extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put 
maintenance into a running system


--
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: [EXTERNAL] Re: How should I send file to another sysplex securely.

[Horne, Jim]

Why wouldn't you just write a batch job to invoke SFTP?  It is z/OS to z/OS and 
can handle almost all files, as far as I know

Jim Horne

-Original Message-
How about using sftp - of course you would need to copy the file to an omvs 
file to do it, or get the Dovetail enhanced sftp which supports z/OS datasets.

NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

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

Re: Serverpac installs January 2022 and beyond - Requests

[Carmen Vitullo]

I think I IPL'd the CPAC system that was built from the ServerPac once 
in my career, it was the company/dept's standard and we had a small LPAR 
built just for that reason. Documentation was provided, IPLing the CPAC 
system was only done to proceed with the ServerPac install.


 moving on from that company I moved to a different process, seems 
everyone has a better way, for me building the target sysres and zfs 
file systems, running some IVP tests and build my new master catalog, 
and IPL that system on my sandbox system.


I have a documented process to copy/migrate the new version or maint to 
production that works well even for someone who's not a z/os sysprog.


Carmen


On 7/21/2021 1:19 PM, Tom Brennan wrote:
Same with me when I ran ServerPac installs - I never IPL'd using the 
datasets provided by the installer such as catalogs, RACF, spool, SMF, 
page, etc.  I never understood IBM's reason for doing that, and also 
never understood the reason for running the system validation jobs on 
the vanilla system.  What was much more important for us was IPLing 
the new res pack on a sandbox system with our own system datasets, 
parms, and usermods - and then solve any issues that may come up.


So those IBM-supplied system datasets were never used, and although I 
could not delete them using the CPP dialog, I would always set them to 
1 track or 1 cylinder before running the alloc job - just to save space.


It just made little sense to me to prove the vanilla system from IBM 
works correctly.  Of course it does, otherwise why would they send it 
to me?


On 7/20/2021 10:23 PM, Gibney, Dave wrote:
I don't know how it would work with zOSMF, but I don't worry about 
the dataset sizes of my SMPE target datasets. Because I never IPL 
using them.
I copy to new SYSRES, FDR and ADRDSSU dataset copies to single 
extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put 
maintenance into a running system


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


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


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

Re: How should I send file to another sysplex securely.

[ITschak Mugzach]

encrypt and send over NJE using xmit?

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *




On Thu, Jul 22, 2021 at 5:08 PM Colin Paice  wrote:

> I was wondering the best way customers send sensitive data between z/OS
> images.
> I was thinking about exporting one's private certificates.
>
>1. I can create a dataset of the private certificates on system 1 and
>have it encrypted.   I can send it to the other system.   How can I
> decrypt
>it on the remote system as it needs shared certificates?  It seems a
>chicken and egg problem
>2. I can put a password on the file through JCL and use FTPS to send
>it.   This could easily be broken
>
> This is hypothetical, but I would be interested in how to do it.
>
> Colin Paice
>
> --
> 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: How should I send file to another sysplex securely.

[Lionel B. Dyck]

How about using sftp - of course you would need to copy the file to an omvs 
file to do it, or get the Dovetail enhanced sftp which supports z/OS datasets.


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Thursday, July 22, 2021 9:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How should I send file to another sysplex securely.

I was wondering the best way customers send sensitive data between z/OS images.
I was thinking about exporting one's private certificates.

   1. I can create a dataset of the private certificates on system 1 and
   have it encrypted.   I can send it to the other system.   How can I decrypt
   it on the remote system as it needs shared certificates?  It seems a
   chicken and egg problem
   2. I can put a password on the file through JCL and use FTPS to send
   it.   This could easily be broken

This is hypothetical, but I would be interested in how to do it.

Colin Paice

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

How should I send file to another sysplex securely.

[Colin Paice]

I was wondering the best way customers send sensitive data between z/OS
images.
I was thinking about exporting one's private certificates.

   1. I can create a dataset of the private certificates on system 1 and
   have it encrypted.   I can send it to the other system.   How can I decrypt
   it on the remote system as it needs shared certificates?  It seems a
   chicken and egg problem
   2. I can put a password on the file through JCL and use FTPS to send
   it.   This could easily be broken

This is hypothetical, but I would be interested in how to do it.

Colin Paice

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

Re: Concatinated datasets

[A T & T Management]

 Good morning all!
Just wanted to find out what the dataset name is from where a module is loaded 
from.  Now when in this case I say module I also say that it can be a parmlib 
entry in a concatenated PDS as well.
Scott

On Wednesday, July 21, 2021, 2:19:34 PM EDT, Rob Schramm 
 wrote:  
 
 Seems like Scott should tell us the Why.  If you were just trying to
validate the correct module..  maybe signature would do it?

Rob

On Mon, Jul 19, 2021, 1:42 PM Seymour J Metz  wrote:

> HEWLKED is the Linkage Editor; it creates load modules on SYSLMOD; I
> don''t know of any way to make it direct its output to storage.
>
> Were you thinking of the loader? HEWLD, HEWLDI,  HEWLDIA, HEWLDRGO,
> IEWBLDGO , IEWLDRGO or LOADER?
>
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Monday, July 19, 2021 11:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Concatinated datasets
>
> On Mon, 19 Jul 2021 14:12:21 +, Seymour J Metz wrote:
>
> >> HEWLKD
>
> >Where is that EP documented.
> >
> My typo.  HEWLKED.  Mentioned sparsely in Program Management User's Guide.
> Strangely, more extensive mentions in SMP/E material.
>
> Accepts in SYSLIN concatenated:
> o Object (SYSPUNCH) files
> o Load Modules.
>
> Does not accept:
> o Commands
> o GOFF objects
> o Program Objects.
>
> Feels obsolescent.
>
> 
> From: Paul Gilmartin
> Sent: Saturday, July 17, 2021 1:32 PM
>    ...
> It's possible (PGM=HEWLKD) to create an executable in storage
> directly from SYSLIN, never creating a program object on DASD.
>
> -- gil
>
> --
> 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