z/OS Authorized Code Scanner Webcast

[Timothy Sipples]

I'm hosting another Webcast this Friday (June 9) at 11:00 AM Singapore time 
(03:00 UTC). This time it's about the z/OS Authorized Code Scanner (zACS).

zACS is an important tool to help keep Program Call and Supervisor Call 
routines secure. You really don't want unauthorized code to fetch or update 
storage (memory) that it has no business accessing. zACS helps identify these 
potential exposures so you can fix them. If you'd like to learn more about zACS 
then this Webcast is for you. And it's at a time that generally works for 
participants in Asia-Pacific time zones.

To register please visit:

https://ibm.biz/apac-webinar-subscription

On June 30th (same time) I'm presenting a "Mainframe Security Freebies" 
Webcast. I'm still working on this talk and presentation, so I'm still open to 
ideas and contributions if you have any favorite "freebies." This time I'm 
focusing on free security-related stuff for your mainframe whether it's for 
z/OS, Linux, or any other mainframe operating system.

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/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

Re: z/OS 3.1: Now UNIXR Certified

[David Crayford]

On 6/6/2023 12:02 am, Farley, Peter wrote:

Which is fine for those who have access to those tools; many of us do not have that 
luxury, nor the permission nor the disk space to "try them out" for ourselves.


That's a really unfortunate situation. I encourage you to talk to your 
management and try to convince them to change their policy. All the cool 
new tools and technologies, like dynamic languages, compilers, 
libraries, frameworks, and more, often require USS (UNIX System 
Services). By not giving you access to USS, they're basically keeping 
you stuck in the past and preventing your growth. It's important to make 
them understand that adapting and learning new things is essential for 
professional development, no matter how old you are.





-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: Monday, June 5, 2023 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1: Now UNIXR Certified

Peter - I believe you'll find that the Co:Z folks, at coztoolkit.com, have 
tools that may provide the performance improvements that you are looking for.

The ZIGI tool will take advantage of their getpds and putpds commands if they 
are available and achieve significantly improved performance compared to native 
cp.


Lionel B. Dyck <><
Website: 
https://urldefense.com/v3/__https://www.lbdsoftware.com__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!LAIovDokCs-oEgMZ6WCSnTOL8NyW8GN8r0RbiJPkLNybyfjLR0U7xWJijkAwrCmc7-VI_n5W5CsQYcDqizc$
Github: 
https://urldefense.com/v3/__https://github.com/lbdyck__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!LAIovDokCs-oEgMZ6WCSnTOL8NyW8GN8r0RbiJPkLNybyfjLR0U7xWJijkAwrCmc7-VI_n5W5CsQyKQdnzg$

“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 
Farley, Peter
Sent: Monday, June 5, 2023 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1: Now UNIXR Certified

Where the performance of the USS file system falls down is in the transfer between z/OS files/data stores and 
USS files/data stores.  Practical experimentation has shown me that the "cp" and "cat" 
commands are the fastest way to sequentially transfer non-DB2 data using only a pre-written utility (and both 
do support VSAM files), but that is not to say those are fast processes compared to directly reading and 
writing files in the "other system".  When the business-important permanent data store is not 
originally in the USS file system you must deal with that transfer time in the application design or write 
your own data transfer code to achieve an efficiently running system.

Neither zowe nor zoau provide good performance in the data transfer process.  The zowe transfer time is 
reasonable for one-offs (but still not as fast as "cp" or "cat") but zoau is horribly 
slow no matter how it is used.  The DB2CLI is a significant time consumer; the python-ibmdb module does it 
far faster, though that product is still officially in "beta" mode.

As usual, the best way to optimize data access time is good design and a 
thorough knowledge of the technical benefits and flaws of your system.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, June 5, 2023 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1: Now UNIXR Certified

One compelling reason to embrace zFS is its potential for modernization and 
facilitating the development of contemporary tools. While acknowledging the 
significance of QSAM, VSAM KSDS, and other older technologies, it is crucial to 
recognize the advancements made in data structure formats for disk files since 
the days of VSAM. In the present era, LSM-trees have gained popularity for 
their application in NoSQL key-value stores, blazing-fast TSDBs, and highly 
optimized logging systems.

Attempting to implement an LSM-tree using VSAM would be an arduous endeavor, 
bordering on a nightmare. Even with the assistance of Media Manager, it remains 
a Herculean task to reconcile these two disparate technologies.

I dedicated a couple of hours to porting RocksDB, and the results have been 
nothing short of exceptional. It operates seamlessly on z/OS, demonstrating its 
prowess and resilience. Another noteworthy aspect of LSM-trees is their 
inherent ability to merge and compact while in operation, eliminating the need 
for reorgs.
https://urldefense.com/v3/__https://github.com/facebook/rocksdb__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!LzT4O_YlJ0b4g_9FS6BO4zVHzZ55N3E8k4QPWtQx_hnCZfUjLh3mDAsW-PYPhMIqZnaz3WNQfEhFE3UKfk3uzfY$

https://urldefense.com/v3/__https://www.youtube.com/watch?v=I6jB0nM9SKU__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!LzT4O_YlJ0b4g_9FS6BO4zVHzZ55N3E8k4QPWtQx_hnCZfUjLh3mDAsW-PYPhMIqZnaz3WNQfEhFE3UKiaUQef4$

On 5/6/2023 5:55 pm, David Crayford wrote:


On 2/6/2023 11:31 pm, René Jansen wrote:

What I remember of it is that he was convinced it was

Re: z/OS 3.1: Now UNIXR Certified

[David Crayford]

On 5/6/2023 6:07 pm, Seymour J Metz wrote:

OTOH, benchmarks are tricky things, and it is often easy to get the answers you 
want by carefully cherrypicking the details. I suspect that QSAM really is 
faster for the test he ran.


QSAM may have stood a chance against HFS but it has no chance against 
zFS.  It's a very standard benchmark which simply reads/writes 4096 
length records. The code is in the public domain so I challenge anybody 
to try to tweak the code so that QSAM performs better. If you can, then 
leave a comment in the gist and DM me your details. I will send you a 
bottle of fine claret, maybe a burgundy if that tickles your fancy. I'm 
that confident it won't happen :)


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

Re: z/OS 3.1: Now UNIXR Certified

[Seymour J Metz]

4096? That sounds like it is tuned to the underlying CI structure of zFS.

Would you consider performance parameters on DCBE to be cheating?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Tuesday, June 6, 2023 6:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1: Now UNIXR Certified

On 5/6/2023 6:07 pm, Seymour J Metz wrote:
> OTOH, benchmarks are tricky things, and it is often easy to get the answers 
> you want by carefully cherrypicking the details. I suspect that QSAM really 
> is faster for the test he ran.

QSAM may have stood a chance against HFS but it has no chance against
zFS.  It's a very standard benchmark which simply reads/writes 4096
length records. The code is in the public domain so I challenge anybody
to try to tweak the code so that QSAM performs better. If you can, then
leave a comment in the gist and DM me your details. I will send you a
bottle of fine claret, maybe a burgundy if that tickles your fancy. I'm
that confident it won't happen :)

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

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

Re: z/OS Authorized Code Scanner Webcast

[Seymour J Metz]

What's that in EDT (US East Coast, daylight)? Thanks.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Timothy Sipples [sipp...@sg.ibm.com]
Sent: Tuesday, June 6, 2023 5:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS Authorized Code Scanner Webcast

I'm hosting another Webcast this Friday (June 9) at 11:00 AM Singapore time 
(03:00 UTC). This time it's about the z/OS Authorized Code Scanner (zACS).

zACS is an important tool to help keep Program Call and Supervisor Call 
routines secure. You really don't want unauthorized code to fetch or update 
storage (memory) that it has no business accessing. zACS helps identify these 
potential exposures so you can fix them. If you'd like to learn more about zACS 
then this Webcast is for you. And it's at a time that generally works for 
participants in Asia-Pacific time zones.

To register please visit:

https://ibm.biz/apac-webinar-subscription

On June 30th (same time) I'm presenting a "Mainframe Security Freebies" 
Webcast. I'm still working on this talk and presentation, so I'm still open to 
ideas and contributions if you have any favorite "freebies." This time I'm 
focusing on free security-related stuff for your mainframe whether it's for 
z/OS, Linux, or any other mainframe operating system.

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/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

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

Re: Best practice for /etc and /var when upgrading

[Seymour J Metz]

Then what did he to about the functionality previously done by the 
customizations?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pew, Curtis G [curtis@austin.utexas.edu]
Sent: Monday, June 5, 2023 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best practice for /etc and /var when upgrading

How do people handle /SYSTEM/etc and /SYSTEM/var when upgrading z/OS? In the 
past we’ve had these filesystems on an auxiliary volume, so that they remained 
the same during any upgrades unless we deliberately changed something. For our 
last upgrade (this past weekend) our management outsourced the upgrade to a 3rd 
party service provider, and the sysprog doing it configured completely new 
filesystems for these that were the generic IBM-provided versions, without any 
of our customizations. He claims this is a best practice. What say ye?


--
Curtis Pew
ITS Campus Solutions
curtis@austin.utexas.edu




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

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

Re: CVT or PSA field with ever changing value?

[Seymour J Metz]

How would the OS prevent it? There are lots of unauthorized services tied into 
the CVT, so fetch-protecting the PSA isn't viable.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Ed 
Jaffe [edja...@phoenixsoftware.com]
Sent: Monday, June 5, 2023 1:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CVT or PSA field with ever changing value?

On 6/5/2023 10:03 AM, Binyamin Dissen wrote:
> Is there some PSA/CVT field that most of the time where it is examined (not
> talking microseconds here) the value will be different.

It seems unlikely the operating system would ever allow dispatched work
to observe such a difference.


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

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

Re: z/OS 3.1: Now UNIXR Certified

[David Crayford]

On 6/6/2023 6:42 pm, Seymour J Metz wrote:

4096? That sounds like it is tuned to the underlying CI structure of zFS.


It makes no difference what the record length is. I can updtae the gist 
if you suspect I'm dealing from the bottom of the deck!





Would you consider performance parameters on DCBE to be cheating?


Of course not. It won't make up for a 5x difference.





--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Tuesday, June 6, 2023 6:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1: Now UNIXR Certified

On 5/6/2023 6:07 pm, Seymour J Metz wrote:

OTOH, benchmarks are tricky things, and it is often easy to get the answers you 
want by carefully cherrypicking the details. I suspect that QSAM really is 
faster for the test he ran.

QSAM may have stood a chance against HFS but it has no chance against
zFS.  It's a very standard benchmark which simply reads/writes 4096
length records. The code is in the public domain so I challenge anybody
to try to tweak the code so that QSAM performs better. If you can, then
leave a comment in the gist and DM me your details. I will send you a
bottle of fine claret, maybe a burgundy if that tickles your fancy. I'm
that confident it won't happen :)

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

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


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

Re: Best practice for /etc and /var when upgrading

[rpinion865]

I came to a new shop at this time last year.  Me predecessor did all of the 
heavy lifting to install z/OS 2.4.  Basically, I had to do a little 
customization, and roll 2.4 into TECH, DEV, and PROD.  Fortunately my 
predecessor documented everything he had done, which made my job much easier.  
His documentation regarding /etc & /var showed much the same information that 
Mark Zelden shared earlier, up to showing the output of the diff commands.

To answer your question, my predecessor started with the virgin 2.4 /etc and 
/var and applied all of the changes from the previously customized z/OS 2.2 
/etc and /var.




Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, June 6th, 2023 at 6:56 AM, Seymour J Metz  wrote:


> Then what did he to about the functionality previously done by the 
> customizations?
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Pew, Curtis G [curtis@austin.utexas.edu]
> Sent: Monday, June 5, 2023 2:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Best practice for /etc and /var when upgrading
> 
> How do people handle /SYSTEM/etc and /SYSTEM/var when upgrading z/OS? In the 
> past we’ve had these filesystems on an auxiliary volume, so that they 
> remained the same during any upgrades unless we deliberately changed 
> something. For our last upgrade (this past weekend) our management outsourced 
> the upgrade to a 3rd party service provider, and the sysprog doing it 
> configured completely new filesystems for these that were the generic 
> IBM-provided versions, without any of our customizations. He claims this is a 
> best practice. What say ye?
> 
> 
> --
> Curtis Pew
> ITS Campus Solutions
> curtis@austin.utexas.edu
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: z/OS Authorized Code Scanner Webcast

[John Pratt]

Hi Shmuel,

By my reckoning 11am Singapore is 11pm the day before EDT.

John.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Tuesday, 6 June 2023 8:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Authorized Code Scanner Webcast

What's that in EDT (US East Coast, daylight)? Thanks.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Timothy Sipples [sipp...@sg.ibm.com]
Sent: Tuesday, June 6, 2023 5:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS Authorized Code Scanner Webcast

I'm hosting another Webcast this Friday (June 9) at 11:00 AM Singapore time
(03:00 UTC). This time it's about the z/OS Authorized Code Scanner (zACS).

zACS is an important tool to help keep Program Call and Supervisor Call
routines secure. You really don't want unauthorized code to fetch or update
storage (memory) that it has no business accessing. zACS helps identify
these potential exposures so you can fix them. If you'd like to learn more
about zACS then this Webcast is for you. And it's at a time that generally
works for participants in Asia-Pacific time zones.

To register please visit:

https://ibm.biz/apac-webinar-subscription

On June 30th (same time) I'm presenting a "Mainframe Security Freebies"
Webcast. I'm still working on this talk and presentation, so I'm still open
to ideas and contributions if you have any favorite "freebies." This time
I'm focusing on free security-related stuff for your mainframe whether it's
for z/OS, Linux, or any other mainframe operating system.

-
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/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

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

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

Re: Best practice for /etc and /var when upgrading

[Seymour J Metz]

So not "the generic IBM-provided versions, without any of our customizations.". 
Applying an installation delta to copiesof the IBM /etc and /var as part of the 
installation process sounds like best practice to me. Of course, you also need 
procedures for service that hits them.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
rpinion865 [042a019916dd-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, June 6, 2023 7:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best practice for /etc and /var when upgrading

I came to a new shop at this time last year.  Me predecessor did all of the 
heavy lifting to install z/OS 2.4.  Basically, I had to do a little 
customization, and roll 2.4 into TECH, DEV, and PROD.  Fortunately my 
predecessor documented everything he had done, which made my job much easier.  
His documentation regarding /etc & /var showed much the same information that 
Mark Zelden shared earlier, up to showing the output of the diff commands.

To answer your question, my predecessor started with the virgin 2.4 /etc and 
/var and applied all of the changes from the previously customized z/OS 2.2 
/etc and /var.




Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, June 6th, 2023 at 6:56 AM, Seymour J Metz  wrote:


> Then what did he to about the functionality previously done by the 
> customizations?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Pew, Curtis G [curtis@austin.utexas.edu]
> Sent: Monday, June 5, 2023 2:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Best practice for /etc and /var when upgrading
>
> How do people handle /SYSTEM/etc and /SYSTEM/var when upgrading z/OS? In the 
> past we’ve had these filesystems on an auxiliary volume, so that they 
> remained the same during any upgrades unless we deliberately changed 
> something. For our last upgrade (this past weekend) our management outsourced 
> the upgrade to a 3rd party service provider, and the sysprog doing it 
> configured completely new filesystems for these that were the generic 
> IBM-provided versions, without any of our customizations. He claims this is a 
> best practice. What say ye?
>
>
> --
> Curtis Pew
> ITS Campus Solutions
> curtis@austin.utexas.edu
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: z/OS Authorized Code Scanner Webcast

[Tony Harminc]

On Tue, 6 Jun 2023 at 12:45, Seymour J Metz  wrote:

> What's that in EDT (US East Coast, daylight)? Thanks.
>

Seriously - you don't know your own offset from UTC? But everyone else
should know it for you?

Tony H.


> I'm hosting another Webcast this Friday (June 9) at 11:00 AM Singapore
> time (03:00 UTC). This time it's about the z/OS Authorized Code Scanner
> (zACS).
>

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

Re: CVT or PSA field with ever changing value?

[Peter Relson]

If you're authorized, you could of course disable and then use some CPU-related 
area as the STCK/STCKF/STCKE target.

The comments on PSATIME_ON_CP are pretty clear about what it is.

If you're looking for a CPU-time-related field, if you happen to know you're a 
task, TCBTTIME or STCB_TTIME might fit the bill.

All of these fields are updated based on time slice and undispatch. That's 
about as frequently as you will find.

Peter


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

Re: z/OS Authorized Code Scanner Webcast

[Seymour J Metz]

I'm UTC-5, but the last time I converted (from Amsterdam) I seemed to be an 
hour off, and I just got two different answers on this list :-(


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Tuesday, June 6, 2023 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Authorized Code Scanner Webcast

On Tue, 6 Jun 2023 at 12:45, Seymour J Metz  wrote:

> What's that in EDT (US East Coast, daylight)? Thanks.
>

Seriously - you don't know your own offset from UTC? But everyone else
should know it for you?

Tony H.


> I'm hosting another Webcast this Friday (June 9) at 11:00 AM Singapore
> time (03:00 UTC). This time it's about the z/OS Authorized Code Scanner
> (zACS).
>

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

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

Re: z/OS 3.1: Now UNIXR Certified

[Rick Troth]

On 6/5/23 23:19, kekronbekron wrote:

Porting applications to Linux-s390x has never been particularly difficult.

It starts getting hairy when attempts are made for vectorized apps, or other 
acceleration frameworks that are available for x86 Intel or AMD.
Can't port all of them but maybe need to re-create them, to have the same 
capabilities on Z.



Thanks for clarifying.
I view those as non-kernel optimizations. Services provided by the 
kernel/system are very very consistent.
Not saying they aren't important, but that well-written apps can at 
least function in their absence. Such sources "drop right in" to Linux 
of any flavor.


I've personally re-compiled a large number of FLOSS apps for Linux on 
more than a half dozen processor architectures.
This kind of problem (optimization) has become secondary in my 
experience. (Again, NOT saying it doesn't matter.)


Contrast "Linux to Linux" with "Linux to USS" and the question of what 
the system provides, and *how* it provides that, becomes dramatically 
more significant.

And we're *still* saddled with platform optimizations.




- KB

--- Original Message ---
On Tuesday, June 6th, 2023 at 2:25 AM, Rick Troth  wrote:



Porting applications to Linux-s390x has never been particularly difficult.
The biggest challenge has always been such things as endianness.
Linux-s390x presents the same kernel interface to userland as Linux-i386.

Porting to USS has (at least) two significant hurdles: EBCDIC and a
different system interface. Being Unix certified doesn't really help the
porting process.
Even so, I wish that more packages would be ported to USS. It's better
FOR ANY GIVEN PACKAGE that it be ported to USS (and/or to other Unix,
such as Slolaris or AIX). The more broadly a package ports, the better
the health of its heart/core.
But I'm not being altrustic: I wish that they were available on USS. I
miss them!

-- R; <><



On 6/5/23 11:01, kekronbekron wrote:


True, however, I expect it to at least be less difficult than it was in the 
past.
Less difficult that it was with linux/s390x.
Some of the key things IBM has done (and is doing) are
LinuxONE community cloud,
Wazi as a Service (on IBM cloud),
and upstreaming LLVM and Golang bits.

Icing on the cake will be zDT Learner's Edition, if it ever sees the light of 
day again.

Are there any other noteworthy ports that haven't been upstreamed to because of 
this?

- KB

--- Original Message ---
On Monday, June 5th, 2023 at 5:31 PM, David Crayford dcrayf...@gmail.com wrote:


On 5/6/2023 7:42 pm, kekronbekron wrote:


porting RocksDB
Is zOS support upstreamed too, by any chance?

The likelihood of the Meta maintainers accepting a z/OS patch PR is
extremely low. Due to z/OS being a niche platform, maintainers tend to
be hesitant in accepting patches unless they are supported by
organizations such as IBM (in the case of Node.js) with a commitment to
support the port. A notable example is the Perl community, which faced
significant challenges when removing EBCDIC support after the original
porters (IBM) lost interest. As a result, it is more commonplace to
maintain a separate patch file for z/OS-specific modifications.


- KB
--- Original Message ---
On Monday, June 5th, 2023 at 4:35 PM, David Crayford dcrayf...@gmail.com wrote:


One compelling reason to embrace zFS is its potential for modernization
and facilitating the development of contemporary tools. While
acknowledging the significance of QSAM, VSAM KSDS, and other older
technologies, it is crucial to recognize the advancements made in data
structure formats for disk files since the days of VSAM. In the present
era, LSM-trees have gained popularity for their application in NoSQL
key-value stores, blazing-fast TSDBs, and highly optimized logging systems.

Attempting to implement an LSM-tree using VSAM would be an arduous
endeavor, bordering on a nightmare. Even with the assistance of Media
Manager, it remains a Herculean task to reconcile these two disparate
technologies.

I dedicated a couple of hours to porting RocksDB, and the results have
been nothing short of exceptional. It operates seamlessly on z/OS,
demonstrating its prowess and resilience. Another noteworthy aspect of
LSM-trees is their inherent ability to merge and compact while in
operation, eliminating the need for reorgs.
https://github.com/facebook/rocksdb

https://www.youtube.com/watch?v=I6jB0nM9SKU

On 5/6/2023 5:55 pm, David Crayford wrote:


On 2/6/2023 11:31 pm, René Jansen wrote:


What I remember of it is that he was convinced it was a lot slower.
He was mistaken! I've tested it out, and QSAM is no match for zFS. You
can find the details in this gist:
https://gist.github.com/daveyc/14b45d6d70d8dd9af1848e539d78881f.
Adding an fsync() call after writing each record barely incurs any
overhead. zFS, operating with highly optimized Media Manager APIs,
handles it efficiently. Additionally, zFS functions as a caching file
system.
I have observed a certain degree of sno

Re: Any one having issues accessing SERVICELINK

[Lopez, Sharon]

I'm reposting.  Can others check and see if you can get on to SERVICELINK?

Thank you.
Sharon Lopez

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lopez, Sharon
Sent: Monday, June 5, 2023 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Any one having issues accessing SERVICELINK

Thank you.



The information transmitted is intended solely for the individual or entity to 
which it is addressed and may contain confidential and/or privileged material. 
Any review, retransmission, dissemination or other use of or taking action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you have received this email in error please 
contact the sender and delete the material from any computer.

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


The information transmitted is intended solely for the individual or entity to 
which it is addressed and may contain confidential and/or privileged material. 
Any review, retransmission, dissemination or other use of or taking action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you have received this email in error please 
contact the sender and delete the material from any computer.

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

Re: z/OS Authorized Code Scanner Webcast

[Pommier, Rex]

GIYF...

Eastern Daylight Time (EDT), when observing daylight saving time 
(spring/summer), are four hours behind Coordinated Universal Time (UTC−04:00).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Tuesday, June 6, 2023 7:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: z/OS Authorized Code Scanner Webcast

I'm UTC-5, but the last time I converted (from Amsterdam) I seemed to be an 
hour off, and I just got two different answers on this list :-(


--
Shmuel (Seymour J.) Metz
https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!KjMRP1Ixj6eLE0Fj!vf15eA_LVSP6rtOomcGg-7xXOoD62Wn_9p1JKXi1dZmpVmvAhOG8F1kb0Hp0Uh_5gdclpr7SQrabQSzz-g$
 


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Tuesday, June 6, 2023 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Authorized Code Scanner Webcast

On Tue, 6 Jun 2023 at 12:45, Seymour J Metz  wrote:

> What's that in EDT (US East Coast, daylight)? Thanks.
>

Seriously - you don't know your own offset from UTC? But everyone else should 
know it for you?

Tony H.


> I'm hosting another Webcast this Friday (June 9) at 11:00 AM Singapore 
> time (03:00 UTC). This time it's about the z/OS Authorized Code 
> Scanner (zACS).
>

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

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


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

Re: Any one having issues accessing SERVICELINK

[Michael Babcock]

Nope, just tried.   Got an authorization error.

On Tue, Jun 6, 2023 at 9:07 AM Lopez, Sharon <
038467b8de97-dmarc-requ...@listserv.ua.edu> wrote:

> I'm reposting.  Can others check and see if you can get on to SERVICELINK?
>
> Thank you.
> Sharon Lopez
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Lopez, Sharon
> Sent: Monday, June 5, 2023 2:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Any one having issues accessing SERVICELINK
>
> Thank you.
>
>
>
> The information transmitted is intended solely for the individual or
> entity to which it is addressed and may contain confidential and/or
> privileged material. Any review, retransmission, dissemination or other use
> of or taking action in reliance upon this information by persons or
> entities other than the intended recipient is prohibited. If you have
> received this email in error please contact the sender and delete the
> material from any computer.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> The information transmitted is intended solely for the individual or
> entity to which it is addressed and may contain confidential and/or
> privileged material. Any review, retransmission, dissemination or other use
> of or taking action in reliance upon this information by persons or
> entities other than the intended recipient is prohibited. If you have
> received this email in error please contact the sender and delete the
> material from any computer.
>
> --
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Any one having issues accessing SERVICELINK

[Mark Jacobs]

It's still not working for me, nor others on my team.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


--- Original Message ---
On Tuesday, June 6th, 2023 at 10:43 AM, Michael Babcock  
wrote:


> Nope, just tried. Got an authorization error.
> 
> On Tue, Jun 6, 2023 at 9:07 AM Lopez, Sharon <
> 038467b8de97-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > I'm reposting. Can others check and see if you can get on to SERVICELINK?
> > 
> > Thank you.
> > Sharon Lopez
> > 
> > -Original Message-
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf
> > Of Lopez, Sharon
> > Sent: Monday, June 5, 2023 2:18 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Any one having issues accessing SERVICELINK
> > 
> > Thank you.
> > 
> > The information transmitted is intended solely for the individual or
> > entity to which it is addressed and may contain confidential and/or
> > privileged material. Any review, retransmission, dissemination or other use
> > of or taking action in reliance upon this information by persons or
> > entities other than the intended recipient is prohibited. If you have
> > received this email in error please contact the sender and delete the
> > material from any computer.
> > 
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send email
> > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > 
> > The information transmitted is intended solely for the individual or
> > entity to which it is addressed and may contain confidential and/or
> > privileged material. Any review, retransmission, dissemination or other use
> > of or taking action in reliance upon this information by persons or
> > entities other than the intended recipient is prohibited. If you have
> > received this email in error please contact the sender and delete the
> > material from any computer.
> > 
> > --
> > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: z/OS 3.1: Now UNIX® Certified

[Gord Tomlin]

On 2023-06-05 18:55 PM, Paul Gilmartin wrote:

Porting to USS has (at least) two significant hurdles: EBCDIC


How much is that mitigated by Enhanced ASCII?  What residual
problems remain?  Unsupported library functions?



A couple of additional problems you can encounter:
- code that ASSumes that lower case alphabetic characters collate
  higher than upper case alphabetic characters;
- code that ASSumes that all lower case alphabetic characters
  are in a contiguous range of hex values (similar for upper case);
- code that ASSumes that digits collate lower than alphabetic
  characters.

Some years ago, I was investigating porting a well-known database 
package that shall remain nameless to z/OS USS, and found that the code 
had a lot of the above.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: Best practice for /etc and /var when upgrading

[Mark Zelden]

On Tue, 6 Jun 2023 03:15:46 +, kekronbekron  
wrote:

>I do wonder... with git now available, and this being normal USS, maybe zOSMF 
>can start formally adopting/requiring git.
>Then, moving updates from these files onto newer versions is a matter of 
>applying git patches on the new ones, where possible.
>Something that the zOSMF UI can accomodate.
>
>Do let me know if this doesn't make sense lol.
>

No, that makes no sense.   Think of /etc as the SYS1.PARMLIB for z/OS Unix.  
Any customization to
existing files should not be touched.  That is why it only makes sense to copy 
what's new into it
and also compare the distributed /etc to what you already have to see if 
possible other changes
may be desired.   I can't think of many required changes of the years but when 
there are
they are (or should be) in the migration manual or upgrade workflow for current 
versions.

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: http://www.mzelden.com/mvsutil.html

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

Re: Best practice for /etc and /var when upgrading

[Mark Zelden]

On Tue, 6 Jun 2023 11:26:02 +, Seymour J Metz  wrote:

>So not "the generic IBM-provided versions, without any of our 
>customizations.". Applying an installation delta to copiesof the IBM /etc and 
>/var as part of the installation process sounds like best practice to me. Of 
>course, you also need procedures for service that hits them.
>

No service ever hits /etc or /var.  They are not SMP/E targets.  The 
distributed /etc 
can be thought of being like IPO1.PARMLIB from serverpac.  

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: http://www.mzelden.com/mvsutil.html

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

Re: z/OS 3.1: Now UNIX® Certified

[Paul Gilmartin]

On Tue, 6 Jun 2023 11:02:47 -0400, Gord Tomlin wrote:

>On 2023-06-05 18:55 PM, Paul Gilmartin wrote:
>>> Porting to USS has (at least) two significant hurdles: EBCDIC
>>>
>> How much is that mitigated by Enhanced ASCII?  What residual
>> problems remain?  Unsupported library functions?
>
>A couple of additional problems you can encounter:
>- code that ASSumes that lower case alphabetic characters collate
>   higher than upper case alphabetic characters;
>- code that ASSumes that all lower case alphabetic characters
>   are in a contiguous range of hex values (similar for upper case);
>- code that ASSumes that digits collate lower than alphabetic
>   characters.
>
Does the Enhanced ASCII support cover all those problems?
Have you a counterexampl?

>Some years ago, I was investigating porting a well-known database
>package that shall remain nameless to z/OS USS, and found that the code
>had a lot of the above.
>
Did you compile it in Enhanced ASCII mode?  Were the data EBCDIC or ASCII?

-- 
gil
\

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

Re: Any one having issues accessing SERVICELINK

[Lopez, Sharon]

It's finally working!  Would love to know what happened.

Thanks to everyone that replied.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, June 6, 2023 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any one having issues accessing SERVICELINK

It's still not working for me, nor others on my team.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get&search=markjacobs@protonmail.com__;!!JT0xjr86ZxPthq8!vYLwK64EcczE4bVP14-bpdiWsClnEpMuM9-TAiXM6fEsz59DIyqGDKkKZP_HGMy7XazMGYJZI9M4D0dYPfVp1YCD69_1N_bp2jIZ$


--- Original Message ---
On Tuesday, June 6th, 2023 at 10:43 AM, Michael Babcock  
wrote:


> Nope, just tried. Got an authorization error.
>
> On Tue, Jun 6, 2023 at 9:07 AM Lopez, Sharon <
> 038467b8de97-dmarc-requ...@listserv.ua.edu> wrote:
>
> > I'm reposting. Can others check and see if you can get on to SERVICELINK?
> >
> > Thank you.
> > Sharon Lopez
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> > Behalf Of Lopez, Sharon
> > Sent: Monday, June 5, 2023 2:18 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Any one having issues accessing SERVICELINK
> >
> > Thank you.
> >
> > The information transmitted is intended solely for the individual or
> > entity to which it is addressed and may contain confidential and/or
> > privileged material. Any review, retransmission, dissemination or
> > other use of or taking action in reliance upon this information by
> > persons or entities other than the intended recipient is prohibited.
> > If you have received this email in error please contact the sender
> > and delete the material from any computer.
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN
> >
> > The information transmitted is intended solely for the individual or
> > entity to which it is addressed and may contain confidential and/or
> > privileged material. Any review, retransmission, dissemination or
> > other use of or taking action in reliance upon this information by
> > persons or entities other than the intended recipient is prohibited.
> > If you have received this email in error please contact the sender
> > and delete the material from any computer.
> >
> > 
> > -- 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 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


The information transmitted is intended solely for the individual or entity to 
which it is addressed and may contain confidential and/or privileged material. 
Any review, retransmission, dissemination or other use of or taking action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you have received this email in error please 
contact the sender and delete the material from any computer.

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

Re: z/OS Authorized Code Scanner Webcast

[Tom Brennan]

Everybody probably knows this in Google:

  11am in singapore

  11:00 AM Wednesday, in Singapore is
  8:00 PM Tuesday, in West Covina, CA

But maybe lesser known is this:

  11am in singapore in new york

  11:00 AM Wednesday, in Singapore is
  11:00 PM Tuesday, in New York, NY

Is that correct?  I guess so :)

I did attend Tim's previous meeting and I believe the local 8pm time was 
correct for that one.


On 6/6/2023 7:17 AM, Pommier, Rex wrote:

GIYF...

Eastern Daylight Time (EDT), when observing daylight saving time 
(spring/summer), are four hours behind Coordinated Universal Time (UTC−04:00).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Tuesday, June 6, 2023 7:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: z/OS Authorized Code Scanner Webcast

I'm UTC-5, but the last time I converted (from Amsterdam) I seemed to be an 
hour off, and I just got two different answers on this list :-(


--
Shmuel (Seymour J.) Metz
https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!KjMRP1Ixj6eLE0Fj!vf15eA_LVSP6rtOomcGg-7xXOoD62Wn_9p1JKXi1dZmpVmvAhOG8F1kb0Hp0Uh_5gdclpr7SQrabQSzz-g$


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Tuesday, June 6, 2023 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Authorized Code Scanner Webcast

On Tue, 6 Jun 2023 at 12:45, Seymour J Metz  wrote:


What's that in EDT (US East Coast, daylight)? Thanks.



Seriously - you don't know your own offset from UTC? But everyone else should 
know it for you?

Tony H.



I'm hosting another Webcast this Friday (June 9) at 11:00 AM Singapore
time (03:00 UTC). This time it's about the z/OS Authorized Code
Scanner (zACS).



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

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


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



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

Re: Any one having issues accessing SERVICELINK

[Steve Thompson]

Well, it all started with a garbage disposal unit that would not 
run. So I went to the panel, and couldn't find any circuit 
breakers that were tripped. So I took the switch plate off the 
wall for the switch that controlled the garbage disposal unit.  
Long story short, I took the switch out of the circuit and 
swapped it with another and put it all back together and the 
disposal unit started working.


And then I got an email saying SERVICELINK is working again.

That's my st-st-story and I'm st-st-sticking with it. ;-)

Steve Thompson



On 6/6/2023 12:36 PM, Lopez, Sharon wrote:

It's finally working!  Would love to know what happened.

Thanks to everyone that replied.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, June 6, 2023 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any one having issues accessing SERVICELINK

It's still not working for me, nor others on my team.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get&search=markjacobs@protonmail.com__;!!JT0xjr86ZxPthq8!vYLwK64EcczE4bVP14-bpdiWsClnEpMuM9-TAiXM6fEsz59DIyqGDKkKZP_HGMy7XazMGYJZI9M4D0dYPfVp1YCD69_1N_bp2jIZ$


--- Original Message ---
On Tuesday, June 6th, 2023 at 10:43 AM, Michael Babcock  
wrote:



Nope, just tried. Got an authorization error.

On Tue, Jun 6, 2023 at 9:07 AM Lopez, Sharon <
038467b8de97-dmarc-requ...@listserv.ua.edu> wrote:


I'm reposting. Can others check and see if you can get on to SERVICELINK?

Thank you.
Sharon Lopez

-Original Message-
From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
Behalf Of Lopez, Sharon
Sent: Monday, June 5, 2023 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Any one having issues accessing SERVICELINK

Thank you.

The information transmitted is intended solely for the individual or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of or taking action in reliance upon this information by
persons or entities other than the intended recipient is prohibited.
If you have received this email in error please contact the sender
and delete the material from any computer.


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

The information transmitted is intended solely for the individual or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of or taking action in reliance upon this information by
persons or entities other than the intended recipient is prohibited.
If you have received this email in error please contact the sender
and delete the material from any computer.


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


The information transmitted is intended solely for the individual or entity to 
which it is addressed and may contain confidential and/or privileged material. 
Any review, retransmission, dissemination or other use of or taking action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you have received this email in error please 
contact the sender and delete the material from any computer.

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


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

Re: Best practice for /etc and /var when upgrading

[Pew, Curtis G]

Thanks to everyone who has replied. I’m saving your responses for the meeting 
we’re having with the service provider’s management on Friday. (This was far 
from the only issue we had with the upgrade.)


On Jun 6, 2023, at 11:01 AM, Mark Zelden 
mailto:m...@mzelden.com>> wrote:

No service ever hits /etc or /var.  They are not SMP/E targets.  The 
distributed /etc
can be thought of being like IPO1.PARMLIB from serverpac.

--
Curtis Pew
ITS Campus Solutions
curtis@austin.utexas.edu




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

Re: z/OS 3.1: Now UNIX® Certified

[Gord Tomlin]

On 2023-06-06 12:02 PM, Paul Gilmartin wrote:

A couple of additional problems you can encounter:
- code that ASSumes that lower case alphabetic characters collate
   higher than upper case alphabetic characters;
- code that ASSumes that all lower case alphabetic characters
   are in a contiguous range of hex values (similar for upper case);
- code that ASSumes that digits collate lower than alphabetic
   characters.


Does the Enhanced ASCII support cover all those problems?
Have you a counterexampl?


Some years ago, I was investigating porting a well-known database
package that shall remain nameless to z/OS USS, and found that the code
had a lot of the above.


Did you compile it in Enhanced ASCII mode?  Were the data EBCDIC or ASCII?


The key phrase above is "I was investigating porting". I didn't actually 
do the port. Had I done the port, the data that the database would have 
been handling would have been EBCDIC (yeah, I don't love EBCDIC either, 
but when in Rome...). I decided the dog smelled bad, so I didn't adopt it.


I don't think Enhanced ASCII would do anything for any of the problems I 
listed. On the other hand, one could use functions such as isalpha(), 
islower() and isdigit() to automatically do things properly.


This are the sort of thing I am referring to:

   if (mychar >= 'a' && mychar <= 'z') {
  do something based on mychar being lower case alphabetic;
   }

This fails on EBCDIC data because there are characters that are not 
alphabetic characters between 'a' and 'z'.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Kafka

[Frank Swarbrick]

Does anyone publish messages to Kafka from z/OS?  If so, what technology do you 
use?

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

Re: z/OS 3.1: Now UNIX® Certified

[Paul Gilmartin]

On Tue, 6 Jun 2023 15:19:02 -0400, Gord Tomlin wrote:
>
>This are the sort of thing I am referring to:
>
>if (mychar >= 'a' && mychar <= 'z') {
>   do something based on mychar being lower case alphabetic;
>}
>
>This fails on EBCDIC data because there are characters that are not
>alphabetic characters between 'a' and 'z'.
>
If your file is tagged EBCDIC auto conversion should deal with that.

And strcoll() provides more help.

But DFSORT doesn't understand "PARM='LOCALE=EN_US'".

-- 
gil

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

Re: Problems with IBM Software Download Servers Change

[Mark Jacobs]

I just tried an order. My HTTPS connection failed with a certificate error. 
I'll check again in the morning.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


--- Original Message ---
On Monday, June 5th, 2023 at 4:41 PM, Mark Zelden  wrote:


> On Mon, 5 Jun 2023 13:21:01 -0700, Lizette Koehler stars...@mindspring.com 
> wrote:
> 
> > I get that often
> > 
> > I open a Case to SMP/e support. They can usually let me know what is wrong
> > 
> > A couple of times I had to update my NTS Batch job from
> > 
> > eccgw01.boulder.ibm.com
> > 
> > To
> > ecggw.southdata.ibm.com
> > 
> > lizette
> 
> 
> Those are actually the same servers (one is an alias DNS record). It was the 
> deliver servers
> 
> deliverycb-bld.dhe.ibm.com
> deliverycb-mul.dhe.ibm.com
> 
> 
> https://www.ibm.com/support/pages/node/6997317?myns=z000&mynp=OCSWG90&mync=E&cm_sp=z000-_-OCSWG90-_-E
> 
> Opening a case was my next step, but I figured I see other's with the same 
> problem here.
> 
> Anyway, don't bother testing or seeing if it works because IBM just fixed it 
> in the last
> 5 minutes. I've been running tests every 15 minutes all day...
> 
> 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: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://search390.techtarget.com/ateExperts/
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Kafka

[David Crayford]

On 7/6/2023 4:00 am, Frank Swarbrick wrote:

Does anyone publish messages to Kafka from z/OS?


Yes https://www.ibm.com/docs/en/om-im/5.6.0?topic=introduction-architecture



If so, what technology do you use?


We use a combination of technologies in our core product. We utilize the 
Java Producer API and have implemented the librdkafka library, along 
with a CELQPIPI bridge for calling it from Metal/C (HLASM). 
Additionally, we employ Python for developing test harnesses. While 
Kafka can run on z/OS, we deploy it on a k8s cluster running on Linux 
VMs for better performance. Linux offers advantages such as faster 
execution due to zero-copy optimization, which is not available in USS.


Kafka is a remarkable technology widely adopted by mainframe sites. It 
empowers the creation of an event-driven architecture, leveraging Apache 
Kafka as the central nervous system. This architecture enables 
applications to communicate through events, which represent significant 
occurrences or updates in the system.


Within this architecture, Kafka serves as a scalable and fault-tolerant 
event streaming platform. Producers generate events and publish them to 
Kafka topics, while consumers subscribe to topics and asynchronously 
consume the events. This decoupled communication allows for the 
independent evolution of components and real-time processing of events.


The benefits of Kafka event-driven architecture include loose coupling 
between components, real-time processing and analysis capabilities, and 
fault tolerance through durable event storage. It finds diverse 
applications in microservices, data integration, real-time analytics, 
and event-driven systems. Overall, it provides a scalable and flexible 
foundation for building responsive and high-volume systems.


Kafka is a batch killer! Down here in Australia the government created a 
new payments platform using the concept of a payID (email address, phone 
number etc) to processe payments and transfers in real time. All the 
banks used Kafka as the core technology along with CDC solutions running 
on z/OS. Real-time settlements are becoming a must for the banks. Nobody 
wants to wait for overnight batch to process settlements.


Kafka offers more than just being a message broker like MQ. It includes 
powerful features like the Streams API and ksqlDB.


Kafka Streams is a client library in Apache Kafka for building real-time 
stream processing applications. It allows developers to process and 
transform data streams directly within the Kafka ecosystem, without 
external dependencies.


Key features of Kafka Streams include stream processing with operations 
like filtering, mapping, aggregating, and joining; support for stateful 
processing and exactly-once processing semantics; interactive queries to 
access state stores; seamless integration with the Kafka ecosystem; and 
scalability and fault tolerance through distributed coordination. One 
popular use case for Kafka Streams is anomaly detection


ksqlDB is an open-source event streaming database that integrates with 
Apache Kafka, providing a SQL-like query language for real-time stream 
processing. It supports time windows for partitioning and analyzing 
streaming data based on specific intervals. With sliding, tumbling, and 
hopping windows, you can capture events within these intervals.


By using time windows in ksqlDB, you can perform calculations, 
aggregations, filters, and joins on data within defined time intervals. 
This enables real-time trend monitoring, analysis of data in discrete 
segments, and capturing events that span multiple windows.


ksqlDB also offers materialized views, which are precomputed and 
continuously updated views derived from one or more streams or tables. 
Materialized views improve query performance by avoiding redundant 
calculations and joins, particularly useful for frequently accessed data.


Leveraging time windows and materialized views in ksqlDB empowers 
real-time analytics, pattern identification, and data-driven 
decision-making based on time-related criteria within your streaming 
data. It serves as a powerful SQL engine built on top of the Kafka 
Streams API.


One compelling use case to explore is the modernization of a performance 
analyzer product. The current solution relies on batch processing, where 
customers schedule jobs to read SMF records, perform aggregations using 
time windows, and generate reports with metrics like MIN, MAX, AVG, 
STDDEV, and more. To investigate outliers, customers can run list 
reports to examine individual transactions. It may take several hours 
before problems are detected.


By leveraging the capabilities of ksqlDB and a real-time SMF stream, we 
can greatly simplify this process. With a SQL query utilizing time 
windows and aggregate functions, we can conduct real-time analysis on 
the streaming data, promptly detect outliers, and emit anomalies to a 
dedicated topic. These anomalies can then be processed by a service

Re: Best practice for /etc and /var when upgrading

[kekronbekron]

Consider, for example, you upgrade from Ubuntu 20.04 to 22.04, and have updated 
the sudoers file.
When upgrading, you get a prompt showing a diff between the new version and 
your customized version.

And quoting a bit from your reply...
> compare the distributed /etc to what you already have to see if possible 
> other changes
may be desired. 

"compare the..."

Normal diff, git diff... 

/untouched/etc/
/custom/etc

(git) diff against both to see what we customized.
create a patch

/new-untouched/etc/
/new-custom/etc/

Here, I'm saying /new-custom/etc/ can be created by doing a git apply of the 
patch from earlier.

I mean... creating patches is quite common to keep just the delta, on a 
version-controlled repository.

If it still doesn't make sense, it would be good to correct my understanding... 
without being pointed to the git website :)

- KB

--- Original Message ---
On Tuesday, June 6th, 2023 at 9:29 PM, Mark Zelden  wrote:


> On Tue, 6 Jun 2023 03:15:46 +, kekronbekron kekronbek...@protonmail.com 
> wrote:
> 
> > I do wonder... with git now available, and this being normal USS, maybe 
> > zOSMF can start formally adopting/requiring git.
> > Then, moving updates from these files onto newer versions is a matter of 
> > applying git patches on the new ones, where possible.
> > Something that the zOSMF UI can accomodate.
> > 
> > Do let me know if this doesn't make sense lol.
> 
> 
> No, that makes no sense. Think of /etc as the SYS1.PARMLIB for z/OS Unix. Any 
> customization to
> existing files should not be touched. That is why it only makes sense to copy 
> what's new into it
> and also compare the distributed /etc to what you already have to see if 
> possible other changes
> may be desired. I can't think of many required changes of the years but when 
> there are
> they are (or should be) in the migration manual or upgrade workflow for 
> current versions.
> 
> 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: http://www.mzelden.com/mvsutil.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Best practice for /etc and /var when upgrading

[Mark Zelden]

I don't know git so I can't really comment.  I did google gif diff and see what 
you mean
now by a patch.  

For one, it seems like overkill.  Two, I don't have git diff on z/OS so somehow 
I'd have to
get all my existing /etc (and /var) out there to compare what IBM would put out 
there
that matches the /etc (and /var) you get with a new OS?  

To go back to my parmlib example, why would I need to compare IPO1.PARMLIB 
sample 
members to my running parmlib members from a system I'm about to upprade.  
The LNKLST, APF, SVCs, etc are are locally customized for my running system.  
However, if 
a new sample member was introduced that could be used if I implemented some new
feature, then it may be nice to have that sample in my running parmlib with the
"merge" process or "IEBCOPY, no replace" if you will.  :) 

Not really a good comparison because in this scenario the new parmlib member 
would be put
in the SMP/E target IBM.PARMLIB or in SAMPLIB, but it is the best I could come 
up with
right now.  

BTW, A better approach to what the OP said happened in his upgrade (done by some
3rd party) is to not touch it at all and just use your existing /etc and /var 
for your OS
upgrade or a copy of it with documented required changes from the upgrade 
workflow,
just like you would handle required parmlib changes.  

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: http://www.mzelden.com/mvsutil.html


On Wed, 7 Jun 2023 01:53:40 +, kekronbekron  
wrote:

>Consider, for example, you upgrade from Ubuntu 20.04 to 22.04, and have 
>updated the sudoers file.
>When upgrading, you get a prompt showing a diff between the new version and 
>your customized version.
>
>And quoting a bit from your reply...
>> compare the distributed /etc to what you already have to see if possible 
>> other changes
>may be desired. 
>
>"compare the..."
>
>Normal diff, git diff... 
>
>/untouched/etc/
>/custom/etc
>
>(git) diff against both to see what we customized.
>create a patch
>
>/new-untouched/etc/
>/new-custom/etc/
>
>Here, I'm saying /new-custom/etc/ can be created by doing a git apply of the 
>patch from earlier.
>
>I mean... creating patches is quite common to keep just the delta, on a 
>version-controlled repository.
>
>If it still doesn't make sense, it would be good to correct my 
>understanding... without being pointed to the git website :)
>
>- KB
>
>--- Original Message ---
>On Tuesday, June 6th, 2023 at 9:29 PM, Mark Zelden  wrote:
>
>
>> On Tue, 6 Jun 2023 03:15:46 +, kekronbekron kekronbek...@protonmail.com 
>> wrote:
>> 
>> > I do wonder... with git now available, and this being normal USS, maybe 
>> > zOSMF can start formally adopting/requiring git.
>> > Then, moving updates from these files onto newer versions is a matter of 
>> > applying git patches on the new ones, where possible.
>> > Something that the zOSMF UI can accomodate.
>> > 
>> > Do let me know if this doesn't make sense lol.
>> 
>> 
>> No, that makes no sense. Think of /etc as the SYS1.PARMLIB for z/OS Unix. 
>> Any customization to
>> existing files should not be touched. That is why it only makes sense to 
>> copy what's new into it
>> and also compare the distributed /etc to what you already have to see if 
>> possible other changes
>> may be desired. I can't think of many required changes of the years but when 
>> there are
>> they are (or should be) in the migration manual or upgrade workflow for 
>> current versions.
>> 
>> 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: http://www.mzelden.com/mvsutil.html
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Best practice for /etc and /var when upgrading

[kekronbekron]

Integrating git is not something we as customers need to take on ourselves (for 
system upgrade workflows like this).
It's something best given in a polished manner by IBM, as a part of zOSMF.
And again, getting git ourself is another thing; so the suggestion on IBM 
establishing a dependency on git (ex: for zOSMF's use) and working backwards up 
to what is required.
Of course, they can choose IBM zOS Change tracker, but it's not free, and is 
yet another thing to learn.
As long as there's a solution that hides the complexities and delivers the 
niceness in an interface, that'll be the way to go.

CA's Mainframe/Chorus Software Manager was ahead of its time.
It or zOSMF needs to be far, far better today than CSM was years ago.

- KB

--- Original Message ---
On Wednesday, June 7th, 2023 at 7:56 AM, Mark Zelden  wrote:


> I don't know git so I can't really comment. I did google gif diff and see 
> what you mean
> now by a patch.
> 
> For one, it seems like overkill. Two, I don't have git diff on z/OS so 
> somehow I'd have to
> get all my existing /etc (and /var) out there to compare what IBM would put 
> out there
> that matches the /etc (and /var) you get with a new OS?
> 
> To go back to my parmlib example, why would I need to compare IPO1.PARMLIB 
> sample
> members to my running parmlib members from a system I'm about to upprade.
> The LNKLST, APF, SVCs, etc are are locally customized for my running system. 
> However, if
> a new sample member was introduced that could be used if I implemented some 
> new
> feature, then it may be nice to have that sample in my running parmlib with 
> the
> "merge" process or "IEBCOPY, no replace" if you will. :)
> 
> Not really a good comparison because in this scenario the new parmlib member 
> would be put
> in the SMP/E target IBM.PARMLIB or in SAMPLIB, but it is the best I could 
> come up with
> right now.
> 
> BTW, A better approach to what the OP said happened in his upgrade (done by 
> some
> 3rd party) is to not touch it at all and just use your existing /etc and /var 
> for your OS
> upgrade or a copy of it with documented required changes from the upgrade 
> workflow,
> just like you would handle required parmlib changes.
> 
> 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: http://www.mzelden.com/mvsutil.html
> 
> 
> On Wed, 7 Jun 2023 01:53:40 +, kekronbekron kekronbek...@protonmail.com 
> wrote:
> 
> > Consider, for example, you upgrade from Ubuntu 20.04 to 22.04, and have 
> > updated the sudoers file.
> > When upgrading, you get a prompt showing a diff between the new version and 
> > your customized version.
> > 
> > And quoting a bit from your reply...
> > 
> > > compare the distributed /etc to what you already have to see if possible 
> > > other changes
> > > may be desired.
> > 
> > "compare the..."
> > 
> > Normal diff, git diff...
> > 
> > /untouched/etc/
> > /custom/etc
> > 
> > (git) diff against both to see what we customized.
> > create a patch
> > 
> > /new-untouched/etc/
> > /new-custom/etc/
> > 
> > Here, I'm saying /new-custom/etc/ can be created by doing a git apply of 
> > the patch from earlier.
> > 
> > I mean... creating patches is quite common to keep just the delta, on a 
> > version-controlled repository.
> > 
> > If it still doesn't make sense, it would be good to correct my 
> > understanding... without being pointed to the git website :)
> > 
> > - KB
> > 
> > --- Original Message ---
> > On Tuesday, June 6th, 2023 at 9:29 PM, Mark Zelden m...@mzelden.com wrote:
> > 
> > > On Tue, 6 Jun 2023 03:15:46 +, kekronbekron 
> > > kekronbek...@protonmail.com wrote:
> > > 
> > > > I do wonder... with git now available, and this being normal USS, maybe 
> > > > zOSMF can start formally adopting/requiring git.
> > > > Then, moving updates from these files onto newer versions is a matter 
> > > > of applying git patches on the new ones, where possible.
> > > > Something that the zOSMF UI can accomodate.
> > > > 
> > > > Do let me know if this doesn't make sense lol.
> > > 
> > > No, that makes no sense. Think of /etc as the SYS1.PARMLIB for z/OS Unix. 
> > > Any customization to
> > > existing files should not be touched. That is why it only makes sense to 
> > > copy what's new into it
> > > and also compare the distributed /etc to what you already have to see if 
> > > possible other changes
> > > may be desired. I can't think of many required changes of the years but 
> > > when there are
> > > they are (or should be) in the migration manual or upgrade workflow for 
> > > current versions.
> > > 
> > > 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: http://www.mzelden.com/mvsutil.html
> > > 
> > > --

Re: Best practice for /etc and /var when upgrading

[Gibney, Dave]

On occasion, I tried the USS diff to evaluate my running /etc against a new 
serverpac version. And sometimes to compare the previous serverpac version with 
 the new one.

The utility of this exercise varied. 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of kekronbekron
> Sent: Tuesday, June 6, 2023 7:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Best practice for /etc and /var when upgrading
> 
> Integrating git is not something we as customers need to take on ourselves
> (for system upgrade workflows like this).
> It's something best given in a polished manner by IBM, as a part of zOSMF.
> And again, getting git ourself is another thing; so the suggestion on IBM
> establishing a dependency on git (ex: for zOSMF's use) and working backwards
> up to what is required.
> Of course, they can choose IBM zOS Change tracker, but it's not free, and is 
> yet
> another thing to learn.
> As long as there's a solution that hides the complexities and delivers the
> niceness in an interface, that'll be the way to go.
> 
> CA's Mainframe/Chorus Software Manager was ahead of its time.
> It or zOSMF needs to be far, far better today than CSM was years ago.
> 
> - KB
> 
> --- Original Message ---
> On Wednesday, June 7th, 2023 at 7:56 AM, Mark Zelden
>  wrote:
> 
> 
> > I don't know git so I can't really comment. I did google gif diff and see 
> > what
> you mean
> > now by a patch.
> >
> > For one, it seems like overkill. Two, I don't have git diff on z/OS so 
> > somehow
> I'd have to
> > get all my existing /etc (and /var) out there to compare what IBM would put
> out there
> > that matches the /etc (and /var) you get with a new OS?
> >
> > To go back to my parmlib example, why would I need to compare
> IPO1.PARMLIB sample
> > members to my running parmlib members from a system I'm about to
> upprade.
> > The LNKLST, APF, SVCs, etc are are locally customized for my running system.
> However, if
> > a new sample member was introduced that could be used if I implemented
> some new
> > feature, then it may be nice to have that sample in my running parmlib with
> the
> > "merge" process or "IEBCOPY, no replace" if you will. :)
> >
> > Not really a good comparison because in this scenario the new parmlib
> member would be put
> > in the SMP/E target IBM.PARMLIB or in SAMPLIB, but it is the best I could
> come up with
> > right now.
> >
> > BTW, A better approach to what the OP said happened in his upgrade (done
> by some
> > 3rd party) is to not touch it at all and just use your existing /etc and 
> > /var for
> your OS
> > upgrade or a copy of it with documented required changes from the upgrade
> workflow,
> > just like you would handle required parmlib changes.
> >
> > 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.ht
> ml__%3B!!JmPEgBY0HMszNaDT!pk5HXJWpgjdGm1ZKxIR0jXpfieiYVx5kXcbXxI
> juUxrbI5Q96ZNuTbnMoBubxwv4x6Hh483-
> uHawPpVeYyZWlAbrCog_VLTF%24&data=05%7C01%7CGIBNEY%40WSU.ED
> U%7C503456fbfcbe4365386708db67000c1a%7Cb52be471f7f147b4a8790
> c799bb53db5%7C0%7C0%7C638217022129812477%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u1zF6wTztHDEhj1jeBW4YCupjk
> 1DpKQjwtgLZgrRxFI%3D&reserved=0
> >
> >
> > On Wed, 7 Jun 2023 01:53:40 +, kekronbekron
> kekronbek...@protonmail.com wrote:
> >
> > > Consider, for example, you upgrade from Ubuntu 20.04 to 22.04, and
> have updated the sudoers file.
> > > When upgrading, you get a prompt showing a diff between the new
> version and your customized version.
> > >
> > > And quoting a bit from your reply...
> > >
> > > > compare the distributed /etc to what you already have to see if possible
> other changes
> > > > may be desired.
> > >
> > > "compare the..."
> > >
> > > Normal diff, git diff...
> > >
> > > /untouched/etc/
> > > /custom/etc
> > >
> > > (git) diff against both to see what we customized.
> > > create a patch
> > >
> > > /new-untouched/etc/
> > > /new-custom/etc/
> > >
> > > Here, I'm saying /new-custom/etc/ can be created by doing a git apply of
> the patch from earlier.
> > >
> > > I mean... creating patches is quite common to keep just the delta, on a
> version-controlled repository.
> > >
> > > If it still doesn't make sense, it would be good to correct my
> understanding... without being pointed to the git website :)
> > >
> > > - KB
> > >
> > > --- Original Message ---
> > > On Tuesday, June 6th, 2023 at 9:29 PM, Mark Zelden
> m...@mzelden.com wrote:
> > >
> > > > On Tue, 6 Jun 2023 03:15:46 +, kekronbekron
> kekronbek...@protonmail.com wrote:
> > > >
> > > > > I do wonder... with git now available, and this being normal USS, 
> > > > > maybe
> zOSMF can start f

Re: Best practice for /etc and /var when upgrading

[kekronbekron]

True, which is why a colourized and visually easy interface to viewing the diff 
(like the diff view in GitHub or JetBrains IDEs) is important to make its use a 
lot easier.

- KB

--- Original Message ---
On Wednesday, June 7th, 2023 at 9:15 AM, Gibney, Dave 
<03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:


> On occasion, I tried the USS diff to evaluate my running /etc against a new 
> serverpac version. And sometimes to compare the previous serverpac version 
> with the new one.
> 
> The utility of this exercise varied.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> > Behalf Of kekronbekron
> > Sent: Tuesday, June 6, 2023 7:36 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Best practice for /etc and /var when upgrading
> > 
> > Integrating git is not something we as customers need to take on ourselves
> > (for system upgrade workflows like this).
> > It's something best given in a polished manner by IBM, as a part of zOSMF.
> > And again, getting git ourself is another thing; so the suggestion on IBM
> > establishing a dependency on git (ex: for zOSMF's use) and working backwards
> > up to what is required.
> > Of course, they can choose IBM zOS Change tracker, but it's not free, and 
> > is yet
> > another thing to learn.
> > As long as there's a solution that hides the complexities and delivers the
> > niceness in an interface, that'll be the way to go.
> > 
> > CA's Mainframe/Chorus Software Manager was ahead of its time.
> > It or zOSMF needs to be far, far better today than CSM was years ago.
> > 
> > - KB
> > 
> > --- Original Message ---
> > On Wednesday, June 7th, 2023 at 7:56 AM, Mark Zelden
> > m...@mzelden.com wrote:
> > 
> > > I don't know git so I can't really comment. I did google gif diff and see 
> > > what
> > > you mean
> > > now by a patch.
> > > 
> > > For one, it seems like overkill. Two, I don't have git diff on z/OS so 
> > > somehow
> > > I'd have to
> > > get all my existing /etc (and /var) out there to compare what IBM would 
> > > put
> > > out there
> > > that matches the /etc (and /var) you get with a new OS?
> > > 
> > > To go back to my parmlib example, why would I need to compare
> > > IPO1.PARMLIB sample
> > > members to my running parmlib members from a system I'm about to
> > > upprade.
> > > The LNKLST, APF, SVCs, etc are are locally customized for my running 
> > > system.
> > > However, if
> > > a new sample member was introduced that could be used if I implemented
> > > some new
> > > feature, then it may be nice to have that sample in my running parmlib 
> > > with
> > > the
> > > "merge" process or "IEBCOPY, no replace" if you will. :)
> > > 
> > > Not really a good comparison because in this scenario the new parmlib
> > > member would be put
> > > in the SMP/E target IBM.PARMLIB or in SAMPLIB, but it is the best I could
> > > come up with
> > > right now.
> > > 
> > > BTW, A better approach to what the OP said happened in his upgrade (done
> > > by some
> > > 3rd party) is to not touch it at all and just use your existing /etc and 
> > > /var for
> > > your OS
> > > upgrade or a copy of it with documented required changes from the upgrade
> > > workflow,
> > > just like you would handle required parmlib changes.
> > > 
> > > 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> > > efense.com%2Fv3%2F__http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.ht
> > > ml__%3B!!JmPEgBY0HMszNaDT!pk5HXJWpgjdGm1ZKxIR0jXpfieiYVx5kXcbXxI
> > > juUxrbI5Q96ZNuTbnMoBubxwv4x6Hh483-
> > > uHawPpVeYyZWlAbrCog_VLTF%24&data=05%7C01%7CGIBNEY%40WSU.ED
> > > U%7C503456fbfcbe4365386708db67000c1a%7Cb52be471f7f147b4a8790
> > > c799bb53db5%7C0%7C0%7C638217022129812477%7CUnknown%7CTWF
> > > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u1zF6wTztHDEhj1jeBW4YCupjk
> > > 1DpKQjwtgLZgrRxFI%3D&reserved=0
> > > 
> > > On Wed, 7 Jun 2023 01:53:40 +, kekronbekron
> > > kekronbek...@protonmail.com wrote:
> > > 
> > > > Consider, for example, you upgrade from Ubuntu 20.04 to 22.04, and
> > > > have updated the sudoers file.
> > > > When upgrading, you get a prompt showing a diff between the new
> > > > version and your customized version.
> > > > 
> > > > And quoting a bit from your reply...
> > > > 
> > > > > compare the distributed /etc to what you already have to see if 
> > > > > possible
> > > > > other changes
> > > > > may be desired.
> > > > 
> > > > "compare the..."
> > > > 
> > > > Normal diff, git diff...
> > > > 
> > > > /untouched/etc/
> > > > /custom/etc
> > > > 
> > > > (git) diff against both to see what we customized.
> > > > create a patch
> > > > 
> > > > /new-untouched/etc/
> > > > /new-custom/etc/
> > > > 
> > > > Here, I'm 

Routing HMC message

[Peter]

Hello

Is it possible to route HMC operating system message and download them as
text file to the desktop?

Right now we are in the situation where TCPIP IP is not reachable but I
just wanted go through all the messages loaded during IPL.

Peter

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