Re: IBM-MAIN Digest - 15 Mar 2024 to 16 Mar 2024 (#2024-76)

[Jason Dodd]

I haven't been able to find a case where GNU COBOL has been used on 
z/OS. Has it and I'm just not aware?


On 3/17/24 00:00, IBM-MAIN automatic digest system wrote:

Date:Sat, 16 Mar 2024 19:36:29 +
From:Mark Jacobs
Subject: GNU COBOL

GnuCOBOL "has reached an industrial maturity and can compete with
proprietary offers in all environments," boasted contributor Fabrice Le
Fessant, in a FOSDEM talk.

https://thenewstack.io/20-years-in-the-making-gnucobol-is-ready-for-industry/

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

Re: IBM-MAIN access with Usenet / news (NNTP) reader

[Niemand @ thuis.nl]

TA (albeit many, if not all, USENET servers, e.g., eternal-september.org, are 
filled with SPAM :(

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

Re: IBM-MAIN access with Usenet / news (NNTP) reader

[Tom Marchant]

IIRC the list is sent to USENET using a one way link and it is not possible to 
send posts back to the link from USENET. This has been discussed before. Search 
the archives for more information.

-- 
Tom Marchant

On Fri, 5 Jan 2024 04:33:02 -0600, Niemand @ thuis.nl  
wrote:

>Is access possible to the UA Listserv via an NNTP client, e.g., Thunderbird?  
>And if so, what is the URI of the server?

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

[Rupert Reynolds]

Thanks. Well said.

Can I just add the general Internet advice "If in doubt, don't feed the
troll"? :-)

Roops.

On Sun, 17 Sep 2023, 22:48 Darren Evans-Young,  wrote:

> 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

Re: IBM-MAIN Posting Guidelines

[Sasso, Len]

Totally agree.

From: IBM Mainframe Discussion List  on behalf of 
Support, DUNNIT SYSTEMS LTD. 
Sent: Tuesday, September 19, 2023 2:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IBM-MAIN Posting Guidelines

 [External: Use caution with links & attachments]

Hi Darren,

If possible, may I suggest that your simple 1-2 sentence guidelines be included 
at the top of the main IBM-MAIN archive web page as well as at the top of every 
digest email sent out?

Thanks for all of your efforts here over the years. This list and group of 
professionals has always been beneficial to me.

--
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-MAIN Posting Guidelines

[Support, DUNNIT SYSTEMS LTD.]

Hi Darren,

If possible, may I suggest that your simple 1-2 sentence guidelines be included 
at the top of the main IBM-MAIN archive web page as well as at the top of every 
digest email sent out?

Thanks for all of your efforts here over the years. This list and group of 
professionals has always been beneficial to me.

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

[Lance D. Jackson]

Long overdue - thanks Darren.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Darren Evans-Young
Sent: Sunday, September 17, 2023 17:48
To: IBM-MAIN@LISTSERV.UA.EDU
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

Re: IBM-MAIN Posting Guidelines

[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: IBM-MAIN Posting Guidelines

[John Abell]

Thanks Doug.  It has been annoying to say the least. 

John T. Abell   
Tel:800-295-7608Option 4
President 
International:  1-416-593-5578  Option 4
E-mail:  john.ab...@intnlsoftwareproducts.com
Fax:800-295-7609

International:  1-416-593-5579


International Software Products
www.ispinfo.com


This email may contain confidential and privileged material for the sole use of 
the intended recipient(s). Any review, use, retention, distribution or 
disclosure by others is strictly prohibited. If you are not the intended 
recipient (or authorized to receive on behalf of the named recipient), please 
contact the sender by reply email and delete all copies of this message. 
Also,email is susceptible to data corruption, interception, 
tampering, unauthorized amendment and viruses. We only send and receive emails 
on the basis that we are not liable for any such corruption, interception, 
tampering, amendment or viruses or any consequence thereof.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Doug Fuerst
Sent: Sunday, September 17, 2023 6:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN Posting Guidelines

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

Re: IBM-MAIN Posting Guidelines

[Roberto Halais]

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

Re: IBM-MAIN Posting Guidelines

[Doug Fuerst]

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

Re: IBM-MAIN Posting Guidelines

[Steve Horein]

Thank you!

On Sun, Sep 17, 2023 at 4:48 PM Darren Evans-Young  wrote:

> 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

Re: IBM-MAIN Posting Guidelines

[Mark Jacobs]

Thank you.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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


--- Original Message ---
On Sunday, September 17th, 2023 at 5:48 PM, Darren Evans-Young  
wrote:


> 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

Re: IBM-MAIN@LISTSERV.UA.EDU

[esst...@juno.com]

It appears i can retriev information by specifying either of these two 
commands:NETSTAT ALL FORM SHORT (CLIENT AWTSTDP3 
NETSTAT ALL FORM LONG (CLIENT AWTSTDP3.Thanks everyone

-- Original Message --
From: Colin Paice 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
Date: Fri, 11 Aug 2023 13:49:42 +0100

The doc says *The APPLname filter is valid only with TELnet.  *Are you
using telnet?

On Fri, 11 Aug 2023 at 13:43, esst...@juno.com  wrote:

> NETSTAT TELNET (APPLNAME AWTSTDP3 did not reurn any useful data
> It only returned 
>
> -- Original Message --
> From: Peter Vels 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
> Date: Fri, 11 Aug 2023 08:52:14 +1000
>
> Try:
>
> NETSTAT TELNET (APPLNAME AWTSTDP3
>
> On Fri, 11 Aug 2023 at 07:59, esst...@juno.com  wrote:
>
> > Yes I have looked at that page, and not getting any data - so I suspect
> my
> > sytax is incorrect
> >
> > -- Original Message --
> > From: Mike Schwab 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
> > Date: Thu, 10 Aug 2023 16:23:11 -0500
> >
> >
> https://www.ibm.com/docs/en/zos/2.2.0?topic=overview-netstat-command-filter
> >
> >
> > On Thu, Aug 10, 2023, 15:56 esst...@juno.com  wrote:
> >
> > > Hello.I am trying to use TSO NETSTAT with a FILTER and keep receiving
> > > -EZZ2351I Incorrect option: FILTER..I can issue NETSTAT ALL, however
> > there
> > > too much data..So I'm Trying to use a filter..I have tried many
> different
> > > variations such as:NETSTAT (FILTER APPLMAE AWTSTDP3
> > > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > > NETSTAT ALLCONN/a | (FILTER APPLNAME AWTSTDP3
> > > NETSTAT ALLCONN | (FILTER APPLNAME AWTSTDP3..I can't seem to get the
> > > syntax correct.Can someone provide an example of using NETSTAT with a
> > > FILETER and APPLNAME of AWTSTDP3 with the proper syntax?,.paul
> > >
> > > --
> > > 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
>
> --
> 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-MAIN@LISTSERV.UA.EDU

[esst...@juno.com]

-- Original Message --
From: Colin Paice 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
Date: Fri, 11 Aug 2023 13:49:42 +0100

The doc says *The APPLname filter is valid only with TELnet.  *Are you
using telnet?

On Fri, 11 Aug 2023 at 13:43, esst...@juno.com  wrote:

> NETSTAT TELNET (APPLNAME AWTSTDP3 did not reurn any useful data
> It only returned 
>
> -- Original Message --
> From: Peter Vels 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
> Date: Fri, 11 Aug 2023 08:52:14 +1000
>
> Try:
>
> NETSTAT TELNET (APPLNAME AWTSTDP3
>
> On Fri, 11 Aug 2023 at 07:59, esst...@juno.com  wrote:
>
> > Yes I have looked at that page, and not getting any data - so I suspect
> my
> > sytax is incorrect
> >
> > -- Original Message --
> > From: Mike Schwab 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
> > Date: Thu, 10 Aug 2023 16:23:11 -0500
> >
> >
> https://www.ibm.com/docs/en/zos/2.2.0?topic=overview-netstat-command-filter
> >
> >
> > On Thu, Aug 10, 2023, 15:56 esst...@juno.com  wrote:
> >
> > > Hello.I am trying to use TSO NETSTAT with a FILTER and keep receiving
> > > -EZZ2351I Incorrect option: FILTER..I can issue NETSTAT ALL, however
> > there
> > > too much data..So I'm Trying to use a filter..I have tried many
> different
> > > variations such as:NETSTAT (FILTER APPLMAE AWTSTDP3
> > > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > > NETSTAT ALLCONN/a | (FILTER APPLNAME AWTSTDP3
> > > NETSTAT ALLCONN | (FILTER APPLNAME AWTSTDP3..I can't seem to get the
> > > syntax correct.Can someone provide an example of using NETSTAT with a
> > > FILETER and APPLNAME of AWTSTDP3 with the proper syntax?,.paul
> > >
> > > --
> > > 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
>
> --
> 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-MAIN@LISTSERV.UA.EDU

[Colin Paice]

The doc says *The APPLname filter is valid only with TELnet.  *Are you
using telnet?

On Fri, 11 Aug 2023 at 13:43, esst...@juno.com  wrote:

> NETSTAT TELNET (APPLNAME AWTSTDP3 did not reurn any useful data
> It only returned 
>
> -- Original Message --
> From: Peter Vels 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
> Date: Fri, 11 Aug 2023 08:52:14 +1000
>
> Try:
>
> NETSTAT TELNET (APPLNAME AWTSTDP3
>
> On Fri, 11 Aug 2023 at 07:59, esst...@juno.com  wrote:
>
> > Yes I have looked at that page, and not getting any data - so I suspect
> my
> > sytax is incorrect
> >
> > -- Original Message --
> > From: Mike Schwab 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
> > Date: Thu, 10 Aug 2023 16:23:11 -0500
> >
> >
> https://www.ibm.com/docs/en/zos/2.2.0?topic=overview-netstat-command-filter
> >
> >
> > On Thu, Aug 10, 2023, 15:56 esst...@juno.com  wrote:
> >
> > > Hello.I am trying to use TSO NETSTAT with a FILTER and keep receiving
> > > -EZZ2351I Incorrect option: FILTER..I can issue NETSTAT ALL, however
> > there
> > > too much data..So I'm Trying to use a filter..I have tried many
> different
> > > variations such as:NETSTAT (FILTER APPLMAE AWTSTDP3
> > > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > > NETSTAT ALLCONN/a | (FILTER APPLNAME AWTSTDP3
> > > NETSTAT ALLCONN | (FILTER APPLNAME AWTSTDP3..I can't seem to get the
> > > syntax correct.Can someone provide an example of using NETSTAT with a
> > > FILETER and APPLNAME of AWTSTDP3 with the proper syntax?,.paul
> > >
> > > --
> > > 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
>
> --
> 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-MAIN@LISTSERV.UA.EDU

[esst...@juno.com]

My understanding is that NETSTAT with a FILTER; should return a subset of the 
information returned by NETSTAT ALL NETSTAT TELNET (APPLNAME AWTSTDP3  only 
returned --
-- Original Message --
From: Peter Vels 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
Date: Fri, 11 Aug 2023 08:52:14 +1000

Try:

NETSTAT TELNET (APPLNAME AWTSTDP3

On Fri, 11 Aug 2023 at 07:59, esst...@juno.com  wrote:

> Yes I have looked at that page, and not getting any data - so I suspect my
> sytax is incorrect
>
> -- Original Message --
> From: Mike Schwab 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
> Date: Thu, 10 Aug 2023 16:23:11 -0500
>
> https://www.ibm.com/docs/en/zos/2.2.0?topic=overview-netstat-command-filter
>
>
> On Thu, Aug 10, 2023, 15:56 esst...@juno.com  wrote:
>
> > Hello.I am trying to use TSO NETSTAT with a FILTER and keep receiving
> > -EZZ2351I Incorrect option: FILTER..I can issue NETSTAT ALL, however
> there
> > too much data..So I'm Trying to use a filter..I have tried many different
> > variations such as:NETSTAT (FILTER APPLMAE AWTSTDP3
> > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > NETSTAT ALLCONN/a | (FILTER APPLNAME AWTSTDP3
> > NETSTAT ALLCONN | (FILTER APPLNAME AWTSTDP3..I can't seem to get the
> > syntax correct.Can someone provide an example of using NETSTAT with a
> > FILETER and APPLNAME of AWTSTDP3 with the proper syntax?,.paul
> >
> > --
> > 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

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

Re: IBM-MAIN@LISTSERV.UA.EDU

[esst...@juno.com]

NETSTAT TELNET (APPLNAME AWTSTDP3 did not reurn any useful data
It only returned 

-- Original Message --
From: Peter Vels 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
Date: Fri, 11 Aug 2023 08:52:14 +1000

Try:

NETSTAT TELNET (APPLNAME AWTSTDP3

On Fri, 11 Aug 2023 at 07:59, esst...@juno.com  wrote:

> Yes I have looked at that page, and not getting any data - so I suspect my
> sytax is incorrect
>
> -- Original Message --
> From: Mike Schwab 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
> Date: Thu, 10 Aug 2023 16:23:11 -0500
>
> https://www.ibm.com/docs/en/zos/2.2.0?topic=overview-netstat-command-filter
>
>
> On Thu, Aug 10, 2023, 15:56 esst...@juno.com  wrote:
>
> > Hello.I am trying to use TSO NETSTAT with a FILTER and keep receiving
> > -EZZ2351I Incorrect option: FILTER..I can issue NETSTAT ALL, however
> there
> > too much data..So I'm Trying to use a filter..I have tried many different
> > variations such as:NETSTAT (FILTER APPLMAE AWTSTDP3
> > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > NETSTAT ALLCONN/a | (FILTER APPLNAME AWTSTDP3
> > NETSTAT ALLCONN | (FILTER APPLNAME AWTSTDP3..I can't seem to get the
> > syntax correct.Can someone provide an example of using NETSTAT with a
> > FILETER and APPLNAME of AWTSTDP3 with the proper syntax?,.paul
> >
> > --
> > 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

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

Re: IBM-MAIN@LISTSERV.UA.EDU

[Peter Vels]

Try:

NETSTAT TELNET (APPLNAME AWTSTDP3

On Fri, 11 Aug 2023 at 07:59, esst...@juno.com  wrote:

> Yes I have looked at that page, and not getting any data - so I suspect my
> sytax is incorrect
>
> -- Original Message --
> From: Mike Schwab 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
> Date: Thu, 10 Aug 2023 16:23:11 -0500
>
> https://www.ibm.com/docs/en/zos/2.2.0?topic=overview-netstat-command-filter
>
>
> On Thu, Aug 10, 2023, 15:56 esst...@juno.com  wrote:
>
> > Hello.I am trying to use TSO NETSTAT with a FILTER and keep receiving
> > -EZZ2351I Incorrect option: FILTER..I can issue NETSTAT ALL, however
> there
> > too much data..So I'm Trying to use a filter..I have tried many different
> > variations such as:NETSTAT (FILTER APPLMAE AWTSTDP3
> > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> > NETSTAT ALLCONN/a | (FILTER APPLNAME AWTSTDP3
> > NETSTAT ALLCONN | (FILTER APPLNAME AWTSTDP3..I can't seem to get the
> > syntax correct.Can someone provide an example of using NETSTAT with a
> > FILETER and APPLNAME of AWTSTDP3 with the proper syntax?,.paul
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: IBM-MAIN@LISTSERV.UA.EDU

[esst...@juno.com]

Yes I have looked at that page, and not getting any data - so I suspect my 
sytax is incorrect 

-- Original Message --
From: Mike Schwab 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN@LISTSERV.UA.EDU
Date: Thu, 10 Aug 2023 16:23:11 -0500

https://www.ibm.com/docs/en/zos/2.2.0?topic=overview-netstat-command-filter


On Thu, Aug 10, 2023, 15:56 esst...@juno.com  wrote:

> Hello.I am trying to use TSO NETSTAT with a FILTER and keep receiving
> -EZZ2351I Incorrect option: FILTER..I can issue NETSTAT ALL, however there
> too much data..So I'm Trying to use a filter..I have tried many different
> variations such as:NETSTAT (FILTER APPLMAE AWTSTDP3
> NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> NETSTAT ALLCONN/a | (FILTER APPLNAME AWTSTDP3
> NETSTAT ALLCONN | (FILTER APPLNAME AWTSTDP3..I can't seem to get the
> syntax correct.Can someone provide an example of using NETSTAT with a
> FILETER and APPLNAME of AWTSTDP3 with the proper syntax?,.paul
>
> --
> 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-MAIN@LISTSERV.UA.EDU

[Mike Schwab]

https://www.ibm.com/docs/en/zos/2.2.0?topic=overview-netstat-command-filter


On Thu, Aug 10, 2023, 15:56 esst...@juno.com  wrote:

> Hello.I am trying to use TSO NETSTAT with a FILTER and keep receiving
> -EZZ2351I Incorrect option: FILTER..I can issue NETSTAT ALL, however there
> too much data..So I'm Trying to use a filter..I have tried many different
> variations such as:NETSTAT (FILTER APPLMAE AWTSTDP3
> NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> NETSTAT ALLCONN (FILTER APPLNAME AWTSTDP3
> NETSTAT ALLCONN/a | (FILTER APPLNAME AWTSTDP3
> NETSTAT ALLCONN | (FILTER APPLNAME AWTSTDP3..I can't seem to get the
> syntax correct.Can someone provide an example of using NETSTAT with a
> FILETER and APPLNAME of AWTSTDP3 with the proper syntax?,.paul
>
> --
> 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-main topics, was: Re: Cloud may be overpriced...

[Bill Johnson]

This list is practically worthless. There are thousands of mainframe workers 
and 20 people here who use it to prove they’re “geniuses”. In an earlier 
thread, most of you talked about how easy it was to write some filter to send 
my things to the circular file. Or you could simply ignore me. But, deep down, 
you can’t. The only people worth listening to are the IBMers and most of them 
can be reached via email. This is just a mirror for narcissists. I did enjoy 
the argument from a week or so ago between Metz & the other guy.


Sent from Yahoo Mail for iPhone


On Wednesday, August 9, 2023, 1:15 PM, Steve Smith  wrote:

Yep.  And people have quit the list because the signal to noise ratio is
below minimums.

This list badly needs an administrator who will block at least those
posters who have never contributed relevant content.

sas

On Wed, Aug 9, 2023 at 11:18 AM Joel C. Ewing  wrote:

> The funding of the host of ibm-main is totally irrelevant because
> postings on this list are not regulated by the university or the
> government but by mutual consent of its participants and the list
> administrator, with the goal that this list deal with topics that have
> at least some relevance with IBM mainframes and not digress into
> irrelevancies or pointless argument.  People have joined this list
> precisely because it has technical and professional relevance, not to
> read some of the playground insults that have been traded in recent weeks.
>
> I too have strong feelings on politics and religion, but ibm-main is not
> the appropriate place for such arguments, or for unprofessional
> insults.  Those who flagrantly and consistently violate the conventions
> of this list can expect to be and deserve to be criticized by other
> participants, have their posts blocked by other participants, and if
> they persist, eventually have their right to post to the list revoked.
>
>      Joel C. Ewing
>
>

--
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-main topics, was: Re: Cloud may be overpriced...

[Steve Smith]

Yep.  And people have quit the list because the signal to noise ratio is
below minimums.

This list badly needs an administrator who will block at least those
posters who have never contributed relevant content.

sas

On Wed, Aug 9, 2023 at 11:18 AM Joel C. Ewing  wrote:

> The funding of the host of ibm-main is totally irrelevant because
> postings on this list are not regulated by the university or the
> government but by mutual consent of its participants and the list
> administrator, with the goal that this list deal with topics that have
> at least some relevance with IBM mainframes and not digress into
> irrelevancies or pointless argument.  People have joined this list
> precisely because it has technical and professional relevance, not to
> read some of the playground insults that have been traded in recent weeks.
>
> I too have strong feelings on politics and religion, but ibm-main is not
> the appropriate place for such arguments, or for unprofessional
> insults.  Those who flagrantly and consistently violate the conventions
> of this list can expect to be and deserve to be criticized by other
> participants, have their posts blocked by other participants, and if
> they persist, eventually have their right to post to the list revoked.
>
>  Joel C. Ewing
>
>

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

Re: IBM-MAIN

[Bob Bridges]

I understood, Bill.  I even realized that both of you may not have meant "I've 
said my say and you should stop talking about it now".  It seems more likely 
that Bill Ogden meant "I'm not going to say anything more on the subject" and 
you were making a joke.  But it was too much  fun to ignore.

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

/* We never fail God's tests; we just keep taking them until we pass.  
-attributed to Francis Frangipane */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Thursday, May 4, 2023 15:3

2 different Bills

--- On Thursday, May 4, 2023, 2:30 PM, Bob Bridges  
wrote:
I especially liked the bit at the end (which I have every confidence is not the 
end):

Bill: END  no more on this topic!

Bill> That's it, no more, I get the last word.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, May 4, 2023 10:33

So why are you continuing this nonsense? Isn't it hypocritical to thank Darren 
and then ignore what he wrote?

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

Re: IBM-MAIN

[Bill Johnson]

2 different Bills


Sent from Yahoo Mail for iPhone


On Thursday, May 4, 2023, 2:30 PM, Bob Bridges  wrote:

I especially liked the bit at the end (which I have every confidence is not
the end):

Bill: END  no more on this topic!

Bill> That's it, no more, I get the last word.

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

/* June: Israeli and Palestinian leaders reach an agreement under which
Israel will withdraw its settlers from the Gaza strip, arousing peace hopes
in amnesia victims everywhere.  -Dave Barry, "2005 in Review" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Thursday, May 4, 2023 10:33

So why are you continuing this nonsense? Isn't it hypocritical to thank
Darren and then ignore what he wrote?

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

[Bob Bridges]

I especially liked the bit at the end (which I have every confidence is not
the end):

Bill: END  no more on this topic!

Bill> That's it, no more, I get the last word.

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

/* June: Israeli and Palestinian leaders reach an agreement under which
Israel will withdraw its settlers from the Gaza strip, arousing peace hopes
in amnesia victims everywhere.  -Dave Barry, "2005 in Review" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Thursday, May 4, 2023 10:33

So why are you continuing this nonsense? Isn't it hypocritical to thank
Darren and then ignore what he wrote?

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

Re: IBM-MAIN

[Seymour J Metz]

So why are you continuing this nonsense? Isn't it hypocritical to thank Darren 
and then ignore what he wrote?


From: IBM Mainframe Discussion List  on behalf of 
billogden 
Sent: Thursday, May 4, 2023 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN

Thank you for trying to stop the runaway politics.

I do spend time looking at a fair amount of history. I have some memories of
comments from the 1500s, the 1700s, the 1800s, and the early 1900s all
saying (using various terms) that "changes" (aka "progress") should be
stopped because "things are better without changes." For example, look how
many people lost their jobs when "automation" replaced horses  or how
many "traditional" healers lost their hobbies when antibiotics were
invented.
One can carry this line of thinking to almost any point in history. "Stop
progress"  "Stop the smarter people" "Stop the more capable people"
"Inventors/investors/organizers/hard-workers should not be allowed to profit
from their special work"   "etc, etc, etc"

Silly?  Look carefully at Russia from about 1920 to 1980 and see what
enforced socialism brings.

END  no more on this topic!

Bill Ogden

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

[Bill Johnson]

Why are US oil companies subsidized? Why is agriculture subsidized? Why are 
banks bailed out almost every time? Why does government fund much of the 
pharmaceutical research? Why is socialized medicine rated higher? (France #1 US 
#37) Why are the top rated countries for quality of life always Finland, 
Sweden, & other social Democracies?

Russia was run by the communist party (dictatorship) during your period. Is 
still run by a dictator. Sham elections.

That’s it, no more, I get the last word.


Sent from Yahoo Mail for iPhone


On Thursday, May 4, 2023, 9:54 AM, billogden  wrote:

Thank you for trying to stop the runaway politics.

I do spend time looking at a fair amount of history. I have some memories of
comments from the 1500s, the 1700s, the 1800s, and the early 1900s all
saying (using various terms) that "changes" (aka "progress") should be
stopped because "things are better without changes." For example, look how
many people lost their jobs when "automation" replaced horses  or how
many "traditional" healers lost their hobbies when antibiotics were
invented. 
One can carry this line of thinking to almost any point in history. "Stop
progress"  "Stop the smarter people" "Stop the more capable people"
"Inventors/investors/organizers/hard-workers should not be allowed to profit
from their special work"  "etc, etc, etc"

Silly?  Look carefully at Russia from about 1920 to 1980 and see what
enforced socialism brings.

END  no more on this topic!

Bill Ogden

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

[billogden]

Thank you for trying to stop the runaway politics.

I do spend time looking at a fair amount of history. I have some memories of
comments from the 1500s, the 1700s, the 1800s, and the early 1900s all
saying (using various terms) that "changes" (aka "progress") should be
stopped because "things are better without changes." For example, look how
many people lost their jobs when "automation" replaced horses  or how
many "traditional" healers lost their hobbies when antibiotics were
invented. 
One can carry this line of thinking to almost any point in history. "Stop
progress"  "Stop the smarter people" "Stop the more capable people"
"Inventors/investors/organizers/hard-workers should not be allowed to profit
from their special work"   "etc, etc, etc"

Silly?  Look carefully at Russia from about 1920 to 1980 and see what
enforced socialism brings.

END  no more on this topic!

Bill Ogden

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

Re: IBM-MAIN

[Dean Kent]

My perspective is:  Politics is philosophy, but with a lot of emotion...

On 5/3/2023 10:25 AM, Bob Bridges wrote:

Without in the least wishing to feed the trolls, I may as well say that I never 
mind these digressions.  I wouldn't want them to take over the forum, but the 
occasional hot-blooded off-topic food fight is at worst mildly entertaining and 
at best gives me an excuse to emit a superior smirk as I stay out of it.  And 
sometimes someone actually makes a GOOD point, at which point I may contribute.

It's better, of course, when the dialogue leaves out the hostility.  But I 
can't control that, and my feelings aren't delicate.

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

/* A recent Pentagon scenario-building exercise suggested a sudden breakdown in the North 
Atlantic circulation, producing a dramatic regional cooling.  A disaster film called The 
Day After Tomorrow, released a couple of weeks ago, suggests an apocalyptic future not 
foreseen by most serious climatologists.  In fact, we do not know whether global warming 
will continue to increase on a steady ramp or possibly cross the threshold of some 
nonlinear process.  We're in the middle of a large uncontrolled experiment on the only 
planet we have.  -Donald Kennedy, Editor-in-Chief  of "Science" [Vol 304, Issue 
5677, 1565, 11 June 2004] */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Wednesday, May 3, 2023 09:53

I think I also triggered this by trying to show why we (the
industry) need to pay attention to Asimov's laws of robotics.

--- On 5/3/2023 9:36 AM, Matt Hogstrom wrote:

I seeded the discussion with the idea that our technology has impacts beyond 
the tech itself.  Had I thought about it I could have easily intuited that it 
would go political and end up exactly where we are at.  That wasn’t the intent 
but was the outcome.

I repent in dust and ashes.


--- On May 2, 2023, at 10:56 PM, Darren Evans-Young  wrote:
Haven't had to remind folks of this in a awhile. This list is for the 
discussion of IBM Mainframes.
Not political discussions/opinions and other worthless sh*t that I
and others really don't care about.  If it continues, I will start removing 
people from the list.

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

[Bob Bridges]

Without in the least wishing to feed the trolls, I may as well say that I never 
mind these digressions.  I wouldn't want them to take over the forum, but the 
occasional hot-blooded off-topic food fight is at worst mildly entertaining and 
at best gives me an excuse to emit a superior smirk as I stay out of it.  And 
sometimes someone actually makes a GOOD point, at which point I may contribute.

It's better, of course, when the dialogue leaves out the hostility.  But I 
can't control that, and my feelings aren't delicate.

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

/* A recent Pentagon scenario-building exercise suggested a sudden breakdown in 
the North Atlantic circulation, producing a dramatic regional cooling.  A 
disaster film called The Day After Tomorrow, released a couple of weeks ago, 
suggests an apocalyptic future not foreseen by most serious climatologists.  In 
fact, we do not know whether global warming will continue to increase on a 
steady ramp or possibly cross the threshold of some nonlinear process.  We're 
in the middle of a large uncontrolled experiment on the only planet we have.  
-Donald Kennedy, Editor-in-Chief  of "Science" [Vol 304, Issue 5677, 1565, 11 
June 2004] */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Wednesday, May 3, 2023 09:53

I think I also triggered this by trying to show why we (the
industry) need to pay attention to Asimov's laws of robotics.

--- On 5/3/2023 9:36 AM, Matt Hogstrom wrote:
> I seeded the discussion with the idea that our technology has impacts beyond 
> the tech itself.  Had I thought about it I could have easily intuited that it 
> would go political and end up exactly where we are at.  That wasn’t the 
> intent but was the outcome.
>
> I repent in dust and ashes.
>
>> --- On May 2, 2023, at 10:56 PM, Darren Evans-Young  wrote:
>> Haven't had to remind folks of this in a awhile. This list is for the 
>> discussion of IBM Mainframes.
>> Not political discussions/opinions and other worthless sh*t that I 
>> and others really don't care about.  If it continues, I will start removing 
>> people from the list.

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

Re: IBM-MAIN

[Bill Johnson]

Matt said “I seeded the discussion with the idea that our technology has 
impacts beyond the tech itself.”

Tech DOES have a huge impact. Automation has killed millions of good paying 
blue collar jobs here in the Midwest. Most of you “techies” didn’t show much 
concern for those people. Now that the next tech phase, AI, might affect YOU, 
suddenly there’s some concern.

As for off topic stuff, you guys take threads off topic all the time. And 
nobody cares. Like many of you have stated, you were just going to ignore me or 
show us your programming skills by sending my responses directly to the 
circular file. It takes 2 or more to tango.

I think I’ll save you the terror of my diatribes since I no longer need to 
waste retirement time here with privileged geniuses.

One guy here once called me book smart but not street smart. That was hilarious 
considering I’ve run 2 businesses, one of which did business with the Mafia. 
Trust me, you get street smart when the mafia threatens you. Plus the 10k 
reward we got from Garda systems for helping capture a multimillion dollar 
heist locally.

Adios 

Sent from Yahoo Mail for iPhone


On Wednesday, May 3, 2023, 9:37 AM, Matt Hogstrom  wrote:

I seeded the discussion with the idea that our technology has impacts beyond 
the tech itself.  Had I thought about it I could have easily intuited that it 
would go political and end up exactly where we are at.  That wasn’t the intent 
but was the outcome.

I repent in dust and ashes.

Matt Hogstrom


> On May 2, 2023, at 10:56 PM, Darren Evans-Young  wrote:
> 
> Haven't had to remind folks of this in a awhile. This list is for the 
> discussion of IBM Mainframes.
> Not political discussions/opinions and other worthless sh*t that I and others 
> really don't care
> about.  If it continues, I will start removing people from the list.
> 
> Thank you for your cooperation.
> 
> 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

Re: IBM-MAIN

[Steve Thompson]

I think I also triggered this by trying to show why we (the 
industry) need to pay attention to Asimov's laws of robotics.


Sorry,
Steve Thompson

On 5/3/2023 9:36 AM, Matt Hogstrom wrote:

I seeded the discussion with the idea that our technology has impacts beyond 
the tech itself.  Had I thought about it I could have easily intuited that it 
would go political and end up exactly where we are at.  That wasn’t the intent 
but was the outcome.

I repent in dust and ashes.

Matt Hogstrom



On May 2, 2023, at 10:56 PM, Darren Evans-Young  wrote:

Haven't had to remind folks of this in a awhile. This list is for the 
discussion of IBM Mainframes.
Not political discussions/opinions and other worthless sh*t that I and others 
really don't care
about.  If it continues, I will start removing people from the list.

Thank you for your cooperation.

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

Re: IBM-MAIN

[Seymour J Metz]

OTOH, it's nice to see that Darren is alive and kicking.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Matt Hogstrom [m...@hogstrom.org]
Sent: Wednesday, May 3, 2023 9:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN

I seeded the discussion with the idea that our technology has impacts beyond 
the tech itself.  Had I thought about it I could have easily intuited that it 
would go political and end up exactly where we are at.  That wasn’t the intent 
but was the outcome.

I repent in dust and ashes.

Matt Hogstrom


> On May 2, 2023, at 10:56 PM, Darren Evans-Young  wrote:
>
> Haven't had to remind folks of this in a awhile. This list is for the 
> discussion of IBM Mainframes.
> Not political discussions/opinions and other worthless sh*t that I and others 
> really don't care
> about.  If it continues, I will start removing people from the list.
>
> Thank you for your cooperation.
>
> 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

Re: IBM-MAIN

[Lionel B. Dyck]

Matt - there is no need to repent. It was a perfectly valid post as it impacts 
every company that uses technology. You are not responsible for the way others 
react - that is on them. You were professional and provided the information for 
others to consume.

So go wash those ashes and dust off.


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

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Wednesday, May 3, 2023 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN

I seeded the discussion with the idea that our technology has impacts beyond 
the tech itself.  Had I thought about it I could have easily intuited that it 
would go political and end up exactly where we are at.  That wasn’t the intent 
but was the outcome.

I repent in dust and ashes.

Matt Hogstrom


> On May 2, 2023, at 10:56 PM, Darren Evans-Young  wrote:
> 
> Haven't had to remind folks of this in a awhile. This list is for the 
> discussion of IBM Mainframes.
> Not political discussions/opinions and other worthless sh*t that I and 
> others really don't care about.  If it continues, I will start removing 
> people from the list.
> 
> Thank you for your cooperation.
> 
> 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

Re: IBM-MAIN

[Matt Hogstrom]

I seeded the discussion with the idea that our technology has impacts beyond 
the tech itself.  Had I thought about it I could have easily intuited that it 
would go political and end up exactly where we are at.  That wasn’t the intent 
but was the outcome.

I repent in dust and ashes.

Matt Hogstrom


> On May 2, 2023, at 10:56 PM, Darren Evans-Young  wrote:
> 
> Haven't had to remind folks of this in a awhile. This list is for the 
> discussion of IBM Mainframes.
> Not political discussions/opinions and other worthless sh*t that I and others 
> really don't care
> about.  If it continues, I will start removing people from the list.
> 
> Thank you for your cooperation.
> 
> 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

Re: IBM-MAIN

[David Purdy]

 +x'10'
On Wednesday, May 3, 2023 at 09:26:16 AM EDT, Lionel B. Dyck 
 wrote:  
 
 +1


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

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gord Tomlin
Sent: Wednesday, May 3, 2023 8:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN

On 2023-05-02 22:56 PM, Darren Evans-Young wrote:
> Haven't had to remind folks of this in a awhile. This list is for the 
> discussion of IBM Mainframes.
> Not political discussions/opinions and other worthless sh*t that I and 
> others really don't care about.  If it continues, I will start 
> removing people from the list

Thank you!

--

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

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

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

[Lionel B. Dyck]

+1


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

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gord Tomlin
Sent: Wednesday, May 3, 2023 8:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN

On 2023-05-02 22:56 PM, Darren Evans-Young wrote:
> Haven't had to remind folks of this in a awhile. This list is for the 
> discussion of IBM Mainframes.
> Not political discussions/opinions and other worthless sh*t that I and 
> others really don't care about.  If it continues, I will start 
> removing people from the list

Thank you!

--

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

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

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

Re: IBM-MAIN

[Gord Tomlin]

On 2023-05-02 22:56 PM, Darren Evans-Young wrote:

Haven't had to remind folks of this in a awhile. This list is for the 
discussion of IBM Mainframes.
Not political discussions/opinions and other worthless sh*t that I and others 
really don't care
about.  If it continues, I will start removing people from the list


Thank you!

--

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

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

Re: IBM-MAIN Digest - 12 Jan 2023 to 13 Jan 2023 (#2023-11)

[Willie Favero]

INFO IBM-MAIN


--
*Willie*
--
Alternate E-Mail -> *myblack...@gmail.com* 


My Website ---> http://WillieFavero.com/ 
My Bandmix Info > https://www.bandmix.com/willie_favero/
Kompoz Activity--> https://www.kompoz.com/music/artist/p-bass-player/

Houston Area, TX, USA
My QR code
On 1/13/2023 11:00 PM, IBM-MAIN automatic digest system wrote:

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

Re: IBM-MAIN Digest - 7 Jan 2023 to 8 Jan 2023 (#2023-7)

[Willie Favero]

?


--
*Willie*
--
Alternate E-Mail -> *myblack...@gmail.com* 


My Website ---> http://WillieFavero.com/ 
My Bandmix Info > https://www.bandmix.com/willie_favero/
Kompoz Activity--> https://www.kompoz.com/music/artist/p-bass-player/

Houston Area, TX, USA
My QR code
On 1/8/2023 11:00 PM, IBM-MAIN automatic digest system wrote:

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

Re: IBM-MAIN Digest - 25 Dec 2022 to 26 Dec 2022 (#2022-355)

[Paul Gilmartin]

On Tue, 27 Dec 2022 11:04:55 -0800, Bill  wrote:
...
o Please don't reply with "Subject: ... Digest ..."
o Please don't quote the entire digest in your reply.

Aren't there tools for replying to  individual digest entries?

(But the Digest should have a "No-Reply" header.)

-- 
gil

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

Re: IBM-MAIN Digest - 25 Dec 2022 to 26 Dec 2022 (#2022-355)

[Bill]

There is a PTF for IBM Markup R100, 5669-326, volid 3102, PTF # IP00082, 
flagged as Corrective Service, on 3.5 and 5.25 diskettes. 

Message originated on my iPhone 12

> On Dec 27, 2022, at 11:10 AM, Bill  wrote:
> 
> The IBM Markup User’s Guide and Tutorial publication number is S544-3350-00, 
> Dept. V53, P.O. Box 1900, Boulder, CO 80301-9191.
> 
> Message originated on my iPhone 12
> 
>> On Dec 27, 2022, at 11:04 AM, Bill  wrote:
>> 
>> I have a pristine, complete boxed copy of IBM Markup in 3.5 and 5.25 
>> diskettes. IBM Markup, Version 1.0, part no. 6476161, dated 10/1987, 
>> S544-3357-00, is described in the license information as “… an IBM Personal 
>> Computer entry-assist program that allows you to create and edit GML 
>> documents using DCF R3.0 or 3.1+ running in either VM/CMS or MVS/TSO.” 
>> Central Service terminated 10/16/1990.  
>> 
>> This program requires DOS 2.1 or 3.3 for a file transfer program to the 
>> mainframe. 
>> 
>> Message originated on my iPhone 12
>> 
 On Dec 26, 2022, at 9:00 PM, IBM-MAIN automatic digest system 
  wrote:
>>> 
>>> There are 12 messages totaling 546 lines in this issue.
>>> 
>>> Topics of the day:
>>> 
>>> 1. Markup languages (2)
>>> 2. Markup languages - more on the shortcomings of MS Word (10)
>>> 
>>> --
>>> 
>>> Date:Mon, 26 Dec 2022 14:10:56 +
>>> From:Seymour J Metz 
>>> Subject: Re: Markup languages
>>> 
>>> I doubt it, since mark was primarily interested in XEDIT compatibility. 
>>> Similarly, I don't expect to see a chart comparint e.g., ooRexx, Regina, to 
>>> KEXX.
>>> 
>>> 
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>> 
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>>> Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org]
>>> Sent: Saturday, December 24, 2022 3:07 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Markup languages
>>> 
> On Fri, 23 Dec 2022, at 12:51, Seymour J Metz wrote:
 emacs
 THE
 vi
 ...
>>> 
>>> I've never used either  emacs  or  vi  and don't much want to have to
>>> learn another text editor's command set.
>>> 
>>> Regarding THE, is there a list anywhere of what the differences between
>>> it and Kedit are?  Wading through the THE documentation looking at
>>> each command is tedious, and it's not helped by finding out that some
>>> things are labelled "(not implemented)".
>>> 
>>> 
 You may have my copy of TSPF when they pry it out of my cold, dead
 fingers.
>>> 
>>> I suspect that actually getting it from your estate might be tricky
>>> 
>>> --
>>> Jeremy Nicoll - my opinions are my own.
>>> 
>>> --
>>> 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
>>> 
>>> --
>>> 
>>> Date:Mon, 26 Dec 2022 14:44:30 +
>>> From:Seymour J Metz 
>>> Subject: Re: Markup languages
>>> 
>>> TeX is the underlying language. I believe that most people use a document 
>>> development environment with an editor and preview facility. Some of the 
>>> available environments can automatically download required packages from 
>>> CTAN. It is possible to generate a PDF without an intermediate DVI file.
>>> 
>>> I'd start by looking at MiKTeX, TeX Live and TeXworks, or browse CTAN.
>>> 
>>> 
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>> 
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>>> Bob Bridges [robhbrid...@gmail.com]
>>> Sent: Thursday, December 22, 2022 6:38 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Markup languages
>>> 
>>> I got quite a few nominations from the two forums where I posted this
>>> question, and it's early days to say I've settled on one, but currently I'm
>>> looking hard at LaTeX.  I found a tutorial on it at javatpoint.com, but that
>>> was written by a non-native-English writer (maybe he a Slav?, guessing by
>>> his odd use of definite articles) and there are some phrases in there I
>>> can't parse with confidence.  I imagine whatever documentation comes with
>>> the download will be clearer.
>>> 
>>> But it seems there are multiple pieces I need to fetch.  I get the
>>> impression that TEX is the actual markup language, and LaTeX is ... what?  A
>>> series of extensions to TEX to allow it to do more?  And I need a program
>>> that will convert my text and markup codes to a printer-ready document,
>>> and/or to a PDF file.  And most people use a text editor specifically

Re: IBM-MAIN Digest - 25 Dec 2022 to 26 Dec 2022 (#2022-355)

[Bill]

The IBM Markup User’s Guide and Tutorial publication number is S544-3350-00, 
Dept. V53, P.O. Box 1900, Boulder, CO 80301-9191.

Message originated on my iPhone 12

> On Dec 27, 2022, at 11:04 AM, Bill  wrote:
> 
> I have a pristine, complete boxed copy of IBM Markup in 3.5 and 5.25 
> diskettes. IBM Markup, Version 1.0, part no. 6476161, dated 10/1987, 
> S544-3357-00, is described in the license information as “… an IBM Personal 
> Computer entry-assist program that allows you to create and edit GML 
> documents using DCF R3.0 or 3.1+ running in either VM/CMS or MVS/TSO.” 
> Central Service terminated 10/16/1990.  
> 
> This program requires DOS 2.1 or 3.3 for a file transfer program to the 
> mainframe. 
> 
> Message originated on my iPhone 12
> 
>> On Dec 26, 2022, at 9:00 PM, IBM-MAIN automatic digest system 
>>  wrote:
>> 
>> There are 12 messages totaling 546 lines in this issue.
>> 
>> Topics of the day:
>> 
>> 1. Markup languages (2)
>> 2. Markup languages - more on the shortcomings of MS Word (10)
>> 
>> --
>> 
>> Date:Mon, 26 Dec 2022 14:10:56 +
>> From:Seymour J Metz 
>> Subject: Re: Markup languages
>> 
>> I doubt it, since mark was primarily interested in XEDIT compatibility. 
>> Similarly, I don't expect to see a chart comparint e.g., ooRexx, Regina, to 
>> KEXX.
>> 
>> 
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>> 
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>> Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org]
>> Sent: Saturday, December 24, 2022 3:07 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Markup languages
>> 
 On Fri, 23 Dec 2022, at 12:51, Seymour J Metz wrote:
>>> emacs
>>> THE
>>> vi
>>> ...
>> 
>> I've never used either  emacs  or  vi  and don't much want to have to
>> learn another text editor's command set.
>> 
>> Regarding THE, is there a list anywhere of what the differences between
>> it and Kedit are?  Wading through the THE documentation looking at
>> each command is tedious, and it's not helped by finding out that some
>> things are labelled "(not implemented)".
>> 
>> 
>>> You may have my copy of TSPF when they pry it out of my cold, dead
>>> fingers.
>> 
>> I suspect that actually getting it from your estate might be tricky
>> 
>> --
>> Jeremy Nicoll - my opinions are my own.
>> 
>> --
>> 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
>> 
>> --
>> 
>> Date:Mon, 26 Dec 2022 14:44:30 +
>> From:Seymour J Metz 
>> Subject: Re: Markup languages
>> 
>> TeX is the underlying language. I believe that most people use a document 
>> development environment with an editor and preview facility. Some of the 
>> available environments can automatically download required packages from 
>> CTAN. It is possible to generate a PDF without an intermediate DVI file.
>> 
>> I'd start by looking at MiKTeX, TeX Live and TeXworks, or browse CTAN.
>> 
>> 
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>> 
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>> Bob Bridges [robhbrid...@gmail.com]
>> Sent: Thursday, December 22, 2022 6:38 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Markup languages
>> 
>> I got quite a few nominations from the two forums where I posted this
>> question, and it's early days to say I've settled on one, but currently I'm
>> looking hard at LaTeX.  I found a tutorial on it at javatpoint.com, but that
>> was written by a non-native-English writer (maybe he a Slav?, guessing by
>> his odd use of definite articles) and there are some phrases in there I
>> can't parse with confidence.  I imagine whatever documentation comes with
>> the download will be clearer.
>> 
>> But it seems there are multiple pieces I need to fetch.  I get the
>> impression that TEX is the actual markup language, and LaTeX is ... what?  A
>> series of extensions to TEX to allow it to do more?  And I need a program
>> that will convert my text and markup codes to a printer-ready document,
>> and/or to a PDF file.  And most people use a text editor specifically
>> dedicated to working with LaTeX; various options for that last are
>> mentioned.  Do you have any specific recommendations?  Because I think I'm
>> about ready to download and experiment.
>> 
>> ---
>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>> 
>> /* A person reveals his character by nothing so clearly as the joke he
>> 

Re: IBM-MAIN Digest - 25 Dec 2022 to 26 Dec 2022 (#2022-355)

[Bill]

I have a pristine, complete boxed copy of IBM Markup in 3.5 and 5.25 diskettes. 
IBM Markup, Version 1.0, part no. 6476161, dated 10/1987, S544-3357-00, is 
described in the license information as “… an IBM Personal Computer 
entry-assist program that allows you to create and edit GML documents using DCF 
R3.0 or 3.1+ running in either VM/CMS or MVS/TSO.” Central Service terminated 
10/16/1990.  

This program requires DOS 2.1 or 3.3 for a file transfer program to the 
mainframe. 

Message originated on my iPhone 12

> On Dec 26, 2022, at 9:00 PM, IBM-MAIN automatic digest system 
>  wrote:
> 
> There are 12 messages totaling 546 lines in this issue.
> 
> Topics of the day:
> 
>  1. Markup languages (2)
>  2. Markup languages - more on the shortcomings of MS Word (10)
> 
> --
> 
> Date:Mon, 26 Dec 2022 14:10:56 +
> From:Seymour J Metz 
> Subject: Re: Markup languages
> 
> I doubt it, since mark was primarily interested in XEDIT compatibility. 
> Similarly, I don't expect to see a chart comparint e.g., ooRexx, Regina, to 
> KEXX.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org]
> Sent: Saturday, December 24, 2022 3:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Markup languages
> 
>> On Fri, 23 Dec 2022, at 12:51, Seymour J Metz wrote:
>> emacs
>> THE
>> vi
>> ...
> 
> I've never used either  emacs  or  vi  and don't much want to have to
> learn another text editor's command set.
> 
> Regarding THE, is there a list anywhere of what the differences between
> it and Kedit are?  Wading through the THE documentation looking at
> each command is tedious, and it's not helped by finding out that some
> things are labelled "(not implemented)".
> 
> 
>> You may have my copy of TSPF when they pry it out of my cold, dead
>> fingers.
> 
> I suspect that actually getting it from your estate might be tricky
> 
> --
> Jeremy Nicoll - my opinions are my own.
> 
> --
> 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
> 
> --
> 
> Date:Mon, 26 Dec 2022 14:44:30 +
> From:Seymour J Metz 
> Subject: Re: Markup languages
> 
> TeX is the underlying language. I believe that most people use a document 
> development environment with an editor and preview facility. Some of the 
> available environments can automatically download required packages from 
> CTAN. It is possible to generate a PDF without an intermediate DVI file.
> 
> I'd start by looking at MiKTeX, TeX Live and TeXworks, or browse CTAN.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Bob Bridges [robhbrid...@gmail.com]
> Sent: Thursday, December 22, 2022 6:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Markup languages
> 
> I got quite a few nominations from the two forums where I posted this
> question, and it's early days to say I've settled on one, but currently I'm
> looking hard at LaTeX.  I found a tutorial on it at javatpoint.com, but that
> was written by a non-native-English writer (maybe he a Slav?, guessing by
> his odd use of definite articles) and there are some phrases in there I
> can't parse with confidence.  I imagine whatever documentation comes with
> the download will be clearer.
> 
> But it seems there are multiple pieces I need to fetch.  I get the
> impression that TEX is the actual markup language, and LaTeX is ... what?  A
> series of extensions to TEX to allow it to do more?  And I need a program
> that will convert my text and markup codes to a printer-ready document,
> and/or to a PDF file.  And most people use a text editor specifically
> dedicated to working with LaTeX; various options for that last are
> mentioned.  Do you have any specific recommendations?  Because I think I'm
> about ready to download and experiment.
> 
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> 
> /* A person reveals his character by nothing so clearly as the joke he
> resents.  -G C Lichtenberg */
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Seymour J Metz
> Sent: Thursday, December 22, 2022 08:39
> 
> My preference, alas, is dead: BookMagager BUILD/MVS (or VM), which is built
> on BookMaster and DCF. Lacking that, I make do with LaTeX, which I find
> powerful but clumsier 

Re: IBM-MAIN Digest - 5 Nov 2022 to 6 Nov 2022 (#2022-306)

[Willie Favero]

?

--
*Willie*
--
Alternate E-Mail -> *myblack...@gmail.com* 


My Website ---> http://WillieFavero.com/ 
My Bandmix Info > https://www.bandmix.com/willie_favero/
Kompoz Activity--> https://www.kompoz.com/music/artist/p-bass-player/

Houston Area, TX, USA
My QR code
On 11/6/2022 11:01 PM, IBM-MAIN automatic digest system wrote:

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

Re: IBM-MAIN Digest - 1 Nov 2022 to 2 Nov 2022 (#2022-302)

[Tom Brennan]

$#@

Is it Friday yet?

On 11/3/2022 7:57 PM, Reg Harbeck wrote:

/* ¬ */

- Reg Harbeck, M.A.
+1.403.605.7986


On Nov 3, 2022, at 17:23, Reg Harbeck  wrote:

#!

- Reg Harbeck, M.A.
+1.403.605.7986


On Nov 3, 2022, at 15:17, zMan  wrote:

!

Srsly, what do you mean?


On Thu, Nov 3, 2022 at 4:33 PM Willie Favero  wrote:


?

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




--
zMan -- "I've got a mainframe and I'm not afraid to use it"

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



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



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




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

Re: IBM-MAIN Digest - 1 Nov 2022 to 2 Nov 2022 (#2022-302)

[Reg Harbeck]

/* ¬ */

- Reg Harbeck, M.A.
+1.403.605.7986

> On Nov 3, 2022, at 17:23, Reg Harbeck  wrote:
> 
> #!
> 
> - Reg Harbeck, M.A.
> +1.403.605.7986
> 
>> On Nov 3, 2022, at 15:17, zMan  wrote:
>> 
>> !
>> 
>> Srsly, what do you mean?
>> 
 On Thu, Nov 3, 2022 at 4:33 PM Willie Favero  wrote:
>>> 
>>> ?
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> 
>> 
>> 
>> -- 
>> zMan -- "I've got a mainframe and I'm not afraid to use it"
>> 
>> --
>> 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-MAIN Digest - 1 Nov 2022 to 2 Nov 2022 (#2022-302)

[Reg Harbeck]

#!

- Reg Harbeck, M.A.
+1.403.605.7986

> On Nov 3, 2022, at 15:17, zMan  wrote:
> 
> !
> 
> Srsly, what do you mean?
> 
>> On Thu, Nov 3, 2022 at 4:33 PM Willie Favero  wrote:
>> 
>> ?
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> 
> -- 
> zMan -- "I've got a mainframe and I'm not afraid to use it"
> 
> --
> 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-MAIN Digest - 1 Nov 2022 to 2 Nov 2022 (#2022-302)

[zMan]

!

Srsly, what do you mean?

On Thu, Nov 3, 2022 at 4:33 PM Willie Favero  wrote:

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


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: IBM-MAIN Digest - 1 Nov 2022 to 2 Nov 2022 (#2022-302)

[Willie Favero]

?

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

Re: IBM-MAIN Digest - 25 Aug 2022 to 26 Aug 2022 (#2022-235)

[Seymour J Metz]

I was thinking more of the influence that UoW had than of work done directly by 
staff or students.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Monday, August 29, 2022 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN Digest - 25 Aug 2022 to 26 Aug 2022 (#2022-235)

Seymour J Metz wrote:

>Influence for Waterloo?



Eh? If you mean UofW, no, there was never any 3270 emulator development there. 
I worked there 1980-86, and managed to leave at the
peak of the mainframe there-dumb luck. It was gone soon after.



SimWare (Sim3270) and UofW worked together, including a nifty Volker-Craig 
ASCII terminal with a 3270 keyboard that sent the Sim3270
key sequences. Not sure that got produced, alas, but I did play with it!






--
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-MAIN Digest - 25 Aug 2022 to 26 Aug 2022 (#2022-235)

[Phil Smith III]

Seymour J Metz wrote:

>Influence for Waterloo?

 

Eh? If you mean UofW, no, there was never any 3270 emulator development there. 
I worked there 1980-86, and managed to leave at the
peak of the mainframe there-dumb luck. It was gone soon after.

 

SimWare (Sim3270) and UofW worked together, including a nifty Volker-Craig 
ASCII terminal with a 3270 keyboard that sent the Sim3270
key sequences. Not sure that got produced, alas, but I did play with it!

 

 


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

Re: IBM-MAIN Digest - 25 Aug 2022 to 26 Aug 2022 (#2022-235)

[Paul Gilmartin]

On Sun, 28 Aug 2022 22:27:21 +, Seymour J Metz wrote:

>Influence for Waterloo?
>
>
>From:  Phil Smith III 
>Sent: Saturday, August 27, 2022 12:08 PM
>
>Tony Harminc wrote, re Hummingbird:
>>Which, iirc, was the TN3270 program developed at McGill U. by Pierre Goyette.
>
>And QWS3270 came from Queens', no? Interesting that two of the (many, Many, 
>MANY!) 3270 emulators came from Canadian universities...
>
Commercial sites placed actual 327x on employees' desks; students relied on
personal systems or timesharing, usually on non-IBM equipment.

Add Peter DiCamillo's , the earliest 3270
emulator available where I worked.

-- 
gil

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

Re: IBM-MAIN Digest - 25 Aug 2022 to 26 Aug 2022 (#2022-235)

[Seymour J Metz]

Influence for Waterloo?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Saturday, August 27, 2022 12:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN Digest - 25 Aug 2022 to 26 Aug 2022 (#2022-235)

Tony Harminc wrote, re Hummingbird:
>Which, iirc, was the TN3270 program developed at McGill U. by Pierre
>Goyette.

And QWS3270 came from Queens', no? Interesting that two of the (many, Many, 
MANY!) 3270 emulators came from Canadian universities...

--
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-MAIN Digest - 25 Aug 2022 to 26 Aug 2022 (#2022-235)

[Phil Smith III]

Tony Harminc wrote, re Hummingbird:
>Which, iirc, was the TN3270 program developed at McGill U. by Pierre
>Goyette.

And QWS3270 came from Queens', no? Interesting that two of the (many, Many, 
MANY!) 3270 emulators came from Canadian universities...

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Peter Relson]

> Interesting. That completion code would not have been in correct IBM 
code
> (Fxx abends have indicated the non-availability of SVC xx, for as long 
as
> the SVC FLIH has existed, as far as I know).

It was many moons ago, maybe it was z/OS 1.4 or earlier (OS/390 2.10?).
Definitely it was RMM problem, described in some APAR


I was wrong as of some point that I am not aware of (we would probably not 
have approved if asked). And it's even documented under Fnn. F13, F14, 
F17, F37 are the exceptions.

We're considering changing to create one abend code for "invalid SVC" with 
an abend reason code of the SVC number, in order to be able to use those 
completion codes for other cases.

Peter Relson
z/OS Core Technoloy Design


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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[R.S.]

W dniu 25.10.2020 o 14:44, Peter Relson pisze:


BTW2: I even experienced F37 abend in the past. It was related to huge
(at the time) Jaguar J1A tapes and good compression and ...problems in
RMM. AFAIK I put over 6TB (terabytes) of uncompressed data on 300GB cart.


Interesting. That completion code would not have been in correct IBM code
(Fxx abends have indicated the non-availability of SVC xx, for as long as
the SVC FLIH has existed, as far as I know).


It was many moons ago, maybe it was z/OS 1.4 or earlier (OS/390 2.10?).
Definitely it was RMM problem, described in some APAR. Jaguar J1A was 
relatively new at the time and capacity growth was signigicant when 
compared to MAGSTAR 3590-H. AFAIR the problem was related to "number of 
bytes written" field in RMM, counter overflow.

Regarding F37 - I just used google and found some cases of RMM & F37.
BTW: google say F16 is not abend. ;-)

--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Seymour J Metz]

I vaguely recall that OS/360 had some Fxx system ABEND codes that did not 
indicate missing SVCs.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Peter Relson [rel...@us.ibm.com]
Sent: Sunday, October 25, 2020 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down


BTW2: I even experienced F37 abend in the past. It was related to huge
(at the time) Jaguar J1A tapes and good compression and ...problems in
RMM. AFAIK I put over 6TB (terabytes) of uncompressed data on 300GB cart.


Interesting. That completion code would not have been in correct IBM code
(Fxx abends have indicated the non-availability of SVC xx, for as long as
the SVC FLIH has existed, as far as I know).

Peter Relson
z/OS Core Technology Design


--
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: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Peter Relson]

BTW2: I even experienced F37 abend in the past. It was related to huge 
(at the time) Jaguar J1A tapes and good compression and ...problems in 
RMM. AFAIK I put over 6TB (terabytes) of uncompressed data on 300GB cart.


Interesting. That completion code would not have been in correct IBM code 
(Fxx abends have indicated the non-availability of SVC xx, for as long as 
the SVC FLIH has existed, as far as I know).

Peter Relson
z/OS Core Technology Design


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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[R.S.]

AFAIK, the abend for directory exhaustion is NOT x37. It is rather B14 
or so.
BTW: yes, I know there are several x37 abends. That's why I used 
lowercase 'x'.
BTW2: I even experienced F37 abend in the past. It was related to huge 
(at the time) Jaguar J1A tapes and good compression and ...problems in 
RMM. AFAIK I put over 6TB (terabytes) of uncompressed data on 300GB cart.


--
Radoslaw Skorupka
Lodz, Poland






W dniu 24.10.2020 o 16:55, Joel C. Ewing pisze:

I'm not assuming any abend code outside the x37 family, just asking
which one.

x37 is not an actual abend code but a generic reference to family of
abend codes  (A37, B37, D37, E37) relating to various out-of-space
conditions.  For a PDS, you get a distinct E37 abend rather than a B37
or D37 when a space failure occurs when attempting to add a directory
entry.

Yes, the underlying root cause for a space failure in the directory is
different for a PDS vs a PDSE, and the problem resolution for a PDSE is
the same whether the no-free-block failure is for a directory-block or a
data-block; yet there are legitimate arguments for preserving an abend
distinction between the case where no member  could be created vs the
possible creation of a member with incomplete data.   The latter case is
potentially more dangerous, as an incomplete member is more likely to be
successfully read by a subsequent process and produce additional
incorrect results that must be resolved.  Or does PDSE logic design
somehow preclude reading a PDSE member when an out-of-space condition
has prevented a proper close and writing of all data blocks during the
member creation?
     JC Ewing

On 10/23/20 9:03 AM, R.S. wrote:

Why do you assume there is/should be other abend than x37?
Any request for new place in the dataset could end with such an abend.





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Paul Gilmartin]

On Sat, 24 Oct 2020 09:55:43 -0500, Joel C. Ewing wrote:
>
> ... Or does PDSE logic design
>somehow preclude reading a PDSE member when an out-of-space condition
>has prevented a proper close and writing of all data blocks during the
>member creation?
>   
I should hope that a well-designed program using BPAM would avoid the
STOW subsequent to an error writing.  But what happens if  the member
is allocated as DSN=data.set.name(member) and the program uses QSAM?

-- gil

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Joel C. Ewing]

I'm not assuming any abend code outside the x37 family, just asking
which one.

x37 is not an actual abend code but a generic reference to family of
abend codes  (A37, B37, D37, E37) relating to various out-of-space
conditions.  For a PDS, you get a distinct E37 abend rather than a B37
or D37 when a space failure occurs when attempting to add a directory
entry.  

Yes, the underlying root cause for a space failure in the directory is
different for a PDS vs a PDSE, and the problem resolution for a PDSE is
the same whether the no-free-block failure is for a directory-block or a
data-block; yet there are legitimate arguments for preserving an abend
distinction between the case where no member  could be created vs the
possible creation of a member with incomplete data.   The latter case is
potentially more dangerous, as an incomplete member is more likely to be
successfully read by a subsequent process and produce additional
incorrect results that must be resolved.  Or does PDSE logic design
somehow preclude reading a PDSE member when an out-of-space condition
has prevented a proper close and writing of all data blocks during the
member creation?
    JC Ewing

On 10/23/20 9:03 AM, R.S. wrote:
> Why do you assume there is/should be other abend than x37?
> Any request for new place in the dataset could end with such an abend.
>

-- 
Joel C. Ewing

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Peter Relson]

... I think PDSE on LNKLST *may have* 
secondary extents and it is NOT bad practise like in case of PDS.


A PDSE counts as having only one extent. That correlates to the DEB for 
the opened concatenation having only one extent entry for a PDSE.
I conclude that the information about other extents is "elsewhere".


What happens when a program reads a member with pages in an
extent not reported in an outdated DEB?


Perhaps this translates to ...with pages in an extent not reported in an 
outdated "elsewhere". If there can be such outdated data for PDSE, then 
one would guess that the answer is the same thing that happens for a PDS. 
I don't know if there can or cannot be.

Peter Relson
z/OS Core Technology Design


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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[R.S.]

Why do you assume there is/should be other abend than x37?
Any request for new place in the dataset could end with such an abend.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 23.10.2020 o 15:15, Joel C. Ewing pisze:

Mike,
Did you miss the "assuming the PDSE has no free blocks and  cannot be
extended"?

I was just curious if the PDSE logic mimicked  the PDS behavior of
making a distinction in the failure response for a full and
non-extendable PDSE depending on whether the no-more-space failure is
first detected when trying to allocate a free block to the directory or
when trying to allocate one for member data.  Or do both these cases
produce an identical ABEND failure along the lines of PDSE
out-of-space-and-unable-to-extend?

     JC Ewing

On 10/22/20 10:23 PM, Mike Schwab wrote:

If all the PDSE directory blocks are full it grabs another block for
the directory, it can't run out of space unless the entire data set
cannot be expanded.

On Thu, Oct 22, 2020 at 5:30 PM Joel C. Ewing  wrote:

I would assume a directory entry must be created before attempting to
allocate space for the contents of a new PDSE member.  So, assuming the
PDSE has no free blocks and cannot be extended, do you get a different
type of ABEND if the out-of-space condition occurs at directory entry
creation time because a new directory block just happens to be needed vs
finding space in an existing directory block and then hitting the
out-of-space condition trying to allocate a block for the member data?
With no free blocks, obviously no new members can be added to the PDSE,
but it looks like it might still  be possible that the failure could be
reflected differently to the user or program depending on purpose for
which a block were needed at the initial point of failure.

In a pathological case where you were just adding a very large number
of  Alias directory entries pointing to existing members, I would think
you could use all remaining free blocks in the PDSE just for directory
blocks without allocating any new blocks for member content, so if PDSE
block allocation failure makes any distinction between failures
occurring when a directory block is needed vs a member data block, that
would be another case that might be reflected as a shortage of directory
space.
 JC Ewing

On 10/22/20 10:52 AM, Charles Mills wrote:

Putting it differently, there is no distinction between "member data space" and "directory 
entry space." Being out of one is being out of both. A PDSE of 10 tracks could equally well hold one 
member of ~500K or lots and lots of tiny or "null" members. A mischievous programmer adding an 
unbounded number of empty members would be no different in effect from a mischievous programmer adding one 
member of unbounded size.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, October 22, 2020 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

W dniu 22.10.2020 o 15:12, Paul Gilmartin pisze:

On Thu, 22 Oct 2020 13:50:44 +0200, R.S. wrote:


Remark: while shortage of space is possible in PDSE, then shortage of
directory blocks is not possible.


What happens if an inquisitive programmer mischievously adds an
unbounded number of empty  members to a small PDSE?  Or adds
numerous aliases to a nearly full PDSE?

My guess: x37 abend or next extent. This is NOT directory full, it is
lack of space.

...

--
Joel C. Ewing






==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Cou

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Joel C. Ewing]

Mike,
Did you miss the "assuming the PDSE has no free blocks and  cannot be
extended"?

I was just curious if the PDSE logic mimicked  the PDS behavior of
making a distinction in the failure response for a full and
non-extendable PDSE depending on whether the no-more-space failure is
first detected when trying to allocate a free block to the directory or
when trying to allocate one for member data.  Or do both these cases
produce an identical ABEND failure along the lines of PDSE
out-of-space-and-unable-to-extend?

    JC Ewing

On 10/22/20 10:23 PM, Mike Schwab wrote:
> If all the PDSE directory blocks are full it grabs another block for
> the directory, it can't run out of space unless the entire data set
> cannot be expanded.
>
> On Thu, Oct 22, 2020 at 5:30 PM Joel C. Ewing  wrote:
>> I would assume a directory entry must be created before attempting to
>> allocate space for the contents of a new PDSE member.  So, assuming the
>> PDSE has no free blocks and cannot be extended, do you get a different
>> type of ABEND if the out-of-space condition occurs at directory entry
>> creation time because a new directory block just happens to be needed vs
>> finding space in an existing directory block and then hitting the
>> out-of-space condition trying to allocate a block for the member data?
>> With no free blocks, obviously no new members can be added to the PDSE,
>> but it looks like it might still  be possible that the failure could be
>> reflected differently to the user or program depending on purpose for
>> which a block were needed at the initial point of failure.
>>
>> In a pathological case where you were just adding a very large number
>> of  Alias directory entries pointing to existing members, I would think
>> you could use all remaining free blocks in the PDSE just for directory
>> blocks without allocating any new blocks for member content, so if PDSE
>> block allocation failure makes any distinction between failures
>> occurring when a directory block is needed vs a member data block, that
>> would be another case that might be reflected as a shortage of directory
>> space.
>> JC Ewing
>>
>> On 10/22/20 10:52 AM, Charles Mills wrote:
>>> Putting it differently, there is no distinction between "member data space" 
>>> and "directory entry space." Being out of one is being out of both. A PDSE 
>>> of 10 tracks could equally well hold one member of ~500K or lots and lots 
>>> of tiny or "null" members. A mischievous programmer adding an unbounded 
>>> number of empty members would be no different in effect from a mischievous 
>>> programmer adding one member of unbounded size.
>>>
>>> Charles
>>>
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>>> Behalf Of R.S.
>>> Sent: Thursday, October 22, 2020 7:29 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
>>>
>>> W dniu 22.10.2020 o 15:12, Paul Gilmartin pisze:
>>>> On Thu, 22 Oct 2020 13:50:44 +0200, R.S. wrote:
>>>>
>>>>> Remark: while shortage of space is possible in PDSE, then shortage of
>>>>> directory blocks is not possible.
>>>>>
>>>> What happens if an inquisitive programmer mischievously adds an
>>>> unbounded number of empty  members to a small PDSE?  Or adds
>>>> numerous aliases to a nearly full PDSE?
>>> My guess: x37 abend or next extent. This is NOT directory full, it is
>>> lack of space.
>>>
>>> ...
>>
>> --
>> Joel C. Ewing
>>
>
>

-- 
Joel C. Ewing

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Mike Schwab]

If all the PDSE directory blocks are full it grabs another block for
the directory, it can't run out of space unless the entire data set
cannot be expanded.

On Thu, Oct 22, 2020 at 5:30 PM Joel C. Ewing  wrote:
>
> I would assume a directory entry must be created before attempting to
> allocate space for the contents of a new PDSE member.  So, assuming the
> PDSE has no free blocks and cannot be extended, do you get a different
> type of ABEND if the out-of-space condition occurs at directory entry
> creation time because a new directory block just happens to be needed vs
> finding space in an existing directory block and then hitting the
> out-of-space condition trying to allocate a block for the member data?
> With no free blocks, obviously no new members can be added to the PDSE,
> but it looks like it might still  be possible that the failure could be
> reflected differently to the user or program depending on purpose for
> which a block were needed at the initial point of failure.
>
> In a pathological case where you were just adding a very large number
> of  Alias directory entries pointing to existing members, I would think
> you could use all remaining free blocks in the PDSE just for directory
> blocks without allocating any new blocks for member content, so if PDSE
> block allocation failure makes any distinction between failures
> occurring when a directory block is needed vs a member data block, that
> would be another case that might be reflected as a shortage of directory
> space.
> JC Ewing
>
> On 10/22/20 10:52 AM, Charles Mills wrote:
> > Putting it differently, there is no distinction between "member data space" 
> > and "directory entry space." Being out of one is being out of both. A PDSE 
> > of 10 tracks could equally well hold one member of ~500K or lots and lots 
> > of tiny or "null" members. A mischievous programmer adding an unbounded 
> > number of empty members would be no different in effect from a mischievous 
> > programmer adding one member of unbounded size.
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> > Behalf Of R.S.
> > Sent: Thursday, October 22, 2020 7:29 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
> >
> > W dniu 22.10.2020 o 15:12, Paul Gilmartin pisze:
> >> On Thu, 22 Oct 2020 13:50:44 +0200, R.S. wrote:
> >>
> >>> Remark: while shortage of space is possible in PDSE, then shortage of
> >>> directory blocks is not possible.
> >>>
> >> What happens if an inquisitive programmer mischievously adds an
> >> unbounded number of empty  members to a small PDSE?  Or adds
> >> numerous aliases to a nearly full PDSE?
> > My guess: x37 abend or next extent. This is NOT directory full, it is
> > lack of space.
> >
> > ...
>
>
> --
> Joel C. Ewing
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Charles Mills]

How many PDSE members can dance on the head of a disk?

It's Friday in Europe and Asia.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Thursday, October 22, 2020 3:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

I would assume a directory entry must be created before attempting to
allocate space for the contents of a new PDSE member.  So, assuming the
PDSE has no free blocks and cannot be extended, do you get a different
type of ABEND if the out-of-space condition occurs at directory entry
creation time because a new directory block just happens to be needed vs
finding space in an existing directory block and then hitting the
out-of-space condition trying to allocate a block for the member data?  
With no free blocks, obviously no new members can be added to the PDSE,
but it looks like it might still  be possible that the failure could be
reflected differently to the user or program depending on purpose for
which a block were needed at the initial point of failure.

In a pathological case where you were just adding a very large number
of  Alias directory entries pointing to existing members, I would think
you could use all remaining free blocks in the PDSE just for directory
blocks without allocating any new blocks for member content, so if PDSE
block allocation failure makes any distinction between failures
occurring when a directory block is needed vs a member data block, that
would be another case that might be reflected as a shortage of directory
space.

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Joel C. Ewing]

I would assume a directory entry must be created before attempting to
allocate space for the contents of a new PDSE member.  So, assuming the
PDSE has no free blocks and cannot be extended, do you get a different
type of ABEND if the out-of-space condition occurs at directory entry
creation time because a new directory block just happens to be needed vs
finding space in an existing directory block and then hitting the
out-of-space condition trying to allocate a block for the member data?  
With no free blocks, obviously no new members can be added to the PDSE,
but it looks like it might still  be possible that the failure could be
reflected differently to the user or program depending on purpose for
which a block were needed at the initial point of failure.

In a pathological case where you were just adding a very large number
of  Alias directory entries pointing to existing members, I would think
you could use all remaining free blocks in the PDSE just for directory
blocks without allocating any new blocks for member content, so if PDSE
block allocation failure makes any distinction between failures
occurring when a directory block is needed vs a member data block, that
would be another case that might be reflected as a shortage of directory
space.
    JC Ewing

On 10/22/20 10:52 AM, Charles Mills wrote:
> Putting it differently, there is no distinction between "member data space" 
> and "directory entry space." Being out of one is being out of both. A PDSE of 
> 10 tracks could equally well hold one member of ~500K or lots and lots of 
> tiny or "null" members. A mischievous programmer adding an unbounded number 
> of empty members would be no different in effect from a mischievous 
> programmer adding one member of unbounded size.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of R.S.
> Sent: Thursday, October 22, 2020 7:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
>
> W dniu 22.10.2020 o 15:12, Paul Gilmartin pisze:
>> On Thu, 22 Oct 2020 13:50:44 +0200, R.S. wrote:
>>
>>> Remark: while shortage of space is possible in PDSE, then shortage of
>>> directory blocks is not possible.
>>>
>> What happens if an inquisitive programmer mischievously adds an
>> unbounded number of empty  members to a small PDSE?  Or adds
>> numerous aliases to a nearly full PDSE?
> My guess: x37 abend or next extent. This is NOT directory full, it is 
> lack of space.
>
> ...


-- 
Joel C. Ewing

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Paul Gilmartin]

On Thu, 22 Oct 2020 08:52:38 -0700, Charles Mills wrote:

>Putting it differently, there is no distinction between "member data space" 
>and "directory entry space." Being out of one is being out of both. A PDSE of 
>10 tracks could equally well hold one member of ~500K or lots and lots of tiny 
>or "null" members. A mischievous programmer adding an unbounded number of 
>empty members would be no different in effect from a mischievous programmer 
>adding one member of unbounded size.
> 
Similar to modern UNIX filesystems' removing the boundary between inode
space and member space:
$ df -k /
Filesystem   1024-blocks  Used Available Capacity iused   
ifree %iused  Mounted on
 /dev/disk3s1   195312500 133893044  5759732870% 1662310 
92233720368531134970%   /

-- gil

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Charles Mills]

Putting it differently, there is no distinction between "member data space" and 
"directory entry space." Being out of one is being out of both. A PDSE of 10 
tracks could equally well hold one member of ~500K or lots and lots of tiny or 
"null" members. A mischievous programmer adding an unbounded number of empty 
members would be no different in effect from a mischievous programmer adding 
one member of unbounded size.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, October 22, 2020 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

W dniu 22.10.2020 o 15:12, Paul Gilmartin pisze:
> On Thu, 22 Oct 2020 13:50:44 +0200, R.S. wrote:
>
>> Remark: while shortage of space is possible in PDSE, then shortage of
>> directory blocks is not possible.
>>
> What happens if an inquisitive programmer mischievously adds an
> unbounded number of empty  members to a small PDSE?  Or adds
> numerous aliases to a nearly full PDSE?
My guess: x37 abend or next extent. This is NOT directory full, it is 
lack of space.

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[R.S.]

W dniu 22.10.2020 o 15:12, Paul Gilmartin pisze:

On Thu, 22 Oct 2020 13:50:44 +0200, R.S. wrote:


Remark: while shortage of space is possible in PDSE, then shortage of
directory blocks is not possible.


What happens if an inquisitive programmer mischievously adds an
unbounded number of empty  members to a small PDSE?  Or adds
numerous aliases to a nearly full PDSE?
My guess: x37 abend or next extent. This is NOT directory full, it is 
lack of space.




BTW: Correct me if I'm wrong, but I think PDSE on LNKLST *may have*
secondary extents and it is NOT bad practise like in case of PDS.


Where does the DEB accounting for added secondary extents reside?
What happens when a program reads a member with pages in an
extent not reported in an outdated DEB?
Ask IBM. However even IBM HealthChecker shouts when find non-zero 
secondary allocation for linklisted datasets, but NOT for PDSEs. 
Example: SYS1.SIEALNKE is provided with secondary allocations, while 
SYS1.LINKLIB has secondary space set to zero.



--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Paul Gilmartin]

On Thu, 22 Oct 2020 13:50:44 +0200, R.S. wrote:

>Remark: while shortage of space is possible in PDSE, then shortage of
>directory blocks is not possible.
>
What happens if an inquisitive programmer mischievously adds an
unbounded number of empty  members to a small PDSE?  Or adds
numerous aliases to a nearly full PDSE?

>BTW: Correct me if I'm wrong, but I think PDSE on LNKLST *may have*
>secondary extents and it is NOT bad practise like in case of PDS.
>
Where does the DEB accounting for added secondary extents reside?
What happens when a program reads a member with pages in an
extent not reported in an outdated DEB?

-- gil

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[R.S.]

Remark: while shortage of space is possible in PDSE, then shortage of 
directory blocks is not possible.


BTW: Correct me if I'm wrong, but I think PDSE on LNKLST *may have* 
secondary extents and it is NOT bad practise like in case of PDS.


--
Radoslaw Skorupka
Lodz, Poland






W dniu 18.10.2020 o 12:06, David Spiegel pisze:

Hi Dave,
For LNKLSTd PDSEs, modules deemed to be in use aren't "removed" from 
the PDSE, which could cause shortage of directory blocks or space.
I usually have to run it twice. The first time is without a PARM, the 
second time with PARM='PerformPendingDelete,NoAnalysis'.


Please see: 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/pdsexmp4.htm


Regards,
David




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[R.S.]

(This is about * and other special names, not about PDS and LNKLST. )

There are two *valid* approaches:

1. Unix-like. Allow use of special characters in the names, but also 
support a method to disable special treatment of the character. That's 
why it is possible to use * as/in the filename, but there is also a 
method to delete or manage file named *. One can tell system "hey this 
is just name *".
Disadvantage: unexperienced user may issue "rm *" command just to delete 
single file.


2. Disallow use of special characters in the names. So special character 
has special meaning only. One can use * only as "all names", but not as 
part of the name. And there is set of "legal" characters which can be 
used in the name, other characters are forbidden even if the characers 
have no special meaning. Example: left bracket have no meaning as 
generic, but it cannot be used in the name. The same for Ą (polish 
character), etc.
Disadvantage: I don't know any system which works as described here. 
Usually there are some inconsistencies. MVS part of z/OS is good 
example. Ancient PC-DOS as well.


So, if ALL could be used both as special name and as regular name, and 
there was no method to distinguish it - it was inconsistency.


BTW: I know a case where (silly) system administrator used "rm *" and 
...deleted all files belonging to banking application. Yes, on 
production. This branch was closed for several days, fortunately they 
had backups and ...paper documents for recovery.


--
Radoslaw Skorupka
Lodz, Poland







W dniu 19.10.2020 o 01:00, Charles Mills pisze:

Not sure exactly how that would be code injection. I meant it as an example of 
a poorly chosen meta (not quite the right word) in syntax. In your example, if 
you are going to allow a member name of '*' then giving dataset(*) a special 
meaning is an invitation to trouble. In DOS/360's case, IBM allowed a phase 
name of ALL, but ALL had a special meaning as the operand of a DELETC 
statement. BTW, the core image library had *everything* executable in it in 
those days. DELETC ALL would be like deleting SYS1.NUCLEUS, SYS1.LINKLIB, 
SYS1.LPALIB and every other load library on the system. They had a SYSRES that 
had to be restored from tape before it would IPL.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, October 17, 2020 9:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

On Sat, 17 Oct 2020 16:19:40 -0700, Charles Mills wrote:


Back in the late sixties ... I wrote a quick program that exactly filled the 
remaining space in the library and named it ALL. They ran the appropriate 
utility with the control statement DELETC ALL with the predictable results. 
They were as unhappy with me as I was with them.


So can you claim to be the inventor of code injection?





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[David Spiegel]

Hi Peter,
Since SCSQAUTH contains all MQ LNKLSTd modules (and no MQ modules are in 
any other LNKLSTd PDS(e)) and MQ, CICS, IMS and Batch are down, I can 
guarantee that no User/Task/Job will attempt to fetch an MQ module.


There are 2 reasons why I would not compress SCSQAUTH:
1) It's a PDSE (not a PDS). My understanding (please correct me if I'm 
wrong) is that PDSEs do not need compression to reclaim space left 
behind by deleted/replaced members.
2) The Dataset has every member deleted. Afterwards, I IEBCOPY into it. 
Why would anyone compress an empty dataset (or a recently populated one)?


Stopping LLA ... that affects the customer's (not robust as it should 
be) Automation. Our implicit rule is that the fewer tasks involved, the 
greater chance of success (implementation and staying within the 
maintenance window).


The "real world" often has considerations that you won't find in a 
pristine laboratory setting. (I've worked many years in both.)


Regards,
David

On 2020-10-20 09:14, Peter Relson wrote:


How about this situation ...
I am part of a team of people who plan maintenance upgrades many months
in advance.
There is no possibility of IPL (for many of the maintenance upgrades).
All Batch is held (other than implementation jobs); DFSMShsm, CICS, IMS
and DB2 are down.
TSO is limited to implementers.
SCSQAUTH (an MQ LNKLSTd Dataset) is emptied, its contents replaced and
LLA is REFRESHd.
MQ, CICS, IMS and DB2 are started and tested by implementers and then by
the customer.
After everyone signs off, it's back to "business as usual" and Batch is
restarted.

Do you see any holes in this approach?


If you can guarantee that no one does any fetch that might involve a
member with the same name as one within the PDS that you emptied then
"maybe".
And if you don't need to compress the data set then "maybe".
The operating system cannot stop you from compressing the data set. But it
tries a little, by allocating the data set with DISP=SHR, so that if you
do what you really should do for a compress, of using DISP=OLD, you won't
be able to.

If you're going to refresh LLA anyway, why not be safer and stop LLA
first, then restart when you're ready? The refresh will negate any
relevant caching of directories or modules, so there's no real benefit to
having LLA up across the operations.

Peter Relson
z/OS Core Technology Design


--
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: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Peter Relson]

How about this situation ...
I am part of a team of people who plan maintenance upgrades many months 
in advance.
There is no possibility of IPL (for many of the maintenance upgrades).
All Batch is held (other than implementation jobs); DFSMShsm, CICS, IMS 
and DB2 are down.
TSO is limited to implementers.
SCSQAUTH (an MQ LNKLSTd Dataset) is emptied, its contents replaced and 
LLA is REFRESHd.
MQ, CICS, IMS and DB2 are started and tested by implementers and then by 
the customer.
After everyone signs off, it's back to "business as usual" and Batch is 
restarted.

Do you see any holes in this approach?


If you can guarantee that no one does any fetch that might involve a 
member with the same name as one within the PDS that you emptied then 
"maybe".
And if you don't need to compress the data set then "maybe".
The operating system cannot stop you from compressing the data set. But it 
tries a little, by allocating the data set with DISP=SHR, so that if you 
do what you really should do for a compress, of using DISP=OLD, you won't 
be able to. 

If you're going to refresh LLA anyway, why not be safer and stop LLA 
first, then restart when you're ready? The refresh will negate any 
relevant caching of directories or modules, so there's no real benefit to 
having LLA up across the operations.

Peter Relson
z/OS Core Technology Design


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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[David Spiegel]

Hi Peter,
How about this situation ...
I am part of a team of people who plan maintenance upgrades many months 
in advance.

There is no possibility of IPL (for many of the maintenance upgrades).
All Batch is held (other than implementation jobs); DFSMShsm, CICS, IMS 
and DB2 are down.

TSO is limited to implementers.
SCSQAUTH (an MQ LNKLSTd Dataset) is emptied, its contents replaced and 
LLA is REFRESHd.
MQ, CICS, IMS and DB2 are started and tested by implementers and then by 
the customer.
After everyone signs off, it's back to "business as usual" and Batch is 
restarted.


Do you see any holes in this approach?

Thanks and regards,
David

On 2020-10-19 09:46, Peter Relson wrote:

You delete members (let alone delete all members) from any LNKLST data set
at your own risk. If you're going to do that, you'd better not have LLA
active.
Maybe you get away with it with LLA up and a refresh. That doesn't mean it
worked or didn't leave you undesirably exposed.

Peter Relson
z/OS Core Technology Design


--
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: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Peter Relson]

You delete members (let alone delete all members) from any LNKLST data set 
at your own risk. If you're going to do that, you'd better not have LLA 
active.
Maybe you get away with it with LLA up and a refresh. That doesn't mean it 
worked or didn't leave you undesirably exposed.

Peter Relson
z/OS Core Technology Design


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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Binyamin Dissen]

On Sat, 17 Oct 2020 18:04:38 -0500 Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

:>On Sat, 17 Oct 2020 17:48:57 -0500, Steve Horein wrote:

:>>Good ole IDCAMS anyone?
:>>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/dgt3i231.htm
 
:>How might one delete a PDS member named "*   "?

Modify the program that created it. STOW D is easier than STOW A.

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

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Charles Mills]

Not sure exactly how that would be code injection. I meant it as an example of 
a poorly chosen meta (not quite the right word) in syntax. In your example, if 
you are going to allow a member name of '*' then giving dataset(*) a special 
meaning is an invitation to trouble. In DOS/360's case, IBM allowed a phase 
name of ALL, but ALL had a special meaning as the operand of a DELETC 
statement. BTW, the core image library had *everything* executable in it in 
those days. DELETC ALL would be like deleting SYS1.NUCLEUS, SYS1.LINKLIB, 
SYS1.LPALIB and every other load library on the system. They had a SYSRES that 
had to be restored from tape before it would IPL.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, October 17, 2020 9:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

On Sat, 17 Oct 2020 16:19:40 -0700, Charles Mills wrote:

>Back in the late sixties ... I wrote a quick program that exactly filled the 
>remaining space in the library and named it ALL. They ran the appropriate 
>utility with the control statement DELETC ALL with the predictable results. 
>They were as unhappy with me as I was with them.
> 
So can you claim to be the inventor of code injection?

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Lizette Koehler]

You can use IEBPDSE to validate a PDSE data set and determine whether it is 
valid or corrupted.

Lizette

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Sunday, October 18, 2020 6:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

Hi Dave,
In case that it's a LNKLKSTd PDSE (i.e. not a PDS) and it's close to 100% full 
(Of course, it's only 1 extent, because that's a good practice for LNKLST 
Datasets)  and more than a few large modules/program objects are deemed to be 
in use, your IEBCOPY Job will ABEND x37, even though in ISPF Option 3.2 it 
looks empty.

During MQ Maintenace/Upgrades I've had to run IEBPDSE for every system which 
LNKLSTs SCSQAUTH.

Regards,
David

On 2020-10-18 08:24, Jousma, David wrote:
> Well, thanks for that.  It’s a new one on me.  For years, when replacing 
> contents of linklisted datasets, I've just deleted all members, copied all 
> new content in, and refreshed lla.
>
> __
> ___
> Dave Jousma
> AVP | Director, Technology Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of David Spiegel
> Sent: Sunday, October 18, 2020 6:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> Hi Dave,
> For LNKLSTd PDSEs, modules deemed to be in use aren't "removed" from the 
> PDSE, which could cause shortage of directory blocks or space.
> I usually have to run it twice. The first time is without a PARM, the second 
> time with PARM='PerformPendingDelete,NoAnalysis'.
>
> Please see:
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.
> v2r3.idau100%2Fpdsexmp4.htmdata=04%7C01%7C%7Ca56a150920a8496a24f7
> 08d87360d67b%7C84df9e7fe9f640afb435%7C1%7C0%7C637386207048
> 000830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=aAbpMrMEEjDcjZVv6JSxQuQw3
> 0TaA1ix6tOrgaCFIuU%3Dreserved=0
>
> Regards,
> David
>
>
> On 2020-10-18 01:18, Jousma, David wrote:
>> Never heard of the utility.  Why would that be needed?
>>
>> _
>> _
>> ___
>> Dave Jousma
>> AVP | Director, Technology Engineering
>>
>> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
>> Rapids, MI 49546
>> 616.653.8429  |  fax: 616.653.2717
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of David Spiegel
>> Sent: Sunday, October 18, 2020 12:42 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
>>
>> **CAUTION EXTERNAL EMAIL**
>>
>> **DO NOT open attachments or click on links from unknown senders or 
>> unexpected emails**
>>
>> Hi Dave,
>> If it's a Linklisted PDSE, you also may have to run IEBPDSE after the 
>> members are deleted.
>>
>> Regards,
>> David
>>
>> On 2020-10-18 00:11, Jousma, David wrote:
>>> That’s what I was going to say...doesnt get much easier.  I do this 
>>> all the time when I want to update the contents of a linklisted 
>>> dataset
>>>
>>> //IDCAMS   EXEC PGM=IDCAMS
>>> //SYSUDUMP DD   SYSOUT=*
>>> //SYSPRINT DD   SYSOUT=*
>>> //LIBRARY  DD DSN=your.pds.dataset,DISP=SHR //SYSIN DD *
>>>  DELETE your.pds.dataset(*)   FILE(LIBRARY)
>>> /*
>>> 
>>> _
>>> _
>>> ___
>>> Dave Jousma
>>> AVP | Director, Technology Engineering
>>>
>>> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
>>> Rapids, MI 49546
>>> 616.653.8429  |  fax: 616.653.2717
>>>
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On 
>>> Behalf Of Steve Horein
>>> Sent: Saturday, October 17, 2020 6:49 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
>>

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[David Spiegel]

Hi Dave,
In case that it's a LNKLKSTd PDSE (i.e. not a PDS) and it's close to 
100% full (Of course, it's only 1 extent, because that's a good practice 
for LNKLST Datasets)  and more than a few large modules/program objects 
are deemed to be in use, your IEBCOPY Job will ABEND x37, even though in 
ISPF Option 3.2 it looks empty.


During MQ Maintenace/Upgrades I've had to run IEBPDSE for every system 
which LNKLSTs SCSQAUTH.


Regards,
David

On 2020-10-18 08:24, Jousma, David wrote:

Well, thanks for that.  It’s a new one on me.  For years, when replacing 
contents of linklisted datasets, I've just deleted all members, copied all new 
content in, and refreshed lla.

_
Dave Jousma
AVP | Director, Technology Engineering

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Sunday, October 18, 2020 6:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hi Dave,
For LNKLSTd PDSEs, modules deemed to be in use aren't "removed" from the PDSE, 
which could cause shortage of directory blocks or space.
I usually have to run it twice. The first time is without a PARM, the second 
time with PARM='PerformPendingDelete,NoAnalysis'.

Please see:
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.idau100%2Fpdsexmp4.htmdata=04%7C01%7C%7Ca56a150920a8496a24f708d87360d67b%7C84df9e7fe9f640afb435%7C1%7C0%7C637386207048000830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=aAbpMrMEEjDcjZVv6JSxQuQw30TaA1ix6tOrgaCFIuU%3Dreserved=0

Regards,
David


On 2020-10-18 01:18, Jousma, David wrote:

Never heard of the utility.  Why would that be needed?

__
___
Dave Jousma
AVP | Director, Technology Engineering

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


-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of David Spiegel
Sent: Sunday, October 18, 2020 12:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Hi Dave,
If it's a Linklisted PDSE, you also may have to run IEBPDSE after the members 
are deleted.

Regards,
David

On 2020-10-18 00:11, Jousma, David wrote:

That’s what I was going to say...doesnt get much easier.  I do this
all the time when I want to update the contents of a linklisted
dataset

//IDCAMS   EXEC PGM=IDCAMS
//SYSUDUMP DD   SYSOUT=*
//SYSPRINT DD   SYSOUT=*
//LIBRARY  DD DSN=your.pds.dataset,DISP=SHR //SYSIN DD *
 DELETE your.pds.dataset(*)   FILE(LIBRARY)
/*
_
_
___
Dave Jousma
AVP | Director, Technology Engineering

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


-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Steve Horein
Sent: Saturday, October 17, 2020 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Good ole IDCAMS anyone?
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.4.0%2Fcom.ibm.zos.v2r4.
idai200%2Fdgt3i231.htmdata=04%7C01%7C%7Cffe03d56aebe4262c3d308d8
7
31bfa0e%7C84df9e7fe9f640afb435%7C1%7C0%7C6373859112847796
2
1%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
6
Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iyei6oTeqNIWXdTCZAFKf6vOccPPS
d
ryGpw8M8cBiwg%3Dreserved=0


On Sat, Oct 17, 2020 at 5:34 PM Chris Hoelscher

wrote:


I have employed this REXX script for years:

/* REXX */
DSNAME = 'my PDS'
DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */ QUOTE
= "'"
QDSN  = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */

ADDRESS ISPEXEC
"LMINIT  DATAID( MYDATAID)  DATASET(" QDSN ") ENQ(SHRW)"
"LMOPEN  DATAID("MYDATAID") OPTION(OUTPUT)"
"LMMDEL  DATAID("MYDATAID") MEMBER(*)"
"LMCLOSE DATAID("MYDATAID")"
"LMFREE  DATAID("MYDATAID")"

SAY DSN " IS NOW EM

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Paul Gilmartin]

On Sun, 18 Oct 2020 06:06:50 -0400, David Spiegel  wrote:
>
>For LNKLSTd PDSEs, modules deemed to be in use aren't "removed" from the
>PDSE, which could cause shortage of directory blocks or space.
>I usually have to run it twice. The first time is without a PARM, the
>second time with PARM='PerformPendingDelete,NoAnalysis'.
>
Is PARM case-insensitive?  Is that unusual for utilities?

>Please see:
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/pdsexmp4.htm
>
That doc appears to have been generated from a Utilities chapter
template, carelessly edited by an entry-level programmer.  I believe
I'll submit an RCF:

In:  z/OS  Version 2 Release 4
DFSMSdfp Utilities
IBM  SC23-6864-40

Chapter 9. IEBPDSE (PDSE Validation) Program
I see:
Table 32. Job control statements for IEBPDSE (continued)
...
SYSPRINT DD
Use
Defines a sequential output message data set, which can be written on
a system printer, a magnetic tape volume, or a direct access volume.
If this statement is omitted, the output appears in the job log.
...
The block size for the SYSPRINT data set must be a multiple of 121.
If not, the job step will end with a return code of 8.

This the only constraint specified on SYSPRINT attributes.
so may I assume "//SYSPRINT DD BLKSIZE=12100,RECFM=VBA,LRECL=137"
is supported?

SYSIN DD
If specified, the SYSIN data set must be empty.

o Is this enforced?
o If SYSIN is nonempty, what RC and messages result?
o What attributes and device types are supported?
o If SYSIN is the output of a UNIX pipe, does IEBPDSE pause
  until its input is closed to verify that it's empty?
o What other DDNAMEs are allowed, such as SYSUT1, SYSUT2,
  SYSTERM, WOMBAT, ...?  Must they likewise be empty?
...

Example 2: Validate two PDSEs
This example validates two PDSEs.
//STEPCHK2 EXEC PGM=IEBPDSE
//SYSLIB DD DSN=IBMUSER.SIMPLE.V2.PDSE,DISP=OLD
// DD DSN=IBMUSER.SIMPLE.V3.PDSE,DISP=OLD
// DD DSN=SYS1.LINKLIB,DISP=SHR

o SYSLIB has three catenands.  Which two are validated
  and which one is ignored?
o Indention should be consistent.
...

Example 3: Validate a PDSE with the DUMP option
This example validates a PDSE and specifies an SVC dump.
 //STEPLINK EXEC PGM=IEBPDSE,
// PARM=’DUMP’
//SYSLIB DD DSN=SYS1.LINKLIB,DISP=SHR

o Is the SVC dump unconditional, or only if SYSIN is nonempty?
o Why would a programmer want to do this?
o Indention should be consistent.

-- gil

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Jackson, Rob]

Pardon if I missed someone else pointing it out, but one can also browse the 
PDS/PDSE from 3.4 (panel ISRUDSM, not ISRBROM) and enter 's * d' on the command 
line.  It's not as fast or efficient in operation as some of the others . . . .

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Sunday, October 18, 2020 12:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

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

That’s what I was going to say...doesnt get much easier.  I do this all the 
time when I want to update the contents of a linklisted dataset

//IDCAMS   EXEC PGM=IDCAMS
//SYSUDUMP DD   SYSOUT=*
//SYSPRINT DD   SYSOUT=*
//LIBRARY  DD DSN=your.pds.dataset,DISP=SHR //SYSIN DD *
  DELETE your.pds.dataset(*)   FILE(LIBRARY)
/*
_
Dave Jousma
AVP | Director, Technology Engineering

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Horein
Sent: Saturday, October 17, 2020 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Good ole IDCAMS anyone?
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/dgt3i231.htm


On Sat, Oct 17, 2020 at 5:34 PM Chris Hoelscher 
wrote:

> I have employed this REXX script for years:
>
> /* REXX */
> DSNAME = 'my PDS'
> DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */ QUOTE = 
> "'"
> QDSN  = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */
>
> ADDRESS ISPEXEC
> "LMINIT  DATAID( MYDATAID)  DATASET(" QDSN ") ENQ(SHRW)"
> "LMOPEN  DATAID("MYDATAID") OPTION(OUTPUT)"
> "LMMDEL  DATAID("MYDATAID") MEMBER(*)"
> "LMCLOSE DATAID("MYDATAID")"
> "LMFREE  DATAID("MYDATAID")"
>
>  SAY DSN " IS NOW EMPTY"
>
> Chris Hoelscher
> Lead Sys DBA
> IBM Global Technical Services on assignmemt to Humana Inc.
> T 502.476.2538  or 502.407.7266
>
>
> The information transmitted is intended only for the person or entity 
> to which it is addressed and may contain CONFIDENTIAL material.  If 
> you receive this material/information in error, please contact the 
> sender and delete or destroy the material/information.
>
> Humana Inc. and its subsidiaries comply with applicable Federal civil 
> rights laws and do not discriminate on the basis of race, color, 
> national origin, ancestry, age, disability, sex, marital status, 
> gender, sexual orientation, gender identity, or religion.
> Humana Inc. and its subsidiaries do not exclude people or treat them 
> differently because of race, color, national origin, ancestry, age, 
> disability, sex, marital status, gender, sexual orientation, gender 
> identity, or religion.
>
> English: ATTENTION: If you do not speak English, language assistance 
> services, free of charge, are available to you. Call 1‐877‐320‐1235
> (TTY: 711).
>
> Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición 
> servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235
> (TTY: 711).
>
> 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
> 服務。請致電 1‐877‐320‐1235 (TTY: 711)。
>
> Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, 
> gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235
> (TTY: 711).
>
> Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z 
> bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY:
> 711).
>
> 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다.
> 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read,

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Jousma, David]

Well, thanks for that.  It’s a new one on me.  For years, when replacing 
contents of linklisted datasets, I've just deleted all members, copied all new 
content in, and refreshed lla.  

_
Dave Jousma
AVP | Director, Technology Engineering  

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Sunday, October 18, 2020 6:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hi Dave,
For LNKLSTd PDSEs, modules deemed to be in use aren't "removed" from the PDSE, 
which could cause shortage of directory blocks or space.
I usually have to run it twice. The first time is without a PARM, the second 
time with PARM='PerformPendingDelete,NoAnalysis'.

Please see: 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/pdsexmp4.htm

Regards,
David


On 2020-10-18 01:18, Jousma, David wrote:
> Never heard of the utility.  Why would that be needed?
>
> __
> ___
> Dave Jousma
> AVP | Director, Technology Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of David Spiegel
> Sent: Sunday, October 18, 2020 12:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> Hi Dave,
> If it's a Linklisted PDSE, you also may have to run IEBPDSE after the members 
> are deleted.
>
> Regards,
> David
>
> On 2020-10-18 00:11, Jousma, David wrote:
>> That’s what I was going to say...doesnt get much easier.  I do this 
>> all the time when I want to update the contents of a linklisted 
>> dataset
>>
>> //IDCAMS   EXEC PGM=IDCAMS
>> //SYSUDUMP DD   SYSOUT=*
>> //SYSPRINT DD   SYSOUT=*
>> //LIBRARY  DD DSN=your.pds.dataset,DISP=SHR //SYSIN DD *
>> DELETE your.pds.dataset(*)   FILE(LIBRARY)
>> /*
>> _
>> _
>> ___
>> Dave Jousma
>> AVP | Director, Technology Engineering
>>
>> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
>> Rapids, MI 49546
>> 616.653.8429  |  fax: 616.653.2717
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Steve Horein
>> Sent: Saturday, October 17, 2020 6:49 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
>>
>> **CAUTION EXTERNAL EMAIL**
>>
>> **DO NOT open attachments or click on links from unknown senders or 
>> unexpected emails**
>>
>> Good ole IDCAMS anyone?
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.4.0%2Fcom.ibm.zos.v2r4.
>> idai200%2Fdgt3i231.htmdata=04%7C01%7C%7Cffe03d56aebe4262c3d308d8
>> 7
>> 31bfa0e%7C84df9e7fe9f640afb435%7C1%7C0%7C6373859112847796
>> 2
>> 1%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
>> 6 
>> Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iyei6oTeqNIWXdTCZAFKf6vOccPPS
>> d
>> ryGpw8M8cBiwg%3Dreserved=0
>>
>>
>> On Sat, Oct 17, 2020 at 5:34 PM Chris Hoelscher 
>> 
>> wrote:
>>
>>> I have employed this REXX script for years:
>>>
>>> /* REXX */
>>> DSNAME = 'my PDS'
>>> DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */ QUOTE 
>>> = "'"
>>> QDSN  = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */
>>>
>>> ADDRESS ISPEXEC
>>> "LMINIT  DATAID( MYDATAID)  DATASET(" QDSN ") ENQ(SHRW)"
>>> "LMOPEN  DATAID("MYDATAID") OPTION(OUTPUT)"
>>> "LMMDEL  DATAID("MYDATAID") MEMBER(*)"
>>> "LMCLOSE DATAID("MYDATAID")"
>>> "LMFREE  DATAID("MYDATAID")"
>>>
>>>SAY DSN " IS NOW EMPTY"
>>>
>

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[David Spiegel]

Hi Dave,
For LNKLSTd PDSEs, modules deemed to be in use aren't "removed" from the 
PDSE, which could cause shortage of directory blocks or space.
I usually have to run it twice. The first time is without a PARM, the 
second time with PARM='PerformPendingDelete,NoAnalysis'.


Please see: 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/pdsexmp4.htm


Regards,
David


On 2020-10-18 01:18, Jousma, David wrote:

Never heard of the utility.  Why would that be needed?

_
Dave Jousma
AVP | Director, Technology Engineering

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Sunday, October 18, 2020 12:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hi Dave,
If it's a Linklisted PDSE, you also may have to run IEBPDSE after the members 
are deleted.

Regards,
David

On 2020-10-18 00:11, Jousma, David wrote:

That’s what I was going to say...doesnt get much easier.  I do this
all the time when I want to update the contents of a linklisted
dataset

//IDCAMS   EXEC PGM=IDCAMS
//SYSUDUMP DD   SYSOUT=*
//SYSPRINT DD   SYSOUT=*
//LIBRARY  DD DSN=your.pds.dataset,DISP=SHR //SYSIN DD *
DELETE your.pds.dataset(*)   FILE(LIBRARY)
/*
__
___
Dave Jousma
AVP | Director, Technology Engineering

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


-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Steve Horein
Sent: Saturday, October 17, 2020 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Good ole IDCAMS anyone?
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.4.0%2Fcom.ibm.zos.v2r4.
idai200%2Fdgt3i231.htmdata=04%7C01%7C%7Cffe03d56aebe4262c3d308d87
31bfa0e%7C84df9e7fe9f640afb435%7C1%7C0%7C63738591128477962
1%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iyei6oTeqNIWXdTCZAFKf6vOccPPSd
ryGpw8M8cBiwg%3Dreserved=0


On Sat, Oct 17, 2020 at 5:34 PM Chris Hoelscher

wrote:


I have employed this REXX script for years:

/* REXX */
DSNAME = 'my PDS'
DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */ QUOTE
= "'"
QDSN  = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */

ADDRESS ISPEXEC
"LMINIT  DATAID( MYDATAID)  DATASET(" QDSN ") ENQ(SHRW)"
"LMOPEN  DATAID("MYDATAID") OPTION(OUTPUT)"
"LMMDEL  DATAID("MYDATAID") MEMBER(*)"
"LMCLOSE DATAID("MYDATAID")"
"LMFREE  DATAID("MYDATAID")"

   SAY DSN " IS NOW EMPTY"

Chris Hoelscher
Lead Sys DBA
IBM Global Technical Services on assignmemt to Humana Inc.
T 502.476.2538  or 502.407.7266


The information transmitted is intended only for the person or entity
to which it is addressed and may contain CONFIDENTIAL material.  If
you receive this material/information in error, please contact the
sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil
rights laws and do not discriminate on the basis of race, color,
national origin, ancestry, age, disability, sex, marital status,
gender, sexual orientation, gender identity, or religion.
Humana Inc. and its subsidiaries do not exclude people or treat them
differently because of race, color, national origin, ancestry, age,
disability, sex, marital status, gender, sexual orientation, gender
identity, or religion.

English: ATTENTION: If you do not speak English, language assistance
services, free of charge, are available to you. Call 1‐877‐320‐1235
(TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición
servicios gratuitos de asistencia lingüística. Llame al
1‐877‐320‐1235
(TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen,
gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235
(TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z
bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY:
711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다.
1‐877‐320‐1235 (TTY: 711)번으로 전화해

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Roger Lowe]

On Sun, 18 Oct 2020 05:18:20 +, Jousma, David  wrote:

>Never heard of the utility.  Why would that be needed?
>
IEBPDSE is the PDS/E Validation Utility and it validates a PDS/E to see if it 
is valid or corrupted. See the DFSMSdfp Utilities manual.

Roger

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Jousma, David]

Never heard of the utility.  Why would that be needed?

_
Dave Jousma
AVP | Director, Technology Engineering  

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Sunday, October 18, 2020 12:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hi Dave,
If it's a Linklisted PDSE, you also may have to run IEBPDSE after the members 
are deleted.

Regards,
David

On 2020-10-18 00:11, Jousma, David wrote:
> That’s what I was going to say...doesnt get much easier.  I do this 
> all the time when I want to update the contents of a linklisted 
> dataset
>
> //IDCAMS   EXEC PGM=IDCAMS
> //SYSUDUMP DD   SYSOUT=*
> //SYSPRINT DD   SYSOUT=*
> //LIBRARY  DD DSN=your.pds.dataset,DISP=SHR //SYSIN DD *
>DELETE your.pds.dataset(*)   FILE(LIBRARY)
> /*
> __
> ___
> Dave Jousma
> AVP | Director, Technology Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Steve Horein
> Sent: Saturday, October 17, 2020 6:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> Good ole IDCAMS anyone?
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.4.0%2Fcom.ibm.zos.v2r4.
> idai200%2Fdgt3i231.htmdata=04%7C01%7C%7Cffe03d56aebe4262c3d308d87
> 31bfa0e%7C84df9e7fe9f640afb435%7C1%7C0%7C63738591128477962
> 1%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iyei6oTeqNIWXdTCZAFKf6vOccPPSd
> ryGpw8M8cBiwg%3Dreserved=0
>
>
> On Sat, Oct 17, 2020 at 5:34 PM Chris Hoelscher 
> 
> wrote:
>
>> I have employed this REXX script for years:
>>
>> /* REXX */
>> DSNAME = 'my PDS'
>> DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */ QUOTE 
>> = "'"
>> QDSN  = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */
>>
>> ADDRESS ISPEXEC
>> "LMINIT  DATAID( MYDATAID)  DATASET(" QDSN ") ENQ(SHRW)"
>> "LMOPEN  DATAID("MYDATAID") OPTION(OUTPUT)"
>> "LMMDEL  DATAID("MYDATAID") MEMBER(*)"
>> "LMCLOSE DATAID("MYDATAID")"
>> "LMFREE  DATAID("MYDATAID")"
>>
>>   SAY DSN " IS NOW EMPTY"
>>
>> Chris Hoelscher
>> Lead Sys DBA
>> IBM Global Technical Services on assignmemt to Humana Inc.
>> T 502.476.2538  or 502.407.7266
>>
>>
>> The information transmitted is intended only for the person or entity 
>> to which it is addressed and may contain CONFIDENTIAL material.  If 
>> you receive this material/information in error, please contact the 
>> sender and delete or destroy the material/information.
>>
>> Humana Inc. and its subsidiaries comply with applicable Federal civil 
>> rights laws and do not discriminate on the basis of race, color, 
>> national origin, ancestry, age, disability, sex, marital status, 
>> gender, sexual orientation, gender identity, or religion.
>> Humana Inc. and its subsidiaries do not exclude people or treat them 
>> differently because of race, color, national origin, ancestry, age, 
>> disability, sex, marital status, gender, sexual orientation, gender 
>> identity, or religion.
>>
>> English: ATTENTION: If you do not speak English, language assistance 
>> services, free of charge, are available to you. Call 1‐877‐320‐1235
>> (TTY: 711).
>>
>> Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición 
>> servicios gratuitos de asistencia lingüística. Llame al 
>> 1‐877‐320‐1235
>> (TTY: 711).
>>
>> 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
>> 服務。請致電 1‐877‐320‐1235 (TTY: 711)。
>>
>> Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, 
>> gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235
>> (TTY: 711).
>>
>

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[David Spiegel]

Hi Dave,
If it's a Linklisted PDSE, you also may have to run IEBPDSE after the 
members are deleted.


Regards,
David

On 2020-10-18 00:11, Jousma, David wrote:

That’s what I was going to say...doesnt get much easier.  I do this all the 
time when I want to update the contents of a linklisted dataset

//IDCAMS   EXEC PGM=IDCAMS
//SYSUDUMP DD   SYSOUT=*
//SYSPRINT DD   SYSOUT=*
//LIBRARY  DD DSN=your.pds.dataset,DISP=SHR
//SYSIN DD *
   DELETE your.pds.dataset(*)   FILE(LIBRARY)
/*
_
Dave Jousma
AVP | Director, Technology Engineering

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Horein
Sent: Saturday, October 17, 2020 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Good ole IDCAMS anyone?
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.4.0%2Fcom.ibm.zos.v2r4.idai200%2Fdgt3i231.htmdata=04%7C01%7C%7Cffe03d56aebe4262c3d308d8731bfa0e%7C84df9e7fe9f640afb435%7C1%7C0%7C637385911284779621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iyei6oTeqNIWXdTCZAFKf6vOccPPSdryGpw8M8cBiwg%3Dreserved=0


On Sat, Oct 17, 2020 at 5:34 PM Chris Hoelscher 
wrote:


I have employed this REXX script for years:

/* REXX */
DSNAME = 'my PDS'
DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */ QUOTE =
"'"
QDSN  = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */

ADDRESS ISPEXEC
"LMINIT  DATAID( MYDATAID)  DATASET(" QDSN ") ENQ(SHRW)"
"LMOPEN  DATAID("MYDATAID") OPTION(OUTPUT)"
"LMMDEL  DATAID("MYDATAID") MEMBER(*)"
"LMCLOSE DATAID("MYDATAID")"
"LMFREE  DATAID("MYDATAID")"

  SAY DSN " IS NOW EMPTY"

Chris Hoelscher
Lead Sys DBA
IBM Global Technical Services on assignmemt to Humana Inc.
T 502.476.2538  or 502.407.7266


The information transmitted is intended only for the person or entity
to which it is addressed and may contain CONFIDENTIAL material.  If
you receive this material/information in error, please contact the
sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil
rights laws and do not discriminate on the basis of race, color,
national origin, ancestry, age, disability, sex, marital status,
gender, sexual orientation, gender identity, or religion.
Humana Inc. and its subsidiaries do not exclude people or treat them
differently because of race, color, national origin, ancestry, age,
disability, sex, marital status, gender, sexual orientation, gender
identity, or religion.

English: ATTENTION: If you do not speak English, language assistance
services, free of charge, are available to you. Call 1‐877‐320‐1235
(TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición
servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235
(TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen,
gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235
(TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z
bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY:
711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다.
1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


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


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

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


-

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Paul Gilmartin]

On Sat, 17 Oct 2020 16:19:40 -0700, Charles Mills wrote:

>Back in the late sixties ... I wrote a quick program that exactly filled the 
>remaining space in the library and named it ALL. They ran the appropriate 
>utility with the control statement DELETC ALL with the predictable results. 
>They were as unhappy with me as I was with them.
> 
So can you claim to be the inventor of code injection?

I found an injection weakness in "skulker" Exec.  I never exploited it but got
an integrity APAR.

>-Original Message-
>From: Charles Mills
>Sent: Saturday, October 17, 2020 4:13 PM
>
>I would suggest shooting the creator.
> 
Please don't do that.  When I was first learning JCL I experimented with DSNAMEs
protected by apostrophes. With IEFBR14 and DD DISP=(NEW,KEEP) I created
various data set names containing blanks, apostrophes, binary zeroes,
lower case, long qualifiers, ...

A few days later, irate storage administrators descended on me.  I had crashed
their utility that scratched uncatalogued data sets.

But shooting me would have inconvenienced more than assisted them.

They need a better utility; one that could deal with any DSNAME a programmer
could create.

-- gil

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Jousma, David]

That’s what I was going to say...doesnt get much easier.  I do this all the 
time when I want to update the contents of a linklisted dataset

//IDCAMS   EXEC PGM=IDCAMS  
//SYSUDUMP DD   SYSOUT=*
//SYSPRINT DD   SYSOUT=*
//LIBRARY  DD DSN=your.pds.dataset,DISP=SHR 
//SYSIN DD *
  DELETE your.pds.dataset(*)   FILE(LIBRARY)   
/*  
_
Dave Jousma
AVP | Director, Technology Engineering  

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Horein
Sent: Saturday, October 17, 2020 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Good ole IDCAMS anyone?
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/dgt3i231.htm


On Sat, Oct 17, 2020 at 5:34 PM Chris Hoelscher 
wrote:

> I have employed this REXX script for years:
>
> /* REXX */
> DSNAME = 'my PDS'
> DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */ QUOTE = 
> "'"
> QDSN  = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */
>
> ADDRESS ISPEXEC
> "LMINIT  DATAID( MYDATAID)  DATASET(" QDSN ") ENQ(SHRW)"
> "LMOPEN  DATAID("MYDATAID") OPTION(OUTPUT)"
> "LMMDEL  DATAID("MYDATAID") MEMBER(*)"
> "LMCLOSE DATAID("MYDATAID")"
> "LMFREE  DATAID("MYDATAID")"
>
>  SAY DSN " IS NOW EMPTY"
>
> Chris Hoelscher
> Lead Sys DBA
> IBM Global Technical Services on assignmemt to Humana Inc.
> T 502.476.2538  or 502.407.7266
>
>
> The information transmitted is intended only for the person or entity 
> to which it is addressed and may contain CONFIDENTIAL material.  If 
> you receive this material/information in error, please contact the 
> sender and delete or destroy the material/information.
>
> Humana Inc. and its subsidiaries comply with applicable Federal civil 
> rights laws and do not discriminate on the basis of race, color, 
> national origin, ancestry, age, disability, sex, marital status, 
> gender, sexual orientation, gender identity, or religion.
> Humana Inc. and its subsidiaries do not exclude people or treat them 
> differently because of race, color, national origin, ancestry, age, 
> disability, sex, marital status, gender, sexual orientation, gender 
> identity, or religion.
>
> English: ATTENTION: If you do not speak English, language assistance 
> services, free of charge, are available to you. Call 1‐877‐320‐1235 
> (TTY: 711).
>
> Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición 
> servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 
> (TTY: 711).
>
> 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
> 服務。請致電 1‐877‐320‐1235 (TTY: 711)。
>
> Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, 
> gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 
> (TTY: 711).
>
> Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z 
> bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 
> 711).
>
> 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 
> 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

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


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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Seymour J Metz]

Well, in the old days I would have written a Q program to delete it. Whether 
STOW will still accept such a member name is anybody's guess.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, October 17, 2020 7:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

On Sat, 17 Oct 2020 17:48:57 -0500, Steve Horein wrote:

>Good ole IDCAMS anyone?
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/dgt3i231.htm
>
How might one delete a PDS member named "*   "?

-- gil

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

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Charles Mills]

Back in the late sixties I was doing DOS/360 contract programming. I used a 
service bureau that would not let me store executable programs; I had to do a 
compile and go every time on an expensive system I was paying for out of my 
pocket. After running a very long compile I ran out of space in their core 
image ("load") library and the job failed. I asked for credit for the time and 
they refused. I wrote a quick program that exactly filled the remaining space 
in the library and named it ALL. They ran the appropriate utility with the 
control statement DELETC ALL with the predictable results. They were as unhappy 
with me as I was with them.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Saturday, October 17, 2020 4:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

I would suggest shooting the creator.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, October 17, 2020 4:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

On Sat, 17 Oct 2020 17:48:57 -0500, Steve Horein wrote:

>Good ole IDCAMS anyone?
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/dgt3i231.htm
> 
How might one delete a PDS member named "*   "?

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Steve Horein]

On Sat, Oct 17, 2020 at 6:04 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 17 Oct 2020 17:48:57 -0500, Steve Horein wrote:
>
> >Good ole IDCAMS anyone?
> >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/dgt3i231.htm
> >
> How might one delete a PDS member named "*   "?
>
> -- gil
>
>
I guess if you get yourself into that mess, it's up to you to get yourself
out of it.

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Charles Mills]

I would suggest shooting the creator.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, October 17, 2020 4:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

On Sat, 17 Oct 2020 17:48:57 -0500, Steve Horein wrote:

>Good ole IDCAMS anyone?
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/dgt3i231.htm
> 
How might one delete a PDS member named "*   "?

-- gil

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

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Paul Gilmartin]

On Sat, 17 Oct 2020 17:48:57 -0500, Steve Horein wrote:

>Good ole IDCAMS anyone?
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/dgt3i231.htm
> 
How might one delete a PDS member named "*   "?

-- gil

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Paul Gilmartin]

On Sat, 17 Oct 2020 22:34:17 +, Chris Hoelscher wrote:

>I have employed this REXX script for years:
>
>/* REXX */  
>DSNAME = 'my PDS' 
>DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */  
>QUOTE = "'" 
>QDSN  = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */
>
>ADDRESS ISPEXEC 
>"LMINIT  DATAID( MYDATAID)  DATASET(" QDSN ") ENQ(SHRW)"
>"LMOPEN  DATAID("MYDATAID") OPTION(OUTPUT)" 
>"LMMDEL  DATAID("MYDATAID") MEMBER(*)"  
>"LMCLOSE DATAID("MYDATAID")"
>"LMFREE  DATAID("MYDATAID")"
>
> SAY DSN " IS NOW EMPTY"
> 
Does this employ STOW INITIALIZE?:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/stow.htm

Are there interfaces to INITIALIZE other than from assembler?

Does CBTTAPE PDSCLEAR now employ STOW INITIALIZE?

-- gil

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

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Steve Horein]

Good ole IDCAMS anyone?
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/dgt3i231.htm


On Sat, Oct 17, 2020 at 5:34 PM Chris Hoelscher 
wrote:

> I have employed this REXX script for years:
>
> /* REXX */
> DSNAME = 'my PDS'
> DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */
> QUOTE = "'"
> QDSN  = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */
>
> ADDRESS ISPEXEC
> "LMINIT  DATAID( MYDATAID)  DATASET(" QDSN ") ENQ(SHRW)"
> "LMOPEN  DATAID("MYDATAID") OPTION(OUTPUT)"
> "LMMDEL  DATAID("MYDATAID") MEMBER(*)"
> "LMCLOSE DATAID("MYDATAID")"
> "LMFREE  DATAID("MYDATAID")"
>
>  SAY DSN " IS NOW EMPTY"
>
> Chris Hoelscher
> Lead Sys DBA
> IBM Global Technical Services on assignmemt to Humana Inc.
> T 502.476.2538  or 502.407.7266
>
>
> The information transmitted is intended only for the person or entity to
> which it is addressed
> and may contain CONFIDENTIAL material.  If you receive this
> material/information in error,
> please contact the sender and delete or destroy the material/information.
>
> Humana Inc. and its subsidiaries comply with applicable Federal civil
> rights laws and
> do not discriminate on the basis of race, color, national origin,
> ancestry, age, disability, sex,
> marital status, gender, sexual orientation, gender identity, or religion.
> Humana Inc. and its subsidiaries do not
> exclude people or treat them differently because of race, color, national
> origin, ancestry, age,
> disability, sex, marital status, gender, sexual orientation, gender
> identity, or religion.
>
> English: ATTENTION: If you do not speak English, language assistance
> services, free
> of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).
>
> Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición
> servicios
> gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).
>
> 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
> 服務。請致電 1‐877‐320‐1235 (TTY: 711)。
>
> Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen
> sèvis èd
> pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).
>
> Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z
> bezpłatnej
> pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).
>
> 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
> 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.
>
>
> --
> 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

emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Chris Hoelscher]

I have employed this REXX script for years:

/* REXX */  
DSNAME = 'my PDS' 
DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */  
QUOTE = "'" 
QDSN  = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */

ADDRESS ISPEXEC 
"LMINIT  DATAID( MYDATAID)  DATASET(" QDSN ") ENQ(SHRW)"
"LMOPEN  DATAID("MYDATAID") OPTION(OUTPUT)" 
"LMMDEL  DATAID("MYDATAID") MEMBER(*)"  
"LMCLOSE DATAID("MYDATAID")"
"LMFREE  DATAID("MYDATAID")"

 SAY DSN " IS NOW EMPTY"

Chris Hoelscher
Lead Sys DBA 
IBM Global Technical Services on assignmemt to Humana Inc.
T 502.476.2538  or 502.407.7266


The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, ancestry, 
age, disability, sex,
marital status, gender, sexual orientation, gender identity, or religion. 
Humana Inc. and its subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, ancestry, age,
disability, sex, marital status, gender, sexual orientation, gender identity, 
or religion.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


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