Re: JCL error during TSO/E logon

[Seymour J Metz]

Why kill a tree?


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



From: IBM Mainframe Discussion List  on behalf of 
ITschak Mugzach 
Sent: Friday, March 6, 2020 1:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL error during TSO/E logon

Modify tso class in jess to keep the joblog. Your operators can print it
for you to review the error


ITschak

בתאריך יום ו׳, 6 במרץ 2020, 1:08, מאת Jesse 1 Robinson ‏<
jesse1.robin...@sce.com>:

> From the dawn of time, it was deucedly difficult to find the cause of a
> JCL error during TSO logon. Then several releases ago, we were treated to a
> 'fix'. The error would be displayed on the user's screen, allowing the
> problem to be corrected within seconds. Yesterday we had such a situation,
> but any helpful message flashed on the screen for milliseconds and then
> disappeared. In this case it turned out to be missing logon proc.
>
> I hunted in vain for doc on this problem, including maybe a need to set a
> parm somewhere. We run TPX, which it just now occurs to me might be the
> problem...
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.com
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: JCL error during TSO/E logon

[ITschak Mugzach]

You can used recycled paper as well... I thought no one can login, so you
must use the console to modify stcclass and print to viee.

ITschak

בתאריך יום ו׳, 6 במרץ 2020, 13:05, מאת Seymour J Metz ‏:

> Why kill a tree?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of ITschak Mugzach 
> Sent: Friday, March 6, 2020 1:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL error during TSO/E logon
>
> Modify tso class in jess to keep the joblog. Your operators can print it
> for you to review the error
>
>
> ITschak
>
> בתאריך יום ו׳, 6 במרץ 2020, 1:08, מאת Jesse 1 Robinson ‏<
> jesse1.robin...@sce.com>:
>
> > From the dawn of time, it was deucedly difficult to find the cause of a
> > JCL error during TSO logon. Then several releases ago, we were treated
> to a
> > 'fix'. The error would be displayed on the user's screen, allowing the
> > problem to be corrected within seconds. Yesterday we had such a
> situation,
> > but any helpful message flashed on the screen for milliseconds and then
> > disappeared. In this case it turned out to be missing logon proc.
> >
> > I hunted in vain for doc on this problem, including maybe a need to set a
> > parm somewhere. We run TPX, which it just now occurs to me might be the
> > problem...
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-543-6132 Office <= NEW
> > robin...@sce.com
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[Allan Staller]

Have you defined or supplied a JAVAHOME directory?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Conley
Sent: Thursday, March 5, 2020 8:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[CAUTION: This Email is from outside the Organization. Do not click links or 
open attachments unless you trust the sender.]

On 3/5/2020 5:10 PM, Baldeva Prasad wrote:
> Problems in APPLY-CHK of RSU2001 on z/OS2.3 on z14.
>
> While trying to Apply-Chk RSU2001 on z/OS2.3, I am getting the
> following error messages:--
>
> Has anyone seen a similar issue in their environment.
> Does anyone have an idea on what could be causing this or a Resolution for 
> the issue.
>
> Will appreciate any feedback.
> Thanks...
>
> --
> ---
>
>
>
> GIM24608E ** SHELLSCR ENTRY BBLU1702 IS NEEDED TO PROCESS HFS BBL17002 for 
> SYSMOD UI65815, BUT SHELLSCR BBLU1702 IS NOT IN THE MVST100 ZONE.
>
> GIM24608E ** SHELLSCR ENTRY BBLUNPAX IS NEEDED TO PROCESS HFS BBLWLPPX for 
> SYSMOD UI65815, BUT SHELLSCR BBLUNPAX IS NOT IN THE MVST100 ZONE.
>
> GIM22601IAPPLY PROCESSING FAILED FOR SYSMOD UI65815.
>
> The above meesages seem to imply that the SHELLSCR BBLU1702 and BBLUNPAX are 
> not in the z/OS2.3 Global CSI Target Zone MVST100.
>
> However these members are in the Target Zone MVST100 as verfied online
> and also as verfied by running SMPLIST job
>
>  CSI QUERY - SHELLSCR ENTRY Row 1 to 2 of 
> 2
> ===>  SCROLL ===> CSR
>
>   To return to previous panel, enter END .
>
>   Primary Command: FIND
>
>   Entry Type:  SHELLSCR Zone Name: MVST100
>   Entry Name:  BBLU1702 Zone Type: TARGET
>
>   FMID: HWLPEM0   DISTLIB : ABBLLIB  LASTUPD: UI48894  TYPE=ADD
>   RMID: UI48894   SYSLIB  : SBBLLIB  BINARY
>   SHSCRIPT:
>
>
> -
>
> LINK '../BBLU1702.sh'
> PARM PATHMODE(0,7,5,5)
> *** Bottom of data
> 
>
>
>   CSI QUERY - SHELLSCR ENTRY Row 1 to 2 
> of 2
>   ===>  SCROLL ===> 
> CSR
>
>To return to previous panel, enter END .
>
>Primary Command: FIND
>
>Entry Type:  SHELLSCR Zone Name: MVST100
>Entry Name:  BBLUNPAX Zone Type: TARGET
>
>FMID: HWLPEM0   DISTLIB : ABBLLIB  LASTUPD: HWLPEM0  TYPE=ADD
>RMID: UI48757   SYSLIB  : SBBLLIB  BINARY
>SHSCRIPT:
>
>
> -
>
>   LINK '../BBLUNPAX.sh'
>   PARM PATHMODE(0,7,5,5)
>   *** Bottom of data
> 
>

The links are junk.  Using .. at the beginning could mean anything.  I didn't 
find BBLUNPAX.sh on my system, but I found BBLU1702.sh in /usr/lpp/liberty_zos/.

Good Luck,
Tom Conley

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

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


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

Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[Carmen Vitullo]

I've responded to the poster personally due to my ISP's bad reputation my email 
gets blocked :(

I had the same issue, I had the correct levels required for the shellscr and 
BBLU1702 was in my zone, I got by this by appling all the pre-reqs that were 
not applied one at a time, I found an apar that talks about deleting the 
entries but I didn't want to go that way.

apparently SMP/E may be having an issue with the SHELLSCR elements when there's 
a delete element involved, but 2 other PTF's before the latest RSU2001 PTF when 
on without a hitch. 

sorry to respond personally, my email provider was blacklisted :(

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

Re: JCL error during TSO/E logon

[Steve Beaver]

Actually just submit a JOB naming the logon PROC and see what happens.  Just
be sure you have a message class that is saved to sysout

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jesse 1 Robinson
Sent: Thursday, March 5, 2020 5:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL error during TSO/E logon

>From the dawn of time, it was deucedly difficult to find the cause of a JCL
error during TSO logon. Then several releases ago, we were treated to a
'fix'. The error would be displayed on the user's screen, allowing the
problem to be corrected within seconds. Yesterday we had such a situation,
but any helpful message flashed on the screen for milliseconds and then
disappeared. In this case it turned out to be missing logon proc.

I hunted in vain for doc on this problem, including maybe a need to set a
parm somewhere. We run TPX, which it just now occurs to me might be the
problem...

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


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

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

Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[Allan Staller]

Just ran into similar problem with an SDSF PTF with a missing pre-req (z/OS 
2.4).
IBM agreed that the PTF was omitted from the pre-req chain.

If anyone really wants the info, I will dig it up and post.

Cheers,


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Friday, March 6, 2020 7:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[CAUTION: This Email is from outside the Organization. Do not click links or 
open attachments unless you trust the sender.]

I've responded to the poster personally due to my ISP's bad reputation my email 
gets blocked :(

I had the same issue, I had the correct levels required for the shellscr and 
BBLU1702 was in my zone, I got by this by appling all the pre-reqs that were 
not applied one at a time, I found an apar that talks about deleting the 
entries but I didn't want to go that way.

apparently SMP/E may be having an issue with the SHELLSCR elements when there's 
a delete element involved, but 2 other PTF's before the latest RSU2001 PTF when 
on without a hitch.

sorry to respond personally, my email provider was blacklisted :(

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

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


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

Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[Mark Jacobs]

Hopefully the PTF is marked as PE now.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐
On Friday, March 6, 2020 8:55 AM, Allan Staller  wrote:

> Just ran into similar problem with an SDSF PTF with a missing pre-req (z/OS 
> 2.4).
> IBM agreed that the PTF was omitted from the pre-req chain.
>
> If anyone really wants the info, I will dig it up and post.
>
> Cheers,
>
> -Original Message-
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of 
> Carmen Vitullo
>
> Sent: Friday, March 6, 2020 7:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14
>
> [CAUTION: This Email is from outside the Organization. Do not click links or 
> open attachments unless you trust the sender.]
>
> I've responded to the poster personally due to my ISP's bad reputation my 
> email gets blocked :(
>
> I had the same issue, I had the correct levels required for the shellscr and 
> BBLU1702 was in my zone, I got by this by appling all the pre-reqs that were 
> not applied one at a time, I found an apar that talks about deleting the 
> entries but I didn't want to go that way.
>
> apparently SMP/E may be having an issue with the SHELLSCR elements when 
> there's a delete element involved, but 2 other PTF's before the latest 
> RSU2001 PTF when on without a hitch.
>
> sorry to respond personally, my email provider was blacklisted :(
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
>
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: JCL error during TSO/E logon

[Seymour J Metz]

You don't have an alternate proc? You can't telnet to a Unix shell?


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



From: IBM Mainframe Discussion List  on behalf of 
ITschak Mugzach 
Sent: Friday, March 6, 2020 6:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL error during TSO/E logon

You can used recycled paper as well... I thought no one can login, so you
must use the console to modify stcclass and print to viee.

ITschak

בתאריך יום ו׳, 6 במרץ 2020, 13:05, מאת Seymour J Metz ‏:

> Why kill a tree?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of ITschak Mugzach 
> Sent: Friday, March 6, 2020 1:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL error during TSO/E logon
>
> Modify tso class in jess to keep the joblog. Your operators can print it
> for you to review the error
>
>
> ITschak
>
> בתאריך יום ו׳, 6 במרץ 2020, 1:08, מאת Jesse 1 Robinson ‏<
> jesse1.robin...@sce.com>:
>
> > From the dawn of time, it was deucedly difficult to find the cause of a
> > JCL error during TSO logon. Then several releases ago, we were treated
> to a
> > 'fix'. The error would be displayed on the user's screen, allowing the
> > problem to be corrected within seconds. Yesterday we had such a
> situation,
> > but any helpful message flashed on the screen for milliseconds and then
> > disappeared. In this case it turned out to be missing logon proc.
> >
> > I hunted in vain for doc on this problem, including maybe a need to set a
> > parm somewhere. We run TPX, which it just now occurs to me might be the
> > problem...
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-543-6132 Office <= NEW
> > robin...@sce.com
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
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: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[Allan Staller]

I expect IBM is performing that action. I have not followed up.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Friday, March 6, 2020 7:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[CAUTION: This Email is from outside the Organization. Do not click links or 
open attachments unless you trust the sender.]

Hopefully the PTF is marked as PE now.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com&data=02%7C01%7Callan.staller%40HCL.COM%7Ca5479b1be4fb447f655108d7c1d67cef%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637190999313965205&sdata=2kbYHjC0eJsnPfCrOqUBIIjjdzRk0i1I5q5ObxkTkaI%3D&reserved=0

‐‐‐ Original Message ‐‐‐
On Friday, March 6, 2020 8:55 AM, Allan Staller  wrote:

> Just ran into similar problem with an SDSF PTF with a missing pre-req (z/OS 
> 2.4).
> IBM agreed that the PTF was omitted from the pre-req chain.
>
> If anyone really wants the info, I will dig it up and post.
>
> Cheers,
>
> -Original Message-
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf 
> Of Carmen Vitullo
>
> Sent: Friday, March 6, 2020 7:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14
>
> [CAUTION: This Email is from outside the Organization. Do not click 
> links or open attachments unless you trust the sender.]
>
> I've responded to the poster personally due to my ISP's bad reputation 
> my email gets blocked :(
>
> I had the same issue, I had the correct levels required for the shellscr and 
> BBLU1702 was in my zone, I got by this by appling all the pre-reqs that were 
> not applied one at a time, I found an apar that talks about deleting the 
> entries but I didn't want to go that way.
>
> apparently SMP/E may be having an issue with the SHELLSCR elements when 
> there's a delete element involved, but 2 other PTF's before the latest 
> RSU2001 PTF when on without a hitch.
>
> sorry to respond personally, my email provider was blacklisted :(
>
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
>
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Two related alias entry address questions

[Charles Mills]

First, my apologies for the garbled reply. I was in an airport and (a.) 
misconstrued Peter's note as a private reply; and (b.) my Samsung Android 
e-mail client total garbles LISTSERV replies.

Second, there can be little disagreement about the awfulness of two almost 
indistinguishable commands with almost the same name. I don't see how anyone 
can disagree with the assertion that the first two sentences contradict each 
other. I am going to separate them out here to make it more obvious:

The COPYGROUP statement has the same effect as the COPYGRP statement when 
either the input or the output data set or both are partitioned format, that is 
either PDS or PDSEs. 

The function of a COPYGROUP statement differs from COPYGRP only if both of the 
data sets are PDSs.

Third, with regard to IEBCOPY's failing and then exiting with return code zero, 
I can't find any documentation that specifies the meaning of a zero return 
code, but issuing IGW01557W MEMBER NOT COPIED and then exiting with return code 
zero certainly violates the principle of least astonishment.

Fourth, I will reply to the entry point issue separately.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, March 4, 2020 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions

Peter, thanks for the note. I'm on a small screen with fat fingers. I will 
reply fully, tonight or tomorrow. I know the paragraph makes my head spin. 
CharlesSent from a mobile; please excuse the brevity.
 Original message From: Peter Relson  Date: 
3/4/20  6:33 AM  (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Two 
related alias entry address questions The COPYGROUP statement has the 
same effect as the COPYGRP statement wheneither the input or the output data 
set or both are partitioned format, that is eitherPDS or PDSEs. The function of 
a COPYGROUP statement differs from COPYGRPonly if both of the data sets are 
PDSs. COPYGROUP performs a full group copyoperation when both data sets 

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

Re: Two related alias entry address questions

[Charles Mills]

@Peter, did you have an ENTRY BAR statement in the assembly? I think that
statement was the key ingredient that made IEBCOPY consistently preserve the
alias entry point address. I am not certain of what was the key ingredient
because I kept running experiments, getting IEBCOPY RC=0, and finding no
improvement in the target PDS. It turned out that IEBCOPY was failing to do
any copy at all, so I have no idea what would have happened to the alias
offset had IEBCOPY actually done the copy. But I think the key change in
there was the addition of ENTRY BAR.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, March 5, 2020 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions

I was wrong about the 

BAR DS 0D
...
END BAR

case.   I had glossed over what "END BAR" meant.

I do agree with Charles and Gil from earlier:

If you have "END BAR" then the normal entry point for the module will 
locate BAR, not offset 0
If you have "ALIAS BAR" then the alias will locate BAR, not offset 0.

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

Re: JCL error during TSO/E logon

[ITschak Mugzach]

Shmuel,
I did mentioned the need to have an allocation free TMP procedure. However,
if the OP can't login, and do not have sich proc, he can see what is wrong
using console (JES) commands. Fixing the issue is possible using native
edit commands.

Best
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM comming son  *




On Fri, Mar 6, 2020 at 4:00 PM Seymour J Metz  wrote:

> You don't have an alternate proc? You can't telnet to a Unix shell?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of ITschak Mugzach 
> Sent: Friday, March 6, 2020 6:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL error during TSO/E logon
>
> You can used recycled paper as well... I thought no one can login, so you
> must use the console to modify stcclass and print to viee.
>
> ITschak
>
> בתאריך יום ו׳, 6 במרץ 2020, 13:05, מאת Seymour J Metz ‏:
>
> > Why kill a tree?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of ITschak Mugzach 
> > Sent: Friday, March 6, 2020 1:21 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: JCL error during TSO/E logon
> >
> > Modify tso class in jess to keep the joblog. Your operators can print it
> > for you to review the error
> >
> >
> > ITschak
> >
> > בתאריך יום ו׳, 6 במרץ 2020, 1:08, מאת Jesse 1 Robinson ‏<
> > jesse1.robin...@sce.com>:
> >
> > > From the dawn of time, it was deucedly difficult to find the cause of a
> > > JCL error during TSO logon. Then several releases ago, we were treated
> > to a
> > > 'fix'. The error would be displayed on the user's screen, allowing the
> > > problem to be corrected within seconds. Yesterday we had such a
> > situation,
> > > but any helpful message flashed on the screen for milliseconds and then
> > > disappeared. In this case it turned out to be missing logon proc.
> > >
> > > I hunted in vain for doc on this problem, including maybe a need to
> set a
> > > parm somewhere. We run TPX, which it just now occurs to me might be the
> > > problem...
> > >
> > > .
> > > .
> > > J.O.Skip Robinson
> > > Southern California Edison Company
> > > Electric Dragon Team Paddler
> > > SHARE MVS Program Co-Manager
> > > 323-715-0595 Mobile
> > > 626-543-6132 Office <= NEW
> > > robin...@sce.com
> > >
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> 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: JCL error during TSO/E logon

[Jesse 1 Robinson]

Thanks to all who replied via List or offline. I was not asking how to fix the 
JCL errors. We've had to do that (unassisted) for decades. I was asking about a 
x/OS change that occurred some time ago whereby the actual error is displayed 
on the user's screen instead of forcing one to guess by trial and error. Did 
that change actually occur, or am I dreaming? 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
ITschak Mugzach
Sent: Friday, March 6, 2020 6:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: JCL error during TSO/E logon

CAUTION EXTERNAL EMAIL

Shmuel,
I did mentioned the need to have an allocation free TMP procedure. However, if 
the OP can't login, and do not have sich proc, he can see what is wrong using 
console (JES) commands. Fixing the issue is possible using native edit commands.

Best
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring for 
z/OS, x/Linux & IBM I **| z/VM comming son  *




On Fri, Mar 6, 2020 at 4:00 PM Seymour J Metz  wrote:

> You don't have an alternate proc? You can't telnet to a Unix shell?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of ITschak Mugzach 
> Sent: Friday, March 6, 2020 6:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL error during TSO/E logon
>
> You can used recycled paper as well... I thought no one can login, so 
> you must use the console to modify stcclass and print to viee.
>
> ITschak
>
> בתאריך יום ו׳, 6 במרץ 2020, 13:05, מאת Seymour J Metz ‏:
>
> > Why kill a tree?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on 
> > behalf of ITschak Mugzach 
> > Sent: Friday, March 6, 2020 1:21 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: JCL error during TSO/E logon
> >
> > Modify tso class in jess to keep the joblog. Your operators can 
> > print it for you to review the error
> >
> >
> > ITschak
> >
> > בתאריך יום ו׳, 6 במרץ 2020, 1:08, מאת Jesse 1 Robinson ‏<
> > jesse1.robin...@sce.com>:
> >
> > > From the dawn of time, it was deucedly difficult to find the cause 
> > > of a JCL error during TSO logon. Then several releases ago, we 
> > > were treated
> > to a
> > > 'fix'. The error would be displayed on the user's screen, allowing 
> > > the problem to be corrected within seconds. Yesterday we had such 
> > > a
> > situation,
> > > but any helpful message flashed on the screen for milliseconds and 
> > > then disappeared. In this case it turned out to be missing logon proc.
> > >
> > > I hunted in vain for doc on this problem, including maybe a need 
> > > to
> set a
> > > parm somewhere. We run TPX, which it just now occurs to me might 
> > > be the problem...
> > >
> > > .
> > > .
> > > J.O.Skip Robinson
> > > Southern California Edison Company Electric Dragon Team Paddler 
> > > SHARE MVS Program Co-Manager
> > > 323-715-0595 Mobile
> > > 626-543-6132 Office <= NEW
> > > robin...@sce.com


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

Re: JCL error during TSO/E logon

[Wayne Bickerdike]

My presentation at Share last year hinted at a Swiss Army knife approach.
If you are a CICS shop, use REXX/CICS, a quick READ SPOOL and you have your
diagnostic info. Import the JCL and modify the offending PROC, Export back
to the proclib and log on. The REXX file system is a handy place to keep
backups of various PDS members, should a problem like this occur.

On Sat, Mar 7, 2020, 01:32 ITschak Mugzach  wrote:

> Shmuel,
> I did mentioned the need to have an allocation free TMP procedure. However,
> if the OP can't login, and do not have sich proc, he can see what is wrong
> using console (JES) commands. Fixing the issue is possible using native
> edit commands.
>
> Best
> ITschak Mugzach
> *|** IronSphere Platform* *|* *Information Security Continuous Monitoring
> for z/OS, x/Linux & IBM I **| z/VM comming son  *
>
>
>
>
> On Fri, Mar 6, 2020 at 4:00 PM Seymour J Metz  wrote:
>
> > You don't have an alternate proc? You can't telnet to a Unix shell?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of ITschak Mugzach 
> > Sent: Friday, March 6, 2020 6:07 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: JCL error during TSO/E logon
> >
> > You can used recycled paper as well... I thought no one can login, so you
> > must use the console to modify stcclass and print to viee.
> >
> > ITschak
> >
> > בתאריך יום ו׳, 6 במרץ 2020, 13:05, מאת Seymour J Metz ‏:
> >
> > > Why kill a tree?
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf
> > > of ITschak Mugzach 
> > > Sent: Friday, March 6, 2020 1:21 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: JCL error during TSO/E logon
> > >
> > > Modify tso class in jess to keep the joblog. Your operators can print
> it
> > > for you to review the error
> > >
> > >
> > > ITschak
> > >
> > > בתאריך יום ו׳, 6 במרץ 2020, 1:08, מאת Jesse 1 Robinson ‏<
> > > jesse1.robin...@sce.com>:
> > >
> > > > From the dawn of time, it was deucedly difficult to find the cause
> of a
> > > > JCL error during TSO logon. Then several releases ago, we were
> treated
> > > to a
> > > > 'fix'. The error would be displayed on the user's screen, allowing
> the
> > > > problem to be corrected within seconds. Yesterday we had such a
> > > situation,
> > > > but any helpful message flashed on the screen for milliseconds and
> then
> > > > disappeared. In this case it turned out to be missing logon proc.
> > > >
> > > > I hunted in vain for doc on this problem, including maybe a need to
> > set a
> > > > parm somewhere. We run TPX, which it just now occurs to me might be
> the
> > > > problem...
> > > >
> > > > .
> > > > .
> > > > J.O.Skip Robinson
> > > > Southern California Edison Company
> > > > Electric Dragon Team Paddler
> > > > SHARE MVS Program Co-Manager
> > > > 323-715-0595 Mobile
> > > > 626-543-6132 Office <= NEW
> > > > robin...@sce.com
> > > >
> > > >
> > > >
> --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > > >
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> > --
> > 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: JCL error during TSO/E logon

[Steve Smith]

IMHO, a TSO logon proc should have no (0, zero, none, nada, zip) DD
statements.  It doesn't solve every possible problem, but it prevents this
one.

sas

On Fri, Mar 6, 2020 at 11:15 AM Wayne Bickerdike  wrote:

> My presentation at Share last year hinted at a Swiss Army knife approach.
> If you are a CICS shop, use REXX/CICS, a quick READ SPOOL and you have your
> diagnostic info. Import the JCL and modify the offending PROC, Export back
> to the proclib and log on. The REXX file system is a handy place to keep
> backups of various PDS members, should a problem like this occur.
>
> On Sat, Mar 7, 2020, 01:32 ITschak Mugzach  wrote:
>
> > Shmuel,
> > I did mentioned the need to have an allocation free TMP procedure.
> However,
> > if the OP can't login, and do not have sich proc, he can see what is
> wrong
> > using console (JES) commands. Fixing the issue is possible using native
> > edit commands.
> >
> > Best
> > ITschak Mugzach
> > *|** IronSphere Platform* *|* *Information Security Continuous Monitoring
> > for z/OS, x/Linux & IBM I **| z/VM comming son  *
> >
> >
> >
> >
> > On Fri, Mar 6, 2020 at 4:00 PM Seymour J Metz  wrote:
> >
> > > You don't have an alternate proc? You can't telnet to a Unix shell?
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf
> > > of ITschak Mugzach 
> > > Sent: Friday, March 6, 2020 6:07 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: JCL error during TSO/E logon
> > >
> > > You can used recycled paper as well... I thought no one can login, so
> you
> > > must use the console to modify stcclass and print to viee.
> > >
> > > ITschak
> > >
> > > בתאריך יום ו׳, 6 במרץ 2020, 13:05, מאת Seymour J Metz ‏ >:
> > >
> > > > Why kill a tree?
> > > >
> > > >
> > > > --
> > > > Shmuel (Seymour J.) Metz
> > > > http://mason.gmu.edu/~smetz3
> > > >
> > > >
> > > > 
> > > > From: IBM Mainframe Discussion List  on
> > behalf
> > > > of ITschak Mugzach 
> > > > Sent: Friday, March 6, 2020 1:21 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: JCL error during TSO/E logon
> > > >
> > > > Modify tso class in jess to keep the joblog. Your operators can print
> > it
> > > > for you to review the error
> > > >
> > > >
> > > > ITschak
> > > >
> > > > בתאריך יום ו׳, 6 במרץ 2020, 1:08, מאת Jesse 1 Robinson ‏<
> > > > jesse1.robin...@sce.com>:
> > > >
> > > > > From the dawn of time, it was deucedly difficult to find the cause
> > of a
> > > > > JCL error during TSO logon. Then several releases ago, we were
> > treated
> > > > to a
> > > > > 'fix'. The error would be displayed on the user's screen, allowing
> > the
> > > > > problem to be corrected within seconds. Yesterday we had such a
> > > > situation,
> > > > > but any helpful message flashed on the screen for milliseconds and
> > then
> > > > > disappeared. In this case it turned out to be missing logon proc.
> > > > >
> > > > > I hunted in vain for doc on this problem, including maybe a need to
> > > set a
> > > > > parm somewhere. We run TPX, which it just now occurs to me might be
> > the
> > > > > problem...
> > > > >
> > > > > .
> > > > > .
> > > > > J.O.Skip Robinson
> > > > > Southern California Edison Company
> > > > > Electric Dragon Team Paddler
> > > > > SHARE MVS Program Co-Manager
> > > > > 323-715-0595 Mobile
> > > > > 626-543-6132 Office <= NEW
> > > > > robin...@sce.com
> > > > >
> > > > >
> > > > >
> > --
> > > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN
> > > > >
> > > >
> > > >
> --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > > >
> > > >
> --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > > >
> > >
> > > --
> > > 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 I

Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[Allan Staller]

For the record:

MSGIEW2470E 9511 ORDERED SECTION HSFENF41 NOT FOUND IN MODULE during apply of 
UI66155 UI66196 UI66383 

Resolution was to apply (UI65564 and its associated pre-reqs) concurrently with 
apply of (UI66155 UI66196 UI66383)

SMP/E was attempting to link LMOD HSFINLPA as part of (UI66155 UI66196 UI66383)

Resolution was to apply (UI65564 and its associated pre-reqs) concurrently with 
apply of (UI66155 UI66196 UI66383)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Friday, March 6, 2020 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[CAUTION: This Email is from outside the Organization. Do not click links or 
open attachments unless you trust the sender.]

I expect IBM is performing that action. I have not followed up.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Friday, March 6, 2020 7:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14

[CAUTION: This Email is from outside the Organization. Do not click links or 
open attachments unless you trust the sender.]

Hopefully the PTF is marked as PE now.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com&data=02%7C01%7Callan.staller%40HCL.COM%7C387b28509cc54627c74108d7c1d6e9cc%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637191001122270690&sdata=%2BFGWpurhN5sxXhf0%2FlXJr%2F1lVuIroL2Z5zhsh5%2FMwdE%3D&reserved=0

‐‐‐ Original Message ‐‐‐
On Friday, March 6, 2020 8:55 AM, Allan Staller  wrote:

> Just ran into similar problem with an SDSF PTF with a missing pre-req (z/OS 
> 2.4).
> IBM agreed that the PTF was omitted from the pre-req chain.
>
> If anyone really wants the info, I will dig it up and post.
>
> Cheers,
>
> -Original Message-
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf 
> Of Carmen Vitullo
>
> Sent: Friday, March 6, 2020 7:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APPLY-CHECK problems with RSU2001 on z/OS2.3 on z14
>
> [CAUTION: This Email is from outside the Organization. Do not click 
> links or open attachments unless you trust the sender.]
>
> I've responded to the poster personally due to my ISP's bad reputation 
> my email gets blocked :(
>
> I had the same issue, I had the correct levels required for the shellscr and 
> BBLU1702 was in my zone, I got by this by appling all the pre-reqs that were 
> not applied one at a time, I found an apar that talks about deleting the 
> entries but I didn't want to go that way.
>
> apparently SMP/E may be having an issue with the SHELLSCR elements when 
> there's a delete element involved, but 2 other PTF's before the latest 
> RSU2001 PTF when on without a hitch.
>
> sorry to respond personally, my email provider was blacklisted :(
>
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
>
> 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 receiv

Re: JCL error during TSO/E logon

[Seymour J Metz]

It' s not my dog.


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



From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Friday, March 6, 2020 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL error during TSO/E logon

IMHO, a TSO logon proc should have no (0, zero, none, nada, zip) DD
statements.  It doesn't solve every possible problem, but it prevents this
one.

sas

On Fri, Mar 6, 2020 at 11:15 AM Wayne Bickerdike  wrote:

> My presentation at Share last year hinted at a Swiss Army knife approach.
> If you are a CICS shop, use REXX/CICS, a quick READ SPOOL and you have your
> diagnostic info. Import the JCL and modify the offending PROC, Export back
> to the proclib and log on. The REXX file system is a handy place to keep
> backups of various PDS members, should a problem like this occur.
>
> On Sat, Mar 7, 2020, 01:32 ITschak Mugzach  wrote:
>
> > Shmuel,
> > I did mentioned the need to have an allocation free TMP procedure.
> However,
> > if the OP can't login, and do not have sich proc, he can see what is
> wrong
> > using console (JES) commands. Fixing the issue is possible using native
> > edit commands.
> >
> > Best
> > ITschak Mugzach
> > *|** IronSphere Platform* *|* *Information Security Continuous Monitoring
> > for z/OS, x/Linux & IBM I **| z/VM comming son  *
> >
> >
> >
> >
> > On Fri, Mar 6, 2020 at 4:00 PM Seymour J Metz  wrote:
> >
> > > You don't have an alternate proc? You can't telnet to a Unix shell?
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf
> > > of ITschak Mugzach 
> > > Sent: Friday, March 6, 2020 6:07 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: JCL error during TSO/E logon
> > >
> > > You can used recycled paper as well... I thought no one can login, so
> you
> > > must use the console to modify stcclass and print to viee.
> > >
> > > ITschak
> > >
> > > בתאריך יום ו׳, 6 במרץ 2020, 13:05, מאת Seymour J Metz ‏ >:
> > >
> > > > Why kill a tree?
> > > >
> > > >
> > > > --
> > > > Shmuel (Seymour J.) Metz
> > > > http://mason.gmu.edu/~smetz3
> > > >
> > > >
> > > > 
> > > > From: IBM Mainframe Discussion List  on
> > behalf
> > > > of ITschak Mugzach 
> > > > Sent: Friday, March 6, 2020 1:21 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: JCL error during TSO/E logon
> > > >
> > > > Modify tso class in jess to keep the joblog. Your operators can print
> > it
> > > > for you to review the error
> > > >
> > > >
> > > > ITschak
> > > >
> > > > בתאריך יום ו׳, 6 במרץ 2020, 1:08, מאת Jesse 1 Robinson ‏<
> > > > jesse1.robin...@sce.com>:
> > > >
> > > > > From the dawn of time, it was deucedly difficult to find the cause
> > of a
> > > > > JCL error during TSO logon. Then several releases ago, we were
> > treated
> > > > to a
> > > > > 'fix'. The error would be displayed on the user's screen, allowing
> > the
> > > > > problem to be corrected within seconds. Yesterday we had such a
> > > > situation,
> > > > > but any helpful message flashed on the screen for milliseconds and
> > then
> > > > > disappeared. In this case it turned out to be missing logon proc.
> > > > >
> > > > > I hunted in vain for doc on this problem, including maybe a need to
> > > set a
> > > > > parm somewhere. We run TPX, which it just now occurs to me might be
> > the
> > > > > problem...
> > > > >
> > > > > .
> > > > > .
> > > > > J.O.Skip Robinson
> > > > > Southern California Edison Company
> > > > > Electric Dragon Team Paddler
> > > > > SHARE MVS Program Co-Manager
> > > > > 323-715-0595 Mobile
> > > > > 626-543-6132 Office <= NEW
> > > > > robin...@sce.com
> > > > >
> > > > >
> > > > >
> > --
> > > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN
> > > > >
> > > >
> > > >
> --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > > >
> > > >
> --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > > >
> > >
> > > --
> > > 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,
> > >

Re: SMPE BYPASS(HOLDSYS,HOLDERR)

[Jesse 1 Robinson]

I once had to BYPASS HOLDERR(). It was a new product. There was a hold against 
the FMID itself. Until the FMID was APPLIed, no further action was possible. So 
I bypassed that particular HOLDERR, which allowed the FMID itself to APPLY. 
That in turn allowed me to RECEIVE more PTFs, including one that SUP'ed the 
problem PTF. I always felt that this was a packaging error, but the result was 
fine.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Tuesday, February 18, 2020 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SMPE BYPASS(HOLDSYS,HOLDERR)

CAUTION EXTERNAL EMAIL

On Fri, 14 Feb 2020 14:22:27 -0600, Paul Jodlowski wrote:

>Has anybody ever ran SMPE apply with bypass(holderr)?

As others have said, you have not shown a reason that you would need to 
BYPASS(HOLDERR). If there is a need to BYPASS(HOLDERR), it should be specific, 
as in BYPASS(HOLDERR(aparnum)). And first run APPLY CHECK and examine the 
output very carefully to ensure that you are not installing any error PTFs 
beyond the one that you need.

--
Tom Marchant

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

Re: Two related alias entry address questions

[Dale R. Smith]

On Fri, 6 Mar 2020 09:13:39 -0500, Charles Mills  wrote:

>Third, with regard to IEBCOPY's failing and then exiting with return code 
>zero, I can't find any documentation that specifies the >meaning of a zero 
>return code, but issuing IGW01557W MEMBER NOT COPIED and then exiting with 
>return code zero certainly >violates the principle of least astonishment.

IIRC, you stated earlier that you received messages similar to this one:
IGW01557W MEMBER FOO NOT COPIED BECAUSE THE NAME ALREADY EXISTS IN   
THE OUTPUT DATASET CAUSING A COPY GROUP NO-REPLACE CONFLICT

That would indicate to me that you did not specify Replace (R) on either the 
INDD parm of COPYGROUP/COPYGRP or on the SELECT statement for the members.  
Since the specified members already existed in the output file and you did not 
specify Replace, then you told IEBCOPY to only Copy the members if they did not 
exist in the output file.  IEBCOPY did exactly what you told it to do, so the 
Return Code should be zero!  Oddly enough, if you specify Replace and you Copy 
a member that does not exist in the output file, IEBCOPY will give you a Return 
Code of 4!  :-)>

IEBCOPY and other utilities Return Codes are documented, (somewhat!), in 
"Appendix A. Invoking Utility Programs from an Application Program" in the 
"DFSMSdfp Utilities" manual, (at least in z/OS V2.2).

-- 
Dale R. Smith 

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

Re: Two related alias entry address questions

[Charles Mills]

> IEBCOPY did exactly what you told it to do, so the Return Code should be zero!

By that logic, every program should always return a zero. If I code

  LR 16,1

then the assembler will generate a halfword of zeros, because there is no 
register 16. The assembler always generates zeros for invalid instructions. 
Thus the assembler has done exactly what I told it to do. Nonetheless, it will 
give me an RC 8 or 12.

Yes, I read that section of the manual. IBM clearly does not promise anything 
in particular in the way of return codes, so it is certainly possible to argue 
that the 0 is correct.

Nonetheless it utterly violates the principle of least astonishment.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dale R. Smith
Sent: Friday, March 6, 2020 4:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions

On Fri, 6 Mar 2020 09:13:39 -0500, Charles Mills  wrote:

>Third, with regard to IEBCOPY's failing and then exiting with return code 
>zero, I can't find any documentation that specifies the >meaning of a zero 
>return code, but issuing IGW01557W MEMBER NOT COPIED and then exiting with 
>return code zero certainly >violates the principle of least astonishment.

IIRC, you stated earlier that you received messages similar to this one:
IGW01557W MEMBER FOO NOT COPIED BECAUSE THE NAME ALREADY EXISTS IN   
THE OUTPUT DATASET CAUSING A COPY GROUP NO-REPLACE CONFLICT

That would indicate to me that you did not specify Replace (R) on either the 
INDD parm of COPYGROUP/COPYGRP or on the SELECT statement for the members.  
Since the specified members already existed in the output file and you did not 
specify Replace, then you told IEBCOPY to only Copy the members if they did not 
exist in the output file.  IEBCOPY did exactly what you told it to do, so the 
Return Code should be zero!  Oddly enough, if you specify Replace and you Copy 
a member that does not exist in the output file, IEBCOPY will give you a Return 
Code of 4!  :-)>

IEBCOPY and other utilities Return Codes are documented, (somewhat!), in 
"Appendix A. Invoking Utility Programs from an Application Program" in the 
"DFSMSdfp Utilities" manual, (at least in z/OS V2.2).

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

DSPSERV CREATE, is ORIGIN parm a relic?

[Michael Hochee]

Ideally, I would like to create all future data spaces with a size of 2GB, 
rather than 2GB OR 2GB-4K (when the returned ORIGIN value is NZ).  I looked at 
assembler service reference manuals as far back as 1999, and they all state 
that a non-zero origin value (4K) is based on a processor dependency. I 
eventually found a vintage IBM-Amdahl presentation (1989) indicating the 
dependency is due to low-address protection being in effect when the PSF 
(Private-Space Facility) is not active. 

My question is... Is this still relevant 30 years later? Do any G10 or above 
customers run configurations where PSF is inactive? 

Thanks, 
Mike

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

Re: Two related alias entry address questions

[Paul Gilmartin]

On Fri, 6 Mar 2020 16:44:09 -0500, Charles Mills wrote:

>> IEBCOPY did exactly what you told it to do, so the Return Code should be 
>> zero!
>
>By that logic, every program should always return a zero. If I code
>
>  LR 16,1
>
>then the assembler will generate a halfword of zeros, because there is no 
>register 16. The assembler always generates zeros for invalid instructions. 
>Thus the assembler has done exactly what I told it to do. Nonetheless, it will 
>give me an RC 8 or 12.
>
>Yes, I read that section of the manual. IBM clearly does not promise anything 
>in particular in the way of return codes, so it is certainly possible to argue 
>that the 0 is correct.
>
>Nonetheless it utterly violates the principle of least astonishment.
> 
+1

Grrr...  But I've even complained of seeing a "I" suffix on messages
reporting JCL errors fatal from the programmer's point of view.  The
rationale is that it's "Informative" from the operator's point of view.

How many operators peruse JCL messages nowadays?

I have mixed feelings about:

o REPLACE gives RC=4 if the object didn't previously exist.

o "rm -f" gives status 0 if the file never existed.

-- gil

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

Re: JCL error during TSO/E logon

[Tom Brennan]

I liked having DD's in my proc, but I had a second one with no DD's like 
you recommend.  That saved the embarrassment of having to wander over to 
another sysprog's desk with my head held low.


On 3/6/2020 10:20 AM, Steve Smith wrote:

IMHO, a TSO logon proc should have no (0, zero, none, nada, zip) DD
statements.  It doesn't solve every possible problem, but it prevents this
one.

sas



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

Re: Two related alias entry address questions

[Charles Mills]

Yeah, as a software designer I have debated the return code or the like for the 
deletion of a nonexistent item. You can argue either way: in one sense what the 
user requested failed to happen, but on the other hand s/he wanted it not to 
exist and now it does not exist. QED.

While complaining about IEBCOPY I thought about the JCL error issue. I did not 
mention it because bitching about JCL is like bitching about the weather. There 
are many things that might have been done differently that would have made JCL 
errors much easier to spot in the listing.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, March 6, 2020 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions

On Fri, 6 Mar 2020 16:44:09 -0500, Charles Mills wrote:

>> IEBCOPY did exactly what you told it to do, so the Return Code should be 
>> zero!
>
>By that logic, every program should always return a zero. If I code
>
>  LR 16,1
>
>then the assembler will generate a halfword of zeros, because there is no 
>register 16. The assembler always generates zeros for invalid instructions. 
>Thus the assembler has done exactly what I told it to do. Nonetheless, it will 
>give me an RC 8 or 12.
>
>Yes, I read that section of the manual. IBM clearly does not promise anything 
>in particular in the way of return codes, so it is certainly possible to argue 
>that the 0 is correct.
>
>Nonetheless it utterly violates the principle of least astonishment.
> 
+1

Grrr...  But I've even complained of seeing a "I" suffix on messages
reporting JCL errors fatal from the programmer's point of view.  The
rationale is that it's "Informative" from the operator's point of view.

How many operators peruse JCL messages nowadays?

I have mixed feelings about:

o REPLACE gives RC=4 if the object didn't previously exist.

o "rm -f" gives status 0 if the file never existed.

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

Re: Attitude of companies toward mainframers working from home?

[Jesse 1 Robinson]

Came across this lengthy thread from last year. No one seemed to mention the 
effects of a world-wide pandemic. You just can't think of everything...

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: Thursday, August 22, 2019 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Attitude of companies toward mainframers working from 
home?

I'm allowed a combination of home (mostly mornings) and office (I like the 
company food service). I've heard worker bees complain that laboring at home is 
too intense. No socially blessed conversations around the water cooler. No 
visiting with colleagues on topics that may or not be strictly job related. You 
have to work at giving yourself permission to chill. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Thursday, August 22, 2019 10:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Attitude of companies toward mainframers working from 
home?

I have worked REMOTE for years.

I have no drive time, I can go down stairs and get a sandwich and a drink and 
be backup stairs in 5 min if I'm being slow about it.  I live in WebEx all day, 
it you really, really need me they can call me cell.

The down side is you have to have the mindset that you are a work and ignore 
all intrusions into your workspace unless it’s a true emergency.

Steve

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Thursday, August 22, 2019 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Attitude of companies toward mainframers working from home?

I do agree that there is a higher level of responsibility required on the part 
of the remote worker to be "available" during the normal working hours and to 
be diligent about the work hours.   Otherwise a perception may be developed 
that you may be less than productive if you are not responding to 
email/IM/phone calls in a similar fashion to "being in the office".

I for one would embrace the flexible work location with certain ground rules 
set ahead of time for what things may require onsite, etc.   As others have 
mentioned, there really are very few technical reasons anymore why someone 
needs to be onsite.   One can waste time just as easily in the office as they 
can at home.

_
Dave Jousma
AVP | Manager, Systems 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 
esmie moo
Sent: Thursday, August 22, 2019 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Attitude of companies toward mainframers working from home?

**CAUTION EXTERNAL EMAIL**

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

 We were able to work from home until last year.  According  to management's 
explanation "productivity had deteriorated"Now, we all make the trek to the 
office.  A lot of people were caught in a bind because their homes were about 
50 -70 miles away from the city center.  Others had to scramble to find daycare 
for their toddlers.  An immense strain and hardship was exacted on us because 
we now have to pay expensive transportation costs etc.  But as we are reminded 
by management to "count our blessings and we are lucky to have a job".  Amen 
!
On Thursday, August 22, 2019, 02:55:34 a.m. GMT-4, Ron Hawkins 
 wrote:  
 
 Charles,

It may be a bit different for a test environment, but up until I left Hitachi 
last year, I was the only MF person that split time between home and the office.

A year later, the MF itself has moved, and none of the testers works on site. 
When I left they were located in both US states and another country. I am doing 
some contract work for them n and split my time between Australia and 
Philippines.

I liked to have our team to train and work face to face occasionally and had 
regular fly-ins of the team for a week. California killed this off as they want 
to declare you a tax resident if you spend more than 60 calendar days in the 
state. Tell that to someone from Nevada.


RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Thursday, 22 August 2019 06:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] At

Re: Attitude of companies toward mainframers working from home?

[Bob Bridges]

Good point; yeah, that's gotta have an effect, though I suppose it may be 
slight.

What I've noticed, in the last five or ten years, is the increasing range of 
the ~types~ of jobs that are being done remotely.  Twenty years ago I would 
have been surprised to find that companies were willing to have me work on 
their mainframe security from home.  Ten years ago I noticed they were doing it 
with systems programmers, too.  Nowadays I see the occasional req for remote 
managers.  I suppose there are some jobs that simply cannot be done from home, 
forever, but fewer than before.

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

/* The worst thing about new books is that they keep us from reading the old 
ones.  -Joseph Joubert (1754-1824) */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, March 6, 2020 18:56

Came across this lengthy thread from last year. No one seemed to mention the 
effects of a world-wide pandemic. You just can't think of everything...

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

Re: Attitude of companies toward mainframers working from home?

[Mark Jacobs]

It'll be interesting to see how many companies need to enhance their VPN 
infrastructure if/when they increase their remote workforce. With the current 
coronavirus event, that move to a remote workforce might happen sooner than 
planned.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐
On Friday, March 6, 2020 7:52 PM, Bob Bridges  wrote:

> Good point; yeah, that's gotta have an effect, though I suppose it may be 
> slight.
>
> What I've noticed, in the last five or ten years, is the increasing range of 
> the ~types~ of jobs that are being done remotely. Twenty years ago I would 
> have been surprised to find that companies were willing to have me work on 
> their mainframe security from home. Ten years ago I noticed they were doing 
> it with systems programmers, too. Nowadays I see the occasional req for 
> remote managers. I suppose there are some jobs that simply cannot be done 
> from home, forever, but fewer than before.
>
> ---
>
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* The worst thing about new books is that they keep us from reading the old 
> ones. -Joseph Joubert (1754-1824) */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jesse 1 Robinson
> Sent: Friday, March 6, 2020 18:56
>
> Came across this lengthy thread from last year. No one seemed to mention the 
> effects of a world-wide pandemic. You just can't think of everything...
>
> -
>
> 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: Attitude of companies toward mainframers working from home?

[Steve Beaver]

Working from home takes a lot of concentration and effort.  It’s not easy but 
I’ve done it for years

Sent from my iPhone

> On Mar 6, 2020, at 19:54, Mark Jacobs 
> <0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> It'll be interesting to see how many companies need to enhance their VPN 
> infrastructure if/when they increase their remote workforce. With the current 
> coronavirus event, that move to a remote workforce might happen sooner than 
> planned.
> 
> Mark Jacobs
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> GPG Public Key - 
> https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
> 
> ‐‐‐ Original Message ‐‐‐
>> On Friday, March 6, 2020 7:52 PM, Bob Bridges  wrote:
>> 
>> Good point; yeah, that's gotta have an effect, though I suppose it may be 
>> slight.
>> 
>> What I've noticed, in the last five or ten years, is the increasing range of 
>> the ~types~ of jobs that are being done remotely. Twenty years ago I would 
>> have been surprised to find that companies were willing to have me work on 
>> their mainframe security from home. Ten years ago I noticed they were doing 
>> it with systems programmers, too. Nowadays I see the occasional req for 
>> remote managers. I suppose there are some jobs that simply cannot be done 
>> from home, forever, but fewer than before.
>> 
>> ---
>> 
>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>> 
>> /* The worst thing about new books is that they keep us from reading the old 
>> ones. -Joseph Joubert (1754-1824) */
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Jesse 1 Robinson
>> Sent: Friday, March 6, 2020 18:56
>> 
>> Came across this lengthy thread from last year. No one seemed to mention the 
>> effects of a world-wide pandemic. You just can't think of everything...
>> 
>> -
>> 
>> 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