Re: Netview

[Jousma, David]

Just wondering why it might matter?

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Steve Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, April 24, 2024 6:40:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Netview

Radoslaw. That is as good as answer as any Sent from my iPhone No one said I 
could type with one thumb > On Apr 24, 2024, at 17: 36, Radoslaw Skorupka 
<0471ebeac275-dmarc-request@ listserv. ua. edu> wrote: > > W dniu 24. 04. 
2024


Radoslaw.  That is as good as answer as any


Sent from my iPhone

No one said I could type with one thumb

> On Apr 24, 2024, at 17:36, Radoslaw Skorupka 
> <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
>
> W dniu 24.04.2024 o 23:19, Steve Beaver pisze:
>> My understanding is that IBM sold off Netview.
>>
>> Who did they sell it to?
>
> HCL?
>
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> 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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: zOSMF startup on 3.1

[Jousma, David]

Seems to say here that you need JAVA V17 on z/OS V3.1:  
https://www.ibm.com/docs/en/zos/3.1.0?topic=installation-software-requirements-running-zos-31
 If you already have that installed, just change your JAVA_HOME and give it a 
shot.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Pommier, Rex 
Date: Friday, April 19, 2024 at 1:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: zOSMF startup on 3.1
Hello list, Just IPLed z/OS 3. 1 on our sandbox and tried to start zOSMF. The 
angel process started but the server process fails. I compared file permissions 
in the /global/zosmf directories between my 2. 4 system and 3. 1 system and 
they're the


Hello list,



Just IPLed z/OS 3.1 on our sandbox and tried to start zOSMF.  The angel process 
started but the server process fails.  I compared file permissions in the 
/global/zosmf directories between my 2.4 system and 3.1 system and they're the 
same.  The server is failing in the IZUSVR1 step with a cond code 2048.



STDOUT output:

Launching zosmfServer (z/OSMF 3.1.0/wlp-1.0.75.cl230320230319-1900) on IBM J9 
VM, version 8.0.8.20 - pmz6480sr8fp20-20240112_01(SR8 FP20) (en_US)

ÝAUDIT   ¨ CWWKE0001I: The server zosmfServer has been launched.

CWWKE0005E: The runtime environment could not be launched.

CWWKE0018E: An exception occurred while launching the runtime environment: 
java.lang.NullPointerException



STDERR output:

TRAS3005E: Failed to write messages to the 
/global/zosmf/data/logs/zosmfServer/logs/messages.log file.

com.ibm.ws.kernel.boot.LaunchException: Caught unexpected exception 
java.lang.IllegalStateException: Error initializing storage for Equinox 
container.

 at 
com.ibm.ws.kernel.boot.internal.KernelBootstrap.rethrowException(KernelBootstrap.java:734)

 at com.ibm.ws.kernel.boot.internal.KernelBootstrap.go(KernelBootstrap.java:222)

 "and several continuations of this error"



The first message in the STDERR says it couldn't write to the messages.log 
file.  That is incorrect.  Here's the output from that file:



product = z/OSMF 3.1.0 (wlp-1.0.75.cl230320230319-1900)

wlp.install.dir = /usr/lpp/liberty_zos/23.0.0.3/

server.config.dir = /global/zosmf/configuration/servers/zosmfServer/

server.output.dir = /global/zosmf/data/logs/zosmfServer/

java.home = /usr/lpp/java/J8.0_64

java.version = 1.8.0_401

java.runtime = Java(TM) SE Runtime Environment (8.0.8.20 - 
pmz6480sr8fp20-20240112_01(SR8 FP20))

os = z/OS (03.01.00; s390x) (en_US)

process = 16777379@TSTJES2

Classpath = 
/usr/lpp/zosmf/liberty/lib/native/zos/s390x/../../../../lib/ws-launch.jar:/usr/lpp/zosmf/liberty/lib/native/zos/s390x/..

/../../../lib/bootstrap-agent.jar

Java Library path = 
/usr/lpp/java/J8.0_64/lib/s390x/compressedrefs:/usr/lpp/java/J8.0_64/lib/s390x:/usr/lpp/java/J8.0_64/lib/s390x/c

ompressedrefs:/usr/lpp/zosmf/liberty/lib/native/zos/s390x/../../../../lib/native/zos/s390x:/usr/lpp/java/J8.0_64/bin/classic:$LIBPAT

H:/usr/lpp/tcpip/lib:/usr/lpp/gskssl/IBM:/usr/lpp/wbem/lib:/lib:/usr/lib



[4/19/24 17:33:43:388 GMT] 0001 
com.ibm.ws.kernel.launch.internal.FrameworkManager   A CWWKE0001I: The 
server zosmfServer has been launched.

[4/19/24 17:33:43:428 GMT] 0001 
com.ibm.ws.kernel.launch.internal.FrameworkManager   I CWWKE0940I: The 
zOSMFReg product

extension has a product identifier of com.ibm.zoszmf and a product installation 
location of /usr/lpp/zosmf/defaults. This product extension

 was enabled by specifying the WLP_PRODUCT_EXT_DIR environment variable.

[4/19/24 17:33:43:688 GMT] 0001 
com.ibm.ws.logging.internal.impl.IncidentImplI FFDC1015I: An 
FFDC Incident has

been created: "java.lang.IllegalStateException: Error initializing storage for 
Equinox container. com.ibm.ws.kernel.launch.internal.F

rameworkManager 678" at ffdc_24.04.19_15.50.44.0.log





I noticed it is running java 8 where I have java 11 and 17 installed.  Does 
zOSMF work on 3.1 with java 8?



Any idea what I may be missing here?



TIA

Rex



--

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

Re: Anyone exploiting ZEDC?

[Jousma, David]

Thank-you very much for this!   I suspect this is the route we will have to 
take.   To answer your other question, yes, ZEDC is a chargeable feature 
(although very inexpensive) and is turned on in IFAPRD00.

Dave Jousma
Vice President | Director, Technology Engineering



From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 16, 2024 at 3:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC. /* 
DEFINE extra data sets to receive zEDC compression */ 
/**/ 
FILTLIST COMP_DSN INCLUDE(CCM. CCM. FDR. **,


FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC.



/* DEFINE extra data sets to receive zEDC compression */



/**/







FILTLIST COMP_DSN INCLUDE(CCM.CCM.FDR.**,

  RMS.PROD.MSA.BKUP.**,

  LOGR.IFASMF.**,

  DB2%.ARCHLOG%.**)



-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -   46 Line(s) not Displ



/* RULES FOR DISK zEDC HW data compression*/



/**/



   WHEN ( = _DSN) SET ='COMP'

   WHEN ( = 'GDS' &&  > 270MB)

 SET ='COMP'

   WHEN ( = 'ADRDSSU' &&  > 55MB)

 SET ='COMP'









This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Anyone exploiting ZEDC?

[Jousma, David]

Michael,

Yes, thanks.  It is just the sortwk datsets that are the issue.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Michael Oujesky 
Date: Tuesday, April 16, 2024 at 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
Food for thought. zEDC is block oriented rather than record oriented (i. e. 
reads/writes full track blocks on DASD and BLKSIZE become logical (i. e. the 
size of the buffer used to exchange data with the application)), so any 
processing that expects


Food for thought.  zEDC is block oriented rather than record oriented

(i.e. reads/writes full track blocks on DASD and BLKSIZE become

logical (i.e. the size of the buffer used to exchange data with the

application)), so any processing that expects to make use of BLKSIZE

to perform physical I/O (random, update, etc) will fail.



Thus DFSORT will have issues for SORTWK datasets, but not

SORTIN/SORTOUT datasets.



Michael



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Anyone exploiting ZEDC?

[Jousma, David]

No Hogan here.   We use IAM in a bunch of applications because it is 
significantly faster than VSAM (or was).

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 16, 2024 at 3:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
Curious, do you use IAM for Hogan applications? My previous life did, and the 
applications group was very satisfied with the IAM performance vs. native VSAM. 
However, we had to impress on them, that periodic reorgs were more necessary 
for IAM,


Curious, do you use IAM for Hogan applications?  My previous life did, and the 
applications group was very satisfied with the IAM performance vs. native VSAM. 
 However, we had to impress on them, that periodic reorgs were more necessary 
for IAM, than under VSAM.  And, we found out that ADRDSSU dump/restore of VSAM 
was what was being used to perform VSAM reorgs, as opposed to IDCAMS REPRO, 
DELETE,

DEFINE, REPRO.  Guess what, ADRDSSU sees an IAM dataset as extended format PS!









Sent with Proton Mail secure email.



On Tuesday, April 16th, 2024 at 3:02 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Anyone exploiting ZEDC?

[Jousma, David]

Thanks for that.  We do have IAM here, we’ll open a ticket with BMC asking 
about support.   I was just doubting since it presents to the OS as a VSAM 
dataset.

We were hoping to make ZEDC “inclusive” as in everyone gets it to reap the 
space reduction, and job performance improvements and that the OS would decide 
for us if a particular dataset that has the DATACLAS assigned to it would just 
ignore, but that wont be the case.

I have the ability to code ZEDC_preferred or ZEDC-Required.   Required will 
actually fail the allocation, which I don’t want to either, but I also don’t 
want to use non-accelerated compression either.

So, now as you pointed out, we’ll have to approach ZEDC as “exclusive” and only 
opt-in file types that are supported like GDG’s for sure.   We may roll the 
dice on all PS, exempting temp datasets and ISPF work datasets, and more as we 
stumble upon other incompatibilities.

With knowing the technical details, I think IBM missed the boat here.   ZEDC 
ought to be a drop-in replacement for compression, period.  I can specify 
COMPACTION YES for VSAM files but ZEDC wont touch them.   Why?

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 16, 2024 at 2:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
At my previous life, we were using BMC's IAM VSAM interface. I think IAM could 
use zEDC. But I was told by then IDP support, that IAM's internal compression 
was Moe (as in Moe Howard) better than even zEDC. Regarding coding for PS 
datasets


At my previous life, we were using BMC's IAM VSAM interface.  I think IAM could 
use zEDC. But I was told by then IDP support, that IAM's internal compression 
was Moe (as in Moe Howard) better than even zEDC.



Regarding coding for PS datasets opened in/out, I think DAF will show how a PS 
dataset is being opened.  We chose to use zEDC compression for new,catlg,delete 
GDGs because we were very confident that no one was going to process that 
combination as in/out.

And does not the IBM zBNA tool highlight good candidates?  We did not want to 
clutter up our SMS ACS DC routines with too many actions to put certain PS 
datasets into zEDC compression.  But in the end, we did put certain large PS, 
not opened in/out, datasets in the ACS DC routine.









This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Anyone exploiting ZEDC?

[Jousma, David]

Peter,

Interesting.   IBM says VSAM does NOT exploit ZEDC.   VSAM can be compressed, 
but it must all be done on CP, which would be expensive.Within a VSAM 
LINEAR dataset used as ZFS, ZFS will engage ZEDC.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 16, 2024 at 1:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
I do not know what criteria the sysprogs here set things up. But we are 
successfully using zEDC here especially for our huge VSAM and GDG production 
files. I wish I could tell you more, but the sysprogs here are outsourced and 
getting answers


I do not know what criteria the sysprogs here set things up. But we are 
successfully using zEDC here especially for our huge VSAM and GDG production 
files.



I wish I could tell you more, but the sysprogs here are outsourced and getting 
answers from them requires official paperwork and bureaucracy that I have no 
business reason to cover.



From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David

Sent: Tuesday, April 16, 2024 12:39 PM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: Anyone exploiting ZEDC?





Thank-you for this feedback.   I’m starting to feel like this is a half-baked 
solution looking for a problem.  I know of no way to systematically code for 
open for update….







Dave Jousma



Vice President | Director, Technology Engineering







From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>



Date: Tuesday, April 16, 2024 at 12:29 PM



To: IBM-MAIN@LISTSERV.UA.EDU 



Subject: Re: Anyone exploiting ZEDC?



At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets. But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work. As a compromise, we narrowed down to 
new PS







At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets.  But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work.  As a compromise, we narrowed down 
to new PS GDG datasets.  Also we looked at new PS GDG datasets over a certain 
size.  We picked an arbitrary number of tracks/cylinders to apply the zEDC 
compression to.  Once we did that, our production job abends disappeared and we 
started seeing a reduction in space usage on the storage groups where these 
datasets were being allocated on.







Sent with Proton Mail secure email.







On Tuesday, April 16th, 2024 at 12:16 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:







> Is anyone exploiting ZEDC data compression accelerator in your environments? 
> We recently licensed the enablement and are working through the issues in our 
> DEV environment.



>



> We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, 
> but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have 
> issues. We’ve turned back off for now.



>



> There is no central location in any IBM doc(including recent REDBOOKS) that 
> discusses where we can and cannot leverage ZEDC. As it stands now, we had to 
> back out, and looking at taking a new approach in our ACS routines checking 
> for DSORG=PS, and then if not temp-dataset, or tape assign a DC with the 
> right options.



>



> What I am wondering is if anyone is further along that can share how they 
> rolled out? I really don’t want to have to make the applications teams have 
> to “opt-in” by coding a DC in their JCL or other dataset allocations.



>



> Dave Jousma



> Vice President | Director, Technology Engineering



--







This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.





--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information i

Re: Anyone exploiting ZEDC?

[Jousma, David]

Thank-you for this feedback.   I’m starting to feel like this is a half-baked 
solution looking for a problem.  I know of no way to systematically code for 
open for update….

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 16, 2024 at 12:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets. But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work. As a compromise, we narrowed down to 
new PS


At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets.  But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work.  As a compromise, we narrowed down 
to new PS GDG datasets.  Also we looked at new PS GDG datasets over a certain 
size.  We picked an arbitrary number of tracks/cylinders to apply the zEDC 
compression to.  Once we did that, our production job abends disappeared and we 
started seeing a reduction in space usage on the storage groups where these 
datasets were being allocated on.









Sent with Proton Mail secure email.



On Tuesday, April 16th, 2024 at 12:16 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



> Is anyone exploiting ZEDC data compression accelerator in your environments? 
> We recently licensed the enablement and are working through the issues in our 
> DEV environment.

>

> We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, 
> but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have 
> issues. We’ve turned back off for now.

>

> There is no central location in any IBM doc(including recent REDBOOKS) that 
> discusses where we can and cannot leverage ZEDC. As it stands now, we had to 
> back out, and looking at taking a new approach in our ACS routines checking 
> for DSORG=PS, and then if not temp-dataset, or tape assign a DC with the 
> right options.

>

> What I am wondering is if anyone is further along that can share how they 
> rolled out? I really don’t want to have to make the applications teams have 
> to “opt-in” by coding a DC in their JCL or other dataset allocations.

>

> Dave Jousma

> Vice President | Director, Technology Engineering

>

>

>

>

>

> This e-mail transmission contains information that is confidential and may be 
> privileged. It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.

>

> --

> 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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Anyone exploiting ZEDC?

[Jousma, David]

Is anyone exploiting ZEDC data compression accelerator in your environments?   
We recently licensed the enablement and are working through the issues in our 
DEV environment.

We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, but 
are quickly finding that DFSORT, SAS, ISPF recovery datasets all have issues.   
We’ve turned back off for now.

There is no central location in any IBM doc(including recent REDBOOKS) that 
discusses where we can and cannot leverage ZEDC.   As it stands now, we had to 
back out, and looking at taking a new approach in our ACS routines checking for 
DSORG=PS, and then if not temp-dataset, or tape assign a DC with the right 
options.

What I am wondering is if anyone is further along that can share how they 
rolled out?   I really don’t want to have to make the applications teams have 
to “opt-in” by coding a DC in their JCL or other dataset allocations.

Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: [EXTERNAL] Re: IBM key management products

[Jousma, David]

Would have been fun to line them up on a fence, and do some target practice!!!

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Pommier, Rex 
Date: Monday, April 15, 2024 at 2:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: [EXTERNAL] Re: IBM key management products
Didn't phase the drill bit one bit (sorry for the bad pun). I just had to be 
careful not to punch a hole in the bottom of the drives so as to not get glass 
shards dropping on my (very messy) shop floor. -Original Message- From: 
IBM


Didn't phase the drill bit one bit (sorry for the bad pun).  I just had to be 
careful not to punch a hole in the bottom of the drives so as to not get glass 
shards dropping on my (very messy) shop floor.



-Original Message-

From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan

Sent: Monday, April 15, 2024 12:57 PM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: [EXTERNAL] Re: IBM key management products



Nice!  That's the first I've heard of glass platters. Hope your drill bit 
survived the trauma :)



On 4/15/2024 8:33 AM, Pommier, Rex wrote:

> Hi Tom,

>

> Regarding #2, at a former job I got to decommission an HDS box that

> was shared between the mainframe and Unix boxes.  Unencrypted disk in

> it.  Mgmt wanted the data destroyed so they asked me to take the

> individual drives home and drill through each of them.  That was when

> I found out that this particular disk drive had glass platters.  There

> was no getting data off them when the drill bit shattered every

> platter in every spindle.  

>

> Rex

>

> -Original Message-

> From: IBM Mainframe Discussion List  On

> Behalf Of Tom Brennan

> Sent: Friday, April 12, 2024 1:41 PM

> To: IBM-MAIN@LISTSERV.UA.EDU

> Subject: [EXTERNAL] Re: IBM key management products

>

> We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices, all 
> internal disk storage, no external cartridge tapes.  So what does that do for 
> the customer, since (unless you're using an additional form of encryption on 
> the mainframe) the data is still spit out of the devices unencrypted (not 
> counting the additional feature that allows FICON-in-transit encryption).

>

> I have a few theories on this:

>

> #1 If someone gets into the datacenter and steals disks (or the entire DS/TS 
> box), the encrypted contents should be useless.

>

> #2 When a DS/TS box is decommissioned, a customer could "potentially"

> skip any further destruction of the data in the box.  Still, what I've

> seen in reality for decom is to run the IBM SDO (secure data overwrite

> to blot out the disks) and sometimes even shred the individual disks

> (I'd sure like to see that in action!)

>

> #3 If you steal a DS/TS box, make sure you steal the associated key server 
> unit too.

>

> I'd appreciate any comments on these theories.

>

> On 4/12/2024 9:21 AM, Jousma, David wrote:

>> To place a bit more focus on what Rick says…..  You lose/destroy the key(s), 
>> you have lost your data.   There is a lot of discussion about the scope/use 
>> of the keys.   One key, or one per application, or one per dataset, etc.   
>> There is no right/wrong answer (well just one key for everything is probably 
>> not advisable).

>>

>> I personally am still having a hard time wrapping my head around the “real 
>> benefit” of dataset encryption.   Everyone who has READ or more access to 
>> the dataset, must also be permitted to the Key.   Those same people are 
>> still able to copy/print/steal that data.So who does that leave?   Those 
>> that are not permitted to the dataset, and those who administer the storage. 
>>Those that don’t have access to the dataset aren’t going to get the data, 
>> encrypted or not.   Those who administer the storage usually have access to 
>> move/manage the installations data.These are the people who dataset 
>> encryption is protecting against.   That is a very small population to go to 
>> this effort on.

>>

>> Dave Jousma

>> Vice President | Director, Technology Engineering

>>

>>

>>

>>

>>

>> From: IBM Mainframe Discussion List  on

>> behalf of Rick Troth <058ff5c2d0a7-dmarc-requ...@listserv.ua.edu>

>> Date: Friday, April 12, 2024 at 10:59 AM

>> To: IBM-MAIN@LISTSERV.UA.EDU 

>> Subject: Re: IBM key management products Not discounting Luke's

>> excellent response: key management is hard. Look for utilities with

>> reliable import/export capability. Be prepared to OWN your keys. I

>> say this again as a CISSP, own your keys. This is your bread and

>> butter, so to speak,

>>

>&g

Re: IBM key management products

[Jousma, David]

Colin,

Yes, but that can and should be secured via encrypted connection.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Colin Paice <059d4daca697-dmarc-requ...@listserv.ua.edu>
Date: Friday, April 12, 2024 at 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IBM key management products
I too struggled with why we need data set encryption. Someone pointed out data 
in transit, for example FTPing it or copying it to a non z/OS system Colin On 
Fri, 12 Apr 2024 at 17: 22, Jousma, David < 01a0403c5dc1-dmarc-request@ 
listserv. ua. edu>


I too struggled with why we need data set encryption.  Someone pointed out

data in transit, for example FTPing it or copying it to a non z/OS system

Colin



On Fri, 12 Apr 2024 at 17:22, Jousma, David <

01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: IBM key management products

[Jousma, David]

To place a bit more focus on what Rick says…..  You lose/destroy the key(s), 
you have lost your data.   There is a lot of discussion about the scope/use of 
the keys.   One key, or one per application, or one per dataset, etc.   There 
is no right/wrong answer (well just one key for everything is probably not 
advisable).

I personally am still having a hard time wrapping my head around the “real 
benefit” of dataset encryption.   Everyone who has READ or more access to the 
dataset, must also be permitted to the Key.   Those same people are still able 
to copy/print/steal that data.So who does that leave?   Those that are not 
permitted to the dataset, and those who administer the storage.Those that 
don’t have access to the dataset aren’t going to get the data, encrypted or 
not.   Those who administer the storage usually have access to move/manage the 
installations data.These are the people who dataset encryption is 
protecting against.   That is a very small population to go to this effort on.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Rick Troth <058ff5c2d0a7-dmarc-requ...@listserv.ua.edu>
Date: Friday, April 12, 2024 at 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IBM key management products
Not discounting Luke's excellent response: key management is hard. Look for 
utilities with reliable import/export capability. Be prepared to OWN your keys. 
I say this again as a CISSP, own your keys. This is your bread and butter, so 
to speak,


Not discounting Luke's excellent response: key management is hard.

Look for utilities with reliable import/export capability. Be prepared

to OWN your keys.

I say this again as a CISSP, own your keys. This is your bread and

butter, so to speak, the family jewels.

So take care when using these products to ensure that they do what you

want them to do and that you know what they're doing.



One shop where I recently worked had a great slogan, "crypto is easy;

key management is hard".

It's not that the crypto was easy but that it's done already,

implemented, coded, packaged. But the keys *must* be managed by you and

your team, not the kind of thing which can be outsourced.

Keys and certs cannot be installed and forgotten. And sadly, some of the

expirations we are given are too short to be practical. (Various

government issued IDs and licenses commonly last FIVE years. Why do PKI

certs last only two? ... or ONE?)

But I'm getting off topic. Sorry.



The point is, keys are fundamentally different than any other software

or data that we have to manage.

And it's a good idea to limit keys to individuals when you can. (Like

the combination to the bank vault.)

It's all about trust.



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Console Address Space

[Jousma, David]

How would you restart CONSOLE address space if the HMC is down too?  (I have no 
idea if that is possible even if HMC was available).Sounds like a 
standalone dump and IPL might be in order.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
Date: Wednesday, April 10, 2024 at 7:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Console Address Space
Classification: Confidential This past weekend I had an issue where a system 
became totally unresponsive and incommunicado. HMC access also failed, and the 
only conclusion I can come up with, is that the console address space abended. 
I am


Classification: Confidential

This past weekend I had an issue where a system became totally unresponsive and 
incommunicado.

HMC access also failed, and the only conclusion I can come up with, is that the 
console address space abended.



I am working through that debug process, but is there anyway to dynamically 
restart the console address space?



::DISCLAIMER::



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Loss of data for logstream

[Jousma, David]

I should have added to not forget to circle back around, and delete the renamed 
logstream at some point.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 2, 2024 at 6:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Loss of data for logstream
Mark, We’ve run into the problem before, either on a single CF sandbox system, 
or when we did GDPS region swaps. Let me cut/paste a couple snippets for you 
DATA TYPE(LOGR) REPORT(NO) UPDATE LOGSTREAM NAME(IFASMF. ALSSYS. DATA) 
NEWSTREAMNAME(IFASMF. ALSSYS. ZATA)


Mark,



We’ve run into the problem before, either on a single CF sandbox system, or 
when we did GDPS region swaps.  Let me cut/paste a couple snippets for you



DATA TYPE(LOGR) REPORT(NO)

UPDATE LOGSTREAM NAME(IFASMF.ALSSYS.DATA)

NEWSTREAMNAME(IFASMF.ALSSYS.ZATA)



Then when you redefine your logstream, enable these options too.  Since then, 
weve never had a lost data problem.



UPDATE LOGSTREAM NAME(IFASMF.ALSSYS.DATA)

  STG_DUPLEX(YES) DUPLEXMODE(UNCOND)







Dave Jousma

Vice President | Director, Technology Engineering











This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Loss of data for logstream

[Jousma, David]

Mark,

We’ve run into the problem before, either on a single CF sandbox system, or 
when we did GDPS region swaps.  Let me cut/paste a couple snippets for you

DATA TYPE(LOGR) REPORT(NO)
UPDATE LOGSTREAM NAME(IFASMF.ALSSYS.DATA)
NEWSTREAMNAME(IFASMF.ALSSYS.ZATA)

Then when you redefine your logstream, enable these options too.  Since then, 
weve never had a lost data problem.

UPDATE LOGSTREAM NAME(IFASMF.ALSSYS.DATA)
  STG_DUPLEX(YES) DUPLEXMODE(UNCOND)



Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 2, 2024 at 12:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Loss of data for logstream
Yes, one of them. It's in our systems programmer sandbox so I'm not too 
concerned, just looking for a procedure that we can follow if it occurs in 
other sysplexes. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. 
GPG Public Key


Yes, one of them. It's in our systems programmer sandbox so I'm not too 
concerned, just looking for a procedure that we can follow if it occurs in 
other sysplexes.



 Mark Jacobs



Sent from ProtonMail, Swiss-based encrypted email.



GPG Public Key - 
https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!MwwqYLOC6b6whF7V!mZMmmuecDY0BSSyHFyeZvmuhzJalFwFuWoHsXjMEPrAXov0J-9F5Prf6voR3Zzx3K_CvNuw-ynRfY4cCZueih-LSiQQBkejILfg$<https://urldefense.com/v3/__https:/api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!MwwqYLOC6b6whF7V!mZMmmuecDY0BSSyHFyeZvmuhzJalFwFuWoHsXjMEPrAXov0J-9F5Prf6voR3Zzx3K_CvNuw-ynRfY4cCZueih-LSiQQBkejILfg$>





On Monday, April 1st, 2024 at 11:33 PM, Wayne Bickerdike 
<059234794979-dmarc-requ...@listserv.ua.edu> wrote:



> SMF log stream?

>

> On Tue, Apr 2, 2024 at 11:41 AM Jousma, David <

> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

>

> > Rename the logstream, and then define a new one.

> >

> > Dave Jousma

> >

> > Vice President | Director, Technology Engineering

> >

> > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand

> > Rapids, MI 49546

> >

> > 616.653.8429

> > 

> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf

> > of Mark Jacobs 0224d287a4b1-dmarc-requ...@listserv.ua.edu

> > Sent: Monday, April 1, 2024 2:34:57 PM

> > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU

> > Subject: Loss of data for logstream

> >

> > One of my logstreams is showing a status of LOSS OF DATA. What's the

> > procedure to fix that condition? Mark Jacobs Sent from [ProtonMail](https:

> > //urldefense. com/v3/https: //protonmail.

> > com;!!MwwqYLOC6b6whF7V!jnO1EuISd0MISz0CjMwxO6G-PoatxeReVDzn0c2kQipBbLl0FsMyvhyaBTXvv0h1-wXtaF_hC1OS8Tv3XlJ4tAhb4qhYrTWdaFY$),

> >

> > One of my logstreams is showing a status of LOSS OF DATA. What's the

> > procedure to fix that condition?

> >

> > Mark Jacobs

> >

> > Sent from ProtonMail,

> > Swiss-based encrypted email.

> >

> > GPG Public Key -

> > https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!MwwqYLOC6b6whF7V!jnO1EuISd0MISz0CjMwxO6G-PoatxeReVDzn0c2kQipBbLl0FsMyvhyaBTXvv0h1-wXtaF_hC1OS8Tv3XlJ4tAhb4qhYL0jDObo$<https://urldefense.com/v3/__https:/api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!MwwqYLOC6b6whF7V!jnO1EuISd0MISz0CjMwxO6G-PoatxeReVDzn0c2kQipBbLl0FsMyvhyaBTXvv0h1-wXtaF_hC1OS8Tv3XlJ4tAhb4qhYL0jDObo$%3e>

><https://urldefense.com/v3/__https:/api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!MwwqYLOC6b6whF7V!jnO1EuISd0MISz0CjMwxO6G-PoatxeReVDzn0c2kQipBbLl0FsMyvhyaBTXvv0h1-wXtaF_hC1OS8Tv3XlJ4tAhb4qhYL0jDObo$%3e>>

> > --

> > For IBM-MAIN subscribe / signoff / archive access instructions,

> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

> >

> > This e-mail transmission contains information that is confidential and may

> > be privileged. It is intended only for the addressee(s) named above. If

> > you receive this e-mail in error, please do not read, copy or disseminate

> > it in any manner. If you are not the intended recipient, any disclosure,

> > copying, distribution or use of the contents of this information is

> > prohibited. Please reply to the message immediately by informing the sender

> > that the message was misdirected. After replying, please erase it from your

> > computer system.

Re: Loss of data for logstream

[Jousma, David]

Rename the logstream, and then define a new one.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu>
Sent: Monday, April 1, 2024 2:34:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Loss of data for logstream

One of my logstreams is showing a status of LOSS OF DATA. What's the procedure 
to fix that condition? Mark Jacobs Sent from [ProtonMail](https: //urldefense. 
com/v3/__https: //protonmail. 
com__;!!MwwqYLOC6b6whF7V!jnO1EuISd0MISz0CjMwxO6G-PoatxeReVDzn0c2kQipBbLl0FsMyvhyaBTXvv0h1-wXtaF_hC1OS8Tv3XlJ4tAhb4qhYrTWdaFY$),


One of my logstreams is showing a status of LOSS OF DATA. What's the procedure 
to fix that condition?

Mark Jacobs

Sent from 
[ProtonMail](https://urldefense.com/v3/__https://protonmail.com__;!!MwwqYLOC6b6whF7V!jnO1EuISd0MISz0CjMwxO6G-PoatxeReVDzn0c2kQipBbLl0FsMyvhyaBTXvv0h1-wXtaF_hC1OS8Tv3XlJ4tAhb4qhYrTWdaFY$),
 Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!MwwqYLOC6b6whF7V!jnO1EuISd0MISz0CjMwxO6G-PoatxeReVDzn0c2kQipBbLl0FsMyvhyaBTXvv0h1-wXtaF_hC1OS8Tv3XlJ4tAhb4qhYL0jDObo$

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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

It is.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Michael Oujesky 
Date: Thursday, March 28, 2024 at 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
Just a thought, but is Connect Direct available? Michael At 12: 26 PM 
3/28/2024, Jousma, David wrote: >Ding ding ding…. . Gil gets the prize! 
Off-list >send me your favorite adult beverage and where >to send it, and I’ll 
have it delivered


Just a thought, but is Connect Direct available?



Michael



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

Ding ding ding…..Gil gets the prize!   Off-list send me your favorite adult 
beverage and where to send it, and I’ll have it delivered to your door!

Coding EBCDIC, and STRU R was the magic potion.


EZA2509I 16169 megabytes transferred - 10 second interval rate 150928.44 KB/sec 
- Overall transfer rate 130424.81 KB/sec
EZA2509I 17603 megabytes transferred - 10 second interval rate 150308.75 KB/sec 
- Overall transfer rate 131845.13 KB/sec
EZA2509I 19080 megabytes transferred - 10 second interval rate 154934.56 KB/sec 
- Overall transfer rate 133384.38 KB/sec
EZA2509I 20516 megabytes transferred - 10 second interval rate 150550.75 KB/sec 
- Overall transfer rate 134457.31 KB/sec
EZA2509I 21989 megabytes transferred - 10 second interval rate 154457.94 KB/sec 
- Overall transfer rate 135633.81 KB/sec
250 Transfer completed successfully.

DSS running at the remote end

  REST INDD(TAPE)  ODY(RST02A) ADMIN
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'REST '
ADR109I (R/I)-RI01 (01), 2024.088 13:22:47 INITIAL SCAN OF USER CONTROL 
STATEMENTS COMPLETED
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
ADR006I (001)-STEND(01), 2024.088 13:22:47 EXECUTION BEGINS
ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL 
VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION


Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
Will give that a shot Gil. Running now, at the fast speed. We’ll if if ADRDSSU 
at the remote end can read the file Dave Jousma Vice President | Director, 
Technology Engineering From: IBM Mainframe Discussion List 


Will give that a shot Gil.  Running now, at the fast speed.   We’ll if if 
ADRDSSU at the remote end can read the file



Dave Jousma

Vice President | Director, Technology Engineering









This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

Will give that a shot Gil.  Running now, at the fast speed.   We’ll if if 
ADRDSSU at the remote end can read the file

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 12:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
On Thu, 28 Mar 2024 14: 41: 32 +, rpinion865 wrote: >As you have 
determined, it seems that MODE B (Block Mode) is the kicker. Using XMIT or 
TERSE would eliminate the need for MODE B. But we all know there is CPU 
consumption from using


On Thu, 28 Mar 2024 14:41:32 +, rpinion865 wrote:



>As you have determined, it seems that MODE B (Block Mode) is the kicker.  
>Using XMIT or TERSE would eliminate the need for MODE B.  But we all know 
>there is CPU consumption from using those two utilities on both ends.

>

Might STRU R be preferable to MODE B?



(But O discovered that STRU R garbles RECFM=VBS.)



--

gil



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

And all lpars are at the same levels of software.

Dave Jousma
Vice President | Director, Technology Engineering





From: Jousma, David 
Date: Thursday, March 28, 2024 at 10:30 AM
To: IBM Mainframe Discussion List 
Subject: Re: Slow FTP's
Max,

As mentioned, the 50Gb file with MODE B and EBCDIC is slow.  Same file just 
binary mode, it is fast.   Of course, cant transmit a DSS dump as just binary.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Massimo Biancucci <05a019256424-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
Dave, it becomes more interesting. Could it depend on the file data itself ? 
Have you tried a BIG file, EBCDIC with mostly the same data inside ? Same kind 
of transmission, MODE B and EBCDIC. Regards. Max. Il giorno gio 28 mar 2024 
alle ore


Dave,



it becomes more interesting.

Could it depend on the file data itself ?



Have you tried a BIG file, EBCDIC with mostly the same data inside ?

Same kind of transmission, MODE B and EBCDIC.



Regards.

Max.







This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

Max,

As mentioned, the 50Gb file with MODE B and EBCDIC is slow.  Same file just 
binary mode, it is fast.   Of course, cant transmit a DSS dump as just binary.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Massimo Biancucci <05a019256424-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
Dave, it becomes more interesting. Could it depend on the file data itself ? 
Have you tried a BIG file, EBCDIC with mostly the same data inside ? Same kind 
of transmission, MODE B and EBCDIC. Regards. Max. Il giorno gio 28 mar 2024 
alle ore


Dave,



it becomes more interesting.

Could it depend on the file data itself ?



Have you tried a BIG file, EBCDIC with mostly the same data inside ?

Same kind of transmission, MODE B and EBCDIC.



Regards.

Max.







This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

There is no compression involved.As mentioned,  the transfer is only slow 
when using MODE B, EBCDIC on the FTP.   If I remove those, and just do a binary 
file transfer, it flies.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 10:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
What about non-zEDC compression for the destination output dataset? Sent with 
Proton Mail secure email. On Thursday, March 28th, 2024 at 10: 08 AM, Jousma, 
David <01a0403c5dc1-dmarc-request@ LISTSERV. UA. EDU> wrote: > As I 
mentioned,


What about non-zEDC compression for the destination output dataset?









Sent with Proton Mail secure email.



On Thursday, March 28th, 2024 at 10:08 AM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

As I mentioned, a standard binary transfer runs all day to all lpars at 
140Mb/sec.   It seems that only DSS dump files with MODE B, and EBCDIC 
specified slows them down.

I have reached out to our network/firewall teams to see if there some sort of 
data inspection going on.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Styles, Andy (CIO GS - Core Infrastructure & IT Operations ) 
<00d68f765d25-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
Classification: Public Do you have access to any other kind of transfer 
mechanism, and if so, does it happen with that too? (thinking Connect: Direct 
for example). Is the target device of the transfer the same on fast vs slow? 
Andy Styles z/Series


Classification: Public



Do you have access to any other kind of transfer mechanism, and if so, does it 
happen with that too? (thinking Connect:Direct for example).

Is the target device of the transfer the same on fast vs slow?



Andy Styles

z/Series Systems Programmer



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

Max,   Yes tracerte’s have been run, packet traces.   It is standard FTP, no 
SSL encryption going on.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Massimo Biancucci <05a019256424-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
Dave, did you try the basic PING and TRACERTE to see if there's anything 
different ? Is it a basic FTP ? SFTP ? FTPS ? Did you try with XMIT through JNE 
(if available) to measure any difference ? Best regards. Max Il giorno gio 28 
mar 2024


 Dave,



did you try the basic PING and TRACERTE to see if there's anything

different ?

Is it a basic FTP ? SFTP ? FTPS ?



Did you try with XMIT through JNE (if available) to measure any difference ?



Best regards.

Max



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

All between 4 z15’s

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab <05962a42dc49-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
How about processors (z15/z16)? On Thu, Mar 28, 2024 at 7: 30 AM Jousma, David 
<01a0403c5dc1-dmarc-request@ listserv. ua. edu> wrote: > > All, > > 
Grasping at straws here, IBM support center is baffled too. > > To clone


How about processors (z15/z16)?



On Thu, Mar 28, 2024 at 7:30 AM Jousma, David

<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

>

> All,

>

> Grasping at straws here, IBM support center is baffled too.

>

> To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS 
> dump, and FTP it everywhere it needs to be.  Its roughly a 50Gb file 
> transfer.  There is some environmental issue causing slow file transfers to 
> some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other 
> systems on the same CEC.With IBM support help, we’ve narrowed down the 
> problem to the specification of MODE B and EBCDIC on the transfer since it is 
> a DSS dump.   Remove those, and the transfer is fast on the slow systems, and 
> still fast on the fast systems.  Obviously that isn’t a solution though.

>

> So, we are a GDPS shop.   The oddity is that all the “fast” transfers are to 
> the K systems(control systems), and all the “slow” transfers are to the 
> traditional application systems.   TEST, DEV, PROD makes no difference, nor 
> does LPAR busy or not busy.

>

> It seems there is something configured differently on the “slow” systems that 
> is affecting mode b, ebcdic file transfers, but for the life of me, I cannot 
> put my finger on what, nor can the support center, except that the issue is 
> at the remote end, in that the OS cannot offload the data fast enough, so 
> TCPIP/FTP is slowing the transfer pace.

>

> A virtual adult beverage of choice to the one that can point in a direction 
> to look….

>

>

> Dave Jousma

> Vice President | Director, Technology Engineering

>

>

>

>

>

> This e-mail transmission contains information that is confidential and may be 
> privileged.   It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.

>

> --

> 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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

There is, but same for all lpars involved.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of Joe 
Monk <05971158733e-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
Is there a firewall or switch in the path? Joe On Thu, Mar 28, 2024 at 8: 03 AM 
Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. edu> wrote: > 
Joe, > > I had not, just did, worse yet > > EZA1485I 12902400 bytes


Is there a firewall or switch in the path?



Joe



On Thu, Mar 28, 2024 at 8:03 AM Jousma, David <

01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



> Joe,

>

> I had not, just did, worse yet

>

> EZA1485I 12902400 bytes transferred - 10 second interval rate 1281.27

> KB/sec - Overall transfer rate 1281.27 KB/sec

> EZA1485I 21381120 bytes transferred - 10 second interval rate 838.65

> KB/sec - Overall transfer rate 1059.52 KB/sec

> EZA1485I 29491200 bytes transferred - 10 second interval rate 791.23

> KB/sec - Overall transfer rate 969.15 KB/sec

>

> Dave Jousma

> Vice President | Director, Technology Engineering

>

>

>

>

>

> From: IBM Mainframe Discussion List  on behalf

> of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu>

> Date: Thursday, March 28, 2024 at 8:56 AM

> To: IBM-MAIN@LISTSERV.UA.EDU 

> Subject: Re: Slow FTP's

> Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 at

> 7: 31 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua.

> edu> wrote: > All, > > Grasping at straws here, IBM support center is

> baffled too. >

>

>

> Have you tried MODE S (streaming) and TYPE E?

>

>

>

> Joe

>

>

>

> On Thu, Mar 28, 2024 at 7:31 AM Jousma, David <

>

> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

>

>

>

> > All,

>

> >

>

> > Grasping at straws here, IBM support center is baffled too.

>

> >

>

> > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS

>

> > dump, and FTP it everywhere it needs to be.  Its roughly a 50Gb file

>

> > transfer.  There is some environmental issue causing slow file transfers

> to

>

> > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other

>

> > systems on the same CEC.With IBM support help, we’ve narrowed down

> the

>

> > problem to the specification of MODE B and EBCDIC on the transfer since

> it

>

> > is a DSS dump.   Remove those, and the transfer is fast on the slow

>

> > systems, and still fast on the fast systems.  Obviously that isn’t a

>

> > solution though.

>

> >

>

> > So, we are a GDPS shop.   The oddity is that all the “fast” transfers are

>

> > to the K systems(control systems), and all the “slow” transfers are to

> the

>

> > traditional application systems.   TEST, DEV, PROD makes no difference,

> nor

>

> > does LPAR busy or not busy.

>

> >

>

> > It seems there is something configured differently on the “slow” systems

>

> > that is affecting mode b, ebcdic file transfers, but for the life of me,

> I

>

> > cannot put my finger on what, nor can the support center, except that the

>

> > issue is at the remote end, in that the OS cannot offload the data fast

>

> > enough, so TCPIP/FTP is slowing the transfer pace.

>

> >

>

> > A virtual adult beverage of choice to the one that can point in a

>

> > direction to look….

>

> >

>

> >

>

> > Dave Jousma

>

> > Vice President | Director, Technology Engineering

>

> >

>

> >

>

> >

>

> >

>

> >

>

> > This e-mail transmission contains information that is confidential and

> may

>

> > be privileged.   It is intended only for the addressee(s) named above. If

>

> > you receive this e-mail in error, please do not read, copy or disseminate

>

> > it in any manner. If you are not the intended recipient, any disclosure,

>

> > copying, distribution or use of the contents of this information is

>

> > prohibited. Please reply to the message immediately by informing the

> sender

>

> > that the message was misdirected. After replying, please erase it from

> your

>

> > computer system. Your assistance in correcting this error is appreciated.

>

> >

>

> > --

>

> > For IBM-MAIN subscribe / 

Re: Slow FTP's

[Jousma, David]

Joe,

I had not, just did, worse yet

EZA1485I 12902400 bytes transferred - 10 second interval rate 1281.27 KB/sec - 
Overall transfer rate 1281.27 KB/sec
EZA1485I 21381120 bytes transferred - 10 second interval rate 838.65 KB/sec - 
Overall transfer rate 1059.52 KB/sec
EZA1485I 29491200 bytes transferred - 10 second interval rate 791.23 KB/sec - 
Overall transfer rate 969.15 KB/sec

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of Joe 
Monk <05971158733e-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 8:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 at 7: 31 
AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. edu> wrote: > 
All, > > Grasping at straws here, IBM support center is baffled too. >


Have you tried MODE S (streaming) and TYPE E?



Joe



On Thu, Mar 28, 2024 at 7:31 AM Jousma, David <

01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



> All,

>

> Grasping at straws here, IBM support center is baffled too.

>

> To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS

> dump, and FTP it everywhere it needs to be.  Its roughly a 50Gb file

> transfer.  There is some environmental issue causing slow file transfers to

> some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other

> systems on the same CEC.With IBM support help, we’ve narrowed down the

> problem to the specification of MODE B and EBCDIC on the transfer since it

> is a DSS dump.   Remove those, and the transfer is fast on the slow

> systems, and still fast on the fast systems.  Obviously that isn’t a

> solution though.

>

> So, we are a GDPS shop.   The oddity is that all the “fast” transfers are

> to the K systems(control systems), and all the “slow” transfers are to the

> traditional application systems.   TEST, DEV, PROD makes no difference, nor

> does LPAR busy or not busy.

>

> It seems there is something configured differently on the “slow” systems

> that is affecting mode b, ebcdic file transfers, but for the life of me, I

> cannot put my finger on what, nor can the support center, except that the

> issue is at the remote end, in that the OS cannot offload the data fast

> enough, so TCPIP/FTP is slowing the transfer pace.

>

> A virtual adult beverage of choice to the one that can point in a

> direction to look….

>

>

> Dave Jousma

> Vice President | Director, Technology Engineering

>

>

>

>

>

> This e-mail transmission contains information that is confidential and may

> be privileged.   It is intended only for the addressee(s) named above. If

> you receive this e-mail in error, please do not read, copy or disseminate

> it in any manner. If you are not the intended recipient, any disclosure,

> copying, distribution or use of the contents of this information is

> prohibited. Please reply to the message immediately by informing the sender

> that the message was misdirected. After replying, please erase it from your

> computer system. Your assistance in correcting this error is appreciated.

>

> --

> 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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Slow FTP's

[Jousma, David]

Thanks Colin,

We’ve already taken packet traces of both, and sent to IBM.   They see the send 
window being reduced automatically by TCPIP because the remote end cannot keep 
up.   the problem only surfaces when doing EBCDIC and BLOCK transfers.


Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Colin Paice <059d4daca697-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
Dave, I've been working on a TCP session monitor. It reports MB/Second + 
changes to the TCP parameters, such as change in window size, buffer size etc. 
all of which affect throughput. I can let you have a copy of the program if you 
are interested. 


Dave,



I've been working on a TCP session monitor.   It reports MB/Second +

changes to the TCP parameters, such as change in window size, buffer size

etc. all of which affect throughput.



I can let you have a copy of the program if you are interested.

colinpai...@gmail.com



it reports

//SYSPRINT

Using --PORT 22 --SLEEP 10 --COUNT 10 --TCPIP TCPIP



HH:MM:SS,remote ,BytesI,BytesO,,SegsI ,

SegsO,,BI/Sec,BO/Sec,,ReXmtC,

08:33:23,10.1.0.2:41984 , 0, 0,, 0, 0,, 0, 0,,

0,

08:33:23,10.1.0.2:4 ,   676, 45832,,54,63,,67,  4583,,

0,

08:33:33,10.1.0.2:41984 , 0, 0,, 0, 0,, 0, 0,,

0,

08:33:33,10.1.0.2:4 ,52, 27452,,15,28,, 5,  2745,,

0,

08:33:43,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,,

0,

Freeing entry 10.1.0.2:41984



08:33:53,10.1.0.2:37728 ,   156,  1164,,14,11,,15,   116,,

0,

08:33:53,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,,

0,

08:34:04,10.1.0.2:37728 ,   416, 71932,,50,77,,37,  6539,,

0,

08:34:04,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,,

0,

08:34:14,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,,

0,

08:34:14,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,,

0,

08:34:24,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,,

0,

08:34:24,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,,

0,

08:34:34,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,,

0,

08:34:34,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,,

0,



The first time the program sees a connection it dumps out

10.1.0.2:41984  JOBNAME SSHD4 Interface TAP0



10.1.0.2:41984   ResourceId:45   InSegs:37

 OutSegs:31 SSThresh: 65535

10.1.0.2:41984  OutBuffered: 0   InBuffered: 0



10.1.0.2:41984   ReXmtCount: 0CongestionWnd: 41760

 RoundTripTime: 4 RoundTripVar:11

10.1.0.2:41984   SndBufSize: 65536   SndWnd: 64128

 MaxSndWnd: 64256  SendMSS:  1452

10.1.0.2:41984   RcvBufSize: 65536   RcvWnd:131020

 Lcl0WindowCount: 0  Rmt0WindowCount: 0

10.1.0.2:41984





If TCPIP parameters change, such as window size you get in //CHANGE



08:33:23 10.1.0.2:4  NWMConnRoundTripTime n:2 - o:4 = -2



08:33:23 10.1.0.2:4  NWMConnRoundTripVar n:2 - o:7 = -5



08:33:33 10.1.0.2:4  NWMConnRoundTripTime n:3 - o:2 = 1



08:33:33 10.1.0.2:4  NWMConnRoundTripVar n:3 - o:2 = 1



08:33:53 10.1.0.2:37728  NWMConnCongestionWnd n:36000 - o:20160 = 15840



08:33:53 10.1.0.2:37728  NWMConnRoundTripTime n:6 - o:10 = -4



08:33:53 10.1.0.2:37728  NWMConnRoundTripVar n:17 - o:29 = -12



08:33:53 10.1.0.2:37728  NWMConnRcvWnd n:131020 - o:130176 = 844





On Thu, 28 Mar 2024 at 12:31, Jousma, David <

01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



> All,

>

> Grasping at straws here, IBM support center is baffled too.

>

> To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS

> dump, and FTP it everywhere it needs to be.  Its roughly a 50Gb file

> transfer.  There is some environmental issue causing slow file transfers to

> some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other

> systems on the same CEC.With IBM support help, we’ve narrowed down the

> problem to the specification of MODE B and EBCDIC on the transfer since it

> is a DSS dump.   Remove those, and the transfer is fast on the slow

> systems, and still fast on the fast systems.  Obviously that isn’t a

> solution though.

>

> So, we are a GDPS shop.   The oddity is that all the “fast” transfers are

> to the K systems(control systems), and all the “slow” transfers are to the

> traditional application systems.   TEST, DEV, PROD makes no difference, nor

> does LPAR busy or not busy.

>

> It seems there is something configured differently on the “slow” systems

> that is affecting mode b, ebcdic file transfers, but for the life of me, I

> cannot put my finger on what, nor can the support center

Re: Slow FTP's

[Jousma, David]

Thank you, we’ve already compared TCPIP configurations, and they are identical

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 28, 2024 at 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Slow FTP's
z/OS TCP/IP is not my area of expertise. I would check to insure the ITRACE and 
PKTTRACE are turned off, and take a look at TCPCONFIG TCPMAXRCVBUFRSIZE 
TCPRCVBUFRSIZE TCPSENDBFRSIZE And, another possibility D 
TCPIP,tcpipname,NETSTAT,DEV Look


z/OS TCP/IP is not my area of expertise.  I would check to insure the ITRACE 
and PKTTRACE are turned off, and take a look at





TCPCONFIG TCPMAXRCVBUFRSIZE

  TCPRCVBUFRSIZE

  TCPSENDBFRSIZE



And, another possibility



D TCPIP,tcpipname,NETSTAT,DEV



Look for CHECKSUMOFFLOAD YES









Sent with Proton Mail secure email.



On Thursday, March 28th, 2024 at 8:30 AM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



> All,

>

> Grasping at straws here, IBM support center is baffled too.

>

> To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS 
> dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file transfer. 
> There is some environmental issue causing slow file transfers to some systems 
> (40mb’s a sec) and fast file transfers (150Mb/sec) to other systems on the 
> same CEC. With IBM support help, we’ve narrowed down the problem to the 
> specification of MODE B and EBCDIC on the transfer since it is a DSS dump. 
> Remove those, and the transfer is fast on the slow systems, and still fast on 
> the fast systems. Obviously that isn’t a solution though.

>

> So, we are a GDPS shop. The oddity is that all the “fast” transfers are to 
> the K systems(control systems), and all the “slow” transfers are to the 
> traditional application systems. TEST, DEV, PROD makes no difference, nor 
> does LPAR busy or not busy.

>

> It seems there is something configured differently on the “slow” systems that 
> is affecting mode b, ebcdic file transfers, but for the life of me, I cannot 
> put my finger on what, nor can the support center, except that the issue is 
> at the remote end, in that the OS cannot offload the data fast enough, so 
> TCPIP/FTP is slowing the transfer pace.

>

> A virtual adult beverage of choice to the one that can point in a direction 
> to look….

>

>

> Dave Jousma

> Vice President | Director, Technology Engineering

>

>

>

>

>

> This e-mail transmission contains information that is confidential and may be 
> privileged. It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.

>

> --

> 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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Slow FTP's

[Jousma, David]

All,

Grasping at straws here, IBM support center is baffled too.

To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS dump, 
and FTP it everywhere it needs to be.  Its roughly a 50Gb file transfer.  There 
is some environmental issue causing slow file transfers to some systems (40mb’s 
a sec) and fast file transfers (150Mb/sec) to other systems on the same CEC.
With IBM support help, we’ve narrowed down the problem to the specification of 
MODE B and EBCDIC on the transfer since it is a DSS dump.   Remove those, and 
the transfer is fast on the slow systems, and still fast on the fast systems.  
Obviously that isn’t a solution though.

So, we are a GDPS shop.   The oddity is that all the “fast” transfers are to 
the K systems(control systems), and all the “slow” transfers are to the 
traditional application systems.   TEST, DEV, PROD makes no difference, nor 
does LPAR busy or not busy.

It seems there is something configured differently on the “slow” systems that 
is affecting mode b, ebcdic file transfers, but for the life of me, I cannot 
put my finger on what, nor can the support center, except that the issue is at 
the remote end, in that the OS cannot offload the data fast enough, so 
TCPIP/FTP is slowing the transfer pace.

A virtual adult beverage of choice to the one that can point in a direction to 
look….


Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: How to unzip my Rocket MAKE 4.3 file

[Jousma, David]

You likely need to unzip it on your workstation first, and then upload the tar 
file inside it.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, March 19, 2024 at 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: How to unzip my Rocket MAKE 4.3 file
Thanks this is what I needed, but the file I downloaded from rocket was .zip?? 
Ms Terri E Shaffer Senior Systems Engineer, z/OS Support: ACIWorldwide – 
Telecommuter H(412-766-2697) C(412-519-2592) Terri. Shaffer@ aciworldwide. com 
-Original


Thanks this is what I needed, but the file I downloaded from rocket was .zip??



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

Sent: Tuesday, March 19, 2024 12:30 PM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: How to unzip my Rocket MAKE 4.3 file



EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.





I've used something like this:



//BPX10A  EXEC PGM=BPXBATCH,REGION=8M,

//  PARM='sh tar -xvfo /u/sysprogr/make-4.0_b0003.160302.tar'

//STDOUT  DD  PATH='/tmp/sysprogr.pr10',

//PATHOPTS=(OWRONLY,OCREAT,OTRUNC),

//PATHMODE=SIRWXU

//STDERR  DD  PATH='/tmp/sysprogr.pr10a',

//PATHOPTS=(OWRONLY,OCREAT,OTRUNC),

//PATHMODE=SIRWXU

//STDINDD PATH='/dev/null'



Matthew



On Tue, 19 Mar 2024 15:38:24 +, Shaffer, Terri 
 wrote:



>Hi,

>  So I am like a bull in a china closet when it comes to commands in USS.  And 
> looking for the Rocket Read-me apparently, I missed.

>

>So I have my make4.3 zip file in my USS directory, but how do I explode it?

>

>Ms Terri E Shaffer

>Senior Systems Engineer,

>z/OS Support:

>ACIWorldwide - Telecommuter

>H(412-766-2697) C(412-519-2592)

>terri.shaf...@aciworldwide.com



--

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



 
[https://urldefense.com/v3/__https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg__;!!MwwqYLOC6b6whF7V!gKqxWXEqdXmqsNpnxGB0MbxabK3I1KoYmNJz1xieStIteYtD1r1MmdQ2WQB5tohXCl7pB5Lx5NSYOuash9ZoTofi-nZlC5ZLEHE$]
 
>

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Standard Packaging Rules for z/OS-Based Products - current version ???

[Jousma, David]

Lionel,

I haven’t seen the book, but Ive written usermods to replace SMPE controlled 
data.Basically you have the tar’d payload, a script that is aware of SMPE 
phase/actions, etc, and based on an apply or restore does the work.Whether 
you are writing a usermod or installing a FMID I think the contruction would be 
very similar.   This is the job stream to build usermod to apply updates to 
java.security

This script will either create or delete the backup copies of the
security policy jar files.
Policy jar files are installed/removed from the J11.0_64/conf/security
directory. The script uses the following environment variables
for input:

SMP_Directory - directory in which the file resides
SMP_File - name of the HFS file
SMP_Phase - indicates whether the shell script is being called
before or after SMP/E has processed the file
SMP_Action - the action that SMP/E is performing: COPY or DELETE

Here is a jobstream that builds the usermod.  I cannot take total credit for 
it, another member here on IBM-MAIN (whom I cannot remember) got me started.

//E008058E JOB (DP,8710),'MAJV116BUILD',CLASS=X,MSGCLASS=T,
//NOTIFY=E008058
//HEADER   EXEC PGM=IEBGENER
//SYSUT1   DD   DATA,DLM=$$
//E008058E JOB (DP,8710),'MAJV116',CLASS=X,MSGCLASS=T,
//NOTIFY=E008058
//PROCLIB JCLLIB   ORDER=(E008058.SMPE.ZOS25.CLONE.JCL.PROCLIB)
//SMPAPPLY EXEC SMPE
//SMPHOLD   DD DUMMY
//SYSIN  DD *
 SET BDY(GLOBAL) .
  RECEIVE S(MAJV116) SYSMODS BYPASS(APPCHK).
 SET BDY(MVSTZN).
  APPLY S(MAJV116) REDO.
/*
//*  RESTORE S(MAJV116) .
//*  REJECT S(MAJV116) BYPASS(APPCHK).
//SMPPTFIN  DD DATA,DLM=ZZ
++ USERMOD (MAJV116)  /*
 IBM JAVA 11.0 (64-Bit) platform */.
++ VER (Z038)
   FMID(HJVBB00) PRE(UI94773)
/*
  USERMOD DESCRIPTION(S):
MAJV116 -
  
  * WARNING:  DO NOT modify this usermod.  It is created and *
  *   built in SMPE.ZOSnnn.USERMODS.BUILD*
  
  * USERMOD DESCRIPTION: *
  *   - Enabling CSF key support by adding entry to  *
  * java.security for IBMJCECCA  *
  * inserted as the security.provider.2= entry.  *
  *  *
  * The JMVPRC16 proc is here to insure that these changes   *
  * to Java 11.0 can not be accidently lost due to a new  *
  * level of maintence being installed via SMP/E without *
  * some notification of the regression. *
  *  *
  *  D.jousma 11/14/22 - updated Build of MAJV116(USERMOD),  *
  *MAJV116J(HFS),   MAJV116S(Script) *
  *in SMPE.ZOS25.USERMODS.BUILD  *
  *to support JAVA 11.0  *
  *  *
  
  */.
++ HFS (MAJV116J)  /* $java_home/lib/security/java.security.sklm */
   DISTLIB (AAJVHFS)
   SYSLIB  (SAJVB0P)
   PARM (PATHMODE(0,6,4,4))
   LINK ('../conf/security/java.security.sklm')
   SHSCRIPT (MAJV116S,POST)
   TEXT .
$$
//SYSUT2   DD   DSN=&,DISP=(NEW,PASS),RECFM=FB,LRECL=80,
//BLKSIZE=0,SPACE=(CYL,16)
//SYSPRINT DD   SYSOUT=*
//SYSINDD   DUMMY
//JAVA EXEC PGM=GIMDTS
//SYSPRINT DD   SYSOUT=*
//SYSUT1   DD   DSN=SMPE.ZOS25.USERMODS.BUILD(MAJV116J),DISP=SHR
//SYSUT2   DD   DSN=&,DISP=(MOD,PASS)
//MIDDLE   EXEC PGM=IEBGENER
//SYSUT1   DD   DATA,DLM=$$
++ SHELLSCR (MAJV116S)   /* $java_home/MAJV116s */
   DISTLIB (AAJVHFS)
   SYSLIB  (SAJVB0P)
   PARM (PATHMODE(0,7,5,5))
   TEXT .
$$
//SYSUT2   DD   DSN=&,DISP=(MOD,PASS)
//SYSPRINT DD   SYSOUT=*
//SYSINDD   DUMMY
//SCRIPT   EXEC PGM=GIMDTS
//SYSPRINT DD   SYSOUT=*
//SYSUT1   DD   DSN=SMPE.ZOS25.USERMODS.BUILD(MAJV116S),DISP=SHR
//SYSUT2   DD   DSN=&,DISP=(MOD,PASS)
//END  EXEC PGM=IEBGENER
//SYSUT1   DD   DATA,DLM=$$
++ PROC (JVMPRC16) DISTLIB(APROCLIB) SYSLIB(PROCLIB) TXLIB(APROCLIB).
$$
//SYSUT2   DD   DSN=&,DISP=(MOD,PASS)
//SYSPRINT DD   SYSOUT=*
//SYSINDD   DUMMY
//END  EXEC PGM=IEBGENER
//SYSUT1   DD   DATA,DLM=$$
ZZ
//
$$
//SYSUT2   DD   DSN=&,DISP=(MOD,PASS)
//SYSPRINT DD   SYSOUT=*
//SYSINDD   DUMMY
//SAVEIT   EXEC PGM=IEBGENER
//SYSUT1   DD   DSN=&,DISP=(MOD,PASS)
//SYSUT2   DD   DSN=SMPE.ZOS25.USERMODS(MAJV116),DISP=SHR
//SYSPRINT DD   SYSOUT=*
//SYSINDD   DUMMY

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Lionel B. Dyck <057b0ee5a853-dmarc-requ...@listserv.ua.edu>
Date: Thursday, March 14, 2024 at 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Standard Packaging Rules for 

Re: IBM Announces the z/OS Container Platform

[Jousma, David]

Timothy,

I’ll wait to see more information as it becomes available.   So zCX is Ubuntu 
Linux on z/OS, IBM has labelled Redhat Openshift as zCX-OCP, and now we have 
zOSCP.   I like the container Ideas, but this literally sounds like z/OS Unix 
inside a container?   I guess that surprises me, as I don’t hear about people 
actively coding in z/OS Unix.   Or is this something else?

BTW, I am a big proponent of ZCX, and would like to see IBM move its ancillary 
mainframe support software into a docker container.   I know TWS DWC, Omegamon 
TEPS, and others are moving that way.   Just waiting for more to come. We 
are also running Rocker Terminal Emulator Webedition in ZCX to replace all of 
our desktop out-of-date Bluezone implementations.

Dave Jousma
Vice President | Director, Technology Engineering


From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Date: Tuesday, March 5, 2024 at 8:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: IBM Announces the z/OS Container Platform
I’d like to draw your attention to this IBM announcement: https: //urldefense. 
com/v3/__https: //www. ibm. 
com/docs/en/announcements/zos-container-platform-delivers-industry-standard-cloud-technologies-build-run-zos-unix-applications-as-containers-natively-zos__;!!MwwqYLOC6b6whF7V!g9jgcYA166VI9yCFuvhNkTfHy8dDjgaHN__msC1njoKwcSod3-qptPTbiM-TB68jc0uSWrpixIKdSvtHkw$


I’d like to draw your attention to this IBM announcement:



https://urldefense.com/v3/__https://www.ibm.com/docs/en/announcements/zos-container-platform-delivers-industry-standard-cloud-technologies-build-run-zos-unix-applications-as-containers-natively-zos__;!!MwwqYLOC6b6whF7V!g9jgcYA166VI9yCFuvhNkTfHy8dDjgaHN__msC1njoKwcSod3-qptPTbiM-TB68jc0uSWrpixIKdSvtHkw$>



—

Timothy Sipples

Senior Architect

Digital Assets, Industry Solutions, and Cybersecurity

IBM Z/LinuxONE, Asia-Pacific

sipp...@sg.ibm.com





--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Changes to user's TSO PROFILE

[Jousma, David]

Is she logging off cleanly?  Or is she letting her session 522 off.  If the 
latter profile changes don’t get written out and would explain the behavior.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Monday, March 4, 2024 at 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Changes to user's TSO PROFILE
Is there anything that tracks changes to a TSO user's PREFIX? I have a user who 
says her PREFIX keeps getting changed to NOPREFIX. Sent with [Proton 
Mail](https: //urldefense. com/v3/__https: //proton. 
me/__;!!MwwqYLOC6b6whF7V!navz9IU9urj6-WD1bs70v0jirVugGM3fVsmTgIhtPtaDd2ydFFBLTQtu_EI2_Zl_JqzVn7SpnLGTzHWtjx_XvDxZXMXTL0lVDJg$)


Is there anything that tracks changes to a TSO user's PREFIX? I have a user who 
says her PREFIX keeps getting changed to NOPREFIX.



Sent with [Proton 
Mail](https://urldefense.com/v3/__https://proton.me/__;!!MwwqYLOC6b6whF7V!navz9IU9urj6-WD1bs70v0jirVugGM3fVsmTgIhtPtaDd2ydFFBLTQtu_EI2_Zl_JqzVn7SpnLGTzHWtjx_XvDxZXMXTL0lVDJg$)
 secure email.



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: RACF, external password management

[Jousma, David]

Linda,

I'd think twice on this topic.   We do vault our elevated access id's and I am 
fine with that, but to hand off all password management is a solution looking 
for a problem.

There is the racf password quality exit that can be coded up to disallow 
"common" passwords.  On top of that, you can "Force" passphrase use with 
minimum length requirements making such common passwords pretty much a thing of 
the past.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Linda Hagedorn <05cf4637de00-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, February 28, 2024 4:35:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: RACF, external password management

My company wants an external password manager to substitute for RACF. I need to 
know if anyone has experience with this, or common password matching in RACF. 
Background Regulations NYDFS require preventing common passwords to be used. 
Vendor


My company wants an external password manager to substitute for RACF.
I need to know if anyone has experience with this, or common password matching 
in RACF.

Background
Regulations NYDFS require preventing common passwords to be used.
Vendor tools (Courion, CyberArk, etc.) have a corpus to match password changes 
to prevent the use of common passwords.
RACF passwords can be changed from TSO, the internal reader, JCL, Candle 
Session manager, etc., so trying to block password changing through RACF and 
forcing everyone through one of these 3rd party tools may be near impossible.

Any input is appreciated.  Thanks!  Linda

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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Question on BUILDMCS

[Jousma, David]

Just run the buildmcs.  It will use those files to copy from to create the 
relfiles from, when received into the new environment.   Make sure all 
maintenance has been applied.  Many folks run the buildmcs for the fmid in the 
DLIB environment.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
Date: Monday, February 26, 2024 at 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Question on BUILDMCS
Classification: Confidential I am in the process of performing a BUILDMCS for 
the 1st time. This is to preserve some products no longer orderable from IBM. I 
have RTFM'ed the manuals (SMP/E User's Guide and SMP/E Commands), and the 
actual requirements


Classification: Confidential



I am in the process of performing a BUILDMCS for the 1st time. This is to 
preserve some products no longer orderable from IBM.

I have RTFM'ed the manuals (SMP/E User's Guide and SMP/E Commands), and the 
actual requirements are unclear.



When I look at the SMPPUNCH I see stuff like:

++MAC(x)  distlib( )  fromdsn() number(2) vol()  .



I presume number(x) is the relfile number AND fromdsn is the current location 
of the item.



Do I need to physically preserve the current target/distlibs for this product 
to the build MCS can be executed?



Thanks in advance,

::DISCLAIMER::



The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.





--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Tn3270 back door

[Jousma, David]

Issue TCPIP OBEY command from the console?

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
James Cradesh <05a6576c6fa2-dmarc-requ...@listserv.ua.edu>
Date: Friday, February 16, 2024 at 5:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Tn3270 back door
I’m locked out of my test lpar. The ssl cert expired. A new cert was uploaded 
but the tn3270 doesn’t see it. I did refresh Pagent but it didn’t help. How do 
you get around this situation? Is there a way to enable the non ssl port? 
--


I’m locked out of my test lpar.  The ssl cert expired.  A new cert was uploaded 
but the tn3270 doesn’t see it. I did refresh Pagent but it didn’t help.  How do 
you get around this situation?  Is there a way to enable the non ssl port?



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: New SSH vulnerability

[Jousma, David]

We were able to remediate the situation by the following ssh config changes.
 Thanks to our invisible friend kekronbekron for pointing me to some additional 
helpful information.


EDIT /etc/ssh/zos_ssh_config

Command ===>

** *

01 # set crypto options

02 CiphersSource ICSF





EDIT /etc/ssh/sshd_config

Command ===>

000102 Subsystem sftp /usr/lib/ssh/sftp-server

000103

000104 #set crypto options

000105 Ciphers 
aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com<mailto:aes128-...@openssh.com>,aes256-...@openssh.com<mailto:aes256-...@openssh.com>


Dave Jousma
Vice President | Director, Technology Engineering





From: Jousma, David 
Date: Thursday, January 25, 2024 at 9:04 AM
To: IBM-Main (ibm-main@listserv.ua.edu) 
Subject: New SSH vulnerability
Looks like a fairly new SSH vulnerability has surfaced…Anyone figure out a 
local remediation for this yet?   As per usual, IBM is mum.   There is no 
fixing PTF yet based on what I see in ResourceLink.


QID

38913

Severity

HIGH

Definition

SSH Prefix Truncation Vulnerability (Terrapin)

Description

The Terrapin attack exploits weaknesses in the SSH transport layer protocol in 
combination with newer cryptographic algorithms and encryption modes introduced 
by OpenSSH over 10 years ago. Since then, these have been adopted by a wide 
range of SSH implementations, therefore affecting a majority of current 
implementations.





QID Detection Logic (Unauthenticated):



This detection attempts to start the SSH key exchange process and examines 
whether either of the vulnerable ChaCha20-Poly1305 Algorithm or CBC-EtM 
Algorithm is active. It subsequently verifies whether Strict Key Exchange is 
enabled. If a target is identified as vulnerable, it indicates that the target 
supports either of the vulnerable algorithms and lacks support for Strict Key 
Exchange.

Solution

Customers are advised to refer to the individual vendor advisory for their 
operating system and install the patch released by the vendor. For more 
information regarding the vulnerability, please refer to Terrapin Vulnerability



Patch:



Following are links for downloading patches to fix the vulnerabilities:

OpenWall Security Advisory

Impact

Successful exploitation of the vulnerability may allow an attacker to downgrade 
the security of an SSH connection when using SSH extension negotiation. The 
impact in practice heavily depends on the supported extensions. Most commonly, 
this will impact the security of client authentication when using an RSA public 
key.

CVEs

CVE-2023-48795

Results

SSH Prefix Truncation Vulnerability (Terrapin) detected on port: 22

ChaCha20-Poly1305 Algorithm Support: True

CBC-EtM Algorithm Support: False

Strict Key Exchange algorithm enabled: False

EVM Report

Yes

EVM Risk Score

4.9

Host Details

Host

192.168.30.2

IP Address

192.168.30.2

Operating System

IBM OS/390

Tier

T3

FQDN



Port

22

Protocol

tcp




Dave Jousma
Vice President | Director, Technology Engineering






This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

New SSH vulnerability

[Jousma, David]

Looks like a fairly new SSH vulnerability has surfaced…Anyone figure out a 
local remediation for this yet?   As per usual, IBM is mum.   There is no 
fixing PTF yet based on what I see in ResourceLink.


QID

38913

Severity

HIGH

Definition

SSH Prefix Truncation Vulnerability (Terrapin)

Description

The Terrapin attack exploits weaknesses in the SSH transport layer protocol in 
combination with newer cryptographic algorithms and encryption modes introduced 
by OpenSSH over 10 years ago. Since then, these have been adopted by a wide 
range of SSH implementations, therefore affecting a majority of current 
implementations.





QID Detection Logic (Unauthenticated):



This detection attempts to start the SSH key exchange process and examines 
whether either of the vulnerable ChaCha20-Poly1305 Algorithm or CBC-EtM 
Algorithm is active. It subsequently verifies whether Strict Key Exchange is 
enabled. If a target is identified as vulnerable, it indicates that the target 
supports either of the vulnerable algorithms and lacks support for Strict Key 
Exchange.

Solution

Customers are advised to refer to the individual vendor advisory for their 
operating system and install the patch released by the vendor. For more 
information regarding the vulnerability, please refer to Terrapin Vulnerability



Patch:



Following are links for downloading patches to fix the vulnerabilities:

OpenWall Security Advisory

Impact

Successful exploitation of the vulnerability may allow an attacker to downgrade 
the security of an SSH connection when using SSH extension negotiation. The 
impact in practice heavily depends on the supported extensions. Most commonly, 
this will impact the security of client authentication when using an RSA public 
key.

CVEs

CVE-2023-48795

Results

SSH Prefix Truncation Vulnerability (Terrapin) detected on port: 22

ChaCha20-Poly1305 Algorithm Support: True

CBC-EtM Algorithm Support: False

Strict Key Exchange algorithm enabled: False

EVM Report

Yes

EVM Risk Score

4.9

Host Details

Host

192.168.30.2

IP Address

192.168.30.2

Operating System

IBM OS/390

Tier

T3

FQDN



Port

22

Protocol

tcp




Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: I hate to be a pain (Cross-Posted)

[Jousma, David]

Your keystore should be RACF or TSS.   Depending on keylength, ICSF will likely 
store parts of the key in CKDS or PKDS datasets.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Steve Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu>
Date: Wednesday, January 17, 2024 at 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: I hate to be a pain (Cross-Posted)
This is not may area of expertise, and I can't find a YOUTUBE or a step by step 
checklist How does one create a keystore on zOS? Regards, Steve 
-- For 
IBM-MAIN subscribe /


This is not may area of expertise, and I can't find a YOUTUBE or a step by

step checklist







How does one create a keystore on zOS?











Regards,











Steve









--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Jousma, David]

Pretty hard to mess up the master key, since it only lives in the crypto 
hardware.

That's the other thing though.  Sounds like the OP wants to encrypt everything 
with the same HLQ, with the same key  that's a big exposure if the key gets 
accidentally deleted.  Not sure what the rule of thumb is either, as one key 
per dataset turns into a key management nightmare.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Leonard D Woren 
Sent: Sunday, January 14, 2024 7:05:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE 
format)?

(I read the whole thread before starting this reply. ) Steve Estle wrote on 
1/13/2024 8: 28 AM: > [. . . ] > My true reason for composing this is that 
we've discovered the inability to encrypt load libraries - even in PDSE format. 
[. . . ] >


(I read the whole thread before starting this reply.)

Steve Estle wrote on 1/13/2024 8:28 AM:
> [...]
> My true reason for composing this is that we've discovered the inability to 
> encrypt load libraries - even in PDSE format.
[...]
> I know this seems innocuous, but we'd like to encrypt as much as possible in 
> our environment and due to Top Secret deficiencies we have to encrypt at high 
> level qualifier level (HLQ) (all or nothing under each HLQ unfortunately).  
> Given we have load module libraries under many differ HLQ's this is posing 
> difficulties in moving forward with our rollout when an HLQ does have one or 
> more load module libraries as part of that HLQ.  You can only imagine the 
> pain of renaming a load library given all the JCL, etc that is referencing 
> that library name.

So, you have poor naming conventions and a poor security system, and
you want IBM to make difficult changes which will potentially affect
all customers negatively?

> 2. If I were to submit an IBM idea, can I count on this community for some 
> backing here to help in upvoting such an idea submission?

I'd vote the highest value of "no".


An aside, since I didn't keep track of which comment mentioned this
(maybe it was on an old item cross-posted from RACF-L?).  For those
concerned about ransomware, z/OS encryption of all data at rest means
that a ransomware hacker need only mess up the master key so that no
data sets can be decrypted.  No need to waste time encrypting all
data, since it's already encrypted.


/Leonard


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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Jousma, David]

We looked at dataset encryption to please our auditors.Just trying to see 
the benefit, honestly.If you are a permitted user of the dataset by any 
means, then you have to be permitted to the encryption key profile as well.

So who are you protecting the data from?  Storage managers?  Storage managers 
don't need access to datasets to manage them.

Additionally, I think IBM dropped the ball a bit in that nothing stops a 
permitted user to copy that data to an un-encrypted dataset.  IMO, once 
encrypted any copies inherit the same encryption.

The technology that I see as beneficial is one that I think is in the works 
with ibm in that data will never be decrypted including during execution.  I 
forget the term used for that.

Other parts of PE we are doing, focusing mostly on encrypted IP connections, 
encrypted ficon, and possibly encrypted cf structures.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Steve Estle 
Sent: Saturday, January 13, 2024 11:28:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

Everyone, Our team is knee deep into pervasive encryption rollout on ZOS 2. 5 
and despite the fact such functionality has been out for years by IBM to do 
this, it is quite surprising how many software vendors when you contact them 
they have


Everyone,

Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and despite 
the fact such functionality has been out for years by IBM to do this, it is 
quite surprising how many software vendors when you contact them they have no 
clue what you're talking about - that is a complete aside - I'm not going to 
name vendors here but if you want some examples you can contact me offline.

My true reason for composing this is that we've discovered the inability to 
encrypt load libraries - even in PDSE format.  I've yet to get a straight 
answer from IBM on why this is?...   Is this a "giant" technical hurdle for 
IBM?  Or is it just cause there hasn't been anyone who raised the need yet?  If 
the latter does this capability interest others here if I were to raise as an 
IBM idea - would you vote for it?

I know this seems innocuous, but we'd like to encrypt as much as possible in 
our environment and due to Top Secret deficiencies we have to encrypt at high 
level qualifier level (HLQ) (all or nothing under each HLQ unfortunately).  
Given we have load module libraries under many differ HLQ's this is posing 
difficulties in moving forward with our rollout when an HLQ does have one or 
more load module libraries as part of that HLQ.  You can only imagine the pain 
of renaming a load library given all the JCL, etc that is referencing that 
library name.

Also, while encrypting load module libraries might seem a little far fetched, 
there are of course many malicious viruses that have been launched by injecting 
code into a suspecting piece of code.

So two questions:

1. Why has IBM not already provided such functionality - can anyone speak to 
the technical hurdles to provide?
2. If I were to submit an IBM idea, can I count on this community for some 
backing here to help in upvoting such an idea submission?

Thanks for your indulgence,

Steve Estle
sest...@gmail.com
Peraton systems programmer

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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Stupid JCL question

[Jousma, David]

Ok, so how about the obvious response…… Since you are going to edit the JCL to 
add // or something, why not just comment out or delete the remaining JCL?

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Date: Friday, December 22, 2023 at 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Stupid JCL question
Ooh, not bad! At least, it looks not-bad at first blush, though before I 
implement it I guess I'll wait to see what other comments surface here. Thanks, 
Sri. --- Bob Bridges, robhbridges@ gmail. com, cell 336 382-7313 /* Freedom of 
the press


Ooh, not bad!  At least, it looks not-bad at first blush, though before I 
implement it I guess I'll wait to see what other comments surface here.  
Thanks, Sri.



---

Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313



/* Freedom of the press is limited to those who own one.  -Abbott Joseph 
Liebling */



-Original Message-

From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu

Sent: Friday, December 22, 2023 12:30



Your option works, however, there is another option to make jcl skip steps with 
enclosing the steps as data.



For example, if you had 10 steps and you want only first 6 steps to run then 
simply add //SAVEDD DATA,DLM=## after step 5 and everything else below it 
will be ignored .  It also will give the flexibility of skipping some steps in 
between and run later steps too.



//STEP0100 EXEC PGM=PGM0

//STEP0500 EXEC PGM=PGM4

//STEP0600 EXEC PGM=PGM5

//STEP0700 EXEC PGM=PGM6

//STEP0800 EXEC PGM=PGM7

//STEP0900 EXEC PGM=PGM8



So, from the above example. You code it as follows.



//STEP0100 EXEC PGM=PGM0

//STEP0500 EXEC PGM=PGM4

//SAVEDD DATA,DLM=##

//STEP0600 EXEC PGM=PGM5

//STEP0700 EXEC PGM=PGM6

//STEP0800 EXEC PGM=PGM7

//STEP0900 EXEC PGM=PGM8



For example, if you want to run steps 1 thru 5 and 8 thru 10 you code something 
like this



//STEP0100 EXEC PGM=PGM0

//STEP0500 EXEC PGM=PGM4

//SAVEDD DATA,DLM=##

//STEP0600 EXEC PGM=PGM5

//STEP0700 EXEC PGM=PGM6

##

//STEP0800 EXEC PGM=PGM7

//STEP0900 EXEC PGM=PGM8



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: What is RSED and do I need it on the Mainframe

[Jousma, David]

I should have mentioned to Lizette that you can issue some operator commands 
against the task to see if there is any usage

F RDZRSED,APPL=D P,d

14.03.41 STC12858  BPXM023I (RDZRSED)  447
   447 ProcessId(1114457 ) ASId(00F2) JobName(RDZRSED1) Order(1)
   447  PROCESS LIMITS:CURRENT  HIGHWATER  LIMIT
   447   JAVA HEAP USAGE(%)  3  6100
   447   CLIENTS 0  1 20
   447   MAXFILEPROC   118142  64000
   447   MAXPROCUSER14 14400
   447   MAXTHREADS 34 61  1
   447   MAXTHREADTASKS 34 61   5000
   447  REGION LIMITS: CURRENT  HIGHWATER  LIMIT
   447   PRIVATE < 16M  428.0K  -  10.5M (10.5M)
   447   PRIVATE > 16M  272.3M  -1271.8M (1364.0M)
   447   PRIVATE > 2G   976.0M   1.0GNOLIMIT
   447
   447 ProcessId(1114821 ) ASId(008C) JobName(RDZRSED2) Order(2)
   447  PROCESS LIMITS:CURRENT  HIGHWATER  LIMIT
   447   JAVA HEAP USAGE(%)  3  7100
   447   CLIENTS 0  2 20
   447   MAXFILEPROC   118156  64000
   447   MAXPROCUSER14 14400
   447   MAXTHREADS 34 85  1
   447   MAXTHREADTASKS 34 85   5000
   447  REGION LIMITS: CURRENT  HIGHWATER  LIMIT
447   PRIVATE < 16M  428.0K  -  10.5M (10.5M)
447   PRIVATE > 16M  271.9M  -1271.7M (1364.0M)
447   PRIVATE > 2G   976.0M   1.1GNOLIMIT
447
447 ProcessId(1115005 ) ASId(0107) JobName(RDZRSED3) Order(3)
447  PROCESS LIMITS:CURRENT  HIGHWATER  LIMIT
447   JAVA HEAP USAGE(%)  2  7100
447   CLIENTS 1  2 20
447   MAXFILEPROC   125170  64000
447   MAXPROCUSER14 14400
447   MAXTHREADS 57 84  1
447   MAXTHREADTASKS 57 84   5000
447  REGION LIMITS: CURRENT  HIGHWATER  LIMIT
447   PRIVATE < 16M  448.0K  -  10.5M (10.5M)
447   PRIVATE > 16M  272.4M  -1269.9M (1364.0M)
447   PRIVATE > 2G 1.0G   1.1GNOLIMIT
447
447

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Richard Ruppel 
Date: Wednesday, December 20, 2023 at 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: What is RSED and do I need it on the Mainframe
Dave is right, it is part of IBM Developer for Z and IBM Explorer for z/OS. 
These are tools that your developers may be using for anything from accessing 
z/OS to debugging programs, to working with a source code manager. There's a 
lot of things


Dave is right, it is part of IBM Developer for Z and IBM Explorer for z/OS.  
These are tools that your developers may be using for anything from accessing 
z/OS to debugging programs, to working with a source code manager.  There's a 
lot of things that can be done through these GUIs.  If you have contacts in the 
application teams, you could check to see if they are using these tools.



Richard Ruppel

rmrup...@us.ibm.com



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

[Jousma, David]

This statement is very confusing to me?So for DB2V13 is installed in its 
own global zone, with target and dlib zones.It’s the next part of your 
statement “use my existing target and dlib zones and update ddefs…” that is 
confusing me.   It sounds like you are trying to marry your V13 work with some 
other downlevel environment?  To me it sounds like you already have a V13 
environment, along with some “older” environment.I cannot tell what you are 
trying to accomplish.


>> On Thu, 14 Dec 2023 11:27:16 -0600, Ross Vaughn 
>> mailto:ross.vaugh...@gmail.com>> wrote:

>>

>>> I’m upgrading a product in my DB2v13 global zone.  I plan to use my 
>>> existing target & DLIB zones and just update my DDDEFs to point to my new 
>>> dataset names.

>>> My question is - if I want to create new CSI’s (copied from my existing 
>>> CSIs) for


Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: What is RSED and do I need it on the Mainframe

[Jousma, David]

If the STC proc looks similar to this, it’s a part of z/explorer and/or iDZ.   
You could shut it down, and see who complains.   There is usually a JMON task 
that goes with it for JES interface.

//RSED PROC IVP=, * 'IVP' to do an IVP
//PORT=,
//CNFG='/etc/zexpl',
//HOME='/usr/lpp/IBM/zexpl'
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
// PARM='PGM /bin/rsed.sh  -C -P'
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*



Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Date: Thursday, December 14, 2023 at 2:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: What is RSED and do I need it on the Mainframe
What is the STC RSED? Is it something I need or can I shut it down and remove 
the software? I have very little documentation on this function and how it is 
used in a Mainframe Thank you Lizette 
--






What is the STC RSED?  Is it something I need or can I shut it down and

remove the software?







I have very little documentation on this function and how it is used in a

Mainframe









Thank you







Lizette





--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: SQA overflow condition

[Jousma, David]

Peter, have you been doing any PAGE ADDS, and PAGE DELETES?Years ago, when 
we were migrating to new DASD (TDMF wont move active local page datasets), I 
exhausted EQSA but didn’t realize it at the time.   Now you do PAGE DELETE with 
REPLACE to avoid the ESQA problem.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Peter 
Date: Monday, December 11, 2023 at 5:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SQA overflow condition
These increase we have been whitenessing in last 1 month and never saw this 
overflowing in last 2 years. No software changes have been made but one of the 
product upgrade was backed out but we kept the products LPA SVC module in 
LPALST as the


These increase we have been whitenessing in last 1 month and never saw this

overflowing in last 2 years.



No software changes have been made but one of the product upgrade was

backed out but we kept the products LPA SVC module in LPALST as the SVC

module shipped with higher version of the new product(which was backed out)

was also compatible with lower version of the same product.



So my question can the new SVC module which was shipped with newer version

of product being utilized by lower version of product can cause spike in

ESQA ?







On Mon, Dec 11, 2023, 2:32 PM Martin Packer 

wrote:



> I’m wondering why 108% is a problem. I’d say that’s about the right amount

> of overflow. Unless you know have a shortage of free ECSA.

>

> Thanks, Martin

>

> From: IBM Mainframe Discussion List  on behalf

> of Peter 

> Date: Monday, 11 December 2023 at 04:29

> To: IBM-MAIN@LISTSERV.UA.EDU 

> Subject: [EXTERNAL] Re: SQA overflow condition

> The ESQA usage has gone to 108%.

>

> Is there any tool available in CBTTAPEA which can tell me or trace SQA

> users and who are not releasing the storage?

>

> On Mon, Nov 27, 2023, 5:37 PM Allan Staller <

> 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:

>

> > Classification: Confidential

> >

> > 100% concur w/Martin

> >

> > -Original Message-

> > From: IBM Mainframe Discussion List  On Behalf

> > Of Martin Packer

> > Sent: Sunday, November 26, 2023 2:39 AM

> > To: IBM-MAIN@LISTSERV.UA.EDU

> > Subject: Re: SQA overflow condition

> >

> > [CAUTION: This Email is from outside the Organization. Unless you trust

> > the sender, Don’t click links or open attachments as it may be a Phishing

> > email, which can steal your Information and compromise your Computer.]

> >

> > (This is not specific advice but a way of thinking about things.)

> >

> > SQA can, of course, overflow into CSA - with no real harm done. Unless it

> > causes CSA to go short. (CSA can't overflow into SQA, of course.)

> >

> > The above statements are true for both 24-bit and 31-bit.

> >

> > 1409K below the line, though, is pretty extreme - for 24 bit. If you made

> > SQA larger so that it only overflowed, say, by 100K there would be no

> > wasted virtual storage.

> >

> > More importantly, check out the "free CSA" picture. You really don't want

> > to run out of that. For 24-bit you want a few hundred K free. (But to

> > achieve that might require losing 1MB of 24-bit private, which might not

> be

> > consequence free.)

> >

> > For 31 bit I like to see at least 100MB free ECSA, preferably more. The

> > reason is because ECSA is - in my experience - more volatile.

> >

> > Speaking of volatility, you need to plan defensively - as a problem can

> > lead to surge in SQA and CSA usage .

> >

> > Final point: I would advocate using SMF 78-2 to build a picture of common

> > storage usage - and how variable it is. Here is a blog post I wrote on

> the

> > matter:

> >

> > htt ps://

> > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage

> >

> > (Take out the space to follow the URL - as my mail client turned it into

> > an attachment.) 

> >

> > Cheers, Martin

> >

> > Sent from my iPad

> >

> > > On 26 Nov 2023, at 05:40, Peter  wrote:

> > >

> > > Hello

> > >

> > > I am able to see the below alert condition under RMF postprocessor III

> > >

> > >

> > >

> > > Name Reason Critical val. Possible cause or action

> > >

> > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K.

> > >

> > >

> > >

> > >

> > >

> > > Our SQA and CSA set up in our IEASYSxx is as below

> > >

> > >

> > >

> > > CSA=(2000,30)

> > >

> > >

> > >

> > > SQA=(16,192)

> > >

> > >

> > > Hardware: z14

> > > LPAR : 16gb memory

> > > zOS 2.4

> > >

> > > Do I have think about tunning the SQA parameter ?

> > >

> > > Regards

> > > Peter

> > >

> > > --

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

> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

> >

> > Unless otherwise stated above:

> >

> > IBM United Kingdom Limited

> > Registered in England and 

Re: CBS's "60 Minutes": Quantum Computing

[Jousma, David]

Bob,

It's pretty long haired geeky work going on there, and I think it's hard for 
our older minds to wrap around it.   A year ago I was in POK for executive 
briefing and they gave us a tour of the older quantum computer that they 
actually let people see.   Pretty unimpressive as not much to look at, and the 
one thing that stood out to me was that it's an entirely analog machine.   They 
were correct that they have a front end processor that converts your "program" 
to whatever it uses to load the quantum processor.

This is blowing the computing world apart, and why ibm is also developing 
quantum safe crypto algorithms to keep things secure.

I watched that 60 minutes story too.  The clips that I assume were in POK were 
not in front of the quantum we saw.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Tuesday, December 5, 2023 5:41:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: CBS's "60 Minutes": Quantum Computing

Ok, I watched it. I learned some things, but I still don't get it: 1) Scott 
Pelley describes the possible states of a bit (0 or 1), and then says "Quantum 
encodes information on electrons .. . [which] behave in a way so that they are 
heads AND


Ok, I watched it.  I learned some things, but I still don't get it:

1) Scott Pelley describes the possible states of a bit (0 or 1), and then
says "Quantum encodes information on electrons ... [which] behave in a way
so that they are heads AND tails and everything in between.  You've gone
from handling one bit of information to exponentially more data".  Omitting
the unfortunate misuse of "exponentially", if an electron can be in all
states at once, how can a programmer, or the program, determine what data is
recorded on it?  I don't see how that can be true; they must be using
impressive language to gloss over the details.

2) Michi Okaku likens the difference to calculating a path through a maze.
A "classical" computer (his word) must check all possible turnings one at a
time.  But a quantum computer (he claims) "scans all possible routes
simultaneously".  I can't picture that, and therefore I'm doubtful; again, I
suspect him of blathering about something that he really does understand but
cannot describe accurately for a 60-Minutes audience.

3) We're shown a diagram of five Q-bits, and the voiceover says "Unlike
transistors, each additional Q-bit doubles the computer's power".  That is
~not~ "unlike transistors"; it's exactly what traditional bits do.  "It's
exponential", continues the voiceover, which, again, is exactly what
classical bits are.  "So, while 20 transistors are 20 times more powerful
than one, twenty Q-bits are a ~million~ times more powerful...".  Somebody
should have vetted this sequence.

4) Karina Chou (sp?) of Google says their quantum computer is making an
error about every 100 steps; they're aiming for one every million or so.
Even at that target rate they surely need a lot of self-checking and
self-correcting, no?

5) Dario Gill, when the interviewer asked whether programmers have to learn
a new way of programming, responds "I think that's what's really nice, that
you actually just use a regular laptop, and you write a program - very much
like you would write a traditional program - but when you click on 'Go', it
just happens to run on a very different kind of computer".  I cannot
reconcile this with the above nor with other statements being made about
quantum computing.

It's occurred to me that the whole quantum-computing mania might be no more
than a huge hoax.  I don't believe it, no.  But so far I'm utterly clueless
how to understand the claims about it.

Regardless, thanks, Mr Sipples.  Very interesting.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Silence promotes the presence of God, prevents many harsh and proud
words, and suppresses many dangers in the way of ridiculing or harshly
judging our neighborsIf you are faithful in keeping silence when it is
not necessary to speak, God will preserve you from evil when it is right for
you to talk.  -Francois Fenelon (1651-1715) */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Timothy Sipples
Sent: Monday, December 4, 2023 23:22

If you'd like to understand why IBM is so bullish on quantum computing - and
so focused on quantum-safe cryptography - this "60 Minutes" story is well
worth watching:

https://urldefense.com/v3/__https://www.youtube.com/watch?v=K4ssT6Dzmnw__;!!MwwqYLOC6b6whF7V!jUbLfIaFRnBcXnreXdYyeEFQaEyh9er7r9VMQPuoMud8OeaPpNRLYftEArggb0ryeE0d-m0kz8hyK4_1FHNcJg$

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


This e-mail 

Re: How to download PERL from rocket

[Jousma, David]

You have to install Rockets miniconda I was lamenting a week or two ago.   It 
is the installer for all their ported opensource packages.   Or, if that is not 
important to you can go directly here, and download the tarball, and manually 
install yourself.   https://anaconda.org/zoss-appdev



Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
ITschak Mugzach 
Date: Tuesday, November 21, 2023 at 6:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: How to download PERL from rocket
I am trying to download Perl from Rocket, but when clicking "download Now" I 
get a screen "Rocket Open Source for z/os" without a download link. Any idea 
how to download Perl for z/os? ITschak ITschak Mugzach *|** IronSphere 
Platform* *|* *Information


I am trying to download Perl from Rocket, but when clicking "download Now"

I get a screen "Rocket Open Source for z/os" without a download link. Any

idea how to download Perl for z/os?



ITschak



ITschak Mugzach

*|** IronSphere Platform* *|* *Information Security Continuous Monitoring

for z/OS, x/Linux & IBM I **| z/VM coming soon  *



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Anyone with zCX docker hands on?

[Jousma, David]

David, I do have SWARM active, and both containers are (or were) connected.   
Ive tried creating an overlay network, and connecting the container to it, but 
still no luck.  In fact, I couldn’t even reach RTE from my browser to get a 
3270 session.I just don’t have enough personal experience to come up with 
the correct incantation needed to make the bits flow….

Like I said, RTE is picking up the internal local IP, not the host IP, and the 
internal IP is only known inside the zcx container.

Timothy, what you suggest could work, but my preference is to find the solution 
with “in-the-box” configuration?

Dave Jousma
Vice President | Director, Technology Engineering


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Date: Wednesday, November 8, 2023 at 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone with zCX docker hands on?
> On 8 Nov 2023, at 9: 36 pm, Timothy Sipples  wrote: > 
> > Dave Jousma wrote: > >> Thanks Timothy. Yep found all that, have the 
> instance up and working just fine > >> it’s the peer to peer




What software are you referring to, Docker? That’s fundamental to how Docker 
networking works. Publishing ports using “-p ” doesn’t make the 
services discoverable in docker containers. You meed overlay networking. TE Web 
is a typical clustering architecture using active/passive HA. You will also 
find that you can not run curl from within a Docker image. Most docker 
containers are built to take up as small a footprint as necessary so utilities 
like curl are not installed and you cannot instal them using apt if security 
keys are not enabled, which is best practice.





>

> (“Thinking out loud...”) Could you run a “bigger” Linux container image that 
> includes a VPN tunnel (such as WireGuard) to connect these two peers with one 
> another to work around the issue?



Why not just use a Docker clustering such as swarm instead of hacking together 
solutions that don’t work?

--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Anyone with zCX docker hands on?

[Jousma, David]

David Crayford Wrote:


If you intend to set up zCX for high availability, it would involve running
zCX instances on different LPARs. To achieve this, you'll likely need
Docker Swarm for creating a cluster that operates across multiple nodes.
While OpenShift (Kubernetes) is a more advanced option, it comes with much
higher operational costs in terms of resource usage. OpenShift 4.13 offers
incremental improvements, we've been told it's expected that further
enhancements will be introduced over time.

Thanks David.  I am actually working with one of your associates at Rocket on 
this.  I get the impression that while Rocket has tested RTE in docker (and 
documented as such), clustering never was.  They are going to work on that, and 
provide some example/samples.


Timothy Sipples wrote:

It provides an example using nginx, a popular HTTP(S) server. The example uses 
this startup command:

docker run -p 8080:80 -d nginx

The -p parameter is crucial. In this example it means, “Expose port 8080 to the 
outside world, and any traffic to/from port 8080 should be directed to/from 
port 80 within this nginx container image.” So if you’re trying to get two 
container images (on two different z/OS LPARs, as Dave Crayford suggested) to 
talk to each other you’d start them up with the -p option and then tell them to 
talk to each other on the respective external ports you’ve chosen. Hopefully 
obviously you should pick external ports that aren’t already occupied or 
reserved for other z/OS uses in that LPAR.

Thanks Timothy.  Yep found all that, have the instance up and working just fine 
it’s the peer to peer networking that is not working.   The fine folks at 
Rocket indicate that their software is picking up the internal container IP, 
and not using the Host IP causing the problem.   They are working up their own 
testing, and believe that docker overlay networking can resolve this.

Yes indeed, the reason for zCX vs straight z/OS Unix is the fact that it all 
runs on ZIIPS.   Plus its cool technology to learn and play with.  It’s all a 
part of changing perceptions here that mainframe is just a COBOL machine.   
Separately, we are doing a zCX Openshift POC, mainly because there wasn’t any 
additional infrastructure to provision.   If we were to do Openshift in any 
larger capacity, it would likely be on a LinuxOne box(es).   Our next move for 
DB2 IDAA has to be LinuxOne boxes as well.   I mention all of this as is to 
leverage our investment in GDPS and being able to Hiperswap/Region swap 
everything on  Z or LinuxOne boxes in a coordinated fashion for Disaster 
recovery or facilities maintenance.





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Anyone with zCX docker hands on?

[Jousma, David]

Matt,

I should have expounded at bit further.We’ll do load balancing for these 
zCX servers via F5 switch technology.   Its Rocket RTE that can setup a comm 
channel between the nodes to keep everything in sync.   That’s the problem I am 
trying to solve.

Dave Jousma
Vice President | Director, Technology Engineering





From: Jousma, David 
Date: Tuesday, November 7, 2023 at 2:05 PM
To: IBM Mainframe Discussion List 
Subject: Re: Anyone with zCX docker hands on?
Matt,  It’s vanilla zCX.   I have a separate Openshift POC going in other 
containers.   That’s an animal of its own too.

Dave Jousma
Vice President | Director, Technology Engineering


From: IBM Mainframe Discussion List  on behalf of 
Matt Hogstrom 
Date: Tuesday, November 7, 2023 at 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone with zCX docker hands on?
Is this zCX or are you also using OCP on top? OCP via K8s makes the scaling and 
network admin easier but its a chargeable feature. Matt Hogstrom matt@ 
hogstrom. org “It may be cognitive, but, it ain’t intuitive. " — Hogstrom > On 
Nov 7, 2023,


Is this zCX or are you also using OCP on top?  OCP via K8s makes the scaling 
and network admin easier but its a chargeable feature.



Matt Hogstrom

m...@hogstrom.org





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Anyone with zCX docker hands on?

[Jousma, David]

Matt,  It’s vanilla zCX.   I have a separate Openshift POC going in other 
containers.   That’s an animal of its own too.

Dave Jousma
Vice President | Director, Technology Engineering


From: IBM Mainframe Discussion List  on behalf of 
Matt Hogstrom 
Date: Tuesday, November 7, 2023 at 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone with zCX docker hands on?
Is this zCX or are you also using OCP on top? OCP via K8s makes the scaling and 
network admin easier but its a chargeable feature. Matt Hogstrom matt@ 
hogstrom. org “It may be cognitive, but, it ain’t intuitive. " — Hogstrom > On 
Nov 7, 2023,


Is this zCX or are you also using OCP on top?  OCP via K8s makes the scaling 
and network admin easier but its a chargeable feature.



Matt Hogstrom

m...@hogstrom.org





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Anyone with zCX docker hands on?

[Jousma, David]

Anyone in IBM-MAIN doing anything with zCX containers?   Ive successfully stood 
up Rocket Terminal Emulator(RTE) in a couple of separate ZCX hosts on z/OS 
V2.5.I am now trying to get the clustering feature of RTE to work, but 
there are specific network changes in Docker that need to be made to allow 
separate containers to communicate that Rocket doesn’t document, probably 
because docker experience is expected.   So far for me, its been a lesson of a 
lot of web reading, but no real success.

Just looking to trade some email off-list if someone would be willing to coach 
me along.

Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Better support for multiple master catalogs in a sysplex

[Jousma, David]

Lennie, I can appreciate your RFE, we used to maintain multiple mastercat’s in 
our prod sysplex, but do not anymore.Mostly due to the extra efforts and 
issues you note in your RFE.  Our OMVS and CSF datasets are in usercats.We 
do take catalog backups 4 times a day, and our master catalog is pretty stable, 
as in the contents of it doesn’t change much.

As for your highlights of certain products that are or could be VSAM, we do 
isolate some of those items into their own USERCAT so that we can have stricter 
access rules for those catalogs (general public doesn’t have update access).

We also happened to be a GDPS customer, so we have isolated K systems connected 
to the sysplex where we could do the necessary repairs if it ever came to that. 
   While not all shops are GDPS, the idea remains similar in that you could 
have another disconnected lpar with access to the DASD (but offline), to do any 
kind of necessary recovery.


Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu>
Date: Monday, November 6, 2023 at 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Better support for multiple master catalogs in a sysplex
I have just raised an RFE regarding support for better sharing of VSAM system 
datasets (such as RACF, ICSF key stores and ZFS file systems) when used in a 
sysplex with multiple master catalogs. Please would you examine it and support 
of relevant


I have just raised an RFE regarding support for better sharing of VSAM

system datasets (such as RACF, ICSF key stores and ZFS file systems) when

used in a sysplex with multiple master catalogs.



Please would you examine it and support of relevant for you.







https://urldefense.com/v3/__https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3890__;!!MwwqYLOC6b6whF7V!gDErcwuVzIRgwvRCcZtGPvKZe2wgGAOI3fK9vJWOm4eIrdxXqqQAsa01MoMDrNecT1BKVhVLI0_KyZu2WrJ83n211Cr90JjJM28$







Thanks











Lennie Dymoke-Bradshaw



https://urldefense.com/v3/__https://rsclweb.com__;!!MwwqYLOC6b6whF7V!gDErcwuVzIRgwvRCcZtGPvKZe2wgGAOI3fK9vJWOm4eIrdxXqqQAsa01MoMDrNecT1BKVhVLI0_KyZu2WrJ83n211Cr9tuyN6c4$
 
>





'Dance like no one is watching. Encrypt like everyone is.'









--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Rocket miniconda frustrations

[Jousma, David]

v3/__https:/docs.conda.io/en/latest/__;!!MwwqYLOC6b6whF7V!nKw2Q_nZJULzrJ_tuJayNPhavuj9X-vPKdWbHtISI-iAxar4rZJNPWs83CGlohsSe3UQKlrzXvpFHbFr$>.



It's worth mentioning that the introduction of a package manager for

installing ported tools hasn't been well-received by traditional sysprogs

who prefer the simplicity of downloading a tarball.

On Mon, Nov 6, 2023 at 12:25 AM Kirk Wolf  wrote:



> IBM removed cURL with a PTF? Wow.

>

> It sounds like you found a solution - going to the anaconda site that

> Rocket's miniconda uses and grabbing manually.

>

> I do understand why Rocket would want to use anaconda/miniconda, since it

> handles things like dependencies and other actions needed for

> installation.   They also want to distinguish their support vs free so it's

> understandable why they leave things out.

>

> Do you have an option of using a sandbox LPAR that *is* on the internet to

> manage Rocket packages and updates?  Then you could backup the filesystem

> and move it to your air gapped systems.

>

> Kirk Wolf

> Dovetailed Technologies

> http:// 
> <https://urldefense.com/v3/__http://secure-web.cisco.com/1Id-Qp2TEtetcpfLEhMZXip75BppuJVzAUWJwzcdSz8ngBRG3YYDWNLxGvwkErJWCtcgibj0zSH7FVkr7f7N0hhSt3tAzuazpVHgtc1FkvFjuyOj1aOmGc3Wu5BzzUoJI1pnFeWW52qvwauFPgosqqxmUU6jWnuvb25h_PjWJQ3zLX_FLsME8fR8SpPVMvD4eR9sFEB8tsaiiNhwjmegSsFXOqk_EF_KGUCuR7JYGlVP25pmddin99OcLd9_gFqMahs1MVvXS1Imb0LcATMnoECC4b_wbi4y1lpYc-7c3Aapf0L10I0l2QORnGF-gwyoTe97jXknyo3_gAyulXZFJ0yA0FrqkqHmJNu2G2AmV5VS6iava6oIigaaI5v4CFPSzJWXMn_MemamW4-m9-WPX0rH97d4Imk5mR4CxhB1RkyQ/http*3A*2F*2Fdovetail.com__;JSUl!!MwwqYLOC6b6whF7V!nKw2Q_nZJULzrJ_tuJayNPhavuj9X-vPKdWbHtISI-iAxar4rZJNPWs83CGlohsSe3UQKlrzXuVjcps-$<https://urldefense.com/v3/__http:/secure-web.cisco.com/1Id-Qp2TEtetcpfLEhMZXip75BppuJVzAUWJwzcdSz8ngBRG3YYDWNLxGvwkErJWCtcgibj0zSH7FVkr7f7N0hhSt3tAzuazpVHgtc1FkvFjuyOj1aOmGc3Wu5BzzUoJI1pnFeWW52qvwauFPgosqqxmUU6jWnuvb25h_PjWJQ3zLX_FLsME8fR8SpPVMvD4eR9sFEB8tsaiiNhwjmegSsFXOqk_EF_KGUCuR7JYGlVP25pmddin99OcLd9_gFqMahs1MVvXS1Imb0LcATMnoECC4b_wbi4y1lpYc-7c3Aapf0L10I0l2QORnGF-gwyoTe97jXknyo3_gAyulXZFJ0yA0FrqkqHmJNu2G2AmV5VS6iava6oIigaaI5v4CFPSzJWXMn_MemamW4-m9-WPX0rH97d4Imk5mR4CxhB1RkyQ/http*3A*2F*2Fdovetail.com__;JSUl!!MwwqYLOC6b6whF7V!nKw2Q_nZJULzrJ_tuJayNPhavuj9X-vPKdWbHtISI-iAxar4rZJNPWs83CGlohsSe3UQKlrzXuVjcps-$>>coztoolkit.com

>

> On Fri, Nov 3, 2023, at 6:44 PM, Jousma, David wrote:

> > We do pay for GIT client support through IBM, which I realize is

> actually rocket support behind the scenes.cURL used to come packaged

> with GIT client but was removed with IBM ptf.

> >

> > I was able to just go to the public anaconda website, and download the

> cURL tarball, upload it, and expand it and clone it where needed.   Our

> Jenkins pipeline needs it.

> >

> > Dave Jousma

> >

> > Vice President | Director, Technology Engineering

> >

> >

> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand

> Rapids, MI 49546

> >

> > 616.653.8429

> > 

> > From: IBM Mainframe Discussion List  on

> behalf of David Crayford 

> > Sent: Friday, November 3, 2023 7:01:11 PM

> > To: IBM-MAIN@LISTSERV.UA.EDU 

> > Subject: Re: Rocket miniconda frustrations

> >

> > > On 3 Nov 2023, at 10: 32 pm, Paul Gilmartin

> <042bfe9c879d-dmarc-request@ LISTSERV. UA. EDU> wrote: > > On Fri, 3

> Nov 2023 19: 42: 15 +0800, David Crayford wrote: >> >> Yes. But you still

> need the internet .. . >>

> >

> >

> > > On 3 Nov 2023, at 10:32 pm, Paul Gilmartin <

> 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> > >

> > > On Fri, 3 Nov 2023 19:42:15 +0800, David Crayford  wrote:

> > >>

> > >> Yes. But you still need the internet ...

> > >>

> > > What's the alternative?  Railway Express?  Dialup modem?

> >

> > A lot of customers air-gap their mainframe systems so you can’t use

> package managers. Colin Paice opened an issue for my pyzfile Python package

> to document installation methods on air-gapped systems

> https://urldefense.com/v3/__https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/reading-an-mvs-dataset-using-z-open-automation-utility__;!!MwwqYLOC6b6whF7V!nVlHVMjwgMI8doNcGXgOJIwnci0yoWLQREmOo_7c-J1hWzEQQaXiHBinMK7zqEFHNnMuAhcKDi1m24hwsjs$<https://urldefense.com/v3/__https:/community.ibm.com/community/user/ibmz-and-linuxone/discussion/reading-an-mvs-dataset-using-z-open-automation-utility__;!!MwwqYLOC6b6whF7V!nVlHVMjwgMI8doNcGXgOJIwnci0yoWLQREmOo_7c-J1hWzEQQaXiHBinMK7zqEFHNnMuAhcKDi1m24hwsjs$%3e>

><https://urldefense.com/v3/__https:/community.ibm.com/community/user/ibmz-and-linuxone/discussio

Re: Rocket miniconda frustrations

[Jousma, David]

Doubt IBM did.IBM just packages in smpe what rocket gives them, I assume.   
Search service link for git you will find the ptf

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Kirk Wolf 
Sent: Sunday, November 5, 2023 11:24:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Rocket miniconda frustrations

IBM removed cURL with a PTF? Wow. It sounds like you found a solution - going 
to the anaconda site that Rocket's miniconda uses and grabbing manually. I do 
understand why Rocket would want to use anaconda/miniconda, since it handles 
things


IBM removed cURL with a PTF? Wow.

It sounds like you found a solution - going to the anaconda site that Rocket's 
miniconda uses and grabbing manually.

I do understand why Rocket would want to use anaconda/miniconda, since it 
handles things like dependencies and other actions needed for installation.   
They also want to distinguish their support vs free so it's understandable why 
they leave things out.

Do you have an option of using a sandbox LPAR that *is* on the internet to 
manage Rocket packages and updates?  Then you could backup the filesystem and 
move it to your air gapped systems.

Kirk Wolf
Dovetailed Technologies
http:// 
<https://urldefense.com/v3/__http://dovetail.com__;!!MwwqYLOC6b6whF7V!hLHHFCnsvtvDo_pQ98GTzqjv2a7bLS2RTKnwG5XsNB3eCUMf07F6RWJ1aIKpsExJB-ROLsc9kUYdjgjm$>coztoolkit.com

On Fri, Nov 3, 2023, at 6:44 PM, Jousma, David wrote:
> We do pay for GIT client support through IBM, which I realize is actually 
> rocket support behind the scenes.cURL used to come packaged with GIT 
> client but was removed with IBM ptf.
>
> I was able to just go to the public anaconda website, and download the cURL 
> tarball, upload it, and expand it and clone it where needed.   Our Jenkins 
> pipeline needs it.
>
> Dave Jousma
>
> Vice President | Director, Technology Engineering
>
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
> MI 49546
>
> 616.653.8429
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Crayford 
> Sent: Friday, November 3, 2023 7:01:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Rocket miniconda frustrations
>
> > On 3 Nov 2023, at 10: 32 pm, Paul Gilmartin 
> > <042bfe9c879d-dmarc-request@ LISTSERV. UA. EDU> wrote: > > On Fri, 3 
> > Nov 2023 19: 42: 15 +0800, David Crayford wrote: >> >> Yes. But you still 
> > need the internet .. . >>
>
>
> > On 3 Nov 2023, at 10:32 pm, Paul Gilmartin 
> > <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > On Fri, 3 Nov 2023 19:42:15 +0800, David Crayford  wrote:
> >>
> >> Yes. But you still need the internet ...
> >>
> > What's the alternative?  Railway Express?  Dialup modem?
>
> A lot of customers air-gap their mainframe systems so you can’t use package 
> managers. Colin Paice opened an issue for my pyzfile Python package to 
> document installation methods on air-gapped systems 
> https://urldefense.com/v3/__https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/reading-an-mvs-dataset-using-z-open-automation-utility__;!!MwwqYLOC6b6whF7V!nVlHVMjwgMI8doNcGXgOJIwnci0yoWLQREmOo_7c-J1hWzEQQaXiHBinMK7zqEFHNnMuAhcKDi1m24hwsjs$.
>
> Dave Jousma seems to have found a solution to his problem. Rocket provide an 
> off-line channel for ported tools but it’s only available to customers with 
> commercial support, in which case you have the choice of SMP/E. Most 
> customers that are using ported tools for critical work, such as Git, have 
> commercial support. Z/OS Open Tools is a great alternative if you only 
> require free tools. They have ported tools not available from Rocket, such as 
> nano, which most ISPF users will find easier to use then vim.
>
> >
> > --
> > 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
>
>
> This e-mail transmission contains information that is confidential and may be 
> privileged.   It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not 

Re: Rocket miniconda frustrations

[Jousma, David]

We do pay for GIT client support through IBM, which I realize is actually 
rocket support behind the scenes.cURL used to come packaged with GIT client 
but was removed with IBM ptf.

I was able to just go to the public anaconda website, and download the cURL 
tarball, upload it, and expand it and clone it where needed.   Our Jenkins 
pipeline needs it.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Friday, November 3, 2023 7:01:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Rocket miniconda frustrations

> On 3 Nov 2023, at 10: 32 pm, Paul Gilmartin <042bfe9c879d-dmarc-request@ 
> LISTSERV. UA. EDU> wrote: > > On Fri, 3 Nov 2023 19: 42: 15 +0800, David 
> Crayford wrote: >> >> Yes. But you still need the internet .. . >>


> On 3 Nov 2023, at 10:32 pm, Paul Gilmartin 
> <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Fri, 3 Nov 2023 19:42:15 +0800, David Crayford  wrote:
>>
>> Yes. But you still need the internet ...
>>
> What's the alternative?  Railway Express?  Dialup modem?

A lot of customers air-gap their mainframe systems so you can’t use package 
managers. Colin Paice opened an issue for my pyzfile Python package to document 
installation methods on air-gapped systems 
https://urldefense.com/v3/__https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/reading-an-mvs-dataset-using-z-open-automation-utility__;!!MwwqYLOC6b6whF7V!nVlHVMjwgMI8doNcGXgOJIwnci0yoWLQREmOo_7c-J1hWzEQQaXiHBinMK7zqEFHNnMuAhcKDi1m24hwsjs$.

Dave Jousma seems to have found a solution to his problem. Rocket provide an 
off-line channel for ported tools but it’s only available to customers with 
commercial support, in which case you have the choice of SMP/E. Most customers 
that are using ported tools for critical work, such as Git, have commercial 
support. Z/OS Open Tools is a great alternative if you only require free tools. 
They have ported tools not available from Rocket, such as nano, which most ISPF 
users will find easier to use then vim.

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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Rocket miniconda frustrations

[Jousma, David]

RS,


“2. Quick & dirty: download the package as above and then use pax instead of 
miniconda.”



Thanks for the pointer, that worked perfectly.


Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Date: Thursday, November 2, 2023 at 4:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Rocket miniconda frustrations
BTDT There are two way to circumvent the problem: 1. Use Miniconda with offline 
packages. Yes, you can download the packages manually on you PC then upload it 
to z/OS Unix. 2. Quick & dirty: download the package as above and then use pax


BTDT



There are two way to circumvent the problem:

1. Use Miniconda with offline packages. Yes, you can download the

packages manually on you PC then upload it to z/OS Unix.

2. Quick & dirty: download the package as above and then use pax instead

of miniconda.





My personal opinion: the mess is yet another way to convince user to buy

support.



--

Radoslaw Skorupka

Lodz, Poland









W dniu 02.11.2023 o 18:53, Jousma, David pisze:

> All,

>

> I have a simple need to make cURL available in my environment.   I 
> downloaded, and installed MiniConda from the Rocket open source webpage.   We 
> are behind a proxy, and am having all sorts of problems trying to get that to 
> work.

>

> Does anyone know of a way to download the needed “repository” that miniconda 
> uses, and do a disconnected install?

>

> Dave Jousma

>





--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Rocket miniconda frustrations

[Jousma, David]

Thanks David.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Thursday, November 2, 2023 6:38:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Rocket miniconda frustrations

> On 3 Nov 2023, at 6: 30 am, Jousma, David <01a0403c5dc1-dmarc-request@ 
> LISTSERV. UA. EDU> wrote: > > I find having to have an entire front-end to 
> install something that can just be expanded with a tar or pax command way 
> overkill. 


> On 3 Nov 2023, at 6:30 am, Jousma, David 
> <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
> I find having to have an entire front-end to install something that can just 
> be expanded with a tar or pax command way overkill.
>
>

Do you? I find installing Python packages much easier using pip then 
downloading a tarball. The first software I installed when I moved to a Mac was 
homebrew. Even Windows has winget and third part package managers like 
Chocolatey etc. I agree that for some customers the latter may be more 
convenient. But z/OS open tools has a front end too, zopen. I noticed that you 
have posted in the Rocket forum which is the right place to ask. I suggest 
waiting until CVE-2023-38545 is patched.

>
> Dave Jousma
>
> Vice President | Director, Technology Engineering
>
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
> MI 49546
>
> 616.653.8429
> 
> From: IBM Mainframe Discussion List  <mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of David Crayford 
> mailto:dcrayf...@gmail.com>>
> Sent: Thursday, November 2, 2023 6:21:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU <mailto:IBM-MAIN@LISTSERV.UA.EDU> 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>>
> Subject: Re: Rocket miniconda frustrations
>
>> On 3 Nov 2023, at 1: 59 am, Lionel B. Dyck  wrote: > > 
>> You can get another port of curl from https: //urldefense. com/v3/__https: 
>> //zosopentools. github. 
>> io/meta/*/__;Iw!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlf2nWnRsA$
>
>
>> On 3 Nov 2023, at 1:59 am, Lionel B. Dyck > <mailto:lbd...@gmail.com>> wrote:
>>
>> You can get another port of curl from 
>> https://urldefense.com/v3/__https://zosopentools.github.io/meta/*/__;Iw!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlf2nWnRsA$
>>and it is very simple - much easier (imho) than using miniconda.
>
> If he’s got problems going through a proxy couldn't the same kind of problems 
> occur using zopen and GitHub with Github tokens?
>
> I don’t find using zopen to be easier to use then conda. It’s certainly 
> nowhere near as powerful, for example, virtual environments. I like zopen but 
> I find having to source .env files a PITA and slow when configured in profile 
> scripts. Using conda is just like using homebrew on my Mac. Hat’s off the 
> z/OS Open Tools devs for getting something working well enough with only 
> shell scripts.
>
>>
>> We also discuss things related to the z/OS Open Tools here
>> https://urldefense.com/v3/__https://discord.com/channels/880322471608344597/1118254421202182185__;!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlf3e-1v2I$and
>> you're welcome to join us.
>>
>>
>> Lionel B. Dyck <><
>> Website: 
>> https://urldefense.com/v3/__https://www.lbdsoftware.com__;!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5WlfHGqYwrU$
>>Github: 
>>https://urldefense.com/v3/__https://github.com/lbdyck__;!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlfg7_GH4U$
>>
>> “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
>> Jousma, David
>> Sent: Thursday, November 2, 2023 12:54 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Rocket miniconda frustrations
>>
>> All,
>>
>> I have a simple need to make cURL available in my environment.   I
>> downloaded, and installed MiniConda from the Rocket open source webpage.
>> We are behind a proxy, and am having all sorts of problems trying to get
>> that to work.
>>
>> Does anyone know of a way to download the needed “repository” that miniconda
>> uses, and do a dis

Re: Rocket miniconda frustrations

[Jousma, David]

I find having to have an entire front-end to install something that can just be 
expanded with a tar or pax command way overkill.



Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Thursday, November 2, 2023 6:21:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Rocket miniconda frustrations

> On 3 Nov 2023, at 1: 59 am, Lionel B. Dyck  wrote: > > 
> You can get another port of curl from https: //urldefense. com/v3/__https: 
> //zosopentools. github. 
> io/meta/*/__;Iw!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlf2nWnRsA$


> On 3 Nov 2023, at 1:59 am, Lionel B. Dyck  wrote:
>
> You can get another port of curl from 
> https://urldefense.com/v3/__https://zosopentools.github.io/meta/*/__;Iw!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlf2nWnRsA$
> and it is very simple - much easier (imho) than using miniconda.

If he’s got problems going through a proxy couldn't the same kind of problems 
occur using zopen and GitHub with Github tokens?

I don’t find using zopen to be easier to use then conda. It’s certainly nowhere 
near as powerful, for example, virtual environments. I like zopen but I find 
having to source .env files a PITA and slow when configured in profile scripts. 
Using conda is just like using homebrew on my Mac. Hat’s off the z/OS Open 
Tools devs for getting something working well enough with only shell scripts.

>
> We also discuss things related to the z/OS Open Tools here
> https://urldefense.com/v3/__https://discord.com/channels/880322471608344597/1118254421202182185__;!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlf3e-1v2I$
>  and
> you're welcome to join us.
>
>
> Lionel B. Dyck <><
> Website: 
> https://urldefense.com/v3/__https://www.lbdsoftware.com__;!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5WlfHGqYwrU$
> Github: 
> https://urldefense.com/v3/__https://github.com/lbdyck__;!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlfg7_GH4U$
>
> “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
> Jousma, David
> Sent: Thursday, November 2, 2023 12:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Rocket miniconda frustrations
>
> All,
>
> I have a simple need to make cURL available in my environment.   I
> downloaded, and installed MiniConda from the Rocket open source webpage.
> We are behind a proxy, and am having all sorts of problems trying to get
> that to work.
>
> Does anyone know of a way to download the needed “repository” that miniconda
> uses, and do a disconnected install?
>
> Dave Jousma
>
>
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate it
> in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> 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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply 

Re: Rocket miniconda frustrations

[Jousma, David]

Thanks Lionel, I'll take a peek.   Not sure why Rocket went the miniconda 
route.How much simpler could it be to simply download the tar files for the 
needed tools, and expand them.  Thats the way they used to distribute them.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Lionel B. Dyck 
Sent: Thursday, November 2, 2023 1:59:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Rocket miniconda frustrations

You can get another port of curl from https: //urldefense. com/v3/__https: 
//zosopentools. github. 
io/meta/*/__;Iw!!MwwqYLOC6b6whF7V!llR6t9-ZKapIdJNSb2ib_Sy-VudEr8Hqqn0KQcMijOeUrNVeyFywYL_NGA0irs5VLWom2wCgZSRrN_c$
 and it is very simple - much easier


You can get another port of curl from 
https://urldefense.com/v3/__https://zosopentools.github.io/meta/*/__;Iw!!MwwqYLOC6b6whF7V!llR6t9-ZKapIdJNSb2ib_Sy-VudEr8Hqqn0KQcMijOeUrNVeyFywYL_NGA0irs5VLWom2wCgZSRrN_c$
and it is very simple - much easier (imho) than using miniconda.

We also discuss things related to the z/OS Open Tools here
https://urldefense.com/v3/__https://discord.com/channels/880322471608344597/1118254421202182185__;!!MwwqYLOC6b6whF7V!llR6t9-ZKapIdJNSb2ib_Sy-VudEr8Hqqn0KQcMijOeUrNVeyFywYL_NGA0irs5VLWom2wCg7t2YXLE$
 and
you're welcome to join us.


Lionel B. Dyck <><
Website: 
https://urldefense.com/v3/__https://www.lbdsoftware.com__;!!MwwqYLOC6b6whF7V!llR6t9-ZKapIdJNSb2ib_Sy-VudEr8Hqqn0KQcMijOeUrNVeyFywYL_NGA0irs5VLWom2wCgfV4QlXM$
Github: 
https://urldefense.com/v3/__https://github.com/lbdyck__;!!MwwqYLOC6b6whF7V!llR6t9-ZKapIdJNSb2ib_Sy-VudEr8Hqqn0KQcMijOeUrNVeyFywYL_NGA0irs5VLWom2wCgTXK0f8M$

“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
Jousma, David
Sent: Thursday, November 2, 2023 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Rocket miniconda frustrations

All,

I have a simple need to make cURL available in my environment.   I
downloaded, and installed MiniConda from the Rocket open source webpage.
We are behind a proxy, and am having all sorts of problems trying to get
that to work.

Does anyone know of a way to download the needed “repository” that miniconda
uses, and do a disconnected install?

Dave Jousma



This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Rocket miniconda frustrations

[Jousma, David]

All,

I have a simple need to make cURL available in my environment.   I downloaded, 
and installed MiniConda from the Rocket open source webpage.   We are behind a 
proxy, and am having all sorts of problems trying to get that to work.

Does anyone know of a way to download the needed “repository” that miniconda 
uses, and do a disconnected install?

Dave Jousma



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Changes to IEBCOPY??

[Jousma, David]

Can you actually post the IEBCOPY output showing the error?

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Benik, John E <01ace072c099-dmarc-requ...@listserv.ua.edu>
Date: Monday, October 30, 2023 at 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Changes to IEBCOPY??
We recently uploaded the latest version of Tapetools. That was a success, but 
when we ran our version of $$CPYLIB which is shown below we had issues. //COPY 
EXEC PGM=IEBCOPY //SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* //PDSIBM DD 
DSN= . IBMTOOLS. JCL,DISP=SHR


We recently uploaded the latest version of Tapetools.  That was a success, but 
when we ran our version of $$CPYLIB which is shown below we had issues.



//COPYEXEC PGM=IEBCOPY

//SYSPRINT DD SYSOUT=*

//SYSOUT   DD SYSOUT=*

//PDSIBM   DD DSN=,DISP=SHR

//PDSOUT   DD DSN=,DISP=SHR

//SYSINDD DUMMY

//*

//PEND   *** END OF COPY PROC ***

//*

//STEP  EXEC  COPYLIB

//COPY.SYSIN   DD   *

  COPY OUTDD=PDSOUT,INDD=PDSIBM

   EXCLUDE MEMBER=(STATSORT,EXPIRE,$$CPYLIB,$$TAILOR,$READ*,FTPTOOL*)





IEBCOPY no longer seems to work with the $READ*, and FTPTOOL* we removed those 
and it was fine.  Does anybody know if there where changes to IEBCOPY that may 
prevent this, as it worked fine in 2022?  We are hoping to complete work on 
tape tools this week for all our systems, and realize that we may have to copy 
the $READ*, and FTPTOOL* over to our own library and delete afterwards but 
before $$TAILOR, but would like to avoid if possible as we are training some 
new people to take this over.





Regards,



John Benik



This e-mail, including attachments, may include confidential and/or

proprietary information, and may be used only by the person or entity

to which it is addressed. If the reader of this e-mail is not the intended

recipient or intended recipient’s authorized agent, the reader is hereby

notified that any dissemination, distribution or copying of this e-mail is

prohibited. If you have received this e-mail in error, please notify the

sender by replying to this message and delete this e-mail immediately.



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Cloud Storage

[Jousma, David]

We looked at it briefly, and I think there is a valid use case for using such 
as test data backup, non-critical data,etc.I mentioned in another thread, 
you have to ask yourself the question of how much data can I restore in xx 
amount of time?  You are limited to external network speeds.   If considering 
using in the event of a disaster event, there might be better options.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Jack Zukt 
Date: Friday, October 27, 2023 at 11:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Cloud Storage
Hello all, Is there anyone out there using cloud storage for backup or dataset 
migration, using IBM Cloud Tape Connector for z/OS or Model9? A few months ago 
one of our clients asked Model9 for a POC and that has been one of those 
projects


Hello all,



Is there anyone out there using cloud storage for backup or dataset

migration, using IBM Cloud Tape Connector for z/OS or Model9?

A few months ago one of our clients asked Model9 for a POC and that has

been one of those projects that seems to be going nowhere fast and I am

curious about the upside/downside of this kind of solution versus VTS

solutions (with real cartridges or SSD).

Regards,

Jack



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Does z/VM have a product/tool which can send backup to the Cloud ?

[Jousma, David]

So the issue of using public cloud storage is a question you have to answer for 
yourself.   “How quickly do I need to be able to restore?”   If its TB of data, 
streaming in at network speed, that could be days or weeks.  Will you be out of 
business by then?

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Itschak Mugzach <0305158ad67d-dmarc-requ...@listserv.ua.edu>
Date: Wednesday, October 25, 2023 at 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Does z/VM have a product/tool which can send backup to the Cloud ?
Mike, If you use S3, you can specify which zone to use. BTW, I think Amazon has 
a new local zone in Israel, but I think the requirement Arie put was outside of 
Israel. We backup our servers to Amazon S3 and wrong the protocols ourselves, so


Mike,



If you use S3, you can specify which zone to use. BTW, I think Amazon has a

new local zone in Israel, but I think the requirement Arie put was outside

of Israel. We backup our servers to Amazon S3 and wrong the protocols

ourselves, so it is possible.



ITschak



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: DFDSS RFE - Please read / vote

[Jousma, David]

I did read that Mark, but didn’t provide enough detail., or skimmed over it.   
So, for my ISV extension volume a few things occur at the beginning of 
maintenance rollout time:


  1.  All ISV products get maintained via vendor provided processes with 
datasets that contain a ver/release qualifier
  2.  Clone old master volume to new master volume as new baseline
  3.  When cloning updated ISV libraries to master, the datasets get scratched 
via IEHPROGM on the new master volume, and then updated libraries are copied 
with RENAMEU to remove the ver/release info.
  4.  FDREPORT job is run to generate/re-generate indirect catalog entries (to 
pickup any possibly new datasets that were added), and IDCAMS step to create.

TOL(ENQF) is honored for both source and target datasets with a few exceptions 
(mostly for the things you mentioned already, reallocating, etc).

COPY DS(INC(SYSV.IDP.FDREPORT.V5490SP2.CLIST)) -
 RENUNC((SYSV.IDP.FDREPORT.V5490SP2.CLIST, -
 SYSV.IDP.FDREPORT.CLIST)) -
 LIDY(VND005) ODY(VSM02A) BYPASSACS(**) NSC REPLACEU -
 ALLDATA(*) TOL(ENQF) SPHERE ALLX SHARE

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Date: Monday, October 16, 2023 at 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: DFDSS RFE - Please read / vote
On Sun, 15 Oct 2023 00: 31: 20 +, Jousma, David  
wrote: >Mark, > >I have the same cloning process as you logically. I know 
exactly the problem you face. Your rfe makes sense. > >I get around it by


On Sun, 15 Oct 2023 00:31:20 +, Jousma, David  wrote:



>Mark,

>

>I have the same cloning process as you logically.   I know exactly the problem 
>you face.   Your rfe makes sense.

>

>I get around it by cloning at the volume level, but there is always the 
>outlier that needs to be cloned by itself, or the once in awhile fix that 
>needs to be made.When I run into that I either rename then delete the 
>enqueued dataset via ispf, and then reload, or if the dataset is actually in 
>use validly, I use idcams to delete all members, compress, then reload via 
>iebcopy.

>



Re-read what I wrote though.  I have no problem cloning the sysres set since 
that is also done on the volume level.  The problem is ISV or IBM program 
products that get "added" to the maintenance sysres in preparation for cloning. 
 Around 40 different products that get copied to the volume at any given time 
after maintenance to one of those products.  Then I clone the IBM sysres 
volumes and the program product volumes as one set using full volume copies 
(except for zFS files that are logically copied and have the sysres name as 
part of the dataset name).





Best Regards,



Mark

--

Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS

ITIL v3 Foundation Certified

mailto:m...@mzelden.com

Mark's MVS Utilities: 
https://urldefense.com/v3/__http://www.mzelden.com/mvsutil.html__;!!MwwqYLOC6b6whF7V!l5PVMhb0Ho14o2qfG-4mGoh8trURMMwWV_3J4TJPFXbbuOn6CL5M0mzwZaqcjU4LMJ1WEu-fzBOtjPk$<https://urldefense.com/v3/__http:/www.mzelden.com/mvsutil.html__;!!MwwqYLOC6b6whF7V!l5PVMhb0Ho14o2qfG-4mGoh8trURMMwWV_3J4TJPFXbbuOn6CL5M0mzwZaqcjU4LMJ1WEu-fzBOtjPk$>



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: DFDSS RFE - Please read / vote

[Jousma, David]

Mark,

I have the same cloning process as you logically.   I know exactly the problem 
you face.   Your rfe makes sense.

I get around it by cloning at the volume level, but there is always the outlier 
that needs to be cloned by itself, or the once in awhile fix that needs to be 
made.When I run into that I either rename then delete the enqueued dataset 
via ispf, and then reload, or if the dataset is actually in use validly, I use 
idcams to delete all members, compress, then reload via iebcopy.

There is a restore with tol(enqf) I believe too.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Sent: Friday, October 13, 2023 10:55:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: DFDSS RFE - Please read / vote

On Fri, 13 Oct 2023 15: 31: 42 -0500, Mark Zelden  wrote: 
I've had some offline responses also. Including the suggestion to use 
TOLERATE(ENQFAILURE) which only applies to the input dataset. Let me explain 
again and show


On Fri, 13 Oct 2023 15:31:42 -0500, Mark Zelden  wrote:

I've had some offline responses also. Including the suggestion to use 
TOLERATE(ENQFAILURE)
 which only applies to the input dataset.  Let me explain again and show all 
the DFDSS control cards.

I have an "program products" sysres that is an extension of IBM OS sysres. 
There is a maintenance
version of that sysres, just like you have a maintenance IBM sysres that you 
apply SMP/E maintenance
to.  The PP sysres gets cloned along with the IBM sysres via full volume disk 
to disk copies. That is not
a problem.

That program products sysres (really 2 3390-27 volumes) has perhaps 40 IBM / 
ISV products.
All the datasets are indirectly catalogued via   Program product SMP/E 
target libs are copied
(and renamed during the copy) to the PP maintenance sysres at various time.  
When maintenance
for any give product is applied (or an upgrade) and is ready to roll out the 
sysprog copies
the SMP/E targets to this maintenance sysres.  So think of it as a volume were 
changes are staged for
production.  Then after cloning, the changes are rolled out as a package, be it 
with IBM OS maintenance,
one product, several products, or any combination like that.   This is done via 
rolling IPLs in
a sysplex environment so as not to cause any application outages (usually half 
the LPARs one
month, the other half the next month).   Almost every product's main loadlib is 
in the LNKLST - at
least anything that has associated production JCL, TSO CLISTs / EXECs, ISPxLIBs 
etc.  If something is only
used by an STC, it may not be in the LNKLST. This is to shield anyone from 
having to make
JCL changes etc. (pretty standard stuff, right?).

So many of these datasets being "staged" prior to cloning are ENQed.  If the 
input library
in the copy is larger than the one on the maintenance sysres volume, that is 
when DFDSS
fails.  If it doesn't have to scratch / reallocate the dataset that already 
exists to make it
larger to accommodate the input data set size,  it works fine.

Here is a sample of the copy process with DFDSS, only there would be many more
libraries copied / renamed than just a single one for almost all products.  
(another shortcoming
of DFDSS compared to FDRCOPY where only the HLQ can be renamed and FDRCOPY can
rename the hlq plus add / remove nodes for multiple datasets - dozens if I 
needed,  in a single
control statement, but I digress...)

//SYSINDD  *
 COPY DS( -
   INCLUDE( -
smphlq.product.V6R3.LINKLIB -
   )  -
)  -
  RENAMEU( -
   (smphlq.product.V6R3.LINKLIB -
  prodhlq.product.LINKLIB)-
 ) -
  SHARE TOL(ENQF)   PROCESS(SYS1) -
  BYPASSACS(**)   -
  NULLSTORCLAS-
  LIDY(inpvol)-
  OUTDYNAM(outvol,SYSALLDA)   -
  REPLACEUNCONDITIONAL -
  WAIT(2,2)  ALLDATA(*)  ALLEXCP
/*

If prodhlq.product.LINKLIB is ENQed (in this case you can presume it is due to 
being in the LNKLST on the driving system), you get this error:

ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED 
DATA SET prodhlq.product.LINKLIB. RETURN CODE IS 102, REASON
CODE IS FP-007

ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET


** VOTE here by clicking the vote icon at the top left!
https://urldefense.com/v3/__https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862__;!!MwwqYLOC6b6whF7V!l88xZXKbWy57EEOicntO2a0U2-ASRLcj7Ya5t5ggE89_A6unfsAePPoZPdaeGWNpUinbleEiMkvaePQ$

Regards,  Mark

>Sorry for top posting...
>
>Let's address your comments one keyword at a time:
>
>DELETE - deletes the source (input) dataset.  Ouch!  Lets not delete my SMP/E 
>target libs during copy to my sysres set please!
>
>PURGE -  overlays an output dataset that has an expiration date not yet 
>reached.  Not applicable.
>
>UNCOND -  no such parm 

Re: Any recommendations for a 3270 emulator for Android

[Jousma, David]

Well, you might try Rocket Terminal emulator Web edition.   Its web based, but 
you have to have the server running somewhere in the shop.   We happen to be 
trying it right now in a zCX container on z/OS.

Dave Jousma
Vice President | Director, Technology Engineering



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Date: Monday, September 25, 2023 at 3:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Any recommendations for a 3270 emulator for Android
"Outdated" terminal emulators? They wish. Not that I have anything against new 
and especially better ideas. But I think Attachmate, Rocket, QWS3270 and others 
work just fine. --- Bob Bridges, robhbridges@ gmail. com, cell 336 382-7313 /* 
There


"Outdated" terminal emulators?  They wish.  Not that I have anything against 
new and especially better ideas.  But I think Attachmate, Rocket, QWS3270 and 
others work just fine.



---

Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313



/* There are few things more discouraging to the mind that likes to believe it 
is master in its own house, than the unquestionable effect of a full belly.  
-from The Mauritius Command by Patrick O'Brian */



-Original Message-

From: IBM Mainframe Discussion List  On Behalf Of Bob 
T Roller

Sent: Sunday, September 24, 2023 19:35



I recently received an email advertisement for a product called “Virtel Web 
Access,the browser-based 3270 emulation technology to replace outdated TN3270 
terminal emulators(like PCOMM, Attachmate, Rocket/BlueZone and more), also can 
replace expensive VTAM session managers(like TPX, CL/SuperSession, Tubes, and 
more).”



I don’t have any experience with it.



--- On Sun, Sep 24, 2023 at 7:26 PM, Charles Mills [charl...@mcn.org] wrote:

> Anyone have personal recommendations for a 3270 emulator for Android phones 
> and/or tablets?

>

> Android, NOT Windows -- you would have to pry Vista out of my cold, dead 
> fingers.

>

> I certainly don't intend to do heads-down coding on my phone. This is just so 
> I could respond to a client emergency without having to lug my laptop around.



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: zOSMF Workflows

[Jousma, David]

Thanks for that Kurt!

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Kurt Quackenbush 
Date: Friday, September 22, 2023 at 8:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zOSMF Workflows
> There is something somewhat rudimentary in the create workflow screen with 
> the pulldown, but I dont know if thats zOSMF doing that, or the browser doing 
> that. But then that would likely be just for me? z/OSMF, not your browser, 
> manages


> There is something somewhat rudimentary in the create workflow screen with 
> the pulldown, but I dont know if thats zOSMF doing that, or the browser doing 
> that.   But then that would likely be just for me?



z/OSMF, not your browser, manages the pulldown of previous workflow definition 
files, and it is managed per user.



> What if we had a public workflow that we expected many people to use to 
> provision xyz?



Check out z/OSMF Management Services Catalog (zMSC).  You create a catalog of 
services from which to select, where a service is a workflow.

https://urldefense.com/v3/__https://www.ibm.com/support/z-content-solutions/management-services/__;!!MwwqYLOC6b6whF7V!iGiwecNffyrE3FlfTv6lRzxNDGNxYPZyFco_LlDCCzt3p6eP3do1ivzZ1nz3RtL_j0VzglCikvLBt2c$



Kurt Quackenbush

IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com



Chuck Norris never uses CHECK when he applies PTFs.



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Programming Hardware

[Jousma, David]

I've transitioned full to using a MAC.Love the Apple bluetooth keyboard 
feel, and Apple bluetooth mouse with no buttons.

As for eyesight, I run a pair of 32" 4k monitors.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Tuesday, July 4, 2023 7:27:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Programming Hardware

imho, investing in the tools of my trade is a no-brainer. For us, it's far 
cheaper than many professions. A mechanical-switch keyboard is worth it, even 
if it only lasts for a year. (I (so far) haven't ruined one with a spill, and 
both are


imho, investing in the tools of my trade is a no-brainer.  For us, it's far
cheaper than many professions.  A mechanical-switch keyboard is worth it,
even if it only lasts for a year. (I (so far) haven't ruined one with a
spill, and both are going strong after several years.  Decent ones can be
had for $60-80.  Another option is old mechanical-switch keyboards from the
'80s... if you happen to have an old IBM PS/2 one laying around, check eBay
for how much they're worth.  DIN/USB converters are cheap.

The one thing Microsoft does well is mouses.  Logitech is also good.  The
ones I use average around $60 each.  I usually use wired for the best in
precision, and just to avoid battery changes... but it's a fine line, good
wireless mouses seem to have imperceptible lag these days.

I have a 32" 2K monitor.  I didn't really go high-end on that, maybe $500.

My paycheck depends on my productivity, and these not only directly help
with that, they make me feel better.  Quality matters, and compared to the
fact that my work takes up 1/3 of my time, 1/2 my energy, and provides my
means of living, the costs are trivial.

When I have to use a laptop as-is, it's always a grind... maybe
half-speed.  And that's if I have a mouse handy.  If I'm stuck with
touchpad/eraserhead, maybe half of that.

sas

On Tue, Jul 4, 2023 at 5:50 PM Bob Bridges  wrote:

> ...
> But, oh boy, do I miss tactile feedback!  IBM's software is famously hard
> to use, but their hardware is reliably exceptional.  Heck, I liked the old
> Selectrics, too.
>
>

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Counting EXIT invocations

[Jousma, David]

Best option would be to have the exit issue a WTO, and then scan operlog for 
that.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
jgmauta...@yahoo.com.ar <01f9499d67db-dmarc-requ...@listserv.ua.edu>
Date: Wednesday, June 28, 2023 at 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Counting EXIT invocations
Hi! We have recently implemented a RACF exit. Is there a way to know how many 
times this EXIT was executed (on a given period of time)? Thanks in advance for 
your help, Juan Mautalen 
--


Hi!

We have recently implemented a RACF exit. Is there a way to know how many times 
this EXIT was executed (on a given period of time)?

Thanks in advance for your help,

Juan Mautalen



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: z/OSMF log size

[Jousma, David]

TRACE=Y in the STC JCL?

Dave Jousma



From: IBM Mainframe Discussion List  on behalf of 
Gadi Ben-Avi 
Date: Thursday, May 18, 2023 at 2:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: z/OSMF log size
Thanks, But it looks like z/OSMF is writing to much information for normal 
operations. I'm looking for some kind of setting to fix it. Gadi -Original 
Message- From: IBM Mainframe Discussion List  
On Behalf
ZjQcmQRYFpfptBannerStart
CAUTION EXTERNAL EMAIL
This message came from outside your organization.
DO NOT open attachments or click on links from unknown senders or unexpected 
emails.
ZjQcmQRYFpfptBannerEnd

Thanks,

But it looks like z/OSMF is writing to much information for normal operations.



I'm looking for some kind of setting to fix it.



Gadi



-Original Message-

From: IBM Mainframe Discussion List  On Behalf Of 
kekronbekron

Sent: יום ה 18 מאי 2023 09:42

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: z/OSMF log size



Sorry, I don't know the exact name for it, but there's some timed cut-off 
capability that can be used to archive or make cuts in some intervals.

Then, let them get actually archived into some archival product or datasets.



- KB



--- Original Message ---

On Thursday, May 18th, 2023 at 11:31 AM, Gadi Ben-Avi  wrote:





> Hi,

> The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
> million lines.

>

> Can anyone suggest how to make it a bit smaller?

>

> We are running under z/OS v2.3.

>

> Thanks

>

> Gadi

>

>

> --

> 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
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.





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

Re: CBU Woes

[Jousma, David]

This is what we do as well, as in defining the extra processors as reserves, 
and then just config them on when needed during the envent.




From: IBM Mainframe Discussion List  on behalf of 
Mike Shorkend 
Date: Saturday, April 29, 2023 at 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: CBU Woes
Hi Ed, There are two ways you could do this. The first one is by assigning 
reserve processors in the image profile. After the LPAR is up and running you 
can config the extra CPUs online. You could automate this pretty easily. You 
don't have
ZjQcmQRYFpfptBannerStart

ZjQcmQRYFpfptBannerEnd

Hi Ed,

There are two ways you could do this. The first one is by assigning reserve

processors in the image profile. After the LPAR  is up and running you can

config the extra CPUs online.

You could automate this pretty easily. You don't have to make any changes

going back and forward with/without CBU.



The other way is to create a new image profile with the added CPUs defined.

After you add the CBU, you will need to mark this new profile for

activation and then activate the LPAR.

I guess that you could use BCPii to script this but I am not sure that

BCPii has access to all these controls.You would have to do the reverse

when you withdraw the CBU.



I prefer the first method . Much less hassle.





Mike



On Sat, 29 Apr 2023, 20:43 Ed Jaffe,  wrote:



> Esteemed Sysprogs,

>

> We use CBU to activate additional engines and capacity twice a year.

>

> The image profiles on the HMC match the LPAR names and there seems to be

> no way to associate alternate image profiles to be used while CBU is

> active. Therefore, we have been manually updating the image profiles to

> add the additional engines during the CBU and then manually changing

> them back when the CBU is over.

>

> Is there a better way? Can alternate image profiles be used? If not, can

> these changes be easily scripted?

>

> Thanks,

>

> --

> Phoenix Software International

> Edward E. Jaffe

> 831 Parkview Drive North

> El Segundo, CA 90245

> https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!MwwqYLOC6b6whF7V!ljwlOQMOTrouY0378viK3LLitLzAen0tXgtX2Uw64GxoYekutjvY1TGYftxOg3yJFljakLkujxiJU48nlJdCbC5c$

>

>

>

> 

> 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

>



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: FTPS/HTTPS to testcase sites via proxy (cross posted from IBMTCP-L)

[Jousma, David]

FTPs works for us.  Have to use your IBM file transfer ID and password, 
anonymous no longer works.   For a passive connection, there are some high 
numbered range of ports you need to setup firewall to allow.  My JCL looks like 
this

//FTP  EXEC PGM=FTP,REGION=64M,PARM='(EXIT=8'
//CEEOPTS DD *
ENVAR("GSK_PROTOCOL_TLSV1=0")
ENVAR("GSK_PROTOCOL_TLSV1_2=1")
/*
//SYSFTPD  DD *
SECURE_FTPALLOWED
SECURE_MECHANISM  TLS
TLSRFCLEVEL   CCCNONOTIFY
TLSMECHANISM  FTP
SECURE_DATACONN   PRIVATE
KEYRING   *AUTH*/*
EPSV4 TRUE
FWFRIENDLYTRUE
/*
//SYSPRINT DD SYSOUT=*
//SYSINDD *


From: IBM Mainframe Discussion List  on behalf of 
Peter Vander Woude 
Date: Friday, April 28, 2023 at 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: FTPS/HTTPS to testcase sites via proxy (cross posted from IBMTCP-L)
Has anyone been able to setup their jobs, that send diagnostic data to IBM, via 
ftps or https using a proxy? Now for us, the https is not as straight forward 
as a normal proxy. Ours requires us to pass and indicate it's to use ntlm 
authentication
ZjQcmQRYFpfptBannerStart

ZjQcmQRYFpfptBannerEnd

Has anyone been able to setup their jobs, that send diagnostic data to IBM, via 
ftps or https using a proxy?



Now for us, the https is not as straight forward as a normal proxy.  Ours 
requires us to pass and indicate it's to use ntlm authentication (that's what 
we have to specify in the smp/e receive order job).  In the receive order, we 
have to specify that information, in the java options.


This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: RACF MFA

[Jousma, David]

MFA is a separately charged product from IBM, and is licensed in blocks of 500 
users.  So there will be a software purchase and install on top of the racf 
changes

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Bill Giannelli 
Sent: Wednesday, April 26, 2023 12:55:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: RACF MFA

what is needed to implement MFA (Multi Factor Authentication) in RACF aside 
from the RACF changes? would network changes be needed also? thanks Bill 
-- For 
IBM-MAIN subscribe
ZjQcmQRYFpfptBannerStart
CAUTION EXTERNAL EMAIL
This message came from outside your organization.
DO NOT open attachments or click on links from unknown senders or unexpected 
emails.

ZjQcmQRYFpfptBannerEnd

what is needed to implement MFA (Multi Factor Authentication) in RACF aside 
from the RACF changes?
would network changes be needed also?
thanks
Bill

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

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: What is BPXAS and how do I make them stop piling up?

[Jousma, David]

I believe Steve was indicating that at his shop, msgclass=z is setup as purge, 
when thr job completes.   You can use whatever msgclass works for your shop, or 
alternatively setup a jes autocommand to purge them after a day.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Monday, April 10, 2023 6:59:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: What is BPXAS and how do I make them stop piling up?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

On Mon, 10 Apr 2023 17:11:11 -0500, Charles Mills wrote:
>
>Okay, I confirmed that MSGCLASS=Z will make output magically disappear.
>
Had you been taking all IBM's defaults: SYSOUT class, disposition of that
class, etc.?

If so, IBM's design is adverse.

But, "IBM's defaults are not IBM's recommendations!"  (source obscure)
(E.g. BLKSIZE=3120)

Is "SYSOUT=Z" an IBM standard?

--
gil

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: Dave Josuma's post

[Jousma, David]

Glad to see you are still kicking around, Ed!

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Edward Gould <04bcc43af339-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, April 9, 2023 3:51:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Dave Josuma's post

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I have been here lurking for the last five or so years. Here is my response to 
Dave’s post.

As for me “arguing,” much of it had to do with IBMer’s sugar-coating many 
issues in older times. To name two, a few were IBM and their blind attitude 
towards COBOL. Arguing on COBOL was and always has been IBM’s blind attitude 
toward the lack of support for large table sizes. They still can’t do large 
table sizes (i.e., 64-bit).

The other issue was for the group of IBM-Main people at GUIDE (SCIDS, to be 
specific) who refused to talk to other IBM Main people. The favorites on here 
seemed (to me anyway encourage it). I should add here that other people sent me 
private replies agreeing with me.

The other sticking point was the old IBM HUGE fix tapes for VSAM. They still 
should be hung out to dry for not doing it well.
 The systems type started the process of turning gray from those. My point 
(beside the complexity of the number of fixes) and to be a bit fair towards 
IBM, SMPE has helped a bit in this area but not to the extent of large numbers 
of fixes).

My health has declined over the years, so I have stayed out of IBM-Main as much 
as possible.

Ed

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: How to determine if Enhanced HOLDDATA received?

[Jousma, David]

Enhanced hold data does not include secint source id's as far as I know.  I 
have to logon to resourcelink to download the list and receive that, and then 
apply by source ID.  I guess I don't understand why isv do jot have access.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Itschak Mugzach <0305158ad67d-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, January 17, 2023 6:04:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: How to determine if Enhanced HOLDDATA received?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

We are not at that size... and our interest is not at a specific client by
a bit wider.

בתאריך יום ד׳, 18 בינו׳ 2023 ב-0:33 מאת Ed Jaffe <
edja...@phoenixsoftware.com>:

> On 1/17/2023 1:15 PM, Itschak Mugzach wrote:
> > Ed,
> > Do you have access to security portal? the information I am looking for
> are
> > only available there. I was told by IBM that as a vendor, I can't get
> > access to it. See below for details about the cvss info:
> > The HOLDDATA available from the IBM Z and LinuxONE Security Portal adds a
> > new HOLD CLASS, SECINT, and the HOLD SYMPTOMS contains the CVSS Base and
> > Temporal scores.
>
> I am surprised to hear IBM would take a position like that. It seems
> almost inconceivable that large vendors like BMC and Broadcom are locked
> out of the Secure Portal.
>
> My experience has been that an individual working for an IBM Z customer,
> with a manager or CISO that will vouch for them, can get access.
>
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!MwwqYLOC6b6whF7V!k4vwRZZ0uzFo3N-MQCi39myqS8-EbrySIm9YeIH_HcPQ-zClDsXaAgkYDgeBvlRiUX_c3uXjyLMxA9eSXg4RMAApf9RMG-iMvL8$
>
>
>
> 
> 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
>
--

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: 
https://urldefense.com/v3/__http://www.Securiteam.co.il__;!!MwwqYLOC6b6whF7V!k4vwRZZ0uzFo3N-MQCi39myqS8-EbrySIm9YeIH_HcPQ-zClDsXaAgkYDgeBvlRiUX_c3uXjyLMxA9eSXg4RMAApf9RMj0WR2Lo$
   **|*

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.





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

Re: HMC Help

[Jousma, David]

Glad you got the answer, as I was about to post the same info.   We have it 
enabled now, probably the last 6 months, and right after it was done I got a 
call from the ibm service representative because "he couldn't logon".   Seems 
like poor design point, but I'm sure there is a reason for it.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, January 17, 2023 4:38:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: HMC Help

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Finally got it resolved. It turns out that once the HMC MFA requirement is 
assigned to a userid, the HMC asks for a OTC for every userid, regardless of 
whether it requires the OTC or not. If not, don't enter anything in the field, 
and select logon/login. Once I removed the requirement for MFA on my test id, 
it stopped asking.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!MwwqYLOC6b6whF7V!l4-yja29ogjExd2YAcOXsrPIIiBHVOQ5--mDm2R1TjymI8JrUUM-DgLqFqav84FYush8_wQQKdEvcNaLKsXlbC-XAqMULtX1wCg$


--- Original Message ---
On Tuesday, January 17th, 2023 at 1:59 PM, Mark Jacobs 
<0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:


> I opened a service request on the HMC. Lets hope they can fix it soon.
>
>
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key - 
> https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!MwwqYLOC6b6whF7V!l4-yja29ogjExd2YAcOXsrPIIiBHVOQ5--mDm2R1TjymI8JrUUM-DgLqFqav84FYush8_wQQKdEvcNaLKsXlbC-XAqMULtX1wCg$
>
>
>
>
> --- Original Message ---
> On Tuesday, January 17th, 2023 at 1:54 PM, Carmen Vitullo petevi...@gmail.com 
> wrote:
>
>
>
> > I looked around - at the older HMC version, tree style I was able to
> > view my other HMC, maybe it was not defined when we installed our Z15
> > and the new HMC version was installed but I cannot get to my other
> > HMCcurrently - I hope someone has an answer for you
> >
> > for me, I call HELP to my IBM SE and they can do some magic
> >
> > Carmen
> >
> > On 1/17/2023 12:45 PM, Mark Jacobs wrote:
> >
> > > IDK, I'm remote and don't know anything about the physical layout of that 
> > > data center.
> > >
> > > Sent from ProtonMail, Swiss-based encrypted email.
> > >
> > > GPG Public Key - 
> > > https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!MwwqYLOC6b6whF7V!l4-yja29ogjExd2YAcOXsrPIIiBHVOQ5--mDm2R1TjymI8JrUUM-DgLqFqav84FYush8_wQQKdEvcNaLKsXlbC-XAqMULtX1wCg$
> > >
> > > --- Original Message ---
> > > On Tuesday, January 17th, 2023 at 1:38 PM, Carmen Vitullo 
> > > petevi...@gmail.com wrote:
> > >
> > > > do you have another HMC? can you access the HMC and remove the MFA
> > > > definitions from this alternate HMC?
> > > >
> > > > just thinking out-loud
> > > >
> > > > Carmen
> > > >
> > > > On 1/17/2023 12:31 PM, Mark Jacobs wrote:
> > > >
> > > > > I really mucked up our HMC. I enabled MFA on the HMC using the HMC as 
> > > > > the MFA server. Associated one userid with MFA, successfully set that 
> > > > > up and logged on to the HMC with it. Now, all the other userids, 
> > > > > including ACSADMIN are requiring an MFA OTP to logon on.
> > > > >
> > > > > HELP
> > > > >
> > > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > > >
> > > > > GPG Public Key - 
> > > > > https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!MwwqYLOC6b6whF7V!l4-yja29ogjExd2YAcOXsrPIIiBHVOQ5--mDm2R1TjymI8JrUUM-DgLqFqav84FYush8_wQQKdEvcNaLKsXlbC-XAqMULtX1wCg$
> > > > >
> > > > > --
> > > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > > > > --
> > > > > Carmen
> > > >
> > > > --
> > > > 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
> >
> > --
> > Carmen
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the 

Re: Limiting quantity of tape drives used by user

[Jousma, David]

Thank you for this, whomever you are!

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
SUBSCRIBE IBM-MAIN Anonymous <04742a5d8435-dmarc-requ...@listserv.ua.edu>
Sent: Friday, November 11, 2022 6:24:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Limiting quantity of tape drives used by user

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Take a look at MOUNTMON
https://urldefense.com/v3/__https://ftp.software.ibm.com/storage/tapetool/__;!!MwwqYLOC6b6whF7V!nJiRcCXIeiHSdcBVxUNc3eAo5wQTHrpRyvqHu0R9U07794LMDgsx9Obr8jXWQICLP-IleSrO6gVmBEAbkv0o9E4bWens1Jt5oM0$

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: HYCD or IOCP

[Jousma, David]

Carmen,  IBM reworked how the drives are managed/shared now.  There is no 
longer a need for CF structure, just the IODF definitions.We share all 
drives across all sysplex’s that the VTL is connected to with no problem.  We 
used to do as you do with certain ranges for certain systems.

From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Date: Thursday, October 13, 2022 at 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: HYCD or IOCP
**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

it's been a while since I've used configured tape devices like this but
if I recall correctly you need to define the devices as shared and
define a CF structure to use AUTOSWAP , or a product like MIM to manage
the devices across multiple systems.

at my site using a virtual tape system we have defined 256 devices and
just manage the number of devices we need across 3 LPARS,  all others
are varied offline at IPL time, so one range is online to LPAR1 then
then next range is varied online to LPAR2 and so on.

that for us was an easier option especially with the virtual tape system

Carmen

On 10/12/2022 10:37 AM, Steve Beaver wrote:
> What is the PARM/OPTION to allow VTD's to auto swap between LPARS if
>
> That LPAR needs a VTD to satisfy a MOUNT request?
>
>
>
> Regards,
>
>
>
>
>
>
>
>
> --
> 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
**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: HYCD or IOCP

[Jousma, David]

Its in the IODF.You have to define the devices as AUTOSWAP.   Then there is 
nothing else to do, other than bring them all online everywhere.

From: IBM Mainframe Discussion List  on behalf of 
Steve Beaver 
Date: Wednesday, October 12, 2022 at 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: HYCD or IOCP
**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

What is the PARM/OPTION to allow VTD's to auto swap between LPARS if

That LPAR needs a VTD to satisfy a MOUNT request?



Regards,








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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: TADz and SMF

[Jousma, David]

Turn them off in SMFPRMxx?




Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429




From: IBM Mainframe Discussion List  on behalf of 
Steve Beaver 
Sent: Sunday, February 13, 2022 6:02:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: TADz and SMF

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

We installed TADz on one of my TEST Lpars



All of a sudden I have 3 SMF DS's going full with a massive quantity of 231
records.



Does TADz cut SMF records and If so how can I turn them off?


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: JES2 mail notification

[Jousma, David]

Is there a cert you need to add to jes2 userid keychain?




Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429




From: IBM Mainframe Discussion List  on behalf of 
Mike Shorkend 
Sent: Sunday, January 16, 2022 8:17:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: JES2 mail notification

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hi,
I am trying to set up email notification for job termination but have run
into a problem that the JES2EDS started task  can't connect to z/OSMF. This
is the joblog(I have had to obfuscate the URI  and NODE)


  J E S 2  J O B  L O G  --  S Y S T E M  S Y S D  --  N O
D E  N O D E 1


1.25.31 S0452379  SUNDAY,16 JAN 2022 

1.25.31 S0452379  IEF196I IGD103I SMS ALLOCATED TO DDNAME SYS1

1.25.31 S0452379  IEF196I IGD104I SYS3.TCPIP.TCPPARMS
   RETAINED,
1.25.31 S0452379  IEF196I DDNAME=SYS1

1.25.31 S0452379  IEF196I IGD103I SMS ALLOCATED TO DDNAME SYS5

1.25.31 S0452379  IEF196I IGD104I SYS3.TCPIP.TCPPARMS
   RETAINED,
1.25.31 S0452379  IEF196I DDNAME=SYS5

1.25.31 S0452379  IEF196I IGD103I SMS ALLOCATED TO DDNAME SYS7

1.25.31 S0452379  IEF196I IGD104I SYS3.PLX2.TCPIP.STANDARD.TCPXLBIN
   RETAINED,
1.25.31 S0452379  IEF196I DDNAME=SYS7

1.25.31 S0452379  IEF196I IGD103I SMS UNIX FILE ALLOCATED TO DDNAME
SYS00011
1.25.31 S0452379  IEF196I IGD104I UNIX FILE WAS RETAINED, DDNAME IS
(SYS00011)
1.25.31 S0452379  IEF196I FILENAME IS (/etc/hosts)

1.25.32 S0452379  $HASP1529 106 0420 Socket closed by remote partner

1.25.32 S0452379  $HASP1534 z/OSMF server URI
https://host.domain.co.il:1443/zosmf
1.25.32 S0452379  $HASP1535 Current message is in email queue $EDSQ004 at
offset 
  918   in EMQT 0288FF01

1.25.32 S0452379 *$HASP1523 Unable to connect to z/OSMF server.



If I plugin the URI to a browser, I connect to z/OMSF without a problem.


$HASP1529   sends you to the HTTP toolkit where a 106 return code is:

Meaning: A communication error has been detected. One or
more of the following problems has occurred:
• A failure in the communication with the web server
• An error in an underlying sockets or SSL/TLS service call
• An error in obtaining the necessary system resources to
process the connect.
Action: Check the diagArea for further diagnostic information.
The toolkit uses many internal services, including sockets, SSL,
and other calls when processing an HTTP API service call. If one
of these internal services fails because of an error in
communications with the targeted server or because of an
internal environmental condition, the error is reported in the
diagnostic area. This information can be useful to the
application programmer but, in many cases, it is for the use of
IBM Support. If one of these errors occurs, clean up the
environment, check for possible communication configuration
problems, and reissue the request

Before opening a case with IBM, has anyone else run into this (and
hopefully solved it)?
z/OS 2.4  and I think that I have followed all the prereq tasks.

Thanks

Mike

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: Long time between IPLs a security risk? was Re: What is OVMSKERN?

[Jousma, David]

The funny part of this peeing contest is that IBM has never published the text 
of security APARs publically.  Not even on resourcelink.   You'll see the apar 
#, and ptf's, but try to search out those apars and you get document not found 
in service link.

Most of the time, I just download the smpe assign file, and receive that, then 
do an apply with sourceid of secint.




Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429




From: IBM Mainframe Discussion List  on behalf of Ed 
Jaffe 
Sent: Wednesday, December 22, 2021 4:20:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Long time between IPLs a security risk? was Re: What is OVMSKERN?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

On 12/22/2021 1:10 PM, Bill Johnson wrote:
> I didn’t mean to insinuate red alerts were for security. Although I have 
> received red alerts for security issues. In the last 2 years (searched) I 
> have 4 red alerts. 1 is security related.

Which security-related APAR was advertised in a Red Alert?


--
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
**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: Long time between IPLs a security risk? was Re: What is OVMSKERN?

[Jousma, David]

We ipl 2 times a year.   It's a matter of balancing change vs stability.   We 
monitor vulnerabilities for sure.  Our environment is not internet facing, so 
any concerns are internal.   Many vulnerability do not require ipl to fix, but 
some do.  We do not install maintenance just because it's there, it's a planned 
event.




Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429




From: IBM Mainframe Discussion List  on behalf of 
Clark Morris <03b2c618bdfc-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, December 21, 2021 6:09:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Long time between IPLs a security risk? was Re: What is OVMSKERN?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

>On Monday 29/11/2021 at 12:41 pm, Charles Mills wrote: Problem is long gone, 
>but FWIW this was 9 months after the last IPL.

Given the need to apply security fixes that probably apply to
SYS1.NUCLEUS or LPA modules, how is it possible to go 9 months without
an IPL and maintain security?

Clark Morris

>Charles

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: The Great Resignation

[Jousma, David]

You know what folks?  We argue enough about control blocks here and there, and 
whether USS is a vtam or unix term.

Let's please leave U.S. politics out of this world-wide forum.




Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429




From: IBM Mainframe Discussion List  on behalf of 
Sasso, Len <039db7f8412a-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, December 18, 2021 6:01:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: The Great Resignation

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

So True!

Trumpsters will put Americans in the Dumpsters"



Thank You and Please Be Safe!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

TEAM: Together Everyone Achieves More

Office Hours: M-F  7 AM - 3:45 PM

Vacation: 12/17/2021 - 01/03/2022

Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com





From: IBM Mainframe Discussion List  on behalf of 
Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, December 18, 2021 5:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: The Great Resignation



 [External Email with Covid-19 Information: Use caution with links & 
attachments]

I doubt Jesus said a man unwilling or unable to work shouldn’t eat. And, I’m 
not surprised the low wage earners are unwilling to work for $2.13/hour (tipped 
wage) plus tips. The federal minimum wage hasn’t gone up in over a decade. If 
the minimum wage I worked for in 1975 had kept pace with inflation, it would be 
over $20 an hour now. In most of Europe, restaurant workers make a living wage 
plus benefits. Tipping is optional. Plus, their health care is single payer and 
better/cheaper. Don’t get me started on their fabulous infrastructure, mass 
transit, and education systems.
Factor in many don’t want to go back to work while a fourth wave of covid is 
raging. (Thanks to the GOP and trumpers pushing against public health) Then 
there are women who can’t afford child care because it eats up the majority of 
their wages. Funny that the build back better legislation intended to address 
that and provide child care help like most of the rest of the world provides.
My brother in law made a career out of the restaurant business. He’s making 6 
figures now as a regional director but works 70 hour weeks, has had 2 heart 
attacks, smokes like a chimney, and will never see retirement from the hamster 
wheel.
Younger Americans are not buying into the rat race. Conspicuous consumption 
isn’t their religion. And as we are seeing, the baby boomers are much to blame 
for global warming, the results we are seeing in fires, floods, polar icecaps 
melting, and yes, the recent record setting tornadoes in Kentucky, Tennessee, & 
other states.
America is in decline when a two bit reality TV show host, who lies 
incessantly, has molested 20+ women, cheats on his taxes, and tried to overturn 
a free and fair election, can get 35% of the populace to follow him.


Sent from Yahoo Mail for iPhone


On Saturday, December 18, 2021, 5:04 PM, Bob Bridges  
wrote:

A while ago on one of the forums I hang out at -- I think it was this one -- we 
talked about people dropping out of the work force and looking for something 
more rewarding.  I'm all for people looking for work they like better, but one 
gathers that a lot of these folks are dropping out and THEN looking for 
something they like better, which strikes me as a teenager's way of doing it.

I particularly remember an NPR report about an example of this, someone who 
quit his job and wanted to get into the restaurant business.  (Don't laugh; I 
thought seriously about making my career in food services, too, before I 
discovered computer programming.)  The item finished by saying that he was now 
applying for unemployment benefits.

Partly but not entirely on the strength of this story, I suggested without a 
great deal of certainty that the COVID payments to all and sundry are largely 
fueling this "Great Resignation" -- that lots of people are finding they can 
afford to take time off from work, get COVID payments and unemployment 
benefits, and worry about working some time later.  I realized that probably 
wasn't the whole story, but it sure sounded like it was a significant part of 
it.  As both a Christian and a political conservative (they're not entirely 
synonymous) I was raised on "if a man will not work, neither let him eat", so I 
was all prepared to wax indignant.

Now I read an article 

New Java vulnerability

[Jousma, David]

Looks like a bad one...


https://www.lunasec.io/docs/blog/log4j-zero-day/



Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429



This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: Multiple TSO logons within sysplex

[Jousma, David]

The only problem with  is that unless you have sms rules to "cleanup" 
these work datasets sometimes hang around.  Not sure if you'd get a not 
catalog2 error or if they get reused.




Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429




From: IBM Mainframe Discussion List  on behalf of 
Radoslaw Skorupka 
Sent: Saturday, November 6, 2021 11:43:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Multiple TSO logons within sysplex

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I've got a many responses, thank everybody! I appreciate your help. This
is the value from being on IBM-MAIN.

Now technical topics:
ISPPROF can now be shared. However you have to configure ISPF for that
(ISPCCONF, single checkbox).
temporary datasets should remain unique, but you no longer need exit 16,
because you can use ISPCCONF instead. BTW: I prefer  over 
Reason:  clearly show system relationship.
GRS SYSIKJUA - nothing changed.
GRS SPFEDIT - seems to be not an issue because of shared ISPPROF.

Regards

--
Radoslaw Skorupka
Lodz, Poland




W dniu 05.11.2021 o 16:57, Radoslaw Skorupka pisze:
> I just re-read Configuring ISPF for Fun and Profit presentation and
> found the following link:
> http://home.roadrunner.com/~pinncons/TSO LOGON with the Same Userid on
> Multiple LPARs in a Sysplex.pdf
>
> However the link is dead.
> Does anyone have the presentation?
> Or any other presentation on the topic.
>
> My goal is to enable multiple TSO/ISPF logons within sysplex.
> What I know:
> - ISPPROF dataset can be shared now (it has changed)
> - LIST, LOG, TEMP datasets should not be shared. The solution is exit
> 16 or ISPF Configuration Utility (add  to the DSNs).
> - I'm not sure about PDF edit recovery files.
> - Did I miss something?
>

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: z/OS ssh git issue

[Jousma, David]

I know you responded back with the TAG ENV vars.  Here are all of mine that are 
set in GITENV.sh

# ASCII support environment values   
export _BPXK_AUTOCVT='ON'
export _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)" 
export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt 
export _TAG_REDIR_OUT=txt



_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: Monday, March 1, 2021 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

They are set.

_TAG_REDIR_IN=txt 
_TAG_REDIR_OUT=txt
_TAG_REDIR_ERR=txt

Thanks for the suggestion.  Now you can see why we are baffled.

_
Lionel B Dyck <
Website: www.lbdsoftware.com

"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 
David Crayford
Sent: Sunday, February 28, 2021 6:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

Make sure you also have the following set:

export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt
export _TAG_REDIR_OUT=txt


On 28/02/2021 10:45 pm, Lionel B Dyck wrote:
> I have in the environment on this system and on the working systems.
>
> _BPXK_AUTOCVT=ON
> _CEE_RUNOPTS=FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)
>
> And I'm not sure which files you are asking about being tagged?
>
> My ssh keys are untagged if that is your question - the same as on my working 
> system.
>
> __
> ___
> Lionel B Dyck <
> Website: www.lbdsoftware.com
>
> "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 Michael Babcock
> Sent: Saturday, February 27, 2021 8:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS ssh git issue
>
> Is AUTOCONVERT turned on in USS?  And the files are tagged?
>
> On Sat, Feb 27, 2021 at 2:24 PM Lionel B Dyck  wrote:
>
>> I’m having an issue on a test lpar with git for z/OS – both version
>> 2.14 and the latest 2.26 ports.
>>
>>
>>
>> I’ve looked at this as have several others without success.
>>
>>
>>
>> When I attempt a git clone I get this error:
>>
>>
>>
>> fatal: protocol error: bad line length character: ---Á
>>
>>
>>
>> When I do a ssh g...@github.com  
>> git-receive-pack lbdyck/qtab.git I get this:
>>
>>
>>
>>
>> --ÄÁ---Ä--ÃÃ-À--ÄÂÂ--Á-/ÄÁ---À/--ÊÁÃËÇÁ/ÀË_/ËÈÁÊÊÁø?ÊÈ-ËÈ
>> / ÈÍË-ÊÁ ø?ÊÈ-ËÈ/ÈÍË-Î--ÀÁ%ÁÈÁ-ÊÁÃË-ËÑÀÁ-Â/>À---,-ÉÍÑÁÈ-/È?_ÑÄ-?Ã
>>
>> Ë-ÀÁ%È/-øÍËÇ-?øÈÑ?>Ë-?¦ÁÄÈ-Ã?Ê_/È-ËÇ/--/ÅÁ>È-ÅÑÈÅÑÈÇÍÂ-Å-ÃÃ-Ä/À-
>> -
>> 
>>
>>
>>
>>
>> If I do the same ssh g...@github.com  
>> git-receive-pack lbdyck/qtab.git on one of my other systems it looks 
>> like
>> this:
>>
>>
>>
>> 00ce342c27f0363f6d24cbb68e8ace7454218d4828a2
>> refs/heads/masterreport-status
>> report-status-v2 delete-refs side-band-64k quiet atomic
>>
>> ofs-delta push-options object-format=sha1
>> agent=git/github-g2ff1cad44179
>>
>>
>>
>>
>> We’ve looked at the TCP/IP setup, the SSH setup, and the Git setup 
>> with no joy.  We’ve also confirmed that the ssh public key has been 
>> properly added to github.
>>
>>
>>
>> Can anyone provide any suggestions that will help resolve this?
>>
>>
>>
>> Thank you
>>
>>
>>
>>
>>
>> ­­­__
>> _
>> __
>> 
>>
>> Lionel B Dyck <
>>
>> Website:   www.lbdsoftware.com
>>
>>
>>
>> "Worry more about your character than your reputation.  Character is 
>> what you are, reputation merely what others think you are." - John 
>> Wooden
>>
>>
>>
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO 
>> IBM-MAIN
>>
> --
> Michael Babcock
> OneMain Financial
> z/OS Systems Programmer, Lead
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to 

Re: Coupling Facility and z/OS SysPlex LPARs moving to new hardware

[Jousma, David]

You will need to define new cf's along with the existing ones in the cfrm 
policy and activate it before you move.




From: IBM Mainframe Discussion List  on behalf of 
Arye Shemer 
Sent: Sunday, February 7, 2021 1:34:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Coupling Facility and z/OS SysPlex LPARs moving to new hardware

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Installation I work with is going to move Coupling Facilities and z/OS
LPARs to new hardware.
To best of my recollections after defining the IODFs for the new systems
(z15)
 which should (could) include definitions for old and new systems.system
programmers can rely on system commands to remove CF LPAR and activate the
new one on the new hardware.
At last my question,
is this assumption correct (using System Commands to remove old and
activate new CF LPARs) ?
I do not expect a list of commands, just approval (or not) :-)
Thank you,
Arye.

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

X3270 or c3270 on mac

[Jousma, David]

I've seen this mentioned here before.   Would anyone who is using mind sharing 
your key map file?  I'm playing around with it on my Mac.  Looking for  a 
headscarf.

Thanks, dave
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: Learning the basics of SMP/E

[Jousma, David]

Thanks Sam!

_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sam 
Golob
Sent: Tuesday, January 26, 2021 1:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Learning the basics of SMP/E

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Dear Folks,

     I was just reviewing an article I wrote in 1988 (a long time ago) that 
encapsulates and summarizes my original efforts to learn SMP/E.

     Many of us systems programmers don't have a chance to do system 
maintenance, leaving it to "the designated person (or people)". And also, when 
breaking in a new person, that person is often given the job of doing the SMP/E 
system maintenance.  In my experience, the first exposure to SMP/E is a 
daunting task.  And it is even somewhat forbidding (to learn SMP/E) for very 
experienced systems programmers also, who (somehow) never ever got exposed to 
it, in their own LONG experience.

     My personal feeling (in 1988, after five years as a sysprog) was that, 
with the PROPER TEACHING, I could have learned, in 3 weeks, what took me 4 
years to learn.

     I didn't want that to happen to anybody else.

     So I wrote an article.  Very carefully.

     I just read it over, today.  That's why I'm writing this piece.

     IF ANYBODY FEELS THE NEED TO LEARN SMP/E, PLEASE GO TO FILE 014 OF THE CBT 
TAPE 
(https://protect2.fireeye.com/v1/url?k=3e1c3ff8-61870700-3e1c1560-0cc47a33347c-5dd923bfd7f64b63=1=abfca06c-81fb-4463-9f31-e90f4b69df4c=http%3A%2F%2Fwww.cbttape.org%2F),
 and READ THE MEMBER, SMPARTCL.

     Part of the problem in learning SMP/E, is that IBM does not tell you about 
its history, and where it came from.  In order to really understand SMP/E, you 
first must have a grasp of doing a SYSGEN, to create a new MVS system.  We 
don't do SYSGENs anymore, so this makes it hard to understand the foundation 
and structure and purpose and method of operation, of SMP/E.

     Nevertheless, in that article, I tried to recreate the history, the best I 
could.

     BOTTOM LINE.  If you want to train someone, or yourself, to do SMP/E, 
please first read this article - CBT File 014 - member SMPARTCL. It is almost 
guaranteed to make the process simpler.

     Hope this helps.

     All the best of everything to all of you.

Sincerely, Sam



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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: How to validate mount points for IPLs

[Jousma, David]

Hi lizette,

For all the zos mounts, I use my service mount batch job as the template for 
those in parmlib with modifications to syntaxes to fit.  Everything else for 
/tmp, ,etc, dev, and any other ancillary vendor, user file systems are 
ieheyeball.   There aren't many that would fail an ipl entirely so can be fixed 
after you are up.  There is the health check that was mentioned,  but that only 
calls out differences between what is in parmlib and what is actually mounted.

Hope this helps!

From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Sent: Sunday, January 24, 2021 1:14:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: How to validate mount points for IPLs

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

List



I am not quite sure what technique or process I can put together to validate
the Mount points in BPXPRMxx prior to an IPL



SYNTAXCHECK only makes sure that I did not finger check



It does not say this will mount or not mount



And with z/OS and other products using lots of mount points - hand checking
is getting difficult.



Any ideas are welcomed.



Thank you



Lizette




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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**



${If.App.WXP}Classification: Internal Use${If.End}
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)

[Jousma, David]

Not sure what the argument is about here, whether you can zap a SMPE module, or 
whether you *should* zap a SMPE module.  We used to have this usermod for Fault 
Analyzer before it was a dynamic exit

++USERMOD (MSYS013) .   
++VER(Z038) FMID(HBB77A0) . 
++ZAP (IEAVTABX) .  
NAME IEAVTABX   
VER  ,  COUNT FIELD 
REP  ,0001  SET COUNT FIELD 
VER 0004 4040,4040,4040,4040FIRST UNUSED ENTRY  
REP 0004 C9C4,C9E7,C4C3,C1D7SET TO IDIXDCAP 

_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Wednesday, January 20, 2021 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no 
member list)

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

W dniu 20.01.2021 o 18:43, Seymour J Metz pisze:
> Nonsense, there's nothing illegal about ++ ZAP.
>
> SMP does what you would expect, including warning you of conflicting service.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> R.S. [r.skoru...@bremultibank.com.pl]
> Sent: Wednesday, January 20, 2021 12:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no 
> member list)
>
> W dniu 20.01.2021 o 18:10, Seymour J Metz pisze:
>>> There are ZAPs to change it in original IBM code.
>>> "Illegal" from SMP/E point of view
>> No.
>>
> Yes.
>
> --
> Radoslaw Skorupka
> Lodz, Poland

Nonsense, there are ZAPs to change it.

-- 
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, 
rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może 
podlegać karze.

mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, 
e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 
169.401.468 złotych.

Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z 
prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które 
wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną 
działalnością bankową.
Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w 
Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo


If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

We are the controller of your personal data, which you provided in connection 
with correspondence with us. We process your data for purposes resulting from 
the subject of correspondence, including those related to the banking services.
More information on how we protect and process personal data can be found in 
the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo.

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is 

Re: clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Jousma, David]

Thanks Marna.   Somehow I knew you'd wander along to this thread.     I'm sure 
I'll get prodded at some point to look at it.  For something we do once every 
couple years, I really havent spent much time looking at it.   Our zOSMF 
installation is still in shambles as we have not yet gotten security working 
correctly(we havent had time, not a talent issue).

_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Marna WALLE
Sent: Tuesday, January 19, 2021 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: clarification please - is z/OSMF required for migrating z/OS from 
v2.3 to v2.4 ?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hi Dave,
We certainly want to have the z/OSMF installation (with a portable software 
instance) easier than a CustomPac Serverpac!  I do understand, though, that 
anything different will take a time to get used to.  With that in mind, I'd 
like to mention a sample portable software instance which you can use to become 
familiar with the z/OSMF installation process today.

Take a look at the requirements on this page (for the PTFs you'll need), you 
can get a very quick overview of what the deployment process looks like (which 
has many of the same steps as the CustomPac dialog), and then download a sample 
package to give it a run on your own system:

https://www.ibm.com/support/z-content-solutions/serverpac-install-zosmf/

This sample is what a ServerPac that is a portable software instance looks like 
today.  We've got CICS, Db2, and IMS (and their program products) portable 
software instances available for ordering on Shopz today, so you could try it 
out now on any of those products if that would be helpful too. 

If I may suggest some hints:  define your software instances for the existing 
software you have today installed in a ServerPac.  Those software instances can 
be a "model" for the incoming portable software instance, and takes just a 
couple of minutes to do.   Installing new software, when based on your existing 
software, could realistically allow you to continue with future installs in a 
half-day, as you do today.

fwiw:  We had a new person in our area that had very little z/OS experience and 
had never installed a ServerPac (or really used SMP/E).  This person was able 
to install a portable software instance in a couple of hours (once he knew the 
volumes and data set names to use).  

-Marna WALLE
z/OS Installation and Upgrade

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Jousma, David]

" However, IBM's plan is to eventually require z/OSMF for future software 
installation.  We have not yet announced when or for which product releases, 
but it's certainly past time to start getting comfortable with z/OSMF in 
general."

Hopefully well after I retire Unless it is made really simple.   These 
days, a complete serverpac install to the point where I am applying my SMPE 
usermods, is maybe a half day's worth of work.   I get it that IBM probably 
wants to do away with the Custompac dialogs.   But please don’t do it only to 
make the process more complicated.

_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kurt Quackenbush
Sent: Friday, January 15, 2021 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: clarification please - is z/OSMF required for migrating z/OS from 
v2.3 to v2.4 ?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

On 1/15/2021 10:00 AM, Bruce Lightsey wrote:
> I am not one of the system programmers but have been tasked with getting this 
> answer for them (and to manage them). My systems guys like SMPe and 
> ServerPacks, etc but z/OSMF is “Alienware” to them – must I tell them to get 
> over it and go with the workflow ?
While z/OSMF is not strictly required for upgrading z/OS V2.3 to V2.4, it is 
highly recommended, specifically for the z/OS V2.4 Upgrade Workflow:

https://github.com/IBM/IBM-Z-zOS/tree/master/zOS-Workflow/zOS%20V2.4%20Upgrade%20Workflow

The workflow is a replacement for the former z/OS Migration books.  If you 
insist on something that approximates a book form, on that page you can find 
links to a sample exported workflow.  The exported format is suitable for 
browsing, printing, and searching.  But really your team should take this 
opportunity to get familiar with the z/OSMF workflow.

z/OS V2.4 is installed using the familiar ServerPac method.  However, IBM's 
plan is to eventually require z/OSMF for future software installation.  We have 
not yet announced when or for which product releases, but it's certainly past 
time to start getting comfortable with z/OSMF in general.

Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when 
he applies PTFs.

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: z/OS Git/SSH Help - Configuration Issue ?

[Jousma, David]

Speaking of GIT, IBM seems to be distributing Rocket Git z/OS client with their 
ADFz offering.   That is great because we are just moving to mainframe DEVOPS 
with GIT, etc and support for that piece of software now comes through IBM, 
instead of paying Rocket for a separate Support offering...

_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: Monday, January 11, 2021 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS Git/SSH Help - Configuration Issue ?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I have a test lpar that I've been given access to and I have installed Git 
(both 2.14 and 2.26) and have the same issues with either release so I'm 
thinking it is outside of git.

 

When I issue the command: ssh g...@github.com  
git-receive-pack lbdyck/racfadm.git I get a response that looks like ascii text 
yet on my work lpar the text if readable. I have confirmed that both ssh and 
sftp work from my windows pc to this test lpar.  

 

Does anyone have any pointers on where to look to fix this?

 

Thanks in advance.

 

Lionel B. Dyck <

Website:   https://www.lbdsoftware.com

 

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

 


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Code to verify LOGON password

[Jousma, David]

Sam,

I'm curious as to the usage scenario?   This almost sounds like a security 
problem?  So you take a users password input, go ask SAF if correct?  Sounds 
like a man-in-the-middle situation?  

_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sam 
Golob
Sent: Friday, January 8, 2021 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Code to verify LOGON password

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Dear Folks,

     Does anyone have user-written code for RACF, so that if the user types in 
a password, the code will verify if it is the user's actual LOGON password?

     I'd like to see code that does this, for ACF2 and Top Secret as well, but 
I'm primarily interested in RACF.

     Thank you very much.  All the best of everything to all of you.

Sincerely, Sam


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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