Re: zOS and z16

2024-04-16 Thread Allan Staller
Classification: Confidential

Nope. z/OS 2.5 is no longer orderable

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, April 16, 2024 6:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOS and z16

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

One thing that might give you problems is WLM. It might behave wonky on a z16 
processor. Is 2.5 even orderable any longer?

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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


On Tuesday, April 16th, 2024 at 5:43 AM, Grant Carson 
<0620d2720937-dmarc-requ...@listserv.ua.edu> wrote:

> Hi,
>
> We are running zVM 7.3 with zOS 2.1 under it, on a z14. We are upgrading to a 
> z16 soon - will 2.1 run on the 16 under zVM? I know that the minimum 
> supported level is 2.2 but (as I have seen asked previously with some of 
> these supported-or-not queries) does that mean it won't actually come up or 
> just isn't supported? Obviously, we haven't applied any z16 toleration (as 
> there isn't any!). We are planning an upgrade to 2.5 but that's not yet 
> ordered...
>
> Thanks
> Grant
>
> 
>
> Zellis is the trading name for Zellis Holdings Ltd and its associated 
> companies "Zellis".
>
> The contents of this email are confidential to Zellis and are solely for the 
> use of the intended recipient. If you received this email in error, please 
> inform the sender immediately and delete the email from your system. Unless 
> Zellis have given you express permission to do so, please do not disclose, 
> distribute or copy the contents of this email.
>
> Unless this email expressly states that it is a contractual offer or 
> acceptance, it is not sent with the intention of creating a legal 
> relationship and does not constitute an offer or acceptance which could give 
> rise to a contract.
>
> Any views expressed in this email are those of the individual sender unless 
> the email specifically states them to be the views of Zellis.
>
> Zellis Holdings Ltd - registered in England and Wales - Company No: 10975623 
> - Registered Office: 740 Waterside Drive, Aztec West, Almondsbury, Bristol, 
> BS32 4UF, UK.
>
> --
> 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
::DISCLAIMER::

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


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


Re: Console Address Space

2024-04-11 Thread Allan Staller
Classification: Confidential

Thast what I thought, but I was hoping. Thanks,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Fatzinger
Sent: Thursday, April 11, 2024 7:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Console Address Space

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

The Console Address Space cannot be restarted.

Peter Fatzinger
z/OS Core Design & Development

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

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


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


Re: Console Address Space

2024-04-11 Thread Allan Staller
Classification: Confidential

1) Consoles would not respond
2) Routed commands from other systems in the sysplex were ignored
3) Operating system messages on the HMC would not respond (V CN(*),ACTIVATE)
4) Integrated 3270 console was not configured in CONSOLXX

Al

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Wednesday, April 10, 2024 11:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Console Address Space

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

When you say the HMC also failed, can you describe what happened.  Did any 
messages show up at all, did you define the HMC in your console parms?  Did you 
maybe forget to just V CN(*),act?

Brian

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

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


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


Console Address Space

2024-04-10 Thread Allan Staller
Classification: Confidential
This past weekend I had an issue where a system became totally unresponsive and 
incommunicado.
HMC access also failed, and the only conclusion I can come up with, is that the 
console address space abended.

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

::DISCLAIMER::

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


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


Re: EXPDT added to newly allocated dataset

2024-04-09 Thread Allan Staller
Classification: Confidential

There are several SMS exits that could be causing this issue

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, April 9, 2024 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXPDT added to newly allocated dataset

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I have an interesting problem I'm looking at and nothing seems obvious as to 
the reason why. On two of our systems when I allocate a new SYS1 dataset, 
non-sms with no DATACLASS assigned by the ACS routines or on the allocation 
itself, when I specify UNIT=3390 it's assigned an EXPDT of today+3 days, when I 
allocate the same dataset on the same volume using UNIT=SYSDA or UNIT=SYSALLDA 
it's not given an EXPDT.

When I do the same processes on different systems in the same SYSPLEX, but in a 
different SMSPLEX, we're not observing the same EXPDT behavior, with no EXPDT 
assigned for both datasets.

Does anyone have ideas on where to look?

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com/), Swiss-based encrypted email.

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

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

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


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


Re: Program to split a jobs output

2024-04-09 Thread Allan Staller
Classification: Confidential

Several commercial products do this . CA-DELIVER, INFOPAC (probably a couple of 
more I am not familiar with.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of ??? 
?? ???
Sent: Tuesday, April 9, 2024 3:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Program to split a jobs output

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi,
Today I had to sent a jobs output to IBM to help determine a problem.
The jobs had 11 sysout datasets, and I wanted to send each one individually.

Does anyone know of a program to do this automagically, before I see how 
complicated it would be to write one?

Gadi

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

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


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


Re: What happens in HSM when I change a Management Class

2024-03-14 Thread Allan Staller
Classification: Confidential


Gadi, Mike has a good point.  Doing HSM tape recycles could help free up any 
tapes with a low number of datasets on them.  This is true for migration tapes 
and backup tapes.  Be warned that if you don't do tape recycles on a scheduled 
basis the process could possibly run for a long time.  As an example, I think 
that could then impact HSM process of recalls from tape.  I believe the place I 
last worked at did tape recycles every day


You might want to consider "sneaking up" or your eventual goal.
Let us say your goal is to eventually get to a 25% recycle percentage.
Day 1 you could do a 5% recycle, Day 2 could be a 10% recycle,

Also, you can issue a HSM RECYCLE command to find out (in advance) how many 
tapes will be included.

BTW, you can also segregate Backup and Migration recycles. By default all tapes 
(Backup and Migration) are included with Migration being processed first.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Feller
Sent: Wednesday, March 13, 2024 4:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What happens in HSM when I change a Management Class

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Gadi, Mike has a good point.  Doing HSM tape recycles could help free up any 
tapes with a low number of datasets on them.  This is true for migration tapes 
and backup tapes.  Be warned that if you don't do tape recycles on a scheduled 
basis the process could possibly run for a long time.  As an example, I think 
that could then impact HSM process of recalls from tape.  I believe the place I 
last worked at did tape recycles every day.

Also, I should have mentioned the information I pasted in my earlier reply came 
from the "DFSMSdfp Storage Administration" manual for z/OS 2.5.  It can be 
found in "Chapter 8. Defining management classes".


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Wednesday, March 13, 2024 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What happens in HSM when I change a Management Class

You should be recycling tapes with a low percent of active datasets.
This copies the remaining active datasets to a new tape then marking this on as 
inactive.  You can manually issue a recycle command against a specific volume.

On Wed, Mar 13, 2024 at 10:56 AM Gadi Ben-Avi  wrote:
>
> Hi Paul,
> Thanks for your detailed explanation.
>
> I would like to delete extra copies of backups, backups that have been on HSM 
> for more than a specified number of days, and as a result of that, tapes that 
> become empty will be deleted.
>
> The end result would be that every backed-up dataset that still exists could 
> have more than one backup, and datasets that do not exist anymore would have 
> only one backup.
>
> Gadi
> 
> From: IBM Mainframe Discussion List  on
> behalf of Paul Feller <05aa34d46684-dmarc-requ...@listserv.ua.edu>
> Sent: Wednesday, March 13, 2024 16:09
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: What happens in HSM when I change a Management Class
>
> [You don't often get email from
> 05aa34d46684-dmarc-requ...@listserv.ua.edu. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Gadi, I have to ask.  Are trying to delete backups of individual
> datasets or the actual tapes created during dataset backup processing?
>
> If you are trying to manage the actual backups of individual datasets,
> have you looked at the different management classes used for the datasets?
>
> The following fields in the management class affect backups taken for
> an individual dataset.
>
> Retain Days Only Backup Ver:
>  Indicates how many days to keep the most recent backup version of a
> deleted data set, starting from the day DFSMShsm detects it has been
> deleted. This attribute applies only when a data set no longer exists
> on primary (level 0) or migrated (levels 1 and 2) storage. The default
> is 60. This field does not apply to objects. Backup copies of objects
> are not retained when the original object is deleted.
>
> Retain Days Extra Backup Vers:
>  Indicates how many days to keep backup versions other than the most
> recent one, starting from the day backups were created. It applies
> only when more than one backup version exists, and when a data set has
> low activity. This attribute applies whether the data set has been
> deleted or not. The default is 30. The number of extra versions is the
> number of backup versions minus one. If you specify 1 for Number of
> Backup Vers, there are no extra versions. For example, if you specify
> 3 for Number of Backup Vers (Data Set Deleted), the number of "extra"
> versions for deleted data sets is 2. These 2 versions are managed
> according to the Retain Days 

Re: IBM Announces the z/OS Container Platform

2024-03-06 Thread Allan Staller
Classification: Confidential

How does this compare to z/CX. IS this a supplement? Replacement? Other?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Timothy Sipples
Sent: Tuesday, March 5, 2024 7:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM Announces the z/OS Container Platform

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

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

https://www.ibm.com/docs/en/announcements/zos-container-platform-delivers-industry-standard-cloud-technologies-build-run-zos-unix-applications-as-containers-natively-zos

-
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, 
Asia-Pacific sipp...@sg.ibm.com


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

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


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


Re: How to reduce the overhead of WLM?

2024-03-05 Thread Allan Staller
Classification: Confidential

The most important resource in most shops is CPU and is usually the critical 
factor in WLM adjustments.
Judicious user of SC period and IMPortance is far more effective in controlling 
the distribution of CPU.
.
I would not overload SYSSTC with work, this will prevent WLM from servicing 
really critical stuff (GRS, XCF, IRLM,..).
However it’s not my dog.

Another thought to the OP. Are you trying to reduce overhead because of a CPU 
shortage, or just curious? Think absolute value vs percentage.
In Sandbox environments, very often something like WLM appears to be the 
largest consumer of CPU), but in absolute terms it is really minor.

HTH,


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Tuesday, March 5, 2024 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to reduce the overhead of WLM?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Would it help to have more of those address spaces in SYSSTC so that WLM 
doesn't try to manage them?

--
Tom Marchant

On Tue, 5 Mar 2024 01:03:27 +, Graham Harris  wrote:

>A few years back, I did a deep dive into tuning CPU usage across a
>multitude of very small z/OS guests under z/VM, and WLM was certainly a
>big hitter for many of them, but as there were so many instances, I was
>able to see notable differences in WLM use between "LPARs", which was
>obviously "of interest".
>The upshot seemed to be that WLM costs had a fairly firm relationship
>with the number of active address spaces on the "LPAR", presumably down
>to the amount of sampling that WLM has to do against each address space
>every 250ms (I think).  I did enquire of IBM as to whether the sampling
>rate could be "adjusted", and that came back with a negative response
>(not really a surprise).
>So the obvious answer may be to only have address spaces started, when
>they are only really needed to be there.
>Although you may need to assess the cost of stopping/starting those
>address spaces, versus the background WLM cost.
>
>
>On Mon, 4 Mar 2024 at 23:08, Wendell Lovewell <
>01e9c0ee0673-dmarc-requ...@listserv.ua.edu> wrote:
>
>> This is probably a strange question, but is there a way to reduce WLM cpu
>> usage?   Here's the situation:
>>
>> - The system is a lightly used development system.  Unless something
>> is in a loop (very rare), CPU % probably is usually less than 10%.
>> And except for system regions & CICS, it's rare to have multiple jobs
>> running concurrently.
>> - Only one processor defined to the VM. No ZIIP either.
>> - We are charged for CPU cycles.
>> - WLM is the highest consumer of CPU.  JES2, TCPIP, ZFS and SDSFAUX
>> round out the top 5 consumers.
>>
>> There is a lot of information about WLM tuning, but as best I can
>> tell almost none of it relates to reducing WLM usage.
>>
>> From reading the Init & Tuning manual, I'm trying these settings:
>> AIMANAGEMENT=NO
>> HIPERDISPATCH=NO
>> CCCAWMT=45
>> RMPTTOM=15000
>>
>> I was thinking that perhaps reducing whatever processing intervals I
>> could might help.  But I can't tell these changes made a difference.
>> (I don't have a tool to measure WLM usage.)
>>
>> Any suggestions would be appreciated.
>>
>> TIA,
>>
>> Wendell
>>
>> -
>> - 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
::DISCLAIMER::

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

Re: How to reduce the overhead of WLM?

2024-03-05 Thread Allan Staller
Classification: Confidential

Agreed!


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Anthony Hirst
Sent: Tuesday, March 5, 2024 7:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to reduce the overhead of WLM?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

If you are running a lot of CICS regions, you might want to look at reducing 
the mastask values, my understanding is that WLM create's PB for every possible 
active task in CICS and they get scanned every 250 ms too.

On Mon, Mar 4, 2024 at 10:15 PM Jim Mulder  wrote:

>   The most important thing is RMPTTOM for reducing the SRM timer pop
> overhead.
> Note that Timer DIE processing is uncaptured time.
>
>   My IEAOPTxx  for running under  VM  has
>
> RMPTTOM=3 /*REDUCE SRM INVOKATION FREQUENCY ON VM */
>
>   And that is a value we set a couple of decades ago, and haven't
> thought much about it since.
> You might want it even higher for faster machines than we had back then.
>
>   I suggested some years ago that SRM should self-tune the timer pop
> interval to be less frequent at low utilization, but I haven't gotten
> any traction on that so far..
>
> Jim Mulder
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Wendell Lovewell
> Sent: Monday, March 4, 2024 6:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How to reduce the overhead of WLM?
>
> This is probably a strange question, but is there a way to reduce WLM cpu
> usage?   Here's the situation:
>
> - The system is a lightly used development system.  Unless something
> is in a loop (very rare), CPU % probably is usually less than 10%.
> And except for system regions & CICS, it's rare to have multiple jobs
> running concurrently.
> - Only one processor defined to the VM. No ZIIP either.
> - We are charged for CPU cycles.
> - WLM is the highest consumer of CPU.  JES2, TCPIP, ZFS and SDSFAUX
> round out the top 5 consumers.
>
> There is a lot of information about WLM tuning, but as best I can tell
> almost none of it relates to reducing WLM usage.
>
> From reading the Init & Tuning manual, I'm trying these settings:
> AIMANAGEMENT=NO
> HIPERDISPATCH=NO
> CCCAWMT=45
> RMPTTOM=15000
>
> I was thinking that perhaps reducing whatever processing intervals I
> could might help.  But I can't tell these changes made a difference.
> (I don't have a tool to measure WLM usage.)
>
> Any suggestions would be appreciated.
>
> TIA,
>
> Wendell
>
> --
> 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
::DISCLAIMER::

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


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


Re: How to reduce the overhead of WLM?

2024-03-05 Thread Allan Staller
Classification: Confidential

1) reduce the number of service class periods and service classes
2) reduce the numberf of workloads
3) set CICS MAXTASKS to a reasonable number
4) Since this is a development system, set your major subsystems to velocity 
goals, not transaction goals (IMS, CICS, DB2, MQ)

This is a combination of experience and remembrance from a WLM training class.

Most people try to over-control WLM instead of letting it do its thing.\

HTH,


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Wendell Lovewell
Sent: Monday, March 4, 2024 5:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to reduce the overhead of WLM?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

This is probably a strange question, but is there a way to reduce WLM cpu 
usage?   Here's the situation:

- The system is a lightly used development system.  Unless something is in a 
loop (very rare), CPU % probably is usually less than 10%.  And except for 
system regions & CICS, it's rare to have multiple jobs running concurrently.
- Only one processor defined to the VM. No ZIIP either.
- We are charged for CPU cycles.
- WLM is the highest consumer of CPU.  JES2, TCPIP, ZFS and SDSFAUX round out 
the top 5 consumers.

There is a lot of information about WLM tuning, but as best I can tell almost 
none of it relates to reducing WLM usage.

From reading the Init & Tuning manual, I'm trying these settings:
AIMANAGEMENT=NO
HIPERDISPATCH=NO
CCCAWMT=45
RMPTTOM=15000

I was thinking that perhaps reducing whatever processing intervals I could 
might help.  But I can't tell these changes made a difference.  (I don't have a 
tool to measure WLM usage.)

Any suggestions would be appreciated.

TIA,

Wendell

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

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


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


Re: TELNET PROFILE, strictly PDS?

2024-03-04 Thread Allan Staller
Classification: Confidential

TCPIP/TELNET come up *LONG* after PDSE initialization.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pew, Curtis G
Sent: Monday, March 4, 2024 1:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TELNET PROFILE, strictly PDS?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On Mar 4, 2024, at 8:25 AM, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

Must  it be the responsibility of every facility to enumerate its capabilities? 
 With great power comes great responsibility.


I believe that the only things that must be PDS and not PDSE are libraries 
accessed at IPL before DFSMS has started the PDSE address space(s).

I know you can use a sequential dataset for the TCP/IP profile, and I’m pretty 
sure you can put it in a Unix file too.


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

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


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


Re: TELNET PROFILE, strictly PDS?

2024-03-04 Thread Allan Staller
Classification: Confidential

You will, at some point need to restart TCPIP to pick up the new PDSE in the 
Profile datasets.
TYPE 1 PDS/E is sufficient for this purpose.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
roscoe5
Sent: Monday, March 4, 2024 7:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TELNET PROFILE, strictly PDS?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I could not find definitive doc saying a PDS/E was/wasn't allowed, but I am 
convinced it is. Thanks.

Over the weekend I created a PDS/E and copied the members, made my update, and 
I'm awaiting Change approval to do any Obey from the new Library to pick it up, 
temporarily. Then the plan is to change the TELNET proc to point to the new 
Library. Over the next several weeks I expect IPLs will pick up the Library. 
Until then we will be slightly on uneven ground.

I read about two different types of PDSs, type-1 and type-2. In a z/OS 2.4 
shop, do we need to specify or is type-2 created by default?

Thanks again!
R

Sent from [Proton Mail](https://proton.me/mail/home) for iOS

On Mon, Mar 4, 2024 at 8:14 AM, Allan Staller 
<[allan.stal...@hcl.com](mailto:On Mon, Mar 4, 2024 at 8:14 AM, Allan Staller 
< wrote:

> Classification: Confidential
>
> 1) Re-allocate as PDS/E. This will require a PDS/E
> 2) Compress in batch w/IEBCOPY and make you changes. No restart required.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of roscoe5
> Sent: Friday, March 1, 2024 2:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TELNET PROFILE, strictly PDS?
>
> [CAUTION: This Email is from outside the Organization. Unless you
> trust the sender, Don't click links or open attachments as it may be a
> Phishing email, which can steal your Information and compromise your
> Computer.]
>
> I'll freely admit I am rusty in this area, but I hope this is an easy 
> question. I know a shop where the TELNET PROFILE dataset is a PDS. We found 
> this today making a minor update and a space abend. All 16 extents full. 
> Compressing while is use being one problem, I'd like to reallocate a new 
> PDS/E or Library or PO-E, whatever the proper term.
>
> But my question is ... is there any restriction against using this file type?
> Must it be an old-fashioned PDS?
>
> I know there were some limitations, years ago, but I thought we were beyond 
> most of those. But I have not kept up for years.
>
> Thanks much everyone.
> R
>
> Sent from [Proton
> Mail](https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%25
> 2Fproton.me%2Fmail%2Fhome=05%7C02%7Callan.staller%40HCL.COM%7C814
> e326573ea4fcedeff08dc3c4f5139%7C189de737c93a4f5a8b686f4ca9941912%7C0%7
> C0%7C638451558588150807%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=Ly3duz
> 0%2B9ivILhYGrItDFNc25OvoTCBvXFO6fzsqWII%3D=0) for iOS
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: TELNET PROFILE, strictly PDS?

2024-03-04 Thread Allan Staller
Classification: Confidential

1) Re-allocate as PDS/E. This will require a PDS/E
2) Compress in batch w/IEBCOPY and make you changes. No restart required.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
roscoe5
Sent: Friday, March 1, 2024 2:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TELNET PROFILE, strictly PDS?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I'll freely admit I am rusty in this area, but I hope this is an easy question. 
I know a shop where the TELNET PROFILE dataset is a PDS. We found this today 
making a minor update and a space abend. All 16 extents full. Compressing while 
is use being one problem, I'd like to reallocate a new PDS/E or Library or 
PO-E, whatever the proper term.

But my question is ... is there any restriction against using this file type?
Must it be an old-fashioned PDS?

I know there were some limitations, years ago, but I thought we were beyond 
most of those. But I have not kept up for years.

Thanks much everyone.
R

Sent from [Proton Mail](https://proton.me/mail/home) for iOS

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

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


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


Re: Question on BUILDMCS

2024-02-26 Thread Allan Staller
Classification: Confidential

Thanks Dave,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Monday, February 26, 2024 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on BUILDMCS

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

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

Dave Jousma
Vice President | Director, Technology Engineering





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


Classification: Confidential



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

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



When I look at the SMPPUNCH I see stuff like:

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



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



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



Thanks in advance,

::DISCLAIMER::



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





--

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

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

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

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

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


Question on BUILDMCS

2024-02-26 Thread Allan Staller
Classification: Confidential

I am in the process of performing a BUILDMCS for the 1st time. This is to 
preserve some products no longer orderable from IBM.
I have RTFM'ed the manuals (SMP/E User's Guide and SMP/E Commands), and the 
actual requirements are unclear.

When I look at the SMPPUNCH I see stuff like:
++MAC(x)  distlib( )  fromdsn() number(2) vol()  .

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

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

Thanks in advance,
::DISCLAIMER::

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


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


Re: Delete HSM backups question

2024-02-26 Thread Allan Staller
Classification: Confidential

The ODS command is *VERY* particular as to the DCB attributes of the ODS 
dataset.
It is documented somewhere in the manual, but I can’t find it with a quick 
search.

The symptoms you show match my experience with the above.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Monday, February 26, 2024 1:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Delete HSM backups question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi Again,
The LIST BCDS ODS(dsname) command created an empty dataset.
Do I have to add anything else to command?

Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Fraser
Sent: יום ב 26 פברואר 2024 09:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Delete HSM backups question

[You don't often get email from 05c7dee21422-dmarc-requ...@listserv.ua.edu. 
Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Use the LIST BCDS command with ODS to create a dataset that will show all HSM 
backups, the source volume and the backup version number.

>From that listing, generate HBDELETE dsn VER(xxx) commands


On Mon, 26 Feb 2024 at 13:58, Gadi Ben-Avi  wrote:

> Thanks,
> How do I find the dataset names that were on these disks?
> How do I make sure that backups of the same datasets that came from
> other disks are not deleted?
>
> Gadi
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Brian Westerman
> Sent: יום ב 26 פברואר 2024 07:27
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Delete HSM backups question
>
> [Some people who received this message don't often get email from
> brian_wester...@syzygyinc.com. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> HBDELETE DataSetName ALL
>
> Brian
>
> --
> 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
::DISCLAIMER::

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


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


Re: Delete HSM backups question

2024-02-26 Thread Allan Staller
Classification: Confidential

I believe HLIST LEVEL() Backup will provide the information you need.
Certainly the HLIST DA() backup will provide the same info if HLIST 
LEVEL(xxx) is unsupported. (I did no look up the syntax).

From there you can generate HBDEL commands (remember to specify date/time or 
all backups will  be deleted. \
You stated you only wanted to delete backups from a specific volume.

I can't think of any way to select the specific volume without a 3rd party add 
on.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Sunday, February 25, 2024 5:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Delete HSM backups question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi,
I would like to delete all backups of datasets that originally resided on 
specific volumes.
The backups were created using HSM
How would I go about that?

We are running z/OS v2.4.

Thanks

Gadi

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

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


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


Re: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Allan Staller
Classification: Confidential

The last mainframe will be turned off in 1994 - Gartner Group

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, February 22, 2024 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

A 5-year prediction is generally safe, because in 5 years people will have 
forgotten the predictions. Who remembers the failed 5-year predictions for, 
e.g., controlled fusion, human level machine translation?

I expect it to eventually happen, but as for when, Hypotheses non fingo 
.

On the flip side, hand optimization for pipelined machines is labor intensive 
and fragile; a compiler with an ARCHLVL parameter is better suited for the job.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Tom 
Harper <05bfa0e23abd-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 22, 2024 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

Dave,

I was told the same thing 54 years ago when I starting working at CalTrans. 
Managers would just be able to code in COBOL PROFITS = SALES - EXPENSES and we 
would all be out of a job.

Of course, there are more programmers now  than at any time in history.

The question of assembler comes up from time to time, and the question has more 
nuances than you might think.

As it turns out, there are lines of code and lines of executed code. What that 
means is that lines of code that are executed frequently are seldom written in 
a compiled language but are instead written in assembler.

A good example is sort. In the 1970s sort typically used about a third of all 
processor and channel resources on a mainframe. Today that number is far lower, 
in the mid-teens despite the fact that much more data is being sorted.

The reason for this is that some very brilliant assembler programmers at 
SyncSort and the  IBM Dfsort team wrote code to highly optimize sorting and 
related functions. I’m counting PL/S as essentially assembler in this instance.

The same is true at BMC Software and my own company Phoenix Software 
International: highly optimized assembler code greatly improved performance.

Even though there are almost uncountable lines of COBOL code, it makes for a 
tiny fraction of executed code. Most compiled languages execute a few 
instructions and then invoke a CICS, IMS, or DB2 function.

Starting in the 1980s, corporations the world over began to understand that it 
was much more cost-effective to buy or lease software from a vendor than 
develop it in house. These developers left the end-user companies and went to 
software houses where they primarily write in assembler. Now ever piece of 
software usually has parts that are not performance-sensitive, so they might 
get written in C++ or Rex or some other compiled language.

I’ve grown up with software, having written my first program in 1960.

Assembler won’t be gone in five years or anytime can the foreseeable future.

So I would revisit your thoughts.

Tom Harper

Phoenix Software International

Sent from my iPhone

> On Feb 22, 2024, at 11:07 AM, Dave Beagle 
> <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>
> Assembler programming will be almost nonexistent in 5 years.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, February 22, 2024, 10:32 AM, Robert Prins 
> <05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:
>
> AI?
>
> More AS!
>
> This is on LinkedIn, it's AI generated and you can probably sue them
> for jaw-dislocation due to excessive laughter:
>
> <
> https://www/.
> linkedin.com%2Fadvice%2F0%2Fhow-can-developers-take-ownership-bugs-ski
> lls-system-development-x9cve=05%7C02%7Callan.staller%40HCL.COM%7C
> cc68e10c66f6488fb04408dc33c94dc1%7C189de737c93a4f5a8b686f4ca9941912%7C
> 0%7C0%7C638442186902794249%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=3tT
> lvB8EH2KJyndo7QBf0U7KKjNBcexrXzghUxXy%2F5Q%3D=0
>>
>
>> On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
>> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> Well, today was NVIDIA earnings day. They are the bellwether for AI.
>> Theirs is the premier AI chip commanding top dollar. And they didn’t
>> disappoint. Their revenues are up 400% in the last year. To 22
>> billion in the latest quarter. They’ve got another chip on tap this
>> year which should continue the incredible growth. If you had invested
>> $10,000 five years ago, you’d have earned 2000%, and would have
>> $200,000. If you 

Re: Nanosecond resolution timestamps for HLL's?

2024-02-22 Thread Allan Staller
Classification: Confidential

I believe the XL/C compiler is included in the z/OS license. XL/C++ I am not 
sure about.
Your shop may never have used it, but I believe it is there. Check with your 
z/OS sysprog.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Wednesday, February 21, 2024 8:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

The runtime is all part of LE.

Our shop does not have the C/C++ compiler.  Never had a business need for it.  
Never even looked in to it, so I don't know the cost.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, February 21, 2024 5:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

Michael,

I do not think it requires the C/C++ compiler to use the C RTL subroutines 
delivered in CEE.SCEELKEX.  You only need the C/C++ documentation to look up 
the routine names, though working out how the C "header" files define the 
parameters and return value and translating those to COBOL would be challenging 
without the headers installed.

Is any large commercial shop actually NOT licensing the XL C/C++ compiler these 
days?  I would hope the cost is not be so prohibitive as to bedevil the 
bean-counters looking for $$ savings.  Don't at least some vendor products 
coded in C/C++ require at least the RTL subroutines (and maybe also the C++ 
DLL's) installed in order to execute at all?  Or is that all delivered in LE?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Wednesday, February 21, 2024 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?



And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Frank 
Swarbrick

Sent: Tuesday, February 20, 2024 12:01 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: Nanosecond resolution timestamps for HLL's?



Try this.



   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.

   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.

   end program 'cgettime_test'.





From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu>

Sent: Monday, February 19, 2024 5:30 PM

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

Subject: Re: Nanosecond resolution timestamps for HLL's?



My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input 

Re: Nanosecond resolution timestamps for HLL's?

2024-02-22 Thread Allan Staller
Classification: Confidential

I believe XL/C is included with the z/OS license. I am not sure about XL/C++

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Wednesday, February 21, 2024 6:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Michael,

I do not think it requires the C/C++ compiler to use the C RTL subroutines 
delivered in CEE.SCEELKEX.  You only need the C/C++ documentation to look up 
the routine names, though working out how the C "header" files define the 
parameters and return value and translating those to COBOL would be challenging 
without the headers installed.

Is any large commercial shop actually NOT licensing the XL C/C++ compiler these 
days?  I would hope the cost is not be so prohibitive as to bedevil the 
bean-counters looking for $$ savings.  Don't at least some vendor products 
coded in C/C++ require at least the RTL subroutines (and maybe also the C++ 
DLL's) installed in order to execute at all?  Or is that all delivered in LE?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Wednesday, February 21, 2024 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?



And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Frank 
Swarbrick

Sent: Tuesday, February 20, 2024 12:01 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: Nanosecond resolution timestamps for HLL's?



Try this.



   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.

   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.

   end program 'cgettime_test'.





From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu>

Sent: Monday, February 19, 2024 5:30 PM

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

Subject: Re: Nanosecond resolution timestamps for HLL's?



My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input priority value is necessary to preserve 
FIFO order when pushing new items into the queue.  As Paul (gil) pointed out, 
named counters might provide a similar function but would be far more 
performance-expensive compared to a simple STCK value.



Yes, I am aware that STCK breaks at the epoch in 2038 (or is it 2042? I forget 
now), which isn't ALL that far away.  A MetalC implementation for STCK values 
has been coded and works acceptably, as does of course a straight-forward 
assembler implementation.  Extension to use STCKE instead of STCK 

Re: Something keeps releasing space on a large (annual) DS

2024-02-21 Thread Allan Staller
Classification: Confidential

The most likely reason is the DATACLAS(? Possibly MGMTCLAS)  ACS Routine. This  
is where partial space release is specified.
It is possible, but un likely that dfHSM is doing the partial space release. 
HSM would be honoring the "dictates" of the DATACLAS.

HTH,


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Wednesday, February 21, 2024 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Something keeps releasing space on a large (annual) DS

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know either - but 
he's an external contractor who just took over the system a few months ago and 
if it's something simple he may not be aware yet of ... I dunno, something in 
SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by 
reference to the current year.  This relieves folks from having to update the 
JCL every year, but maybe something about the way the exec does the allocate is 
causing the problem?  I'm guessing not, because as far as I now this job has 
run correctly for years.  But just in case:

  "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
  "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be releasing 
space?

3) What IS extended PS, anyway?  I'm told it allows more than 16 extents, but 
a) how many more? And b) how else is it different?

4) I allocated the dataset each time using not batch JCL but 3.2 ... expecting 
there's no difference.

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

/* Law #6 of combat operations:  If it's stupid but it works, it isn't stupid. 
*/

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

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


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

Re: Principles of Op

2024-02-20 Thread Allan Staller
Classification: Confidential

Resource link

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Monday, February 19, 2024 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Principles of Op

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Any one know where IBM is hiding this now?

I've been searching for this to find the latest copy, and I'm getting nowhere.

I used to be able to put in IBM TECH LIBRARY and it would be in with the z/OS 
manuals. Can't seem to find it now.

Steve Thompson

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

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


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


Re: Tn3270 back door

2024-02-16 Thread Allan Staller
Classification: Confidential

Don't you have some local 3270 devices defined? As previously suggested, change 
a console to a VTAM terminal and log on w/VTAM instead of TN3270


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Friday, February 16, 2024 11:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Tn3270 back door

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On Fri, 16 Feb 2024 at 05:54, James Cradesh < 
05a6576c6fa2-dmarc-requ...@listserv.ua.edu> wrote:

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

Can you get into line-mode UNIX? SSH or (sigh) telnet?

What about line-mode TSO?

If these ports are open it seems unlikely they'd be secured with the same SSL 
cert. Maybe they're not secured at all...

Tony H.

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

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


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


Re: Banks migrate from mainframes to AI-driven cloud

2024-02-14 Thread Allan Staller
Classification: Confidential

Thae last LzLabs project I was involved in was finally completed  1 1/2 years 
late and the overrun ate up all of the potential saving to the client.
LzLabs now has a total AFAIK 2 "production" implementations.

My USD $0.02 worth

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Andrew Wilkinson
Sent: Tuesday, February 13, 2024 6:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Banks migrate from mainframes to AI-driven cloud

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

> Just ask LzLabs how its goingQuite well I would guess. Otherwise IBM wouldn't 
> bother to sue.


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

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


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


test message please ignore no reply needed

2024-02-13 Thread Allan Staller
Classification: Confidential

test
::DISCLAIMER::

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


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


Re: Banks migrate from mainframes to AI-driven cloud

2024-02-12 Thread Allan Staller
Classification: Confidential

Just ask LzLabs how its going

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Arthur Fichtl
Sent: Saturday, February 10, 2024 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Banks migrate from mainframes to AI-driven cloud

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Am 10.02.2024 um 06:00 schrieb IBM-MAIN automatic digest system:
migration from the mainframe?

The mainframe as a piece of hardware might vanish. But the Exabytes  of MF 
software might move to some sort of virtualization platform, I guess, may that 
be  based on Intel, cloud, or RISC .


--
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
http://www.avast.com/

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

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


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


Re: Where are Unix reason codes over 7371 documented

2024-02-05 Thread Allan Staller
Classification: Confidential

Try   "TSO BPXMTEXT 7663730C"

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Saturday, February 3, 2024 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Where are Unix reason codes over 7371 documented

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I am trying to debug a situation in zSecure where I am getting this message 
from the CKNSERVR address space.

CKN017I 12 BPX1AIO connect failed on socket 1 RC 111 permission denied, reason 
7663 730Cx

   Port 7173 of 192.168.11.100

BPX1AIO documents that its return and reason codes are in the UNIX messages and 
codes manual.

I am looking in manual SA23-2284-60 but the values for errnojr only go up to 
7371.

Where can I find the documentation for higher values?

Lennie








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

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


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


Re: JES2 JOBDEF DUPL_JOB=NODELAY - Any gotchas?

2024-02-02 Thread Allan Staller
Classification: Confidential

Not sure it will help. GRS may deadlock on resources between the jobs. Even if 
GRS does not deadlock, it will still delay the 2nd and subsequent jobs.
All you will likely do ius mod the delay from the JES jobqueue  to the JES 
execque.

My USD $0.02 worth.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Thursday, February 1, 2024 11:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 JOBDEF DUPL_JOB=NODELAY - Any gotchas?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I am not a sysprog but I occasionally play one in my spare time. I am thinking 
of changing a system that I control to DUPL_JOB=NODELAY. Any gotchas? Anything 
I need to consider before I do this? Do most/many of you run with NO_DELAY?

I am trying to solve a problem where I have jobs delayed because the names are 
duplicates. I can't easily change the jobnames.

I can't think of any issues. We don't have any significant automation. I can't 
think of anything where jobs are referenced by name rather than Job ID.

What should I be considering?

Thanks,
Charles

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

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


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


Re: GTF trace for a JCL error?

2024-01-30 Thread Allan Staller
Classification: Confidential

You need to look at the JES output to determine the error.
Use the following command
S taskname,,,MSGCLASS=x  where x is a held sysout class.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Ituriel do Neto
Sent: Tuesday, January 30, 2024 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GTF trace for a JCL error?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi,

You can check the jobclass definitions of your STCs by issuing 
$DJOBCLASS(STC),LONG or looking into SDSF at JC screen. Probably the outdisp is 
(PURGE,PURGE).

In this case, you may change it to (HOLD,HOLD) to see the JCL.


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer






Em terça-feira, 30 de janeiro de 2024 às 11:31:17 BRT, Peter Ten Eyck 
<04d3761a18a7-dmarc-requ...@listserv.ua.edu> escreveu:





Under z/OS 2.4.

I have a STC when started, fails with the following error in the SYSLOG:

IEE132I START COMMAND DEVICE ALLOCATION ERROR

Looking at the STC output in JES, there is a JCL error in the proc (dataset not 
found).

Is there a way to "see" the JCL error without looking at the JES output?

I have been researching and running a GTF trace with no success "seeing" the 
JCL error, not sure what GTF trace options to turn on or if it is possible to 
see that JCL error via a GTF trace.

Is it possible to see that JCL error in a GTF trace, if so, what options 
(parms) do I need to run with?



Note: We had an issue with VTAM not coming up on a LPAR and we were unable to 
access JES to see the JCL error.

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

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


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


Re: GTF trace for a JCL error?

2024-01-30 Thread Allan Staller
Classification: Confidential

Nope!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Ten Eyck
Sent: Tuesday, January 30, 2024 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: GTF trace for a JCL error?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Under z/OS 2.4.

I have a STC when started, fails with the following error in the SYSLOG:

IEE132I START COMMAND DEVICE ALLOCATION ERROR

Looking at the STC output in JES, there is a JCL error in the proc (dataset not 
found).

Is there a way to "see" the JCL error without looking at the JES output?

I have been researching and running a GTF trace with no success "seeing" the 
JCL error, not sure what GTF trace options to turn on or if it is possible to 
see that JCL error via a GTF trace.

Is it possible to see that JCL error in a GTF trace, if so, what options 
(parms) do I need to run with?



Note: We had an issue with VTAM not coming up on a LPAR and we were unable to 
access JES to see the JCL error.

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

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


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


Re: RACF Automation (Cross Posted)

2024-01-26 Thread Allan Staller
Classification: Confidential

Try Vanguard software.  http://www.go2vanguard.com/

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Thursday, January 25, 2024 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF Automation (Cross Posted)

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Back when my client in Ohio installed it, we called it "Sam-Jupiter".  I don't 
know what the extra name implies.  The client seemed content with their choice, 
although it was really designed to work with RACF and this is an ACF2 client.

Also Sailpoint, but I think you mentioned that possibility already.

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

/* Getting an inch of snow is like winning 10 cents in the lottery.  -from 
_Calvin & Hobbes_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Thursday, January 25, 2024 14:08

See if SAM (Security Administration Manager) still exists (possibly rebranded). 
The company no longer exists but I found 
https://dl.acm.org/doi/pdf/10.1145/266741.266758 which described the product.

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

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


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


Re: New SSH vulnerability

2024-01-25 Thread Allan Staller
Classification: Confidential

It does take some time for the fixes to be developed, tested and distributed.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Thursday, January 25, 2024 8:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New SSH vulnerability

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

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


QID

38913

Severity

HIGH

Definition

SSH Prefix Truncation Vulnerability (Terrapin)

Description

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





QID Detection Logic (Unauthenticated):



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

Solution

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



Patch:



Following are links for downloading patches to fix the vulnerabilities:

OpenWall Security Advisory

Impact

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

CVEs

CVE-2023-48795

Results

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

ChaCha20-Poly1305 Algorithm Support: True

CBC-EtM Algorithm Support: False

Strict Key Exchange algorithm enabled: False

EVM Report

Yes

EVM Risk Score

4.9

Host Details

Host

192.168.30.2

IP Address

192.168.30.2

Operating System

IBM OS/390

Tier

T3

FQDN



Port

22

Protocol

tcp




Dave Jousma
Vice President | Director, Technology Engineering





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

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

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


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


Re: Masking SMF data internally

2024-01-22 Thread Allan Staller
Classification: Confidential

Use Fiale-Aid or File Manager if you have them available.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Sunday, January 21, 2024 12:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Masking SMF data internally

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I am not even able to browse

It says 'Invalid record length'. I tried setting the block size and LRECL but 
by default it takes as

Record length': 32767
Block size : 32760

On Sun, Jan 21, 2024, 10:26 AM ITschak Mugzach  wrote:

> Are these files machine or human readable? As you can edit them, I
> believe they are human readable and no Hex data inside. If so, write a
> rexx to translate everything a-z to blanks and write back.
>
> ITschak
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS,
> zLinux and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404
> **|*
> *Skype**: ItschakMugzach **|* *Web**:
> http://www.s/
> ecuriteam.co.il%2F=05%7C02%7Callan.staller%40HCL.COM%7Cbce170c2bc
> dc4427e8bc08dc1a4c4f76%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63
> 8414162258898997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=YRQMcrs36T
> %2F%2BN1WiRNTQgu0nG36IkFr0PrkVsdI%2BdqY%3D=0  **|*
>
>
>
>
>
> בתאריך יום א׳, 21 בינו׳ 2024 ב-7:59 מאת Jake Anderson <
> justmainfra...@gmail.com>:
>
> > Hello
> >
> > We have a requirement of sharing our SMF data to vendor for a sizing
> > operation of our hardware connected to our mainframe
> >
> >
> > Our organization has a policy of masking the critical values before
> sharing
> > it. I see SMF datasets are are editable from ISPF.
> >
> > Is there a way or someone has undergone this exercise of masking the
> > confidential values inside SMF output Dataset?
> >
> > Please advise
> >
> > Jake
> >
> > 
> > -- 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
::DISCLAIMER::

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


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


Re: How can I keep JES2 from being SYSPLEXed?

2024-01-22 Thread Allan Staller
Classification: Confidential

Provide separate JES CKPT and Spool datasets for each "JESPLEX".
You will also need separate NODES for NJE, lines, .

You might also look  at JES Checkpoint auto-tuning.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Wendell Lovewell
Sent: Friday, January 19, 2024 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How can I keep JES2 from being SYSPLEXed?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I have two systems that I want to share dasd and allow for VSAM RLS between the 
systems, but I don’t want to SYSPLEX JES2.  I have MASDEF SHARED=NOCHECK.  What 
else can I do to un-sysplex JES?

Is it safe to delete the JES2 and/or SYSJES group definitions from XCF?  I 
don't have a JES_CKPT_1 structure defined at all.

Background:

I’m trying to add a z/OS 3.1 ( S0W1) to a sysplex where z/OS 2.5 
(Z3- S0W3) is running, but ONLY for VSAM RLS.  I don’t want to “plex” 
anything more than is needed for VSAM/RLS—not JES, not SYSLOG, not VTAM, not 
SMF or anything else.

The systems are running fine stand-alone (each with their own set of disks, 
including the volume with the CDS), but when I try to use the same CDS disk 
between the systems, the first system comes up fine, but JES2 on the system 
brought up last complains that it cannot find the checkpoint datasets of the 
OTHER system:

Z4  : H *$HASP284 JES2 INITIALIZATION CHECKPOINT DIALOG STARTED
Z4  : H *$HASP277 JES2 CAN NOT FIND OR USE THE CHECKPOINT DATA SET(S)
Z4  : H   THAT WERE IN USE WHEN THE MAS WAS LAST ACTIVE BECAUSE 
VOLUME
Z4  : H   FOR CKPT1 NOT MOUNTED
Z4  : H *
Z4  : H   CURRENT CHECKPOINT VALUES:
Z4  : H   CKPT1=(DSNAME=SYS1.HASPCKPT,VOLSER=B5SYS1,INUSE=YES),
Z4  : H   CKPT2=(DSNAME=SYS1.HASPCKP2,VOLSER=B5CFG1,INUSE=YES)
Z4  : H *
Z4  : H   VALID RESPONSES ARE:
Z4  : HCKPT1=...  - UPDATE CURRENT CHECKPOINT SPECIFICATION WITH
Z4  : HCKPT2=...THE VALUES USED WHEN JES2 MAS WAS LAST 
ACTIVE
Z4  : H'RECONFIG' - THE CHECKPOINT DATA SET(S) THAT WERE IN USE
Z4  : H WHEN JES2 WAS LAST ACTIVE ARE NO LONGER
Z4  : H AVAILABLE (ALL-MEMBER WARM START ONLY)
Z4  : H'CONT' - ATTEMPT INITIALIZATION WITH THE VALUES 
LISTED
Z4  : H'TERM' - TERMINATE JES2 INITIALIZATION ON THIS MEMBER
Z4  : H *04 $HASP272 ENTER RESPONSE (ISSUE D R,MSG=$HASP277 FOR RELATED MSG)

"Z4" is the z/OS 3.1 system.  The “B5SYS1” and “B5CFG1” volumes belong to the 
z/OS 2.5 system.  If I bring up z/OS 3.1 with z/OS 2.5 down and then try to 
bring up z/OS 2.5, the same message is displayed except it identifies the 
volumes belonging to the other system.

I can RECONFIG with the correct CKPT volumes, but it always ends with:

Z4  :  $HASP478 INITIAL CHECKPOINT READ IS FROM CKPT1
Z4  :   (SYS1.HASPCKPT ON A3SYS1)
Z4  :   LAST WRITTEN THURSDAY, 18 JAN 2024 AT 21:57:08 (GMT)

Z4  :  $HASP792 JES2 HAS JOINED XCF GROUP JES2 THAT INCLUDES ACTIVE MEMBERS
Z4  :   THAT ARE NOT PART OF THIS MAS
Z4  :   MEMBER=JES2$S0W3,REASON=DIFFERENT COLD START TIME

Z4  :  $HASP428 CORRECT THE ABOVE PROBLEMS AND RESTART JES2
Z4  :  IXZ0002I CONNECTION TO JESXCF COMPONENT DISABLED,
Z4  :   GROUP JES2 MEMBER JES2$S0W1
Z4  :  $HASP9085 JES2 MONITOR ADDRESS SPACE STOPPED FOR JES2
Z4  :  $HASP085 JES2 TERMINATION COMPLETE

Like I said, I don't want a MAS at all--each JES2 should be separate.


(This has already gone too long, but here are some displays that might help:)

Both JES parms use the same MASDEF definition:
MASDEF   SHARED=NOCHECK,
 CKPTLOCK=INFORM,
 RESTART=NO,
 DORMANCY=(25,300),
 HOLD=10,
 LOCKOUT=1200

Z3 $dmasdef  (If other system is down, after a cold start.)
   $HASP843 MASDEF
> $HASP843 MASDEF  OWNMEMB=S0W3,AUTOEMEM=OFF,CKPTLOCK=INFORM,
   $HASP843 COLDTIME=(2022.313,18:50:45),COLDVRSN=z/OS 2.5,
   $HASP843 ENFSCOPE=SYSPLEX,DORMANCY=(25,300),HOLD=10,
> $HASP843 LOCKOUT=1200,RESTART=NO,SHARED=NOCHECK,  <==
   $HASP843 SYNCTOL=120,WARMTIME=(2024.018,22:05:36),
   $HASP843 XCFGRPNM=JES2,QREBUILD=0,CYCLEMGT=MANUAL,
   $HASP843 ESUBSYS=HASP

Z4 $DMASDEF  (If other system is down, after a cold start.)
Z4  :  $HASP843 MASDEF
Z4  :  $HASP843 MASDEF  OWNMEMB=S0W1,AUTOEMEM=OFF,CKPTLOCK=INFORM,
Z4  :  $HASP843 COLDTIME=(2024.019,21:00:02),COLDVRSN=z/OS 3.1,
Z4  :  $HASP843 ENFSCOPE=SYSPLEX,DORMANCY=(25,300),HOLD=10,
Z4  :  $HASP843 LOCKOUT=1200,RESTART=NO,SHARED=NOCHECK,   <==
Z4  :  $HASP843 

Re: ADRDSSU COMPRESS and enq

2024-01-19 Thread Allan Staller
Classification: Confidential

1 copy w/ADRDSSU) TOLENQFAILURE and RENUNC
Or
Allocate new; copy from original w/IEBCOPY
3) test

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, January 19, 2024 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADRDSSU COMPRESS and enq

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Gentlemen,
First, thank you for your answers. I appreciate it.

Regarding TOLENQF - it doesn't work with COMPRESS or CONSOLIDATE. The manual is 
clear here.

Regarding rename - this is the thing I wanted to avoid for several reasons:
1. There is some risk to rename wrong "copy" of the dataset, or alter ICF 
entries for wrong copy.
2. Valid copies are located on non-SMS disk, but cataloged out of regular 
catalog search (SYS1.name in some UCAT). Plus some aliases, etc.
I want to not destroy it.
3. I don't know how to rename such datasets! Yes, I could imagine access from 
another z/OS image, but it would be a series of manual ISPF r command. 
Non-repeatable, error prone. Is there any tool allowing to rename such datasets 
in batch? Wildcard support (i.e. REN SYS1.* SYS2.*) would be welcome.



--
Radoslaw Skorupka
Lodz, Poland





W dniu 19.01.2024 o 13:27, Radoslaw Skorupka pisze:
> I want to compress some system datasets like SYS1.LINKLIB, but *not*
> real "live", rather offline copies.
> DSS ends with RC8, because of failed serialization.
> SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because
> some datasets are serialized by other entities like TSO users.
>
> And I also want to CONSOLIDATE some datasets as well.
>
>
> Any clue?
>

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

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


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


Re: ADRDSSU COMPRESS and enq

2024-01-19 Thread Allan Staller
Classification: Confidential

Rename the "copy" prior to attempting compress.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, January 19, 2024 6:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ADRDSSU COMPRESS and enq

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I want to compress some system datasets like SYS1.LINKLIB, but *not* real 
"live", rather offline copies.
DSS ends with RC8, because of failed serialization.
SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because some 
datasets are serialized by other entities like TSO users.

And I also want to CONSOLIDATE some datasets as well.


Any clue?

--
Radoslaw Skorupka
Lodz, Poland

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

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


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


Re: VolCat - Reallocate ?

2024-01-16 Thread Allan Staller
Classification: Confidential

You might need to add RMM to the tasks to be started/stopped. Not sure if CA-1 
uses the volcat as well.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Tuesday, January 16, 2024 11:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: VolCat - Reallocate ?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi,
  So I need to reallocate my VOLCAT, due to IMBED and REPLICATE present.

So my question is what steps to perform? Like This maybe?

Stop OAM?
Export VOLCAT?
Delete VOLCAT
ALLOCATE new VOLCAT.
IMPORT from Exported copy?
Start OAM?

Is this right, anyone have JCL example of EXP/IMPORT of a volcat?

Or anything I am missing?
Thanks

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



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

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

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

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


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


Re: Racf Userid

2024-01-11 Thread Allan Staller
Classification: Confidential

Suspend it and see who complains. Alternatively, t he type 8x SMF records carry 
the RACF UID
(actually most of the job/dataset oriented records type 30, 14, 15), so you can 
check there as well.

Select by userid and filter out what you know. That which remains is the 
culprit.

MICS, MXG make this trivial.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Chalk, Shelia
Sent: Wednesday, January 10, 2024 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Racf Userid

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello,

I have a userid abc that was last access in racf on 1/7/24 at 5:06 a.m.  Is 
there a report or something that will tell me who (batch job, script, etc..) is 
using this userid?

Thanks
Shelia Chalk
Mainframe System Programmer
sch...@ssfcu.org


==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

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


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


Re: IBM Security Portal

2024-01-10 Thread Allan Staller
Classification: Confidential

They will eventually go into the RSU. I usually make a point of researching 
installing all applicable secant ptf's available at the time the holddata was 
pulled. . 
I have (as of this time) never seen a PE against a secant PTF.

YMMV,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
rpinion865
Sent: Wednesday, January 10, 2024 2:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM Security Portal

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Which begs the next question.  Would security related PTFs make their way into 
normal RSUs, or must they be ordered separately as per the holddata?




Sent with Proton Mail secure email.

On Wednesday, January 10th, 2024 at 3:14 PM, Allan Staller 
<0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:


> Classification: Confidential
>
> This is a severely manual process.
> The PTFS/APARS can be determined from the HOLDDATA.
>
> The PTFs are individually orderable via ShopZ (just like any other PTF). The 
> only difference is that the PTF/APAR information is only available in the 
> HOLDDATA.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf 
> Of rpinion865
>
> Sent: Wednesday, January 10, 2024 2:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM Security Portal
>
> [CAUTION: This Email is from outside the Organization. Unless you 
> trust the sender, Don't click links or open attachments as it may be a 
> Phishing email, which can steal your Information and compromise your 
> Computer.]
>
> I know how to navigate to IBM's Security Portal and pull down the security 
> hold data. My question pertains to where does one get the security related 
> PTFs and APARs. In other words, do the security related PTFs and APARs have 
> to be pulled down from another site, as opposed to the site where one pulls 
> down general maintenance? Thanks in advance.
>
> Sent with Proton Mail secure email.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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: IBM Security Portal

2024-01-10 Thread Allan Staller
Classification: Confidential

This is a severely manual process.
The PTFS/APARS can be determined from the HOLDDATA.

The PTFs are individually orderable via ShopZ (just like any other PTF). The 
only difference is that the PTF/APAR information is only available in the 
HOLDDATA.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
rpinion865
Sent: Wednesday, January 10, 2024 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM Security Portal

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I know how to navigate to IBM's Security Portal and pull down the security hold 
data. My question pertains to where does one get the security related PTFs and 
APARs. In other words, do the security related PTFs and APARs have to be pulled 
down from another site, as opposed to the site where one pulls down general 
maintenance? Thanks in advance.

Sent with [Proton Mail](https://proton.me/) secure email.

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

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


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


Re: OpenSSH CVE-2023-48795 vulnerability

2024-01-05 Thread Allan Staller
Classification: Confidential

IBM has a subscription only list for SECINT PTFs. This information is not 
openly published.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
rpinion865
Sent: Friday, January 5, 2024 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OpenSSH CVE-2023-48795 vulnerability

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I have already searched there and did not find anything related to this 
particular vulnerability.  I did find one PTF from 2023 which is for ssh.  That 
PTF is applied on our sandbox LPAR, scheduled to be rolled out into production 
shortly.  Also, the IBM documentation for z/OS 2.4 SSH states that it is based 
on Open SSH 6.4p1.  Which I think is quite old.




Sent with Proton Mail secure email.

On Friday, January 5th, 2024 at 10:33 AM, Kirk Wolf  wrote:


> This would be found in the IBM Security Portal.
> Here is information on registering to obtain access:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ibm.com%2Fcommunity%2Fz%2Fwp-content%2Fuploads%2Fsites%2F14%2F2022%2F0
> 6%2FzSystem-Integrity.pdf=05%7C02%7Callan.staller%40HCL.COM%7Cf73
> 64caa6e214dbc63fb08dc0e04899c%7C189de737c93a4f5a8b686f4ca9941912%7C0%7
> C0%7C638400660032783209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=CfT
> tRH5qZibRTMsmRhCA%2FY5FttlA7FUiOgt8Ksa87qo%3D=0
>
> Kirk Wolf
> Dovetailed Technologies
> http://
> https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdovet
> ail.comcoztoolkit.com%2F=05%7C02%7Callan.staller%40HCL.COM%7Cf736
> 4caa6e214dbc63fb08dc0e04899c%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C
> 0%7C638400660032939455%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=mxy1
> qvKZXQ9DnC0QnfWuQ6CVgRv8slRgsMZM2dEFjIY%3D=0
>
>
> On Fri, Jan 5, 2024, at 6:50 AM, rpinion865 wrote:
>
> > Does anyone know if the z/OS implementation of ssh is vulnerable to
> > CVE-2023048795? I tried searching for z/OS and OpenSSH (CVE-2023-48795). 
> > But, I did not get any hits specific to z/OS. Thanks in advance.
> >
> > Cross posting to IBMTCP-L and IBM Main
> >
> > Sent with Proton Mail secure email.
> >
> > 
> > -- 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
::DISCLAIMER::

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


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


test. please ignore

2024-01-03 Thread Allan Staller
Classification: Confidential

test

::DISCLAIMER::

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


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


Re: SQA overflow condition

2023-12-11 Thread Allan Staller
Classification: Confidential

RMF  will do this provided VSTOR(D) is specified in ERBRMFxx. It will show the 
alllocations, but not necessarily the "actual" user.
E,g. VTAM, TCPIP,.

HTH

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Sunday, December 10, 2023 10:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SQA overflow condition

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

The ESQA usage has gone to 108%.

Is there any tool available in CBTTAPEA which can tell me or trace SQA users 
and who are not releasing the storage?

On Mon, Nov 27, 2023, 5:37 PM Allan Staller < 
0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:

> Classification: Confidential
>
> 100% concur w/Martin
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Martin Packer
> Sent: Sunday, November 26, 2023 2:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SQA overflow condition
>
> [CAUTION: This Email is from outside the Organization. Unless you 
> trust the sender, Don’t click links or open attachments as it may be a 
> Phishing email, which can steal your Information and compromise your 
> Computer.]
>
> (This is not specific advice but a way of thinking about things.)
>
> SQA can, of course, overflow into CSA - with no real harm done. Unless 
> it causes CSA to go short. (CSA can't overflow into SQA, of course.)
>
> The above statements are true for both 24-bit and 31-bit.
>
> 1409K below the line, though, is pretty extreme - for 24 bit. If you 
> made SQA larger so that it only overflowed, say, by 100K there would 
> be no wasted virtual storage.
>
> More importantly, check out the "free CSA" picture. You really don't 
> want to run out of that. For 24-bit you want a few hundred K free. 
> (But to achieve that might require losing 1MB of 24-bit private, which 
> might not be consequence free.)
>
> For 31 bit I like to see at least 100MB free ECSA, preferably more. 
> The reason is because ECSA is - in my experience - more volatile.
>
> Speaking of volatility, you need to plan defensively - as a problem 
> can lead to surge in SQA and CSA usage .
>
> Final point: I would advocate using SMF 78-2 to build a picture of 
> common storage usage - and how variable it is. Here is a blog post I 
> wrote on the
> matter:
>
> htt ps://
> mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storag
> e
>
> (Take out the space to follow the URL - as my mail client turned it 
> into an attachment.) 
>
> Cheers, Martin
>
> Sent from my iPad
>
> > On 26 Nov 2023, at 05:40, Peter  wrote:
> >
> > Hello
> >
> > I am able to see the below alert condition under RMF postprocessor 
> > III
> >
> >
> >
> > Name Reason Critical val. Possible cause or action
> >
> > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K.
> >
> >
> >
> >
> >
> > Our SQA and CSA set up in our IEASYSxx is as below
> >
> >
> >
> > CSA=(2000,30)
> >
> >
> >
> > SQA=(16,192)
> >
> >
> > Hardware: z14
> > LPAR : 16gb memory
> > zOS 2.4
> >
> > Do I have think about tunning the SQA parameter ?
> >
> > Regards
> > Peter
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598 Registered office: 
> PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be 
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
> may contain viruses in transmission. The e mail and its contents (with 
> or without referred errors) shall therefore not attach any liability 
> on the originator or HCL or its affiliates. Views or opinions, if any, 
> presented in

Re: Starting up a LPAR for the first time joining a parallel sysplex

2023-12-06 Thread Allan Staller
Classification: Confidential

Nothing major on the 1st 2 points. LPAR1 cannot join the sysplex until GRS= in 
IEASYS00 is updated to (at least) TRYJOIN.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Laurence Chiu
Sent: Tuesday, December 5, 2023 2:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Starting up a LPAR for the first time joining a parallel sysplex

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

We are building a parallel sysplex.

LPAR1 is still in a monoplex with GRS=NONE. It will be shutdown. Then we want 
to bring up LPAR2 with GRS=STAR and join the sysplex.

A couple of questions cropped up.

1. Can LPAR2 be brought up, trying to access the share catalog, RACF database 
etc when the other LPAR is not up. What are the gotchas to be looking for 2. 
This will be the first time the LPAR is IPL'd with GRS=STAR and trying to join 
the sysplex.  Would that extend the time for the IPL and what would you be 
looking for during the IPL?  Would it take 2-3 hours to be confident it was 
working - e.g. CDS are okay, an all other parallel sysplex configurations?
3. What happens when LPAR1 comes up and then joins the parallel sysplex?


Thanks

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

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


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


Re: zOSMF install

2023-12-04 Thread Allan Staller
Classification: Confidential

Short answer. Yes. Do it now.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, December 4, 2023 10:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF install

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi all,

Just looking for opinions on this.

Scenario is we're running z/OS 2.4.  We don't have zOSMF installed.  Sometime 
next year we're going to migrate to 3.1.  Would we be better off 
installing/implementing zOSMF 2.4 today in preparation for installing 3.1 or 
should we install zOSMF 3.1 and implement that before installing z/OS 3.1?  Can 
we even install zOSMF 3.1 without having a running zOSMF install already?

Thanks,

Rex

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


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

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


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


Re: JES3plus & TDMF

2023-12-01 Thread Allan Staller
Classification: Confidential

From the APAR numbers, they are ancient and most likely do not apply to ans 
z/OS system (OS 390 or earlier perhaps).
That coed is undoubtedly in the JES3 and Jes3/Plus base. I would not worry 
about them.

One other thing. TDMF can move inactive page datasets. It will refuse to touch 
an in-use page dataset.

The last time I did a DASD migration, I defined temporary page datasets and 
used pageadd/pagdel commands to move the paging activity.
After the original page datasets had been moved, I repeated the process to go 
back to the original page datasets.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Friday, December 1, 2023 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES3plus & TDMF

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Apologies for the double listing to anyone who's also seen this on the JES3-L 
LISTSERV.

The government agency that employs me has three z/OS LPARs (V2R5) running on a 
z15 server. The lone mainframe storage subsystem is a non-replicated, 
channel-attached DS8886. This has never been a JES2 installation and Phoenix 
Software’s JES3plus is now installed. While the JES3 initialization deck has 
DEVICE statements for all tape drives, it has not contained a DEVICE statement 
for a DASD address in over a decade. In other words, DASD allocation is not 
managed by JES3.

The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to 
migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can move 
the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD volumes 
where the coupling facility resides without issues. A co-worker insists that 
all of the LPARs must be brought down, separately, so that each LPAR’s 
‘sensitive’ volumes can be moved from another LPAR.

IBM documents state: ‘JES3 considerations: In order to ensure that JES3 system 
defined volumes will migrate (not required for a Point-In-Time migration) in a 
TDMF (or P/DAS) environment, APARs OW23271, OW28455, and OW28457 must be 
applied. These APARs provides JES3 DDR support for P/DAS and therefore, will 
allow the swapping of volumes. Important: All systems sharing devices where 
JES3 manages the devices must be involved in the TDMF session running. This 
ensures that all JES3 internal tables are properly updated. Failure to do so 
will cause unpredictable results. It is recommended that the user check the UCB 
for the following bit prior to copying volumes in a JES3 environment: UCBJ3DV - 
device is defined to JES3. If the bit is off, TDMF will migrate the volume(s) 
with no errors. If the bit is on, TDMF will make the appropriate calls to JES3 
to notify JES3 of the volume redirection needed.’

Since the DASD volumes at this installation are not managed by JES3, I don’t 
think these APARs are an issue. However, to assuage my co-worker’s fears, I’d 
like to see whether the corresponding PTFs have been applied. Unfortunately, I 
cannot find the PTFs that correspond to any of them.

Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457?

Also, I’m not sure how to display the UCBs involved to verify that the UCBJ3DV 
flag indicates that the volumes are not managed by JES3. Any help you can 
provide on would be appreciated, particularly on how to use either UCBSCAN or 
UCBLOOK macros.


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

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


--
For IBM-MAIN subscribe / signoff / archive 

Re: TCPIP ECSALIMIT

2023-12-01 Thread Allan Staller
Classification: Confidential

I haven't actually experienced this, but I would expect TCPIP to cease 
functioning., while  the rest of the system continues to function.
This is almost (but not quite) as bad as a system crash,

If you have a DVIPA, you could recycle the TCPIP task and the DVIPA backup 
configuration would preserve the sessions.

Otherwise, bad, very very bad,

HTH

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, December 1, 2023 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TCPIP ECSALIMIT

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I want to use ECSALIMIT, which is subparameter of GLOBALCONFIG.
Its purpose is clear for me - TCPIP will not exhaust all the ECSA and will not 
cause system outage.

However... What happens when TCPIP reach the ECSALIMIT? Will the TCPIP task 
abend or simply some less disruptive symptoms will be observed?

--
Radoslaw Skorupka
Lodz, Poland

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

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


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


Re: SQA overflow condition

2023-11-27 Thread Allan Staller
Classification: Confidential

100% concur w/Martin

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Martin Packer
Sent: Sunday, November 26, 2023 2:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SQA overflow condition

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

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

SQA can, of course, overflow into CSA - with no real harm done. Unless it 
causes CSA to go short. (CSA can't overflow into SQA, of course.)

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

1409K below the line, though, is pretty extreme - for 24 bit. If you made SQA 
larger so that it only overflowed, say, by 100K there would be no wasted 
virtual storage.

More importantly, check out the "free CSA" picture. You really don't want to 
run out of that. For 24-bit you want a few hundred K free. (But to achieve that 
might require losing 1MB of 24-bit private, which might not be consequence 
free.)

For 31 bit I like to see at least 100MB free ECSA, preferably more. The reason 
is because ECSA is - in my experience - more volatile.

Speaking of volatility, you need to plan defensively - as a problem can lead to 
surge in SQA and CSA usage .

Final point: I would advocate using SMF 78-2 to build a picture of common 
storage usage - and how variable it is. Here is a blog post I wrote on the 
matter:

htt ps://mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage

(Take out the space to follow the URL - as my mail client turned it into an 
attachment.) 

Cheers, Martin

Sent from my iPad

> On 26 Nov 2023, at 05:40, Peter  wrote:
>
> Hello
>
> I am able to see the below alert condition under RMF postprocessor III
>
>
>
> Name Reason Critical val. Possible cause or action
>
> *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K.
>
>
>
>
>
> Our SQA and CSA set up in our IEASYSxx is as below
>
>
>
> CSA=(2000,30)
>
>
>
> SQA=(16,192)
>
>
> Hardware: z14
> LPAR : 16gb memory
> zOS 2.4
>
> Do I have think about tunning the SQA parameter ?
>
> Regards
> Peter
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598 Registered office: PO Box 
41, North Harbour, Portsmouth, Hants. PO6 3AU


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

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


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


Re: SQA overflow condition

2023-11-27 Thread Allan Staller
Classification: Confidential

Yup!. I could spend about a 1/2 hour typing up the pros/cons of that tuning. 
Almost a short story in length.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Saturday, November 25, 2023 11:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SQA overflow condition

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello

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



Name Reason Critical val. Possible cause or action

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





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



CSA=(2000,30)



SQA=(16,192)


Hardware: z14
LPAR : 16gb memory
zOS 2.4

Do I have think about tunning the SQA parameter ?

Regards
Peter

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

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


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


Re: UNIX REXX LINKMVS TASKLIB?

2023-11-27 Thread Allan Staller
Classification: Confidential

SMS CAN most certainly control temp DS's. I can't say with certainty that this 
will apply to OMVS files.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Thursday, November 23, 2023 11:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UNIX REXX LINKMVS TASKLIB?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On Fri, 24 Nov 2023 00:10:18 +, Seymour J Metz  wrote:

>if you insist on using VOL=SER=foo for a temporary, it will work.

Cleanup of the public volumes is unpredictable. Normal users should never learn 
about VOL=SER especially for temporary datasets.

> IMHO, it's best to let SMS do its thing.

Unless things have changed, SMS does not control temporary datasets. The system 
places them on volumes mounted public or storage bypassing the need for SMS.

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

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


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


Re: Messaeg IXC531I SETXCF START ALTER REQUEST FOR STRUCTURE REJECTED. REASON: STRUCTURE NOT ALLOCATED

2023-11-27 Thread Allan Staller
Classification: Confidential

A connection from the application

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Thursday, November 23, 2023 7:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Messaeg IXC531I SETXCF START ALTER REQUEST FOR STRUCTURE REJECTED. 
REASON: STRUCTURE NOT ALLOCATED

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I am new to setting up the XCF.

The policy1 containing the structure is active.

D XCF,STR,STRNAME=
IXC360I  06.17.28  DISPLAY XCF 501
STRNAME: 
 STATUS: NOT ALLOCATED
 POLICY INFORMATION:
  POLICY SIZE: 5 M
  POLICY INITSIZE: 3 M
  POLICY MINSIZE : 0 M
  FULLTHRESHOLD  : 80
  ALLOWAUTOALT   : NO
  REBUILD PERCENT: 5
  DUPLEX : DISABLED
  ALLOWREALLOCATE: YES
  PREFERENCE LIST: SVCF
  ENFORCEORDER   : NO
  EXCLUSION LIST IS EMPTY


I haven't figured out the command to make the structure active.

What might I be missing?

--
Binyamin Dissen 
http://www.dissensoftware.com/

Director, Dissen Software, Bar & Grill - Israel

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

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


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


Re: Kinda fun

2023-11-08 Thread Allan Staller
Classification: Confidential


Keypunches persisted at University of Waterloo until the early 80s, not because 
the U was backward, but because ONE prof (not my dad!) insisted on using them. 
IIRC the I/O operators (remember them?) tried various stunts, like 
"accidentally" dropping his box of cards (only it wasn't really) in front of 
him and then stepping on them


A similar story at Hughes Aircraft up until the mid 90's. One (1) user insisted 
on use of punched cards. This is in pre-ficon days.
Unfortunately, the data center did not have the cojones to charge the user.
The day he retired, the project was initiated to remove the keypunches and 
disconnect the 2503(?) card/reader punch.

In those days, the limit on bus/tag cables was 200 ft (cumulative). IIRC, that 
particular block multiplexer was running about 190 ft.
De-installing the 2503 saved about 125 ft.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, November 8, 2023 8:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Kinda fun

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Bob Bridges wrote about his history with keypunches.

Mine started in 1965, when I was four. My dad was working on his first 
concordance, of Beowulf, and my mom was going to do the data entry of the text. 
(They'd met in the 50s when he was working for a CIA front doing translation 
and his typist quit. He told them, "I need a new typist, but don't give me 
anyone interesting", and when they brought her in, he thought, "Dammit, nobody 
listens to me around here!" Nine months later they were married.)

So I got to play with a keypunch at a very young age, and then again starting 
in 1975 when I sat in on my dad's PL/C class at the University. I have fond 
memories of playing outside with a bag of chad (please, not "chads"-it was a 
mass noun for 50 years; the 2000 election instantly made it a count noun, but 
we old-timers don't have to put up with that). (Jeez, even Office thinks it 
should be "chads". Kids today.)

Bob, your musing about communications parameters sounds like full/half duplex.

As for the cost of cards-I bought a few boxes on eBay about a decade ago. Even 
then folks were often selling individual cards for several dollars. I still 
have a bunch. My dad always had them in his breast pocket for note cards. He'd 
also always heard that they were the same size as old U.S. bills, but in the 
pre-Internet era had no easy way to verify that. Until one day in the late 80s, 
walking in lower Manhattan, he passed a numismatic store that had an old $1 
bill taped to the inside of the window. He instantly whipped out a card and 
held it up, and sure 'nuff, it was the same size, modulo the clipped corner, of 
course!

Keypunches persisted at University of Waterloo until the early 80s, not because 
the U was backward, but because ONE prof (not my dad!) insisted on using them. 
IIRC the I/O operators (remember them?) tried various stunts, like 
"accidentally" dropping his box of cards (only it wasn't really) in front of 
him and then stepping on them as they went to pick them up. They finally 
managed to get approval to tell him HE would have to pay for the maintenance. 
That cured it.

Don't miss https://www.masswerk.at/keypunch/ !


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

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


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


Re: IBM APAR Names

2023-11-06 Thread Allan Staller
Classification: Confidential

In my experience, the 1st letter of the APAR name is a "version" designator.
e.g. JES2 has historically had many variants of a "single product".

So the APAR "documentation" designation would be OAx.
An actual "APAR FIX" (with test code) for the "1st version" would receive an 
actual apar number of AAx (x is the same number).
Due to code changes between the releases, a 2nd version is required. (i.e. same 
problem, different code). The "2nd version" would receive the designation 
BAx.
After the vetting process is completed, A PTF (or several) will be issued with 
UA SUPing the relevant APAR number).
e.g.  ++PTF(UAx) SUP (AAx, BBx).

My USD $0.02 worth,

::DISCLAIMER::

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


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


Re: Does IBM file manager let you access panvalet

2023-10-24 Thread Allan Staller
Classification: Confidential

That is not an option I would undertake.
Last I heard both Panvalet and Endeavour are both CA (Compuware)  which is what 
prompted the bill,
And the question in this thread.

My opinion is that BMC is behaving like the CA of the late 80's, early 90's.
How many installations decided to dump CA at that time?

My USD $0.02 worth.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Attila Fogarasi
Sent: Tuesday, October 24, 2023 4:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Does IBM file manager let you access panvalet

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

https://www.ibm.com/docs/en/file-manager-for-zos/14.1?topic=libraries-accessing-source-code-in-ca-panvalet

Your other option is to convert Panvalet to Endevor (easy to do as Endevor 
supports the 10 character names that Panvalet has).  Either way it wll be much 
cheaper than BMC.

On Tue, Oct 24, 2023 at 2:15 PM Brian Westerman < 
brian_wester...@syzygyinc.com> wrote:

> Hi,
>
> Does IBM file Manager let you access (i.e. browse) Panvalet datasets
> like the old Compuware File-aid product?  One of our clients is
> getting a huge bill from BMC (they bought Compuware), and they are
> thinking about replacing File-Aid with IBM File Manager.  One of the
> things they use File-Aid for is to read Panvalet (they don't have the
> panvalet ISPF panel option).  I jsut want to make sure that File
> Manager has no issues with reading the panvalet datasets similar to how 
> file-aid does it.
>
> I have File-Manager here, but I don't have Panvalet so I can't tell if
> they are compatible.
>
> Thanks for your help.
> Brian
>
> --
> 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
::DISCLAIMER::

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


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


Re: DVIPA question

2023-10-24 Thread Allan Staller
Classification: Confidential

My presumption is that a data-sharing partner "myserverb" is up and running on 
LPARB. In this case, the transfer is pretty much unnoticeable.

After the transfer of the DVIPA, all new traffic will be routed to 
LPARB/myuserverb. LPARA/myservera will 'wither on the vine.
If LPARA/myservera are shut down too quickly, any users connection to 
LPARA/myservera will be terminated prematurely and cause a perceived outage.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John S. Giltner, Jr.
Sent: Monday, October 23, 2023 9:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DVIPA question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Some situations may require manual intervention.  That that could be done 
through automation.

Some situations may involve noticeable outage outage to the user.


It all depends on how it is setup and how you want to move the task.

Say you have LPARA and LPARB and task "myserver" normally runs on LPARA.

Do you want it to move to LPARB only when LPARA is shutdown and move back when 
LPARA comes back up?

Or do you want to be able to move "myserver" to LPARB while LPARA is still up?

Or a both?

Do you want to prevent "myserver" from running on both at the same time?

You may want to read up on how  TCPIP's Sysplex distributor works.  Although it 
is designed so to have multiple server tasks up at the same time, you can use 
it and just have one task up and running.normally move it from one LPAR to 
another as needed.


On Mon, 23 Oct 2023 11:51:04 +, Allan Staller  wrote:

>Classification: Confidential
>
>I agree, the secondary application must be running on the other LPAR.
>
>I have physically tested this is a prior life and the transition is 
>(apparently) seamless to the end user.
>In that environment, although the cutover was triggered manually, it 
>worked flawlessly, I also (in that environment) simulated an OSA failure by 
>"pulling the plug" on the specific Ethernet cable involved.
>This (again) worked flawlessly, and (apparently) unnoticed by the end 
>user,
>
>
>-iriginal Message-
>From: IBM Mainframe Discussion List  On 
>Behalf Of Jon Perryman
>Sent: Friday, October 20, 2023 11:41 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DVIPA question
>
>[CAUTION: This Email is from outside the Organization. Unless you trust 
>the sender, Don’t click links or open attachments as it may be a 
>Phishing email, which can steal your Information and compromise your 
>Computer.]
>
>On Fri, 20 Oct 2023111:55:17 +, Allan Staller  
>wrote:
>
>> The difference iis n starting/stopping the application is a service 
>> interruption to the end user.
>> The DVIPA activate/deactivate would be seamless to the end user
>
>DVIPA activate/deactivate isn't seamless. First, it would require the 
>application be running on the second LPAR running in standby mode. Second, 
>current connections are interrupted unless the application has been designed 
>to circumvent the problem. Third, you still have a time frame where the 
>application is still unreachable albeit very small hopefully.
>
>Each situation is different and a decision about which method best solves the 
>problem must be made. The OP said his application can only be active on one 
>LPAR. In that case, using activate/deactivate would not provide an advantage 
>although it would work equally as well..
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>::DISCLAIMER::
>
>The contents of this e-mail and any attachment(s) are confidential and 
>intended for the named recipient(s) only. E-mail transmission is not 
>guaranteed to be secure or error-free as information could be intercepted, 
>corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
>in transmission. The e mail and its contents (with or without referred errors) 
>shall therefore not attach any liability on the originator or HCL or its 
>affiliates. Views or opinions, if any, presented in this email are solely 
>those of the author and may not necessarily reflect the views or opinions of 
>HCL or its affiliates. Any form of reproduction, dissemination, copying, 
>disclosure, modification, distribution and / or publication of this message 
>without the prior written consent of authorized r

Re: DVIPA question

2023-10-23 Thread Allan Staller
Classification: Confidential

I agree, the secondary application must be running on the other LPAR.

I have physically tested this is a prior life and the transition is 
(apparently) seamless to the end user.
In that environment, although the cutover was triggered manually, it worked 
flawlessly,
I also (in that environment) simulated an OSA failure by "pulling the plug" on 
the specific Ethernet cable involved.
This (again) worked flawlessly, and (apparently) unnoticed by the end user,


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Friday, October 20, 2023 11:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DVIPA question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On Fri, 20 Oct 2023 11:55:17 +0000, Allan Staller  wrote:

> The difference iis n starting/stopping the application is a service 
> interruption to the end user.
> The DVIPA activate/deactivate would be seamless to the end user

DVIPA activate/deactivate isn't seamless. First, it would require the 
application be running on the second LPAR running in standby mode. Second, 
current connections are interrupted unless the application has been designed to 
circumvent the problem. Third, you still have a time frame where the 
application is still unreachable albeit very small hopefully.

Each situation is different and a decision about which method best solves the 
problem must be made. The OP said his application can only be active on one 
LPAR. In that case, using activate/deactivate would not provide an advantage 
although it would work equally as well..

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

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


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


Re: DVIPA question

2023-10-20 Thread Allan Staller
Classification: Confidential

Either method would be successful in moving the workload. The difference iis n 
starting/stopping the application is a service interruption to the end user.
The DVIPA activate/deactivate would be seamless to the end user.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Thursday, October 19, 2023 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DVIPA question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On Thu, 19 Oct 2023 12:08:04 +, Allan Staller  wrote:

>That is not correct. The DVIPA and be started/stopped in a specific TCPIP 
>instance.
>IIRC, the commad is something like V
>TCPIP,,SYSPLEX,ACTIVATE,DVIPA=xx.xx.xx.xx
>There is also a DEACTIVATE parameter as well.

John Giltner says he stops his app on one LPAR and starts it on another. He 
implies that he is not issuing activate/deactivate for the DVIPA address. It 
would make more sense for IBM to automatically deactivate the address when it 
has no ports in use and to automatically activate it when the first listener 
starts.

There are times when activate / deactivate command is needed. For instance, you 
may have applications running in case of failover recovery but you don't want 
them used until the other system fails. Recovery would only need to activate 
the address without the need to startup the applications and resources.

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

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


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


Re: Extracting SMP/e details

2023-10-20 Thread Allan Staller
Classification: Confidential

There is a REXX? API available. Check the fine manuals.

An alternative would be SMPLIST and parse the output with the tool of you 
choice.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lizette Koehler
Sent: Thursday, October 19, 2023 9:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Extracting SMP/e details

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I need a simple process to get the following out of SMP/e

PTF. Fmid. Date received. Date applied

I am thinking of writing a Rexx or icetool to read a listing to produce the one 
liners

Just wanted to check here to see if there was a better way

I have not found much on cbttape

From time to time I need to show when fixes went in. So this just needs to be a 
simple report

Thanks

Sent from EarthLink Mobile mail


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

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


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


Re: Programatically setting JCL symbols

2023-10-19 Thread Allan Staller
Classification: Confidential

I believe you need to clarify the following.
Are these JCL symbols or SYSTEM symbols.

System symbols can be change dynamically (as of z/OS 2.1; prior to 2.1 via 
unsupported utilkity).
I am unaware of any method to change JCL symbols directly.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Hardee
Sent: Thursday, October 19, 2023 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Programatically setting JCL symbols

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

My apologies, I didn't mean to stir up the hornet's nest of opinions on the 
viability of my question.

I will "grossly" explain what I want to do.
I am not interested in other methods, I have other methods, but I am interested 
in this method the most, if it can be done.

Program A executes and sets a global symbol to a certain value and terminates.
Many other jobs execute and, in each one, as needed, the programs check to see 
if the global symbol is set and, if it is, to what value.
They then make logic path decisions within the program based on the value of 
the global symbol.
Finally, Program B runs, or maybe it's just Program A again, and the global 
symbol is deleted.

So, my question is, still, is it possible to define SET symbols from within a 
program?

Thanks, again, in advance for any *constructive* assistance.
Chuck

On Thu, Oct 19, 2023 at 2:26 AM Lennie Dymoke-Bradshaw < 
032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:

> Yes, I did mean that. My bad for sending a note late at night when I'm
> tired.
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: 18 October 2023 23:56
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Programatically setting JCL symbols
>
> On Wed, 18 Oct 2023 22:53:05 +0100, Lennie Dymoke-Bradshaw wrote:
>
> >On the other hand they can be passed to another job via the internal
> reader specified with the SYMBOLS parameter.
> >For example,
> >//INTRDR   DD  *,SYMLIST=*
> >It could make sense in this instance.
> >
> ITYM:
> // EXPORT SYMLIST=*
> ...
> //INTRDR   DD  SYSOUT=(,INTRDR),SYMBOLS=JCLONLY
>
> It's possible the OP wants to pass values between steps.  The
> guaranteed way to do that is with a temporary data set.
>
> There was s discussion here lately of environment variables.
> Questions I never saw clearly answered:
>
> o Are environment variables available to any program, regardless of
> language?
>
> o Do they require LE or C RTL?
>
> o Do they endure from step to step?
>
> o Are they rooted with WXTRN environ and structured as in POSIX?
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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


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


Re: DVIPA question

2023-10-19 Thread Allan Staller
Classification: Confidential

That is not correct. The DVIPA and be started/stopped in a specific TCPIP 
instance.
IIRC, the commad is something like V TCPIP,,SYSPLEX,ACTIVATE,DVIPA=xx.xx.xx.xx
There is also a DEACTIVATE parameter as well.

Don't ask me for the exact syntax. I haven't looked it up and it has been 
several years since I have been in the environment.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Wednesday, October 18, 2023 10:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DVIPA question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On Wed, 18 Oct 2023 17:18:33 +, Allan Staller  wrote:

>Agreed, however it seems the OP is operating in a "toggle-plex" i.e. either 
>LPAR A is running or LPARB is running. In this case, the DVIPA would be 
>deactivated on one of the LPARS and switched manually via the V TCPIP command 
>to activate/deactivate the DVIPA on LPARA or LPARB.
>
>The "old LPAR" will automatically switch to backup mode when the "new LPAR" is 
>changed from backup to active.

The way I read the OP's response, he says everything is handled in the OSA and 
TCP automatically notifies the OSA when changes affect packet routing.

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

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


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


Re: DVIPA question

2023-10-18 Thread Allan Staller
Classification: Confidential

Agreed, however it seems the OP is operating in a "toggle-plex" i.e. either 
LPAR A is running or LPARB is running. In this case, the DVIPA would be 
deactivated on one of the LPARS and switched manually via the V TCPIP command 
to activate/deactivate the DVIPA on LPARA or LPARB.

The "old LPAR" will automatically switch to backup mode when the "new LPAR" is 
changed from backup to active.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Art 
Zeigler
Sent: Tuesday, October 17, 2023 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DVIPA question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

If the VIPA is set correctly, then the data can dynamically move between the 
two LPARs so the workload is balanced across the two LPAR servers.  I did that 
with MQ and shared queues.  Messages rotated between the two MQ managers and if 
one system went down, the other system continued to handle the message traffic.

Art Zeigler


From: IBM Mainframe Discussion List  on behalf of 
Laurence Chiu 
Sent: Tuesday, October 17, 2023 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: DVIPA question

That is exactly the situation, The second LPAR will be on the same CEC as the 
first, share OSA adapters and be in a sysplex with XCF being the mechanism to 
share the VIPA information. From my reading of the docs, when the server 
application on the primary LPAR is shutdown, and an incoming transaction 
arrives for it, TCP on the second LPAR will see the primary host and 
dynamically route the transaction to the server on the second LPAR. By making 
it dynamic we don't hae to worry about automation moving the VIPA, we can let 
TCP do that.

The second LPAR will be in the same subset as the first.

Youi comment about OMPROUTE is noted.

Thanks

On Wed, Oct 18, 2023 at 1:05 AM John S. Giltner, Jr. 
wrote:

> In addition to everything Jon has stated a few other questions may
> help figure out what needs to be done, or not done.
>
> Are both LPARS on the same CEC?
>
> If both LPARS are on the same CEC, do they share OSA's?
>
> Are the IP addresses you plan to use as VIPA's in the same subnet as
> the OSA's IP addresses?
>
> With certain setups you may need to run OMPROUTE configured for OSPF.
>
> I think if both LPAR's are on the same CEC and they share OSA's and
> the VIPA addresses are in the same subnet as the OSA's, there is not
> much to do, but to configure both TCPIP stacks with the same VIPA
> range and then with PORT definitions assign what VIPA address you want
> that application to 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
::DISCLAIMER::

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


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


Re: CA-1 Withdrawl from z/OS 2.5

2023-09-29 Thread Allan Staller
Classification: Confidential

1) start TMSINIT and reply with the "shutdown" password.
2) dynamically remove the TMS subsystem. (update parmlib,. as needed)
3) namoicall remove TMS load libraries from lnklst, apf,  the TMS loadlibs 
are typically in lnklst.
4) rename TMC and audit files

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gorlinsky
Sent: Thursday, September 28, 2023 4:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CA-1 Withdrawl from z/OS 2.5

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

We are investigating what is necessary to remove CA-1 from the system after 
turning on RMM in protect mode.

My original plan was to us TMSINIT to remove CA-1 and disable the PROC 
(TMSINIT) prior to starting DFRMM...

Or do I need to move it's SVC, re-IPL and not start TMSINIT and then start 
DFRMM...

Any help would be appreciated 

Thanks
Paul

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

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


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


Re: Retrieve LPAR weight without BCPii HWIQUERY ?

2023-09-28 Thread Allan Staller
Classification: Confidential

Look at the code in SHOWZOS on the CBTTAPE. WWW.CBTTAPE.ORG

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Boesel Guillaume
Sent: Thursday, September 28, 2023 8:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Retrieve LPAR weight without BCPii HWIQUERY ?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi,

With HWIQUERY, I'm able to retrieve the weight of a LPAR but, of course, it 
doesn't work if BCPii is not started.

Mainview (LPARACT view) or Sysview (PRISM command) are able to retrieve this 
information on LPARs without BCPii.

Is somebody could help me to understand how products like Mainview or Sysview 
are able to retrieve the weight of a LPAR without BCPii ?

Thank you for your help,
Regards

Guillaume

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

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


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


Re: IBM-MAIN Posting Guidelines

2023-09-18 Thread Allan Staller
Classification: Confidential

Thank you, Darren

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Roberto Halais
Sent: Sunday, September 17, 2023 5:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN Posting Guidelines

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Thank you

On Sun, Sep 17, 2023 at 6:33 PM Doug Fuerst  wrote:

> Finally. Thanks Darren.
>
> Doug Fuerst
> Principal Consultant
> BK Associates
> 718.921.2620 (O)
> 917.572.7364 (C)
> d...@bkassociates.net
>
>
> -- Original Message --
> From "Darren Evans-Young"  To IBM-MAIN@LISTSERV.UA.EDU
> Date 9/17/2023 17:48:07 PM Subject IBM-MAIN Posting Guidelines
>
> >First, I would like to apologize to the list for not being a better
> >list
> owner.
> >Life has been busy.
> >
> >I've had numerous complaints about some postings on the list.
> >So, here's the deal. All posts WILL be directly related to IBM
> >Mainframe
> topics.
> >No discussions of religion, politics, etc.  No name calling, insults,
> etc. Respect
> >each other.
> >
> >Failure to adhere to these simple basic guidelines will result in
> >being
> set
> >to REVIEW and/or removal from the list.
> >
> >Darren
> >
> >-
> >- 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
::DISCLAIMER::

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


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


Re: AI expert hot new position.

2023-09-13 Thread Allan Staller
Classification: Confidential

PKB

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Tuesday, September 12, 2023 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AI expert hot new position.

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

David so badly wants his dying art to be important because it makes him feel 
superior. Textbook narcissist.


Sent from Yahoo Mail for iPhone


On Tuesday, September 12, 2023, 8:58 AM, David Crayford  
wrote:

> On 12 Sep 2023, at 8:04 pm, Jon Butler  wrote:
>
> There will be a need for assembler programmers for quite a while,

YEAH! z/OS syscalls are assembler macros! No HLASM no z/OS. The sheer volume of 
assembler code is an existential threat to the platform as young guys don’t 
want to spend 10 years onboarding.

> but mainly because over the last forty years, and long after even COBOL II 
> added functions and a case construction in 1987, very, very  clever people 
> decided they would write application modules in assembler... and not waste 
> time with comments.  Today, when companies are trying to make their systems 
> Highly Available...or even convert to a cloud provider's service...no one has 
> a clue what the modules do.  Many could have been easily replaced by COBOL's 
> ADDRESS OF or LENGTH OF or PL/I Pointers, but of course that would have been 
> way too easy.  Very few application programs need to control channels.
>
> When I was interviewed by the Db2 Utilities group at the Santa Teresa lab in 
> San Jose (Now Silicon Valley) in 2001, I said I suppose I needed to brush up 
> on my assembler.  They laughed and said "no one uses assembler any more."  
> All the Utilities were written in PL/S, now PL/X.

DB2 Utilities got sold a vendor and the devs moved with it. I heard an amusing 
story that IBM were hell bent on migrating to OO PL/X which was so buggy the 
CICS team in Hursley referred to it as “oh oh PL/X”. It was in the 90’s when 
everybody thought inheritance was a good idea but it introduced “is-a hell” and 
the path length of the code exploded. It was so bad that DB2 utilities were 
close to missing their targets and abandoned it. It was a huge blunder. A lot 
of new code in DB2 Utilities is done Metal/C/

>
> Not to denigrate assembler programmers, or those that decide to take up 
> Sanskrit, but it is a dying art.

Yep. For new code avoid it like the plague. But the legacy needs to be 
maintained.

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

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


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


Re: z/OSMF and the Old Timer

2023-09-12 Thread Allan Staller
Classification: Confidential

FWIW, I do not use *any* cataloged dataset for SMP/E Targets/DLIBDS. During 
installation, I took the time to update all of the DDDEFS with VOLSER 
information.

M USD $0.02 worth.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Longfellow
Sent: Monday, September 11, 2023 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF and the Old Timer

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Thanks Kurt.
It is comforting to know that I can still punch my way out of a paper bag.

I took the 'clear the catalog' approach for the Dlibs.It was not totally 
clear sailing.   Still haunted by data set decisions and location choices made 
(literally) decades ago.

I am now at the Post Deploy options to build and integrate my other products 
and local mods into an IPLable system.

Onwards and upwards.

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

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


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


Re: SMF Extract Using to find the user id who deleted datasets

2023-09-05 Thread Allan Staller
Classification: Confidential

SMF type 17 records
I strongly suggest the DAF program form the CBT tape.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sathish Kumar
Sent: Monday, September 4, 2023 9:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF Extract Using to find the user id who deleted datasets

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi Team,

One of our system datasets someone deleted we are not sure who deleted those 
datasets.  How we can find which user ID deleted a dataset?

I tried to run the SMF extract job using record type 65 but was not able to 
find it.

Pls suggest me

Thanks

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

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


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


Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]

2023-08-28 Thread Allan Staller
Classification: Confidential

"You never see a PTF that is 1MB"

JAVA SDK's ?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Friday, August 25, 2023 8:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

> On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson 
>  wrote:
> With Linux distros there are a few maint systems. The one I am most
> familiar with is RPM.

Linux (nor Unix) does NOT have any maint systems. P in RPM stands for Package 
which is the z/OS equivalent of product / component. Complete packages are 
replaced regardless of the problems you want to fix. Every package has a 
version number which is indentifies all the maintenance included in that 
package.

> To me YAST (the Linux equivalent of SMP/E) handles upgrades

YAST and SMP/e have nothing in common. YAST tells you it's about installation 
and configuration. It's about replacing the entire package and nothing to do 
with maintaining that package. The M in SMP/e stands for Maintenance. You never 
see a PTF that is 1MB. The only reason SMP/e installs, is to create a 
maintenance environment for the product / component. If installation is your 
only requirement, then use a different tool like IEBCOPY, DFDSS or ???.

> Each product/component has its own main entry and dependencies.

Unix dependencies are by version number and have nothing to do with the package 
(product/component) in question. The package is completely replaced. SMP/e 
dependencies can be for entities within the same function, other functions, 
PTFs and APARs. A function is the SMP/e equivalent of a Unix package.

> I thought it was a fairly good replacement for SMP/E for the Linux
> side of things.
> I can see how it could be used to do z/OS and related.

YAST, RPM and other Unix package installers are unacceptable replacements for 
SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an entire 
product/component because they need 1 PTF. Add to that cascading product 
installs because of dependencies. Worse than that, testing must include 
everything that changed in those installs and every product/component that 
interacts with all the installed products/components.

I think z/OS uptime is 99.%. You get what you pay for. Unix maint 
philosophy may be acceptable on $10,000 computers but highly unacceptable on 
multi-million $ computers. We don't tolerate unintentional downtime.

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

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


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


Re: XCFAS and TRUSTED

2023-08-21 Thread Allan Staller
Classification: Confidential

The TRUSTED attribute usually comes along with  an ID that cannot be "logged on 
to", so, it is not available for manipulation.
By this time, auditors should be fully conversant in te trusted attribute.
I don't see an issue here.

My USD 0.02 worth.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Saturday, August 19, 2023 4:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: XCFAS and TRUSTED

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I'm setting up some sysplex and found some healthcheck is not OK, the reason 
was XCFAS was not TRUSTED.
Questions:
1. Is the requirement of the TRUSTED status documented anywhere? That's good to 
know before auditor asked.
2. Is there any way to fix it without reIPL?
3. Somehow related to 2.  - IMHO actually it is not matter of the attribute, 
but the matter of access to some resources. Are the resources needed for XCFAS 
documented/known ?


--
Radoslaw Skorupka
Lodz, Poland

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

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


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


Re: [EXT] Re: Cloud may be overpriced compared to on-premises systems

2023-08-09 Thread Allan Staller
Classification: Confidential

To all,
Stop feeding the troll and maybe he'll go away

::DISCLAIMER::

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


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


Re: DD SYSOUT=(,),DSN=?

2023-08-09 Thread Allan Staller
Classification: Confidential

SYSOUT= & DSN= are mutually exclusive on a given DD statement. Not possible.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, August 8, 2023 2:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DD SYSOUT=(,),DSN=?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

How should the user code
DD SYSOUT=(,),DSN=

in order that the last qualifier of the system-generated name for the sysout 
data set be the user ID under whose authority the job runs?

How many ampersands?  How many apostrophes?  Is it even possible?

--
gil

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

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


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


Re: [EXT] Re: Cloud may be overpriced compared to on-premises systems

2023-08-09 Thread Allan Staller
Classification: Confidential

Bill,
Why don't you move there?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Tuesday, August 8, 2023 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Re: Cloud may be overpriced compared to on-premises systems

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

You’re right, Europe is different. They actually care about people over 
profits. Much better infrastructure, better health care, and better quality of 
lives.


Sent from Yahoo Mail for iPhone


On Tuesday, August 8, 2023, 10:34 AM, Jay Maynard  wrote:

In case you haven't noticed, the US is much, much different from Europe, in 
many ways big and little that bear on this discussion.

But, in typical Bill Johnson fashion, he's convinced he's right and will defend 
his opinions, well-informed or not, to the death.

On Tue, Aug 8, 2023 at 9:29 AM Bill Johnson < 
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Lol, you should have followed your own advice. My dad drove truck his
> whole life. Never once did wind cause an issue. Yeah, it happens, but
> not frequently. And American roads are way more dangerous than European roads.
> The data (facts) are clear. So profit over lives is a Republican choice.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, August 8, 2023, 10:20 AM, Steve Thompson 
> wrote:
>
> I've driven in Germany, Austria and Switzerland and some island
> countries. And I held, for over 15 years a CDL-A with Multi and Tanker
> endorsements.
>
> I did not drive LKW (semis) anywhere but within the USofA. And a box
> truck once into Canada.
>
> Stick to what you know, not what what the Huffy post or others say.
>
> Governors are used by different companies. Some limit their trucks to
> 64MPH. Owner operators can get their trucks with no governors at all.
>
> I have a son-in-law that is finishing his training to be a Diesel
> mechanic able to work on all the current Tractors in the USofA.
> The electronics are unbelievable, and can cause that truck to be down
> for weeks waiting on some solid state relay board (or whatever). The
> world of trucking has changed significantly since I started driving
> back about 2004.
>
> Because I'm also a pilot, I know a bit about wind and its effects.
> Stick to what you know, what you have experienced.
>
> I've seen fully loaded trucks get blown over (55,000+ gross).
> I've seen trucks lose control in snow and swap ends. Managed to not
> jack knife.
>
> Thankfully I never had any problems, no accidents, no incidents.
> I was lucky and I was a novice and just applied my knowledge of
> physics and energy management that I learned in flying to driving a
> 70,000 gross weight truck. I loaded the trucks so the weight was more
> at the bottom than top (I had specialty loads of barn beams).
>
> Stick to what you know.
>
> Take this crap out of here and go argue it elsewhere.
>
> Steve Thompson
>
>
>
> On 8/8/2023 9:07 AM, Bill Johnson wrote:
> > I’ve driven roads in Europe. Every truck is in the right most lane,
> unless they are passing which isn’t common. It’s nothing like the US
> trucking which is designed for large trucks and fast speeds. That’s
> exactly why the carnage on US highways from trucks is way higher. And
> wind as an excuse is just silly. Or speed differential.
> > In Germany and other European Union counties, trucks with a gross
> vehicle weight rating of 3.5 tonnes (7,700 pounds) or more must have a
> governor that limits their speed to 90 kph (54 miles per hour).
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Tuesday, August 8, 2023, 3:52 AM, Jeremy Nicoll <
> jn.ls.mfrm...@letterboxes.org> wrote:
> >
> > On Tue, 8 Aug 2023, at 01:56, Bill Johnson wrote:
> >> In Europe all the trucks go the same speed.
> > Rubbish.  Age of truck and how heavy its load is are certainly factors.
> >
> > An unloaded truck, is a lot more susceptible to high winds so might
> > be driven slower in those conditions; trucks with no load with
> > curtain- sides often have their curtains open in high winds to
> > significantly reduce wind effects.  But that's impossible if there's
> > a partial load or nowhere safe for the driver to open (and tie back) the 
> > curtains.
> >
> >> The trucks all have governors.
> > No they don't.  Some do.  Even so it sets a maximum speed not the
> > actual speed.
> >
> >> They are also all in the right lane.
> > By "right" do you mean "correct"?  Or do you mean the slowest lane?
> > In any case trucks are permitted to be in the next fastest lane
> > while overtaking a slower truck.
> >
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

Re: z/OS performance question

2023-08-07 Thread Allan Staller
Classification: Confidential

In that case, either the capacity  (or weight) of the LPAR will need to be 
increased, or as another suggested, give access to another CP.
The only other thing you can do is get with the DB2 folks to see if they can do 
something with the restore process.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
rpinion865
Sent: Monday, August 7, 2023 7:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS performance question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

While adjusting the WLM definitions might help TSO, I would like to add that I 
put my TSO userid in SYSSTC.  Even running in that service class my TSO 
response is sluggish.




Sent with Proton Mail secure email.

--- Original Message ---
On Monday, August 7th, 2023 at 8:30 AM, Allan Staller 
<0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:


> Classification: Confidential
>
> Ok. You zre using 2 period TSO Service Defs. I suggest you adjust the period 
> 1 duration until 96% (vs. 90%) of transactions end in period one.
> There is no easy way to measure this in advance. The RMF Service Class Period 
> report will however show the results after the fact.
>
> Increase the duration of period one and look at the RM report. Wash, rinse, 
> repeat until the desired goal is achieved. Beyond that, I do not believe 
> there can be much done. IIRC the DB2MSTR address space either runs at IMP 1 
> or in the SYSSTC service class.
>
> Speculating (I am not a DB2 expert) if commits can be take during the 
> restore, it might help.
>
> Wish I could help more.
>
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf 
> Of rpinion865
>
> Sent: Friday, August 4, 2023 12:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS performance question
>
> [CAUTION: This Email is from outside the Organization. Unless you 
> trust the sender, Don’t click links or open attachments as it may be a 
> Phishing email, which can steal your Information and compromise your 
> Computer.]
>
> I am working with the Development LPAR (SC08D3). Below is the TSO service 
> class definition for that LPAR.
>
> Service Class Name . . . . . : TSOSC
>
> Description . . . . . . . . . TSO Production and Development
>
> Workload Name . . . . . . . . TSO (name or ?)
>
> Base Resource Group . . . . .  (name or ?)
>
> Cpu Critical . . . . . . . . . NO (YES or NO)
>
> I/O Priority Group . . . . . . NORMAL (NORMAL or HIGH)
>
> Honor Priority . . . . . . . . DEFAULT (DEFAULT or NO)
>
>
>
> Specify BASE GOAL information. Action Codes: I=Insert new period,
>
> E=Edit period, D=Delete period.
>
>
>
> -- Period -- --- Goal ---
>
> Action # Duration Imp. Description
>
> __ _ _ _ 
>
> __ 1 500 1 90% complete within 00:00:00.060
>
> __ 2 _ 4 Execution velocity of 40
>
> Next, is a mangled text view of the Development (SC08D3) LPAR definition.
> Customize Image Profiles: Z15A:SC08D3 : SC08D3 : Processor Turn on context 
> sensitive help.
> Collapse Z15A:SC08D3
> Collapse SC08D3
> General
> Processor
> Security
> Storage
> Options
> Load
> Crypto
> Group Name
>
> 
>
> Open or close the list box
> Logical Processor Assignments
> Dedicated processors
> Select
> Processor Type
> Initial
> Reserved
> Selected
> Central processors (CPs)
> 1
> 0
> Selected
> z Integrated Information Processors (zIIPs)
> 1
> 0
> Not Dedicated Processor Details for:
> CPs
> zIIPs
> CP Details
> Initial processing weight
> 60
> 1 to 999
> Initial capping
> Enable workload manager
> Minimum processing weight
> 0
> Maximum processing weight
> 0
> Absolute Capping
> None
> Number of processors
> (0.01 to 255.0)
> 0.18
>
>
>
>
>
> Sent with Proton Mail secure email.
>
>
> --- Original Message ---
> On Thursday, August 3rd, 2023 at 12:17 PM, Allan Staller 
> 0387911dea17-dmarc-requ...@listserv.ua.edu wrote:
>
>
>
> > Classification: Confidential
> >
> > You did not say where the TSO response time issues were being observed. I 
> > suspect, from the information provided it is on SC08D3(possible) or SC14D4 
> > (most likely).
> >
> > If you look, I suspect the majority of CPU consumption is from the *MSTR 
> > DB2 address space. DB2 will charge this back to the "user". This ad

Re: z/OS performance question

2023-08-07 Thread Allan Staller
Classification: Confidential

Ok. You zre using 2 period TSO Service Defs. I suggest you adjust the period 1 
duration until 96% (vs. 90%) of transactions end in period one. 
There is no easy way to measure this in advance. The RMF Service Class Period 
report will however show the results after the fact.

Increase the duration of period one and look at the RM report. Wash, rinse, 
repeat until the desired goal is achieved. Beyond that, I do not believe there 
can be much done. IIRC the DB2MSTR address space either runs at IMP 1 or in the 
SYSSTC service class. 

Speculating (I am not a DB2 expert) if commits can be take during the restore, 
it might help.

Wish I could help more.




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
rpinion865
Sent: Friday, August 4, 2023 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS performance question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I am working with the Development LPAR (SC08D3).  Below is the TSO service 
class definition for that LPAR.

Service Class Name . . . . . : TSOSC

Description  . . . . . . . . . TSO Production and Development

Workload Name  . . . . . . . . TSO   (name or ?)

Base Resource Group  . . . . .   (name or ?)

Cpu Critical . . . . . . . . . NO(YES or NO)

I/O Priority Group . . . . . . NORMAL(NORMAL or HIGH)

Honor Priority . . . . . . . . DEFAULT   (DEFAULT or NO)



Specify BASE GOAL information. Action Codes: I=Insert new period,

E=Edit period, D=Delete period.



-- Period --  --- Goal ---

Action  #  Duration   Imp.  Description

  ___  _   _

  __1  500 190% complete within 00:00:00.060

  __2  _   4Execution velocity of 40

Next, is a mangled text view of the Development (SC08D3) LPAR definition.
Customize Image Profiles: Z15A:SC08D3 : SC08D3 : Processor  Turn on context 
sensitive help.
Collapse Z15A:SC08D3
Collapse SC08D3
 General
 Processor
 Security
 Storage
 Options
 Load
 Crypto
Group Name


Open or close the list box
Logical Processor Assignments
Dedicated processors
Select
Processor Type
Initial
Reserved
Selected
Central processors (CPs)
1
0
Selected
z Integrated Information Processors (zIIPs)
1
0
Not Dedicated Processor Details for:
CPs
zIIPs
CP Details
Initial processing weight
60
1 to 999
Initial capping
Enable workload manager
Minimum processing weight
0
Maximum processing weight
0
Absolute Capping
None
Number of processors
(0.01 to 255.0)
0.18





Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, August 3rd, 2023 at 12:17 PM, Allan Staller 
<0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:


> Classification: Confidential
>
> You did not say where the TSO response time issues were being observed. I 
> suspect, from the information provided it is on SC08D3(possible) or SC14D4 
> (most likely).
>
> If you look, I suspect the majority of CPU consumption is from the *MSTR DB2 
> address space. DB2 will charge this back to the "user". This address space is 
> most likely running in the SYSSTC Service class.
>
> I suggest you look at the service class definitions for TSO. At least 80% of 
> all transactions should end in TSO Service Class Period 1, 80 % of the rest 
> in TSO Service Class Period 2 (16%) and the remainder in TSO Service Class 
> period 3 (4 %). Another variation could be TSO Service Class Period 1 at 96% 
> and TSO Service Class Period 2 4%; No TSO Service Class Period 3.
>
> Depending on the scheme chosen above, except for the last TSO Service Class, 
> all should run as importance 1. They may have different performance goals, 
> but the importance should be 1.
>
> " From the activation profile for Development (SC08D3) the Processor 
> definition has the absolute Capping box Number of processors box set to 
> 0.18.”. This sentence does not make sense as written.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf 
> Of rpinion865
>
> Sent: Thursday, August 3, 2023 10:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: z/OS performance question
>
> [CAUTION: This Email is from outside the Organization. Unless you 
> trust the sender, Don’t click links or open attachments as it may be a 
> Phishing email, which can steal your Information and compromise your 
> Computer.]
>
> Let me start off by saying I am not a z/OS 

Re: Minimum LPAR size for z15 processor

2023-08-07 Thread Allan Staller
Classification: Confidential

For the purpose stated (STP Timiing links only) I doubt an increase will be 
needed


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Friday, August 4, 2023 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Minimum LPAR size for z15 processor

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

We're migrating our CF processors from z13's to z15's. One of the CF LPARs on 
the z13 is assigned 1.5GB. There are no structures there, it's just used as 
placeholder for STP timing links. Will that LPAR activate on a z15 processor 
with the same 1.5GB allocation, or will we need to bump it up some?

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com/), Swiss-based encrypted email.

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

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

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


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


Re: z/OS performance question

2023-08-03 Thread Allan Staller
Classification: Confidential

You did not say where the TSO response time issues were being observed. I 
suspect, from the information provided it is on SC08D3(possible) or SC14D4 
(most likely).

If you look, I suspect the majority of CPU consumption is from the *MSTR DB2 
address space. DB2 will charge this back to the "user". This address space is 
most likely running in the SYSSTC Service class.

I suggest you look at the service class definitions for TSO. At least 80% of 
all transactions should end in TSO Service Class Period 1, 80 % of the rest in 
TSO Service Class Period 2  (16%) and the remainder in TSO Service Class period 
3 (4 %). Another variation could be TSO Service Class Period 1 at 96% and TSO 
Service Class Period 2 4%; No TSO Service Class Period 3.

Depending on the scheme chosen above, except for the last TSO Service Class, 
all should run as importance 1. They may have different performance goals, but 
the importance should be 1.

" From the activation profile for Development (SC08D3) the Processor definition 
has the absolute Capping box Number of processors box set to 0.18.”. This 
sentence does not make sense as written.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
rpinion865
Sent: Thursday, August 3, 2023 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS performance question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Let me start off by saying I am not a z/OS performance and capacity planning 
expert. If anything, I am a novice. I am looking for a trivial answer to a 
non-trivial question.
We have a z15 (8562-T02) running three z/OS 2.4 LPAR's, Production (SC10D1), 
Development (SC08D3), and Sysprog (SC14D4). Below is information from the RMF 
Partition Report. My question/problem is this. On the Development LPAR, when a 
DB2 database restore job runs, the MVS Busy goes to 100% as seen from both SDSF 
DA and RMF CPU reports. Most of the CPU Busy goes to the DB2 restore job. The 
batch job runs in a discretionary service class, and TSO users run in a higher 
service class with goal mode. But, response time for the TSO users gets long, 3 
to 5 seconds between enter keys, ISPF screen swaps etc.. Normally the TSO 
response time is sub-second. As you can see, the Development LPAR has one 
Logical CP defined. Based on the capping characteristics of Development as 
displayed below, would adding another Logical CP help TSO response time?

1 P A R T I T I O N D A T A R E P O R T
PAGE 3
z/OS V2R4 SYSTEM ID SC10 DATE 08/01/2023 INTERVAL 14.59.992 RPT VERSION V2R4 
RMF TIME 05.45.00 CYCLE 1.000 SECONDS
-
MVS PARTITION NAME SC10D1 PHYS PROC NUM 5 LP GROUP NAME N/A INITIAL CAP NO 
IMAGE CAPACITY 138 CP 2 2 LIMIT N/A LPAR HW CAP NO NUMBER OF CONFIGURED 
PARTITIONS 5 ICF 1 AVAILABLE N/A HW GROUP CAP NO WAIT COMPLETION NO IIP 2 2 ABS 
MSU CAP NO DISPATCH INTERVAL DYNAMIC

MVS PARTITION NAME SC08D3 PHYS PROC NUM 5 LP GROUP NAME N/A INITIAL CAP NO 
IMAGE CAPACITY 10 CP 2 1 LIMIT N/A LPAR HW CAP YES NUMBER OF CONFIGURED 
PARTITIONS 5 ICF 1 AVAILABLE N/A HW GROUP CAP NO WAIT COMPLETION NO IIP 2 1 ABS 
MSU CAP NO DISPATCH INTERVAL DYNAMIC
-
 PARTITION DATA --
MSU --CAPPING---
NAME S BT WGT DEF ACT DEF WLM% NUM TYPE
SC10D1 A N 999 138 27 N N N 0.0 2.0 CP
SC08D3 A N 60 10 3 N Y N 0.0 1.0 CP (1)
SC14D4 A N 18 4 2 N N N 0.0 1.0 CP
TOTAL 1077

-  From the activation profile for Development (SC08D3) the Processor 
definition has the absolute Capping box Number of processors box set to 0.18.

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

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

Re: Using SAS/MXG to create a .csv file

2023-08-03 Thread Allan Staller
Classification: Confidential

YES. Don't remember how. It is built in to SAS.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Regan
Sent: Wednesday, August 2, 2023 12:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Using SAS/MXG to create a .csv file

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

 Is it possible to create a .csv file using both SAS & MXG? I ask because SAS, 
for PROC PRINT, only supports a line length of 256, and the report I want to 
create from SMF119, subtype 66 records, would be longer than that.

Regards,

Mark Regan, K8MTR General, EN80tg
CTO1 USNR-Retired (1969-1991)
Nationwide Insurance, Retired, 1986-2017 z/OS Network Systems Programmer (z 
NetView, z/OS Communications Server)

Email: marktre...@gmail.com
LinkedIn:  https://www.linkedin.com/in/mark-t-regan

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

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


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


Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-02 Thread Allan Staller
Classification: Confidential

I must disagree here. This is just a different implementation of the existing z 
architecture.
There may be some minor omissions, but I see nothing new here.

FLEX has been around for quite a while, and was always about z-emulation on an 
x86 chip.

It does provide some low-end relief for those that require less than the 
minimum z/16 horsepower.

My USD 0.02 worth.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sebastian Welton
Sent: Wednesday, August 2, 2023 1:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it 
runs and why it survives

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On Tue, 1 Aug 2023 15:53:57 -0400, Steve Thompson  wrote:

>How about we change from Mainframe to zFrame?
>
>Yeah, I know, then when IBM comes up with a new Architecture...
>How long will it take to need > 64bit addressing?
>
>

Here you go:

http://hammocktree.us/flexes/zFrameOV.pdf

https://vtda.org/docs/computing/CornerstoneSystems/MVMUA_ZFrameSlideDeck_Oct2005.pdf

Sebastian

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

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


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


Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-02 Thread Allan Staller
Classification: Confidential

Than sounds suspiciously like a "channel" on the mainframe (pick your favorite 
protocol).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Grant Taylor
Sent: Tuesday, August 1, 2023 9:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it 
runs and why it survives

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On 8/1/23 7:20 PM, David Crayford wrote:
> What’s the difference between between channelized I/O and a rack of
> x86 servers connected to a SAN using fibre channel driven by high
> speed HBAs?

I don't know.

My understanding is that Fibre Channel is an evolution of SCSI which is 
supposedly a somewhat intelligent controller wherein the OS asks said 
controller to fetch / store some data for it.  As I understand it, the OS & 
main CPU aren't involved in the transfer beyond asking the controller to do the 
transfer on it's behalf.

I'd have to reference documentation to see if / how much Direct Memory Access 
comes into play vs the CPU's involvement in the transfer to / from the 
controller.

But between the controller and the back end drive, as I understand it, the CPU 
ins't involved.

So I can't say that "a rack of x86 servers connected to a SAN using fibre 
channel" isn't using channelized I/O.  I think in many ways they are.

This is a place where minutia matters.



Grnat. . . .

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

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


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


Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-02 Thread Allan Staller
Classification: Confidential

My vague recollection of the CRAY was that is used (at the time) a 370/158 to 
buffer up all of the data so the CRAY could run full tilt.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Grant Taylor
Sent: Tuesday, August 1, 2023 5:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it 
runs and why it survives

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On 8/1/23 3:10 PM, Rick Troth wrote:
> Look for channelized I/O,

Didn't supers ~> cray use channelized I/O?

Also, I feel like there is another slippery slope discussion of what is 
channelized I/O in this context.

> then other physical attributes (not just size, not just the
> instruction set).

Please elaborate on what "other physical attributes" means.



Grant. . . .

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

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


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


Re: AT-TLS and CSSMTP setup

2023-07-31 Thread Allan Staller
Classification: Confidential

Have you updated the TCP/IP policy agent accordingly?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Saturday, July 29, 2023 9:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AT-TLS and CSSMTP setup

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I get
BPXF024I (TCPIP) Jul 30 01:12:45 TTLS[16777256]: 18:12:45 TCPIP  639 EZD1286I 
TTLS Error GRPID: 0007 ENVID: 0009 CONNID: 009B
LOCAL: 192.168.1.66..1122 REMOTE: 99.198.97.250..587 JOBNAME: CSSMTP
USERID: CSSMTP RULE: CSSMTP  RC:8 Initial Handshake 00
00 005187621CF0 

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

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


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


Re: Preferred FTP Client for Windows

2023-07-28 Thread Allan Staller
Classification: Confidential

YES.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rick Troth
Sent: Friday, July 28, 2023 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

This is great to hear, John. Thanks.

For people like me, who need excruciating clarity, you're saying that the 
SERVER in the Co:Z product groks traditional datasets as well as USS files. 
Correct? Fantastic!
That means one can use a variety of clients, specifically several which go via 
SSH. Is that also correct?

You mention SFTP which is FTP-like behavior using SSH under the covers.
Contrast with FTPS which is traditional FTP but with SSL/TLS added.
I'm keen on the former because it uses a single channel. Though I much prefer a 
one-shot command in any case, and 'scp' does that (and runs via SSH like 
'sftp').

Does the Co:Z server speak both SSH (for SFTP) and traditional FTP?

-- R; <><


On 7/28/23 07:34, John S. Giltner, Jr. wrote:
> I use sftp  with Co:Z SFTP installed on the z/OS side.  It allows access to 
> z/OS files as well as OMVS files.  Where as OpenSSH on z/OS only allows 
> access to OMVS files.
>
> Under Windows you can use WSL, Putty, Cygwin, or any other CLI sftp product.  
> I use Cygwin most of the time.
>
>
> On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  wrote:
>
>> Hello All,
>>
>> I work in a secure government environment and moving files up and down from 
>> the mainframe (especially traditional ZOS datasets) is a '' pita with 
>> Winscp and everything I read (including IBMMAIN archives) is that tool is 
>> just plain dumb when it comes to datasets with standard ZOS HLQ's.  I'm 
>> trying to do a non-scientific poll - what is the preferred FTP client to run 
>> on Windows platform out there everyone is using that you are happy with and 
>> can easily navigate to either traditional ZOS HLQ dataset or Unix System 
>> Services files.  Of course freeware is preferred if user friendly.
>>
>> I know there is Filezilla but not sure it is much better than Winscp?
>>
>> Thanks for everyone's thoughts and input.
>>
>> Steve Estle
>> steven.es...@peraton.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
::DISCLAIMER::

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


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


Re: Preferred FTP Client for Windows

2023-07-27 Thread Allan Staller
Classification: Confidential

WS/SFTP?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Estle
Sent: Wednesday, July 26, 2023 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Preferred FTP Client for Windows

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello All,

I work in a secure government environment and moving files up and down from the 
mainframe (especially traditional ZOS datasets) is a '' pita with Winscp 
and everything I read (including IBMMAIN archives) is that tool is just plain 
dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on Windows 
platform out there everyone is using that you are happy with and can easily 
navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
Of course freeware is preferred if user friendly.

I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com

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

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


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


Re: RSU Maintenance: Asking For a Friend

2023-07-26 Thread Allan Staller
Classification: Confidential

Lots of extra (unnecessary work) 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rebecca Martin
Sent: Tuesday, July 25, 2023 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU Maintenance: Asking For a Friend

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

The OP is referring to a shop that reinstalls z/OS as a way to get to a current 
RSU level.  In the years in between releases of z/OS, they reorder everything 
at a higher maintenance level and  then do a complete reinstall.

Has anyone ever heard of this method for putting on maintenance? Can you see 
any benefits of this approach?

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

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


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


Re: Ignorant z/OS question

2023-07-26 Thread Allan Staller
Classification: Confidential

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

In this case, it means te code to support said devices was *removed* from z/OS. 
I can't speak for z/VM.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Tuesday, July 25, 2023 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

 > Phil wrote: What does "not supported" mean per se?

 The last 3215 connected to IBM computers using an ICA. IBM z computers do not 
have an ICA nor byte channel therefore not supported on a z16. I suspect you 
can't even define one in the HCD. What was the last IBM computer to have an ICA.
On Monday, July 24, 2023 at 10:48:42 AM PDT, Phil Smith III 
 wrote:

 Shmuel asked:
>Do you have the URL for the Tracy Dean paper?

Yes, I've read it.

>Does it spell out all the pieces?
Probably, but as I said before, it makes enough assumptions that I can't 
understand what to do.

Alan Staller wrote:
>Going back to the original post, I seemed to have missed the
>information about the operating system release.

>z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
>MVS/ESA R.x, but that could be incorrect.)

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

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


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

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


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


Re: Ignorant z/OS question

2023-07-26 Thread Allan Staller
Classification: Confidential

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Tuesday, July 25, 2023 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

 > Phil wrote: What does "not supported" mean per se?

 The last 3215 connected to IBM computers using an ICA. IBM z computers do not 
have an ICA nor byte channel therefore not supported on a z16. I suspect you 
can't even define one in the HCD. What was the last IBM computer to have an ICA.
On Monday, July 24, 2023 at 10:48:42 AM PDT, Phil Smith III 
 wrote:

 Shmuel asked:
>Do you have the URL for the Tracy Dean paper?

Yes, I've read it.

>Does it spell out all the pieces?
Probably, but as I said before, it makes enough assumptions that I can't 
understand what to do.

Alan Staller wrote:
>Going back to the original post, I seemed to have missed the
>information about the operating system release.

>z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
>MVS/ESA R.x, but that could be incorrect.)

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

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


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

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


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


Re: Apply job failed GIM240001E for connect direct 6.2

2023-07-26 Thread Allan Staller
Classification: Confidential

The other around. Add SGDAMAC to the SYSLIB concat.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sathish Kumar
Sent: Tuesday, July 25, 2023 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Apply job failed GIM240001E for connect direct 6.2

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi David,

I have already tried to add SYSLIB CONCAT to SDGAMAC and run this job it's 
failed with same error.

Thanks.


On Tue, 25 Jul, 2023, 11:47 pm David Spiegel, < 
0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

> Hi Satish,
> Please concatenate 'DGA.SDGAMAC'  or equivalent (listed under SDGAMAC 
> Target Zone DDDEF) to Target Zone SYSLIB DDDEF and retry.
>
> Regards,
> David
>
> On 2023-07-25 08:10, Sathish Kumar wrote:
> > Hi,
> >
> > I have updated SYSLIB CONCAT SYS1.MODGEN and rerun the job it's 
> > failed
> with
> > same error.
> >
> > Thanks.
> >
> > On Tue, 25 Jul, 2023, 4:39 pm Gerry Tracey, 
> wrote:
> >
> >> Hi,
> >>
> >> That is the target library for AMODGEN and can be used instead.
> >>
> >> Gerry
> >>
> >>> On 25 Jul 2023, at 12:04, Sathish Kumar  wrote:
> >>>
> >>> Yes we have Sys1.Modgen
> >>>
> >>>> On Tue, 25 Jul, 2023, 4:25 pm Gerry Tracey, 
> >>>> 
> >> wrote:
> >>>> Hi,
> >>>>
> >>>> Do you have SYS1.MODGEN?
> >>>>
> >>>> Gerry
> >>>>
> >>>>>> On 25 Jul 2023, at 11:20, Sathish Kumar 
> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Sure,  I don't have AMODGEN Marco library. So how we can proceed?
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>>
> >>>>>> On Tue, 25 Jul, 2023, 12:41 am Steve Thompson, 
> >>>>>> 
> >> wrote:
> >>>>>> What Allen said.
> >>>>>>
> >>>>>> And make sure you follow what the install doc says for 
> >>>>>> Connect:Direct, as well as any HOLD ACTIONs: do the actions 
> >>>>>> before BYPASS.
> >>>>>>
> >>>>>> Steve Thompson
> >>>>>>
> >>>>>>> On 7/24/2023 1:44 PM, Allan Staller wrote:
> >>>>>>> Classification: Confidential
> >>>>>>>
> >>>>>>> Most likley it is a missing library in the SYSLIB concatenation.
> >>>>>>>
> >>>>>>> 1) Check the assembly listing for "macro not found" messages
> >>>>>>> 2) locate the macro
> >>>>>>> 3) Using the SMPE dialogs, adjust the SYSLIB DDDEF to include 
> >>>>>>> the
> >>>>>> missing macro library(ies)
> >>>>>>> HTH,
> >>>>>>>
> >>>>>>> -Original Message-
> >>>>>>> From: IBM Mainframe Discussion List  
> >>>>>>> On
> >>>>>> Behalf Of Sathish Kumar
> >>>>>>> Sent: Monday, July 24, 2023 12:41 PM
> >>>>>>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>>>>>> Subject: Apply job failed GIM240001E for connect direct 6.2
> >>>>>>>
> >>>>>>> [CAUTION: This Email is from outside the Organization. Unless 
> >>>>>>> you
> >> trust
> >>>>>> the sender, Don’t click links or open attachments as it may be 
> >>>>>> a
> >>>> Phishing
> >>>>>> email, which can steal your Information and compromise your
> Computer.]
> >>>>>>> Hi All,
> >>>>>>>
> >>>>>>> While apply the usermod I get below error for connect direct.
> >>>>>>>
> >>>>>>> GIM240001E ** Assembler processing for sysmid LDIACRJ failed 
> >>>>>>> for
> >> module
> >>>>>> DGAXACRJ in the SDGASAMP library.  The return code 12 Exceeded 
> >>>>>> for
> the
> >>>>>> allowable value.
> >>>>>>> ASMA057E undefined operation code.
> >>>>>&g

Re: Apply job failed GIM240001E for connect direct 6.2

2023-07-26 Thread Allan Staller
Classification: Confidential

The undefined op-codes below are the macros Prevviously mentioned.
The need to be located in some macro library (try looking in .SGDAMAC).

Using the SMP ISPF dialogs add this macro library to the syslib concatenation  
(DDDEF=SYSLIB).

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sathish Kumar
Sent: Tuesday, July 25, 2023 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Apply job failed GIM240001E for connect direct 6.2

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi Tom,

While running the Apply usermod I got below error message.

 GIM24001E ** ASSEMBLER PROCESSING FOR SYSMOD LDIXX@2 FAILED FOR MODULE
DGAXDXX2  IN THE SDGASAMP LIBRARY. THE RETURN CODE (12) EXCEEDED ALLOWABLE 
VALUE. DATE 23.206
 LDIXX02 HDGA620 GIM24001E -
ASSEMBLER PROCESSING FAILED FOR MODULE DGAXDXX2 IN THE SDGASAMP LIBRARY.
THE RETURN CODE WAS 12.
--- POSSIBLE CAUSES ---
 1. THE ASSEMBLER TEXT WAS IN ERROR.
 2. THE WRONG LEVEL OF MACROS WAS BEING USED 3. THE WRONG SET OF MACLIBS WAS 
BEING USED.

** ASMA057E UNDEFINED OPERATION CODE - DGA$SAMP
  ASMA060S COPY CODE NOT FOUND - DMGBLS
ASMA057E UNDEFINED OPERATION CODE - DMOS ASMA057E UNDEFINED OPERATION CODE - 
DMDYNCB  ASMA057E UNDEFINED OPERATION CODE - DMGSAFWA ASMAB57E UNDEFINED 
OPERATION CODE - DMFSQCB ASMA057E UNDEFINED OPERATION CODE - DMFRIXCB ASMA057E 
UNDEFINED OPERATION CODE - SCENTER  ASMA029E INCORRECT REGISTER SPECIFICATION - 
R3 ASMA004E UNDEFINED SYMBOL - R1

On Tue, 25 Jul, 2023, 7:02 pm Tom Marchant, < 
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> You didn't show us the instruction that got the Unidentified operation
> code message, so we can only guess. So far we seem to have guessed wrong.
>
> --
> Tom Marchant
>
> --
> Tom Marchant
>
> On Tue, 25 Jul 2023 17:40:57 +0530, Sathish Kumar
> 
> wrote:
>
> >I have updated SYSLIB CONCAT SYS1.MODGEN and rerun the job it's
> >failed
> with
> >same error.
>
> --
> 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
::DISCLAIMER::

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


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


Re: Ignorant z/OS question

2023-07-26 Thread Allan Staller
Classification: Confidential

As indicated previously, the code to support those devices was *removed* from 
z/OS (or whatever incarnation at that time).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Tuesday, July 25, 2023 11:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

PMFJI here, but when I heard some years ago that z/OS dropped support for 3215 
keyboard/printer consoles it occurred to me to ask what the users of z/OS under 
z/VM were supposed to do to easily automate console logging/monitoring and 
automated IPL/shutdown external to z/OS?  Maybe more recent z/VM’s have 
facilities I am not aware of that can directly capture output from and interact 
with 3270 devices better than in older versions, but I haven’t seen anything in 
this thread that would support that speculation.

Why withdraw support for a simple to use and simple to automate console 
interface that Just Worked (tm)?  It never made any sense to me.  Maybe 
z/OS-centric hubris (automation can only happen inside z/OS, do it our way or 
hit the highway, dude)?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Tuesday, July 25, 2023 12:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question



Hi Phil,

z/VM has ALWAYS (since VM R6.0.) had the CONSOLE at 009 in the Directory

entry for users by convention.

You could DEF 9 3E1 to change it.



Regards,

David



On 2023-07-25 12:00, Phil Smith III wrote:

> Jon Perryman wrote:

>> Steve says there is 1 exception to the hardware console requiring V

>> CN(*),ACT to become the first active console during IPL. He says if

>> you disable all z/OS DEV(###) consoles, then the hardware console
>> will

>> automatically activate because there is no other console available. I

>> believe this to be true but I have never tried this. There may be a

>> couple caveats that can be discussed later if it solves your problem.

>> This is simple to test. From the z/OS VM user, detach all devices

>> specified in PARMLIB(CONSOL##). At the moment, forget he mentions

>> "NIP" device because this is almost always included in

>> PARMLIB(CONSOL##) which means you would have detached it. This is so

>> simple it's worth a try.

> I will, when I can--maybe this weekend! That might be the answer, because the 
> original directory entry (I'm told) had the virtual console at 0009, but the 
> CONSOLxx has it at 03E1.

--



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


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

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


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


Re: Ignorant z/OS question

2023-07-25 Thread Allan Staller
Classification: Confidential

ISTR the some of the older "console" support was removed in the indicated 
timeframe. E.g. 1052
I cannot say for certain that the 3215 code was removed at that time.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Monday, July 24, 2023 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Shmuel asked:
>Do you have the URL for the Tracy Dean paper?

Yes, I've read it.

>Does it spell out all the pieces?
Probably, but as I said before, it makes enough assumptions that I can't 
understand what to do.

Alan Staller wrote:
>Going back to the original post, I seemed to have missed the
>information about the operating system release.

>z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
>MVS/ESA R.x, but that could be incorrect.)

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

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

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


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


Re: Apply job failed GIM240001E for connect direct 6.2

2023-07-24 Thread Allan Staller
Classification: Confidential

Most likley it is a missing library in the SYSLIB concatenation.

1) Check the assembly listing for "macro not found" messages
2) locate the macro
3) Using the SMPE dialogs, adjust the SYSLIB DDDEF to include the missing macro 
library(ies)

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sathish Kumar
Sent: Monday, July 24, 2023 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Apply job failed GIM240001E for connect direct 6.2

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi All,

While apply the usermod I get below error for connect direct.

GIM240001E ** Assembler processing for sysmid LDIACRJ failed for module 
DGAXACRJ in the SDGASAMP library.  The return code 12 Exceeded for the 
allowable value.

ASMA057E undefined operation code.

Lot of ASM* Errors messages in sysprint.

Please advise on this.

Thanks.

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

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


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


Re: Ignorant z/OS question

2023-07-24 Thread Allan Staller
Classification: Confidential

Going back to the original post, I seemed to have missed the information about 
the operating system release.
z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR MVS/ESA 
R.x, but that could be incorrect.)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Friday, July 21, 2023 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Alan Altmark wrote:
>And if you haven't done so, please read the white paper Tracy Dean
>referenced in her post. It is focused on this aspect of managing z/OS
>guests. We spent a lot of time figuring out how to make it all come
>together. (And you may remember me asking related questions on IBM-MAIN
>at the time!)

>Particularly, understand that z/OS isn't using a "device" of any kind
>It thinks it's talking to the Operating System Messages task (aka
>integrated console on the HMC), which CP simulates the same way we do
>the 3215. It also means you can't just SEND a command like you can with
>CMS.

Well, I read that paper. Lots of assumptions in there about z/OS knowledge that 
I don't have, like where it talks about "V CN(MVS0MAST),OFFLINE". I have no V 
(I assume that's VARY?) in any of my CONSOLxx members.

I do have a CNGRP00, which contains:
GROUP  NAME(MSTGRP)
   MEMBERS(S0W103D0,S0W10FFF)

Now that's 3D0 and FFF: 3D0 is a DASD. Seems wrong? The INIT in CONSOL00 is 
INIT  CMDDELIM(;) AMRF(N) MONITOR(DSNAME) CNGRP(00) so it's looking at that 
console group. If I change the 3D0 to 3E1 to match the actual console address, 
is that likely to help/hurt? What I'd rather not do is kill the beast and 
require help from our hosting service--not that they won't help, but we'll have 
to wait at least a bit for that.


(BTW, a nit: "Screenshot 1 - z/VM Login Screen with Dial Command" on page 6 has 
no DIAL command on the screen)

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

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


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


Re: Problem running GIMUNZIP job.

2023-07-20 Thread Allan Staller
Classification: Confidential

TSO BPXMTEXT E329  will ive you some answers and possible corrections

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Thursday, July 20, 2023 2:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Problem running GIMUNZIP job.

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi,
We are in the process of installing z/OS v2.5 from z/OSMF.
One of the first jobs uses GIMUNZIP to create the new z/OS libraries.
When the job got to the SMPPTS library, we got these messages:
GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING
 
/tmp/izud-V110AVN-T1314651/unzip/smpe2023201100726173157/S0354.CB.S0354.CB.ST252475.SMPE.SMPPTS.pax.Z.
 THE RETURN
 CODE WAS '0077'X AND THE REASON CODE WAS 'E329'X.
GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE 
ZSMSP9.CB.ST252475.SMPE.SMPPTS.
GIM20501IGIMUNZIP PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12.

Before the GIMUNZIP step, the job allocates a new ZFS and is supposed to mount 
it at /tmp/izud-V110AVN-T1314651/unzip, but from what I can see, this is does 
not happen, and the files are restores to /tmp, which does not have enough 
space.

The job includes some shell scripts that are supposed to mount the ZFS, but it 
doesn't look like they are running.

The step looks like:
//MOUNTEXEC PGM=BPXBATCH,COND=(0,LT)
//STDPARM  DD *
SH ;
mpdir=/tmp/izud-V110AVN-T1314651/unzip;
dsn='V110AVN.SWDEPL.T1314651.ZFS';
if   -e "$mpdir" ¤; then;
  rm -r $mpdir;
fi;
if   ! -e "$mpdir" ¤; then;
  echo "Work directory $mpdir will be created.";
  umask 077 ;
  mkdir -p -m 700 "$mpdir";
fi;
PATH=$PATH:/usr/sbin;
echo "Format the file system $dsn.";
zfsadm format -aggregate $dsn;
echo "Mount $dsn on $mpdir.";
mount -s nosetuid -t ZFS -f $dsn $mpdir;

There is no output in STDOUT or STDERR.

How can I see the output of the script to make sure it is actually running?

I would ask IBM, but this is running on z/OS v2.3, which is not supported, and 
they won't help.

Thanks

Gadi



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

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


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


Re: SORTWK space usage

2023-07-05 Thread Allan Staller
Classification: Confidential

Responding to my own post. It was SYNCSORT that required single extent SORTWK.
I remember needing to update an ACS routine to enforce this.

This is old, circa 2009, so the restriction may have been removed.

Also, I concur with the JCL recommendations. Allow the sort program to figure 
things out.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Wednesday, July 5, 2023 6:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORTWK space usage

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Classification: Confidential

It depends. SYNCSORT uses one method. DFSORT uses another. IIRC (but verify), 
DFSORT uses only a single extent.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Billy Ashton
Sent: Monday, July 3, 2023 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SORTWK space usage

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello DFSort experts!

Where can I find the explanation of SORTWK space usage? I seem to recall 
reading that only the primary space is used on a SORTWK, so if I have //SORTWK  
DD SPACE=(CYL,(5000,2000))...
I will only get the primary space of 5000 cylinders, and the other
14x2000 cylinders is never used. Is that right?

Is there a written explanation I can forward to the programmers so they 
understand this?

Also (since I know it will come), is there any good way to calculate how much 
DASD sortwork would be used? I know this depends on what is in memory at the 
time, but want to get a better handle on how Sort determines what it needs.

Thanks, everyone! This might be a good discussion!
Billy Ashton

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

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


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

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


Re: SORTWK space usage

2023-07-05 Thread Allan Staller
Classification: Confidential

It depends. SYNCSORT uses one method. DFSORT uses another. IIRC (but verify), 
DFSORT uses only a single extent.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Billy Ashton
Sent: Monday, July 3, 2023 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SORTWK space usage

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello DFSort experts!

Where can I find the explanation of SORTWK space usage? I seem to recall 
reading that only the primary space is used on a SORTWK, so if I have //SORTWK  
DD SPACE=(CYL,(5000,2000))...
I will only get the primary space of 5000 cylinders, and the other
14x2000 cylinders is never used. Is that right?

Is there a written explanation I can forward to the programmers so they 
understand this?

Also (since I know it will come), is there any good way to calculate how much 
DASD sortwork would be used? I know this depends on what is in memory at the 
time, but want to get a better handle on how Sort determines what it needs.

Thanks, everyone! This might be a good discussion!
Billy Ashton

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

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


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


Re: z/OSMF

2023-06-30 Thread Allan Staller
Classification: Confidential

According to the Preview Announcement, z/OS 3.1 requires a minimum of a z/14.

https://www.ibm.com/docs/en/announcements/preview-zos-31-ai-infused-operating-system-next-generation-computing#highx__title__1

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Friday, June 30, 2023 1:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

So is IBM definitely dropping support for the z13s BEFORE z/OS 3.1 is 
officially out?  If not, then it should be supported by z/OS 3.1, as well as 
products like z/OSMF (which are required in order to install z/OS) should be 
able to be run on the z13s, isn't that correct?

Obviously the 4341 and z/OS 2.5 (or z/OS at all) were not compatible, and the 
4341 was discontinued (hardware and software support) before z/OS was announced 
or made available.

In this case, the z13s is still supported by IBM, and is supported by z/OS.

I guess what I am looking for is an official statement that the z13s is not 
supported by z/OS 3.1.  All I currently see is that the z13s isn't listed on 
the installation list for z/OS 3.1, but as it's no longer marketed, that makes 
sense.  That doesn't mean that the z13s can't 'run" z/OS 3.1.

Can the z13s "run" z/OS 3.1?  All I need is a simple yes or no.  Or even a 
"maybe" depending on extended lifecycle support.

If it is 100% not going to run z/OS 3.1, then I would like to be able to tell 
the managers of the 5 sites that are running them that they will need to "move 
up" or "migrate off".  I can't do that without a definitive response.

Brian

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

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


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


Re: SAS Replacement

2023-06-29 Thread Allan Staller
Classification: Confidential

Sounds like bean counters run amuck.

You might have a look at WPS (claims to be source compatible w/SAS)

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kenneth Kripke
Sent: Wednesday, June 28, 2023 2:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SAS Replacement

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello;

 I am curious if there is a known replacement product for SAS, specifically 
Performance and Capacity software that is not dependent on using the SAS 
product to collect, process, and, report on Capacity and performance?

I have heard of IntelliMagic, however, I do not know the capabilities of the 
product.  Any recommendations would be appreciated.



Regards,



Kenneth James Kripke

k.kri...@comcast.net 

443-851-1237




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

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


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


Re: GRS setup for MONOPLEX to SYSPLEX

2023-06-21 Thread Allan Staller
Classification: Confidential

I would tak  a couple of FICON cables and string them between ports. Not sure 
about the z/14 hardware design.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gorlinsky
Sent: Tuesday, June 20, 2023 8:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GRS setup for MONOPLEX to SYSPLEX

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Can we use the back plain of the z/14 to do the CTC thing?

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

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


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


Re: GRS setup for MONOPLEX to SYSPLEX

2023-06-20 Thread Allan Staller
Classification: Confidential

Not my dog, but I would not do that, except under extreme duress.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Monday, June 19, 2023 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GRS setup for MONOPLEX to SYSPLEX

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Even PDSE can be safely shared. If updates only occur from one LPAR and 
read-only everywhere else. And, said updates may not be reflected immediately 
(or until next IPL) in the other read-only LPARs

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Monday, June 19, 2023 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GRS setup for MONOPLEX to SYSPLEX

Yes, PDSE do require SYSPLEX. Not GRS-plex, not CA-MIM (or MII), but SYSPLEX.
Reason: PDSE use sysplex communication, not GRS facilities.

Regarding to the topic: in order to share datasets you need ...nothing.
No parallel sysplex
No base sysplex
Not even GRSplex
No SMSplex
Simply nothing except DASD available from several systems.
Of course, the more mentioned facilities you have the better sharing is.
And yes, in order to share PDSEs (properly) you still have sysplex.
However you can share ICF BCSes (catalogs), VSAM, PS, PDS, etc.
Note: there are various flavours of sharing. Shared DASD as a data transport 
method, shared PDSes with jobs, REXX tools, etc. - it can be shared easily, 
because it is not heavily used. Batch datasets - assuming proper batch windows 
it is also can be shared easily.
For frequent sharing it is good to think about ICF ECS or RLS, etc.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 19.06.2023 o 17:03, Michael Babcock pisze:
> Beware of PDSEs.  I’m not 100% sure but I think the sandbox needs to
> be in the plex to share them.  Updating a PDSE outside of the plex can
> cause corruption.
>
> We have our sandbox in the plex just to avoid issues.
>
> On Mon, Jun 19, 2023 at 9:25 AM Paul Gorlinsky  wrote:
>
>> We have a sandbox system that references TSO user and ISV catalogs
>> and datasets. The sandbox has a unique master catalog but shares
>> virtually everything else.
>>
>> It does have access to the couple facility that the Sysplex is using ...
>> But it is not a member of the Sysplex.
>>
>> Is it possible for a monoplex z/OS system to share DASD, user cats,
>> etc., with a SYSPLEX via GRS management and coupling facility?

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

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


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


  1   2   3   4   5   6   7   8   9   10   >