Re: Enterprise Cobol 6.3.0, XML PARSE and zIIP usage.

[Timothy Sipples]

Is the XML processing you're doing in your test program "trivial," thus z/OS 
correctly decided it wasn't worth even attempting a switch to dispatch the work 
to your zIIP engine?

If my guess seems reasonable are you able to run the test with a bigger XML 
input file?

— — — — —
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: Minor disaster

[Lennie Dymoke-Bradshaw]

Good idea.
Now, how to train my fingers to know what my head knows?
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Wayne Bickerdike
Sent: 29 September 2022 21:48
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Minor disaster

I would recommend that the OP always use the '/' command instead of 'S'.
Given that S and D are co-located on the keyboard and / is far away.

On Thu, Sep 29, 2022 at 10:49 PM Lionel B. Dyck  wrote:

> The issue of how to deal with PDSE member generations is one that I 
> struggled with when developing PDSEGEN. The solution that I came up 
> with was to allow individual generations to be deleted, which required 
> writing a routine to do so as the native TSO DELETE and ISPF Delete 
> options would only delete the base member without the generations at 
> the time.
>
> With PDSEGEN you always see a member list with the base member and all 
> generations.
>
> With PDSEGEN you can delete the base member with a prompt informing 
> you that you are deleting the base and all generations, or you can 
> delete base member and have the -1 promoted to be the new base.
>
> Note that once a generation is deleted that you may not recover it due 
> to the way the PDSE data store is architected. That is both good 
> (never having to compress) and bad (inability to recover a deleted 
> element). However, I believe this was the right decision by the developers.
>
> Now if only the standard ISPF application had these capabilities.
>
> Lionel B. Dyck <><
> Website: https://www.lbdsoftware.com
> Github: https://github.com/lbdyck
>
> “Worry more about your character than your reputation. Character is 
> what you
> are, reputation merely what others think you are.”   - - - John Wooden
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Wayne V. Bickerdike

--
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: SYSPLEX / SYSNAME / SMFID stability

[Ed Jaffe]

On 9/29/2022 5:19 AM, Mark A. Brooks wrote:

Right, I'm not aware of a UUID for a z/OS system.
Every system in a given sysplex must have a unique name.  In that sense 
SysplexName.SystemName might do the trick.  But ...
Sysplex names are not necessarily unique -- test sysplex or DR site could be 
using the same name.


In our case, the D/R sysplex *and* system names are all the same.

The only way we can tell them apart is by CPC Type/Serial.

We have a REXX call WHEREAMI that inspects CPC Type/Serial in the PCCA 
and let's you know where you are.


Of course, serial numbers can faked under z/VM, but we don't do that...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: SYSPLEX / SYSNAME / SMFID stability

[Matt Hogstrom]

> 
On Sep 29, 2022, at 8:19 AM, Mark A. Brooks  wrote:
> 
> Right, I'm not aware of a UUID for a z/OS system.
> Every system in a given sysplex must have a unique name.  In that sense 
> SysplexName.SystemName might do the trick.  But ...
> Sysplex names are not necessarily unique -- test sysplex or DR site could be 
> using the same name.

I wasn’t too worried about DR but that is a good point.  I think the best bet 
is to document the requirement for unique SYSPLEX names and let that be the 
high level qualifier as it were.  I figured for service providers they would 
have some tenant ID for their customer but that’s just meta-data.  Thanks for 
the input.


Matt Hogstrom

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom


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

Re: Minor disaster

[Wayne Bickerdike]

I would recommend that the OP always use the '/' command instead of 'S'.
Given that S and D are co-located on the keyboard and / is far away.

On Thu, Sep 29, 2022 at 10:49 PM Lionel B. Dyck  wrote:

> The issue of how to deal with PDSE member generations is one that I
> struggled with when developing PDSEGEN. The solution that I came up with
> was
> to allow individual generations to be deleted, which required writing a
> routine to do so as the native TSO DELETE and ISPF Delete options would
> only
> delete the base member without the generations at the time.
>
> With PDSEGEN you always see a member list with the base member and all
> generations.
>
> With PDSEGEN you can delete the base member with a prompt informing you
> that
> you are deleting the base and all generations, or you can delete base
> member
> and have the -1 promoted to be the new base.
>
> Note that once a generation is deleted that you may not recover it due to
> the way the PDSE data store is architected. That is both good (never having
> to compress) and bad (inability to recover a deleted element). However, I
> believe this was the right decision by the developers.
>
> Now if only the standard ISPF application had these capabilities.
>
> Lionel B. Dyck <><
> Website: https://www.lbdsoftware.com
> Github: https://github.com/lbdyck
>
> “Worry more about your character than your reputation. Character is what
> you
> are, reputation merely what others think you are.”   - - - John Wooden
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: Unix System Services migration

[Brian Chapman]

Carmen/ Shmuel,

Thank you. I will review these reference manuals.



Thank you,

Brian Chapman


On Thu, Sep 29, 2022 at 9:19 AM Carmen Vitullo  wrote:

> that's a better reference - I have a PDF saved on my work PC somewhere,
> but this looks about the same
>
> Carmen
>
> On 9/29/2022 8:05 AM, Seymour J Metz wrote:
> > See "Chapter 7. Sharing file systems in a sysplex" in z/OS 2.5 UNIX
> System Services Planning, GA32-0884-50.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Brian Chapman [bchapma...@gmail.com]
> > Sent: Thursday, September 29, 2022 8:54 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Unix System Services migration
> >
> > How are most shops handling USS management and migration?
> >
> > For many years, there has been a strong sentiment in my shop against
> > utilizing USS (security and scalability were always cited as the primary
> > reasons) and we were only allowed to utilize USS with IBM and ISV
> software
> > installs. Things are changing and now there is a strong push to change
> our
> > culture around USS. However, we are greatly behind with the times and
> > inexperienced with best management practices regarding USS migrations.
> >
> > I'm sure our shop isn't the only site with a similar configuration, but
> we
> > have multiple systems for development lifecycles (alpha testing on SYSA
> and
> > SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate
> > dataset mounts for each system, this makes sharing common resources
> across
> > the same lifecycle environment impossible; unless it is read-only (but
> how
> > do you update the file system without an outage?). Is there some sort of
> > management practice that we're missing to achieve the ability to leverage
> > common resources in USS?
> >
> > Also, how do you handle migration? Our shop uses CA Endevor. Do you
> employ
> > your change management software with USS migrations? If so, how do you
> copy
> > directories/folders without outages? For directories/files that can
> easily
> > be built with jobs, do you re-run these jobs on each system, or copy
> these
> > elements?
> >
> >
> >
> >
> > Thank you,
> >
> > Brian Chapman
> >
> > --
> > 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: EXTERNAL: Unix System Services migration [Internal]

[Usher, Darrold]

I can't speak to the application development approach much, but I can speak to 
the infrastructure since we have been using USS for many components for many 
years. It lends itself to a sysplex quite well in terms of integrity and 
sharing provided you have the filesystems set-up appropriately. Please see IBM 
USS planning guides for details.

Darrold

Classification: Internal



Disclaimer: This email and any attachments are the property of USAA and may 
contain confidential and/or privileged material. If you are not the intended 
recipient, any use, disclosure or copying of this email or any attachments is 
unauthorized. If you received this email in error, please immediately notify 
the sender and delete the email and any attachments from your computer.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Chapman
Sent: Thursday, September 29, 2022 7:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Unix System Services migration

How are most shops handling USS management and migration?

For many years, there has been a strong sentiment in my shop against utilizing 
USS (security and scalability were always cited as the primary
reasons) and we were only allowed to utilize USS with IBM and ISV software 
installs. Things are changing and now there is a strong push to change our 
culture around USS. However, we are greatly behind with the times and 
inexperienced with best management practices regarding USS migrations.

I'm sure our shop isn't the only site with a similar configuration, but we have 
multiple systems for development lifecycles (alpha testing on SYSA and SYSB, 
beta testing on SYSC and SYSD, etc). Since USS requires separate dataset mounts 
for each system, this makes sharing common resources across the same lifecycle 
environment impossible; unless it is read-only (but how do you update the file 
system without an outage?). Is there some sort of management practice that 
we're missing to achieve the ability to leverage common resources in USS?

Also, how do you handle migration? Our shop uses CA Endevor. Do you employ your 
change management software with USS migrations? If so, how do you copy 
directories/folders without outages? For directories/files that can easily be 
built with jobs, do you re-run these jobs on each system, or copy these 
elements?




Thank you,

Brian Chapman

--
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/OSMF PSWI

[Michael Babcock]

We are missing two, PH45201 and PH46392.  After reading them, they don’t
really seem to match our situation unless there are things fixed that are
not doc’d.

On Thu, Sep 29, 2022 at 7:44 AM Marna WALLE  wrote:

> Michael,
> Have you verified that you have all the correct Driving System PTFs
> installed, as indicated with FIXCAT IBM.DrivingSystem-RequiredService ?.
>
> Check out slide 33 onwards in this presentation that KurtQ did for the Z
> Exchange, https://www.newera-info.com/KQ1.html.  It explains how a new
> master catalog can be used, including how the SSA (now called Temporary
> Catalog Alias) is to be specified and used.
>
> -Marna WALLE
> z/OS System Install and Upgrade
> IBM Poughkeepsie
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
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: z/OSMF PSWI

[Michael Babcock]

I’m not using a new master cat.   We use our sandbox as the driving system
and our target is our maintenance system.  We do IPL the maintenance system
just to ensure it comes up cleanly.

On Thu, Sep 29, 2022 at 7:44 AM Marna WALLE  wrote:

> Michael,
> Have you verified that you have all the correct Driving System PTFs
> installed, as indicated with FIXCAT IBM.DrivingSystem-RequiredService ?.
>
> Check out slide 33 onwards in this presentation that KurtQ did for the Z
> Exchange, https://www.newera-info.com/KQ1.html.  It explains how a new
> master catalog can be used, including how the SSA (now called Temporary
> Catalog Alias) is to be specified and used.
>
> -Marna WALLE
> z/OS System Install and Upgrade
> IBM Poughkeepsie
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
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: Unix System Services migration

[Carmen Vitullo]

that's a better reference - I have a PDF saved on my work PC somewhere, 
but this looks about the same


Carmen

On 9/29/2022 8:05 AM, Seymour J Metz wrote:

See "Chapter 7. Sharing file systems in a sysplex" in z/OS 2.5 UNIX System 
Services Planning, GA32-0884-50.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Brian Chapman [bchapma...@gmail.com]
Sent: Thursday, September 29, 2022 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unix System Services migration

How are most shops handling USS management and migration?

For many years, there has been a strong sentiment in my shop against
utilizing USS (security and scalability were always cited as the primary
reasons) and we were only allowed to utilize USS with IBM and ISV software
installs. Things are changing and now there is a strong push to change our
culture around USS. However, we are greatly behind with the times and
inexperienced with best management practices regarding USS migrations.

I'm sure our shop isn't the only site with a similar configuration, but we
have multiple systems for development lifecycles (alpha testing on SYSA and
SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate
dataset mounts for each system, this makes sharing common resources across
the same lifecycle environment impossible; unless it is read-only (but how
do you update the file system without an outage?). Is there some sort of
management practice that we're missing to achieve the ability to leverage
common resources in USS?

Also, how do you handle migration? Our shop uses CA Endevor. Do you employ
your change management software with USS migrations? If so, how do you copy
directories/folders without outages? For directories/files that can easily
be built with jobs, do you re-run these jobs on each system, or copy these
elements?




Thank you,

Brian Chapman

--
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: Unix System Services migration

[Carmen Vitullo]

For my site, I eventually setup a shared Unix filesystem, we wanted the 
ability to move workloads from system to system, or allow access to 
shared fileystems from any task, batch or ftp process.


my Serverpac filesystems that came with my order are copied to a shared 
sysplex filesystem. it took me some time to get this setup and managed 
the way we needed but it works well.


the IBM doc

Unix system services planning is where I found all the sample processes 
I needed to setup the shared filesystem and the best practice for 
parmlib and system setup


https://www.ibm.com/docs/en/zos/2.1.0?topic=sysplex-establishing-shared-file-system-in


the process will setup a sysplex root, $version root and a $system root, 
fileystems that are specific to each system are mounted at


/SYSA/local/

all version or ZOS filesystems are mounted off the sysplex root, and for 
us, filesystems that are not part of the OS $VERSION are mounted at


/PLEX1/usr/local/

I'm sure others have some great options that work for them this 
enviorment works great for me


Carmen

On 9/29/2022 7:54 AM, Brian Chapman wrote:

How are most shops handling USS management and migration?

For many years, there has been a strong sentiment in my shop against
utilizing USS (security and scalability were always cited as the primary
reasons) and we were only allowed to utilize USS with IBM and ISV software
installs. Things are changing and now there is a strong push to change our
culture around USS. However, we are greatly behind with the times and
inexperienced with best management practices regarding USS migrations.

I'm sure our shop isn't the only site with a similar configuration, but we
have multiple systems for development lifecycles (alpha testing on SYSA and
SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate
dataset mounts for each system, this makes sharing common resources across
the same lifecycle environment impossible; unless it is read-only (but how
do you update the file system without an outage?). Is there some sort of
management practice that we're missing to achieve the ability to leverage
common resources in USS?

Also, how do you handle migration? Our shop uses CA Endevor. Do you employ
your change management software with USS migrations? If so, how do you copy
directories/folders without outages? For directories/files that can easily
be built with jobs, do you re-run these jobs on each system, or copy these
elements?




Thank you,

Brian Chapman

--
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: Unix System Services migration

[Seymour J Metz]

See "Chapter 7. Sharing file systems in a sysplex" in z/OS 2.5 UNIX System 
Services Planning, GA32-0884-50.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Brian Chapman [bchapma...@gmail.com]
Sent: Thursday, September 29, 2022 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unix System Services migration

How are most shops handling USS management and migration?

For many years, there has been a strong sentiment in my shop against
utilizing USS (security and scalability were always cited as the primary
reasons) and we were only allowed to utilize USS with IBM and ISV software
installs. Things are changing and now there is a strong push to change our
culture around USS. However, we are greatly behind with the times and
inexperienced with best management practices regarding USS migrations.

I'm sure our shop isn't the only site with a similar configuration, but we
have multiple systems for development lifecycles (alpha testing on SYSA and
SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate
dataset mounts for each system, this makes sharing common resources across
the same lifecycle environment impossible; unless it is read-only (but how
do you update the file system without an outage?). Is there some sort of
management practice that we're missing to achieve the ability to leverage
common resources in USS?

Also, how do you handle migration? Our shop uses CA Endevor. Do you employ
your change management software with USS migrations? If so, how do you copy
directories/folders without outages? For directories/files that can easily
be built with jobs, do you re-run these jobs on each system, or copy these
elements?




Thank you,

Brian Chapman

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

Unix System Services migration

[Brian Chapman]

How are most shops handling USS management and migration?

For many years, there has been a strong sentiment in my shop against
utilizing USS (security and scalability were always cited as the primary
reasons) and we were only allowed to utilize USS with IBM and ISV software
installs. Things are changing and now there is a strong push to change our
culture around USS. However, we are greatly behind with the times and
inexperienced with best management practices regarding USS migrations.

I'm sure our shop isn't the only site with a similar configuration, but we
have multiple systems for development lifecycles (alpha testing on SYSA and
SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate
dataset mounts for each system, this makes sharing common resources across
the same lifecycle environment impossible; unless it is read-only (but how
do you update the file system without an outage?). Is there some sort of
management practice that we're missing to achieve the ability to leverage
common resources in USS?

Also, how do you handle migration? Our shop uses CA Endevor. Do you employ
your change management software with USS migrations? If so, how do you copy
directories/folders without outages? For directories/files that can easily
be built with jobs, do you re-run these jobs on each system, or copy these
elements?




Thank you,

Brian Chapman

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

Re: Minor disaster

[Lionel B. Dyck]

The issue of how to deal with PDSE member generations is one that I
struggled with when developing PDSEGEN. The solution that I came up with was
to allow individual generations to be deleted, which required writing a
routine to do so as the native TSO DELETE and ISPF Delete options would only
delete the base member without the generations at the time. 

With PDSEGEN you always see a member list with the base member and all
generations.

With PDSEGEN you can delete the base member with a prompt informing you that
you are deleting the base and all generations, or you can delete base member
and have the -1 promoted to be the new base.  

Note that once a generation is deleted that you may not recover it due to
the way the PDSE data store is architected. That is both good (never having
to compress) and bad (inability to recover a deleted element). However, I
believe this was the right decision by the developers.

Now if only the standard ISPF application had these capabilities.

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

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

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

Re: z/OSMF PSWI

[Marna WALLE]

Michael,
Have you verified that you have all the correct Driving System PTFs installed, 
as indicated with FIXCAT IBM.DrivingSystem-RequiredService ?.

Check out slide 33 onwards in this presentation that KurtQ did for the Z 
Exchange, https://www.newera-info.com/KQ1.html.  It explains how a new master 
catalog can be used, including how the SSA (now called Temporary Catalog Alias) 
is to be specified and used.  

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

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

Re: Minor disaster

[Seymour J Metz]

Ah, the swing, a classic from Datamation... There's also "pillage, the burn" 
from The Wizard of Id, 
https://jhs-shop.com/products/copy-of-wizard-of-id-print-pillage-then-burn.

IMHO, every working programmer should have on his door the cartoons I link to 
in http://mason.gmu.edu/~smetz3/#humor


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, September 29, 2022 7:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Minor disaster

(I'll cross-post this Reply to IBM-MAIN and ISPF-L)
On Thu, 29 Sep 2022 00:23:30 -0500, Brian Westerman  wrote:

>Wait, I missed the part where it was completely deleted.  Sorry about that.  I 
>thought it was just overwritten.
>
"completely deleted" vs. "just overwritten" seems to be a distinction without
a difference.  In either case aren't the data gone forever?

On my desktop system several applications have a File menu containing
a Revert option which displays a selection list of versions with timestamps.
ISPF designers seem to have missed the point
.

Revert should be a separate option from Delete, a distinction with a difference.
It should support PDSE2 members containing a mixture of versions created
with ISPF and with other applications.  For versions lacking ISPF timestamps
For versions lacking ISPF timestamps the selection list should show FAMS
timestamps.


>On Thu, 29 Sep 2022 00:18:45 -0500, Brian Westerman wrote:
>
>>I use PDSEGEN on z/OS 2.5 all the time and have no problem recovering old 
>>versions.
>>
>>
>>On Wed, 28 Sep 2022 07:14:17 -0500, Lionel B. Dyck wrote:
>>
>>>If these are PDSE's with generations then the question is what release of
>>>z/OS are you running?  If 2.4 then the ISPF delete member selections will
>>>delete all generations along with the base member. If 2.3 or earlier then
>>>only the base (generation 0) member is deleted and the generations will
>>>remain - just not accessible.
>>>
>>>If you are z/OS 2.3, or earlier, then you can use PDSEGEN (CBTTape file 969)
>>>to see those 'ghost' generations and easily recover them.
>>>
>>>If you are z/OS 2.4 or 2.5 then hope you have HSM backups or some other
>>>backup system.
>>>
>>>-Original Message-
>>>From:  Lennie Dymoke-Bradshaw
>>>Sent: Wednesday, September 28, 2022 7:01 AM
>>>
>>>Aaargghhh!
>>>
>>>I just pressed "D" next to a PDSe member I was editing, instead of "S".
>>>
>>>I have generations set up for this PDSe, but I cannot see how to get to the
>>>member I just accidentally deleted.
>>>
>>>Is there a way to recover the member?
>>>
>>> 
>>>  
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Frsclweb.com%2Fdata=05%7C01%7Csmetz3%40gmu.edu%7Cd5245279f5764a6b161408daa211bb43%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638000494281434185%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=T%2BrxJigpGRN0D5Zkw2YMmCNx8coaQr5IuYTj559JfQo%3Dreserved=0

--
gil

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

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

Re: SYSPLEX / SYSNAME / SMFID stability

[Mark A. Brooks]

Right, I'm not aware of a UUID for a z/OS system.
Every system in a given sysplex must have a unique name.  In that sense 
SysplexName.SystemName might do the trick.  But ...
Sysplex names are not necessarily unique -- test sysplex or DR site could be 
using the same name.

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

Re: Minor disaster

[Paul Gilmartin]

(I'll cross-post this Reply to IBM-MAIN and ISPF-L)
On Thu, 29 Sep 2022 00:23:30 -0500, Brian Westerman  wrote:

>Wait, I missed the part where it was completely deleted.  Sorry about that.  I 
>thought it was just overwritten.
>
"completely deleted" vs. "just overwritten" seems to be a distinction without
a difference.  In either case aren't the data gone forever?

On my desktop system several applications have a File menu containing
a Revert option which displays a selection list of versions with timestamps.
ISPF designers seem to have missed the point
.

Revert should be a separate option from Delete, a distinction with a difference.
It should support PDSE2 members containing a mixture of versions created
with ISPF and with other applications.  For versions lacking ISPF timestamps
For versions lacking ISPF timestamps the selection list should show FAMS
timestamps.


>On Thu, 29 Sep 2022 00:18:45 -0500, Brian Westerman wrote:
>
>>I use PDSEGEN on z/OS 2.5 all the time and have no problem recovering old 
>>versions.
>>
>>
>>On Wed, 28 Sep 2022 07:14:17 -0500, Lionel B. Dyck wrote:
>>
>>>If these are PDSE's with generations then the question is what release of
>>>z/OS are you running?  If 2.4 then the ISPF delete member selections will
>>>delete all generations along with the base member. If 2.3 or earlier then
>>>only the base (generation 0) member is deleted and the generations will
>>>remain - just not accessible.
>>>
>>>If you are z/OS 2.3, or earlier, then you can use PDSEGEN (CBTTape file 969)
>>>to see those 'ghost' generations and easily recover them.
>>>
>>>If you are z/OS 2.4 or 2.5 then hope you have HSM backups or some other
>>>backup system.
>>>
>>>-Original Message-
>>>From:  Lennie Dymoke-Bradshaw
>>>Sent: Wednesday, September 28, 2022 7:01 AM
>>>
>>>Aaargghhh!
>>>
>>>I just pressed "D" next to a PDSe member I was editing, instead of "S".
>>>
>>>I have generations set up for this PDSe, but I cannot see how to get to the
>>>member I just accidentally deleted.
>>>
>>>Is there a way to recover the member?
>>>
>>>  https://rsclweb.com 

-- 
gil

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

Re: Minor disaster

[Paul Gilmartin]

On Thu, 29 Sep 2022 06:14:31 -0500, John S. Giltner, Jr.  wrote:

>Seems you have a HSM copy.  What I do is recover/restore the HSM copy to a new 
>name and then just copy the member from recovered/restored data set to the 
>real data set.
> 
PITA in complexity.  Rather, HSM should support revert to specific
DSN(MEMBER)/Version.

And is HSM time granularity fine enough that you can revert to a
version just an hour old?  Ten minutes?

The design has two competing facilities: HSM and PDSE2.

-- 
gil

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

Re: wc3270. cipher attls

[John S. Giltner, Jr.]

I don't have a whole list, but v4.10ga10  supports at least TLS V1.2 with 
cipher TLS_RSA_WITH_AES_128_CBC_SHA, which is x'002F'.  That is what is chosen 
when I connect to our system using wc3270.

--
John Giltner

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

Re: Minor disaster

[Steve Smith]

+1 For FM's PDSE Workbench.

Too bad FM in general has the horrible policy of not only using 47
different keylists, but insisting on [re-]activating them no matter how
many times the user turns them off.  That makes using FM very frustrating
if you dare to want to control your own PF key settings.

And yeah, it seems a bit presumptive of ISPF to suddenly switch to
all-generation delete.  This is the first I've heard about it, so maybe
there's options to control this, but no one's mentioned it.

ISPF development usually is terrified of changing anything, like to allow
extended stats without jumping through ridiculous hoops.  Or show them on
member list displays.

sas

On Wed, Sep 28, 2022 at 9:15 PM Peter Van Dyke  wrote:

> FYI, IBM File Manager provides the PDSE Workbench utility which supports
> working directly with any member generation in a PDSE V2. For example, you
> can browse/view previous member generations, compare member generations and
> recover  a member from an earlier generation. This can all be done from a
> member list display. If you try to delete the current member (generation =
> 0) a confirmation panel is displayed where you have the option to either
> delete the current member and all its generations or delete the current
> member and have the most recent generation become the current member.
>
> Now wouldn't it be great to have that type of functionality available with
> the ISPF enhanced member list 
>
> Peter Van Dyke
> ex ISPF development team
>
>

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

Re: Minor disaster

[John S. Giltner, Jr.]

Seems you have a HSM copy.  What I do is recover/restore the HSM copy to a new 
name and then just copy the member from recovered/restored data set to the real 
data set.

--
John G.

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

Enterprise Cobol 6.3.0, XML PARSE and zIIP usage.

[Massimo Biancucci]

Hi everybody,

I wrote a simple test program to parse XML.
The program has been compiled with Enterprise Cobol 6.3.0 and
XMLPARSE(XMLSS) option.

I ran the program as a standard batch job and it seems it's not using zIIP
processor (one zIIP is available).
I had a look at SMF30(4) and all the "zIIP on CP" fields are zero (the same
for zAAP).
S.O. is zOS 2.4 and CEC is z15.

>From the Enterprise Cobol Customization Guide:
"
XMLSS
XML PARSE statements are processed using the z/OS XML System Services
parser. The following XML parsing capabilities are available only when this
suboption is in effect:
• Namespace processing enhancements
• The ENCODING, RETURNING NATIONAL, and VALIDATING phrases of the XML PARSE
statement
• Support for direct parsing of XML documents encoded in UTF-8
• Support for parsing very large XML documents, a buffer of XML at a time
• Offloading of XML parsing to System z® Application Assist Processors
(zAAPs)
"

On IEASYSxx there's no ZAAPZIIP parameter so, AFAIK, it should be defaulted
to YES and so zAAP needs should be accomplished by zIIP.
What am I doing wrong ?

Thanks a lot in advance.
Max

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

Re: Using DFSORT over DCOLLECT to get dataset extent number

[Jack Zukt]

Thank you Kolusu,

I am going to try it,

Best Regards,
Jack

On Wed, 28 Sept 2022 at 14:20, Sri h Kolusu  wrote:

> >> I am using OUTREC IFTHEN=(WHEN=( I have been reading the DFSORT
> Application Programming Guide but I have not been finding what I need. As
> far as I can tell, as soon as one of the IFTHEN=(WHEN is met, all the
> others are ignored. So, how do I test different positions on a INREC/OUTREC
> statement?
>
> Jack,
>
> You need to use HIT=NEXT which Specifies that IFTHEN processing should
> continue even if the logical expression is true. By default (if HIT=NEXT is
> not specified), IFTHEN processing stops if the logical expression is true.
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
> --
> 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