Re: load modules

2020-03-05 Thread Brian Westerman 
There is an LLA monitor called MODULE FETCH MONITOR you can get from IBM for 
free (as in beer), and it displays all of the linklist libraries and what 
modules are being used.  You are intended to start it at IPL time and let it 
run until you shutdown, and while it's up you can look at not only what modules 
are used, but how many times that they are used and by who(m).  If you ask 
Peter Relson at IBM (you can find his ID by searching this (or IBM's) site) 
really nicely, I'm sure he will send you a copy.

All you need to do is install it and start the STC (you don't need to IPL but 
it only starts collecting from the time you start it), and you can look at all 
modules used in/from linklist by module name and/or by library.  I used it 
several years ago to clean up some really nasty environments where for 20 odd 
years people would just put everything they could think of in linklist.  It has 
many uses and it really is a pretty cool utility.

Brian Westerman

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

2020-03-05 Thread ITschak Mugzach 
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

Re: JCL error during TSO/E logon

2020-03-05 Thread Binyamin Dissen 
Back in Ye Olde Days I had such a problem (very annoying when users would call
the support desk about these things).

We had a modified IKJEFLD that allowed overrides of PROCs and accounts without
requiring UADS entries.

What I did would call the accounting system to verify that the account was
valid and I added 2 libraries to MSTJCL00, the user proclibs and the SP
proclibs and verified that the override was in the proclib. This had the
advantage that users could create their procs for their applications but not
be able to use them for TSO.

They would get messages such as "not authorized to such an account" or "proc
not known" and would be able to reenter.

I also added code to allow the user to permanently update these as well as the
password from the logon prompt.


On Thu, 5 Mar 2020 23:08:32 + Jesse 1 Robinson 
wrote:

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


--
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: JCL error during TSO/E logon

2020-03-05 Thread Paul Gilmartin 
On Thu, 5 Mar 2020 21:07:32 -0500, Tom Conley wrote:
>
>..., I've used the following JCL
>for years to check out procs that fail (typically my STC sysout goes to
>the bit bucket):
>
>//IBMUSERC JOB 'IBMUSER',
>// CLASS=A,
>// NOTIFY=,
>// MSGCLASS=X,REGION=0M,MSGLEVEL=(1,1)
>//TESTPROC EXEC procname
>
>The error becomes immediately apparent.
> 
In order to extend my understanding, I looked at:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/iea3b6_Examples_of_the_TERM_parameter.htm

Examples of the TERM parameter
z/OS MVS JCL Reference SA23-1385-00 
...
//DD1  DD  TERM=TS,SYSOUT=*

In a background or batch job, the system ignores TERM=TS and
recognizes a sysout data set. (An allocation error occurs if SYSOUT=*
is not coded with TERM=TS.)
...
I immediately had a problem -- I am very accustomed to coding
//SYSPRINT  DD  SYSOUT=*
by itself, not with TERM=TS.  Ah, now I get it.  Scope of quantifiers
in English can be ambiguous.  It would be clearer if it said:
(An allocation error occurs if  TERM=TS is coded without SYSOUT=*.)

Must it be SYSOUT=*?  Will neither SYSOUT=specific-class nor
SYSOUT=(,) be accepted?  What if I use OUTPUT statements to
direct my JES data sets to three different classes and don't specify
MSGCLASS?

And, "...the system ignores TERM=TS ...", but "An allocation error occurs ..."
If it's truly ignored, it can't cause an error.  How about:
...  if  TERM=TS is coded without SYSOUT=* an allocation error occurs.
Otherwise, TERM=TS is ignored.

Feels like an RCF to me.

-- gil

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

2020-03-05 Thread Ed Jaffe 

On 3/3/2020 12:37 PM, Charles Mills wrote:

I will try COPYGRP and COPYGROUP. What's the difference? The description is 
word for word the same.



The big difference (and reason it was invented) is COPYGROUP supports 
member name masking whereas COPYGRP does not.


https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.idau100/copygroup.htm


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



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

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

Re: load modules

2020-03-05 Thread Mike Hochee 
STEPLIBing it seems the simplest, but if for some reason that is not possible, 
then you likely have to follow your module update with an LLA REFRESH or LLA 
UPDATE command. The TSO ISRDDN suggestion can provide module size (assuming it 
differs from the old version) using the M option. 

HTH, 
Mike 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Binyamin Dissen
Sent: Thursday, March 5, 2020 3:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: load modules

Caution! This message was sent from outside your organization.

One would hope that testing would be via STEPLIB.

On Thu, 5 Mar 2020 14:39:31 -0500 Charles Mills  wrote:

:>Sometimes you make a code change, and the problem is no better, so you wonder 
"did I screw up the code change or am I still running the old code?" 
CharlesSent from a mobile; please excuse the brevity.
:> Original message From: Binyamin Dissen 
 Date: 3/5/20  11:07 AM  (GMT-05:00) To: 
IBM-MAIN@LISTSERV.UA.EDU Subject: Re: load modules On Thu, 5 Mar 2020 13:20:38 
+ "Nai, Dean"  wrote::>   Anyone know a way to see 
if a linklst load mode is being used? We made a userexit change and I wanted to 
see if it was using the new load module and not the old one?thanksDon't 
understand why the userexit is relevant. Assuming you changed the loadmodule, 
it should be doing something different. Just run your test case (youDO have a 
test case, don't you?)--Binyamin Dissen 
http://www.dissensoftware.comDirector, Dissen 
Software, Bar & Grill - IsraelShould 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 :>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email 
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

2020-03-05 Thread Tom Conley 

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

Re: JCL error during TSO/E logon

2020-03-05 Thread Tom Conley 

On 3/5/2020 6:08 PM, Jesse 1 Robinson wrote:

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



Skip,

While not directly answering your question, I've used the following JCL 
for years to check out procs that fail (typically my STC sysout goes to 
the bit bucket):


//IBMUSERC JOB 'IBMUSER',
// CLASS=A,
// NOTIFY=,
// MSGCLASS=X,REGION=0M,MSGLEVEL=(1,1)
//TESTPROC EXEC procname

The error becomes immediately apparent.

Tom

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

2020-03-05 Thread Lizette Koehler 
If your TSO JES2 definition has the output go to a queue in JES2 that is not
purged immediately, that is where I typically look.

Other option is to review the SAF setup for the TSO Logon Proc and then test
the Logon proc in your TSO Session.  Or use a JCL Scanner to verify the proc
the user is set up for.

Not sure this is a TPX issue.  But more likely the TSOPROC process in SAF.

Lizette

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Jesse 1 Robinson
Sent: Thursday, March 5, 2020 4: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

JCL error during TSO/E logon

2020-03-05 Thread Jesse 1 Robinson 
>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

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

2020-03-05 Thread Baldeva Prasad 

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 





Below is the SDSF Output:---
  SDSF OUTPUT DISPLAY SMPELST1 JOB25787  DSID   104 LINE 0   COLUMNS 02- 81
  COMMAND INPUT ===>SCROLL ===> CSR
* TOP OF DATA **


PAGE 0001  - NOW SET TO GLOBAL ZONE  DATE 03/03/20  TIME 06:42:35  SMP/E

whose out put is as below:--

PAGE 0001  - NOW SET TO GLOBAL ZONE  DATE 03/03/20  TIME 06:42:35  SMP/E

   LIST SHELLSCR(
 BBLU1702
 BBLUNPAX
)
ALLZONES .
PAGE 0002  - NOW SET TO DLIB   ZONE MVSD100  DATE 03/03/20  TIME 06:42:35  SMP/E

MVSD100 SHELLSCR ENTRIES


   NAME

BBLUNPAX  LASTUPD = HWLPEM0  TYPE=ADD
   LIBRARIES   = DISTLIB=ABBLLIB   SYSLIB=SBBLLIB
   BINARY
   FMID= HWLPEM0
   RMID= UI48757
   PARM= PATHMODE(0,7,5,5)
   LINK= '../BBLUNPAX.sh'

BBLU1702  LASTUPD = UI48894  TYPE=ADD
   LIBRARIES   = DISTLIB=ABBLLIB   SYSLIB=SBBLLIB
   BINARY
   FMID= HWLPEM0
   RMID= UI48894
   PARM= PATHMODE(0,7,5,5)
   LINK= '../BBLU1702.sh'

PAGE 0003  - NOW SET TO DLIB   ZONE MVSD100  DATE 03/03/20  TIME 06:42:35  SMP/E

LIST SUMMARY REPORT FOR MVSD100

ENTRY-TYPE   ENTRY-NAME STATUS

SHELLSCR BBLUNPAX   STARTS ON PAGE 0002
SHELLSCR BBLU1702   STARTS ON PAGE 0002
PAGE 0004  - NOW SET TO TARGET ZONE MVST100  DATE 03/03/20  TIME 06:42:36  SMP/E

MVST100 SHELLSCR ENTRIES


   NAME

BBLUNPAX  LASTUPD = HWLPEM0  TYPE=ADD
   LIBRARIES   = DISTLIB=ABBLLIB   SYSLIB=SBBLLIB
   BINARY
   FMID= HWLPEM0
   RMID= UI48757
   PARM= PATHMODE(0,7,5,5)
   LINK= '../BBLUNPAX.sh'

BBLU1702  LASTUPD = UI48894  TYPE=ADD
   LIBRARIES   = DISTLIB=ABBLLIB   SYSLIB=SBBLLIB
   BINARY
   FMID= HWLPEM0
   RMID= UI48894
   PARM= PATHMODE(0,7,5,5)
   LINK= '../BBLU1702.sh'

PAGE 0005  - NOW SET TO TARGET ZONE MVST100  DATE 03/03/20  TIME 06:42:36  SMP/E

LIST SUMMARY REPORT FOR MVST100

ENTRY-TYPE   ENTRY-NAME STATUS

SHELLSCR BBLUNPAX   STARTS ON

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

2020-03-05 Thread Baldeva Prasad 
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 




Below is the SDSF Output:---
 SDSF OUTPUT DISPLAY SMPELST1 JOB25787  DSID   104 LINE 0   COLUMNS 02- 81
 COMMAND INPUT ===>SCROLL ===> CSR
* TOP OF DATA **


PAGE 0001  - NOW SET TO GLOBAL ZONE  DATE 03/03/20  TIME 06:42:35  SMP/E

whose out put is as below:--

PAGE 0001  - NOW SET TO GLOBAL ZONE  DATE 03/03/20  TIME 06:42:35  SMP/E

  LIST SHELLSCR(
BBLU1702
BBLUNPAX
   )
   ALLZONES .
PAGE 0002  - NOW SET TO DLIB   ZONE MVSD100  DATE 03/03/20  TIME 06:42:35  SMP/E

MVSD100 SHELLSCR ENTRIES


  NAME

BBLUNPAX  LASTUPD = HWLPEM0  TYPE=ADD
  LIBRARIES   = DISTLIB=ABBLLIB   SYSLIB=SBBLLIB
  BINARY
  FMID= HWLPEM0
  RMID= UI48757
  PARM= PATHMODE(0,7,5,5)
  LINK= '../BBLUNPAX.sh'

BBLU1702  LASTUPD = UI48894  TYPE=ADD
  LIBRARIES   = DISTLIB=ABBLLIB   SYSLIB=SBBLLIB
  BINARY
  FMID= HWLPEM0
  RMID= UI48894
  PARM= PATHMODE(0,7,5,5)
  LINK= '../BBLU1702.sh'

PAGE 0003  - NOW SET TO DLIB   ZONE MVSD100  DATE 03/03/20  TIME 06:42:35  SMP/E

LIST SUMMARY REPORT FOR MVSD100

ENTRY-TYPE   ENTRY-NAME STATUS

SHELLSCR BBLUNPAX   STARTS ON PAGE 0002
SHELLSCR BBLU1702   STARTS ON PAGE 0002
PAGE 0004  - NOW SET TO TARGET ZONE MVST100  DATE 03/03/20  TIME 06:42:36  SMP/E

MVST100 SHELLSCR ENTRIES


  NAME

BBLUNPAX  LASTUPD = HWLPEM0  TYPE=ADD
  LIBRARIES   = DISTLIB=ABBLLIB   SYSLIB=SBBLLIB
  BINARY
  FMID= HWLPEM0
  RMID= UI48757
  PARM= PATHMODE(0,7,5,5)
  LINK= '../BBLUNPAX.sh'

BBLU1702  LASTUPD = UI48894  TYPE=ADD
  LIBRARIES   = DISTLIB=ABBLLIB   SYSLIB=SBBLLIB
  BINARY
  FMID= HWLPEM0
  RMID= UI48894
  PARM= PATHMODE(0,7,5,5)
  LINK= '../BBLU1702.sh'

PAGE 0005  - NOW SET TO TARGET ZONE MVST100  DATE 03/03/20  TIME 06:42:36  SMP/E

LIST SUMMARY REPORT FOR MVST100

ENTRY-TYPE   ENTRY-NAME STATUS

SHELLSCR BBLUNPAX   STARTS ON PAGE 0004
SHELLSCR BBLU1702   STARTS ON PAGE

Re: load modules

2020-03-05 Thread Binyamin Dissen 
One would hope that testing would be via STEPLIB.

On Thu, 5 Mar 2020 14:39:31 -0500 Charles Mills  wrote:

:>Sometimes you make a code change, and the problem is no better, so you wonder 
"did I screw up the code change or am I still running the old code?" 
CharlesSent from a mobile; please excuse the brevity.
:> Original message From: Binyamin Dissen 
 Date: 3/5/20  11:07 AM  (GMT-05:00) To: 
IBM-MAIN@LISTSERV.UA.EDU Subject: Re: load modules On Thu, 5 Mar 2020 13:20:38 
+ "Nai, Dean"  wrote::>   Anyone know a way to see 
if a linklst load mode is being used? We made a userexit change and I wanted to 
see if it was using the new load module and not the old one?thanksDon't 
understand why the userexit is relevant. Assuming you changed the loadmodule, 
it should be doing something different. Just run your test case (youDO have a 
test case, don't you?)--Binyamin Dissen 
http://www.dissensoftware.comDirector, Dissen 
Software, Bar & Grill - IsraelShould 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
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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: load modules

2020-03-05 Thread Paul Gilmartin 
On Thu, 5 Mar 2020 14:39:31 -0500, Charles Mills wrote:

>Sometimes you make a code change, and the problem is no better, so you wonder 
>"did I screw up the code change or am I still running the old code?" 
>CharlesSent from a mobile; please excuse the brevity.
>
Wouldn't it be nice if one could generate a strong hash of a program object?

And how come a program object in a UNIX directory is a simple sequence of
bytes while a program object in a PDSE is an ineffable entity?  (Of course, the
UNIX object can't have multiple entry points.  No, "ineffable" does not mean
what some first guess.)

-- gil

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

Re: load modules

2020-03-05 Thread Charles Mills 
Sometimes you make a code change, and the problem is no better, so you wonder 
"did I screw up the code change or am I still running the old code?" 
CharlesSent from a mobile; please excuse the brevity.
 Original message From: Binyamin Dissen 
 Date: 3/5/20  11:07 AM  (GMT-05:00) To: 
IBM-MAIN@LISTSERV.UA.EDU Subject: Re: load modules On Thu, 5 Mar 2020 13:20:38 
+ "Nai, Dean"  wrote::>   Anyone know a way to see 
if a linklst load mode is being used? We made a userexit change and I wanted to 
see if it was using the new load module and not the old one…thanksDon't 
understand why the userexit is relevant. Assuming you changed the loadmodule, 
it should be doing something different. Just run your test case (youDO have a 
test case, don't you?)--Binyamin Dissen 
http://www.dissensoftware.comDirector, Dissen 
Software, Bar & Grill - IsraelShould 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

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

Re: load modules

2020-03-05 Thread David Cole 

Hi Dean,

z/XDC's "LOAD" command loads a module into 
storage according to the same default rules that 
all other processes would follow, and then it 
produces a two part report from which you can 
discern which instance got LOAD'd to you (when multiple instances exist).


Example. Suppose I issue "LOAD XXX". The report would look something like this:

 ENTRYPRIMARY  REFRNCE   USE 
 SUB-  ATTRIBUTES
SEQ# NAME NAME TCB/RB# COUNT 
ASID ENTRY ADDRESS KEY POOL  (ATTR ATTR2 ATTR3-ATTRB)
 _ 1 XXX   5   LLE   1-1 COMN 
_0099B070  0s  DLPA B12204-10 RENT REUS CDE APFLIB CDX DLPA NIP




 ENTRYPRIMARY  DFINING   USE 
 SUB-  ATTRIBUTES
SEQ# NAME NAME QUEUE   COUNT 
ASID ENTRY ADDRESS KEY POOL  (ATTR ATTR2 ATTR3-ATTRB)
 _ 3 XXX   LPQ 4 COMN 
_0099B070  0s  DLPA B12204-10 RENT REUS CDE APFLIB CDX DLPA NIP
 _ 4 XXX   PLPA  COMN 
_00C71070  0s  PLPA B12200-18 RENT REUS LPDE APFLIB CDX NIP


The first part reports who the users are of the 
module within your address space. In this case:

   * There is only one user.
   * It is task #5 (because that's where XDC was 
running when you told it to "LOAD XXX").



The second part reports all instances of the load 
module that exist in your address space. In this case:

   * There are two instances.
   * The first instance overrides the second.
   * The first instance is in the [Dynamic] Link 
Pack Area. It was probably created by a "SETPROG 
LPA,ADD" Operator command to replace the original 
PLPA instance with a newer one.
   * The second instance exists in the PLPA. 
This was the "original" instance created at IPL 
time. It is dormant because all attempts to 
LINK/LOAD/ATTACH XXX will never reach this second 
instance because they will be satisfied by the first.



From the first report, you can tell that the 
z/XDC "LOAD" command gave you access to the first 
(newer) instance. You can tell this by looking at "ENTRY ADDRESS" field.



After issuing the "LOAD" command, you can then 
use z/XDC's "FORMAT" command to look at the 
module's content. Example: "FORMAT XXX+43C" will 
show you what's at +43C past XXX's entry point.


IHTH,
Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

Tools:   z/XDC for Assembler debugging
 c/XDC 
for C debugging







At 3/5/2020 10:10 AM, Nai, Dean wrote:

Hi Chris,
  Let me check XDC..thanks
Dean

On 3/5/20, 9:59 AM, "IBM Mainframe Discussion 
List on behalf of Chris Parker" 
 wrote:
> EXTERNAL:  Do not open attachments or click 
on links unless you recognize and trust the sender.

>
>Hi Dean,
>
>I don’t know what type of tooling you 
have.  So, I'm not sure exactly what to 
suggest.  If you have an eyecatcher in the 
module that you can verify, you could use the 
tso test or testauth command specifying the 
load module as the entry program and then just 
dump the location and header.  You could also 
write a quick and dirty ASM program to do the load and dump the address.

>
>I have XDC.  So, I would just start up a 
session and issue a load command.  :)

>
>Chris
>
>-Original Message-
>From: IBM Mainframe Discussion List 
 On Behalf Of Nai, Dean

>Sent: Thursday, March 5, 2020 8:54 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: load modules
>
>Hi Larre,
>   No luck. I’m thinking this is something 
that can’t be found. Thanks for the response.

>
>Dean Nai
>Senior z/OS Systems Programmer
>Technical Services Group
>Department of Information Technology
>State of New Hampshire
>27 Hazen Drive
>Concord, NH 03301
> work: 603-271-1529
>
>
>
>On 3/5/20, 9:37 AM, "IBM Mainframe 
Discussion List on behalf of Larre Shiller" 
0102cb4997b0-dmarc-requ...@listserv.ua.edu> wrote:

>
>> EXTERNAL:  Do not open attachments or 
click on links unless you recognize and trust the sender.

>>
>>Dean -
>>
>>...how about using the TSO ISRDDN command 
followed by LOAD module_name ...?

>>
>>Larre Shiller
>>US Social Security Administration


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

Re: load modules

2020-03-05 Thread Binyamin Dissen 
On Thu, 5 Mar 2020 13:20:38 + "Nai, Dean"  wrote:

:>   Anyone know a way to see if a linklst load mode is being used? We made a 
userexit change and I wanted to see if it was using the new load module and not 
the old one…thanks

Don't understand why the userexit is relevant. Assuming you changed the load
module, it should be doing something different. Just run your test case (you
DO have a test case, don't you?)

--
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: load modules

2020-03-05 Thread Nai, Dean 
Hi Chris,

  Let me check XDC..thanks

Dean 








On 3/5/20, 9:59 AM, "IBM Mainframe Discussion List on behalf of Chris Parker" 
 wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Hi Dean,
>
>I don’t know what type of tooling you have.  So, I'm not sure exactly what to 
>suggest.  If you have an eyecatcher in the module that you can verify, you 
>could use the tso test or testauth command specifying the load module as the 
>entry program and then just dump the location and header.  You could also 
>write a quick and dirty ASM program to do the load and dump the address.
>
>I have XDC.  So, I would just start up a session and issue a load command.  :)
>
>Chris
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Nai, Dean
>Sent: Thursday, March 5, 2020 8:54 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: load modules
>
>Hi Larre,
>   No luck. I’m thinking this is something that can’t be found. Thanks for the 
> response.
>
>Dean Nai
>Senior z/OS Systems Programmer
>Technical Services Group
>Department of Information Technology
>State of New Hampshire
>27 Hazen Drive
>Concord, NH 03301
> work: 603-271-1529
>
>
>Statement of Confidentiality: The contents of this message are confidential.
>Any unauthorized disclosure, reproduction, use or dissemination (either whole 
>or in part) is prohibited. If you are not the intended recipient of this 
>message, please notify the sender immediately and delete the message from your 
>system.
>
>
>
>
>
>
>
>
>
>On 3/5/20, 9:37 AM, "IBM Mainframe Discussion List on behalf of Larre Shiller" 
>0102cb4997b0-dmarc-requ...@listserv.ua.edu> wrote:
>
>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>> and trust the sender.
>>
>>Dean -
>>
>>...how about using the TSO ISRDDN command followed by LOAD module_name ...?
>>
>>Larre Shiller
>>US Social Security Administration
>>“The opinions expressed in this post are mine personally and do not 
>>necessarily reflect the opinion of the US Social Security Administration 
>>and/or the US Government.”
>>
>>--
>>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
>---
>NOTICE:
>This email and all attachments are confidential, may be proprietary, and may 
>be privileged or otherwise protected from disclosure. They are intended solely 
>for the individual or entity to whom the email is addressed. However, mistakes 
>sometimes happen in addressing emails. If you believe that you are not an 
>intended recipient, please stop reading immediately. Do not copy, forward, or 
>rely on the contents in any way. Notify the sender and/or Imperva, Inc. by 
>telephone at +1 (650) 832-6006 and then delete or destroy any copy of this 
>email and its attachments. The sender reserves and asserts all rights to 
>confidentiality, as well as any privileges that may apply. Any disclosure, 
>copying, distribution or action taken or omitted to be taken by an unintended 
>recipient in reliance on this message is prohibited and may be unlawful.
>Please consider the environment before printing this email.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: load modules

2020-03-05 Thread Chris Parker 
Hi Dean,

I don’t know what type of tooling you have.  So, I'm not sure exactly what to 
suggest.  If you have an eyecatcher in the module that you can verify, you 
could use the tso test or testauth command specifying the load module as the 
entry program and then just dump the location and header.  You could also write 
a quick and dirty ASM program to do the load and dump the address.

I have XDC.  So, I would just start up a session and issue a load command.  :)

Chris

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Nai, Dean
Sent: Thursday, March 5, 2020 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: load modules

Hi Larre,
   No luck. I’m thinking this is something that can’t be found. Thanks for the 
response.

Dean Nai
Senior z/OS Systems Programmer
Technical Services Group
Department of Information Technology
State of New Hampshire
27 Hazen Drive
Concord, NH 03301
 work: 603-271-1529


Statement of Confidentiality: The contents of this message are confidential.
Any unauthorized disclosure, reproduction, use or dissemination (either whole 
or in part) is prohibited. If you are not the intended recipient of this 
message, please notify the sender immediately and delete the message from your 
system.









On 3/5/20, 9:37 AM, "IBM Mainframe Discussion List on behalf of Larre Shiller" 
 wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Dean -
>
>...how about using the TSO ISRDDN command followed by LOAD module_name ...?
>
>Larre Shiller
>US Social Security Administration
>“The opinions expressed in this post are mine personally and do not 
>necessarily reflect the opinion of the US Social Security Administration 
>and/or the US Government.”
>
>--
>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
---
NOTICE:
This email and all attachments are confidential, may be proprietary, and may be 
privileged or otherwise protected from disclosure. They are intended solely for 
the individual or entity to whom the email is addressed. However, mistakes 
sometimes happen in addressing emails. If you believe that you are not an 
intended recipient, please stop reading immediately. Do not copy, forward, or 
rely on the contents in any way. Notify the sender and/or Imperva, Inc. by 
telephone at +1 (650) 832-6006 and then delete or destroy any copy of this 
email and its attachments. The sender reserves and asserts all rights to 
confidentiality, as well as any privileges that may apply. Any disclosure, 
copying, distribution or action taken or omitted to be taken by an unintended 
recipient in reliance on this message is prohibited and may be unlawful.
Please consider the environment before printing this email.

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

Re: load modules

2020-03-05 Thread Nai, Dean 
Hi Larre,
   No luck. I’m thinking this is something that can’t be found. Thanks for the 
response.

Dean Nai
Senior z/OS Systems Programmer  
Technical Services Group
Department of Information Technology
State of New Hampshire
27 Hazen Drive
Concord, NH 03301
 work: 603-271-1529


Statement of Confidentiality: The contents of this message are
confidential.
Any unauthorized disclosure, reproduction, use or dissemination (either
whole or in part) is prohibited. If you are not the intended recipient of
this message, please notify the sender immediately and delete the message
from your system.









On 3/5/20, 9:37 AM, "IBM Mainframe Discussion List on behalf of Larre Shiller" 
 wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Dean -
>
>...how about using the TSO ISRDDN command followed by LOAD module_name ...?
>
>Larre Shiller
>US Social Security Administration
>“The opinions expressed in this post are mine personally and do not 
>necessarily reflect the opinion of the US Social Security Administration 
>and/or the US Government.”
>
>--
>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: load modules

2020-03-05 Thread Larre Shiller 
Dean -

...how about using the TSO ISRDDN command followed by LOAD module_name ...?

Larre Shiller
US Social Security Administration
“The opinions expressed in this post are mine personally and do not necessarily 
reflect the opinion of the US Social Security Administration and/or the US 
Government.”

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

Re: SMP/E receive order problem

2020-03-05 Thread Kurt Quackenbush 

GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING
  /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN
  CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X.
GIM49011S ** AN ERROR OCCURRED WHILE CREATING ARCHIVE FILE
  /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z FROM ITS
  SEGMENTS.
GIM47601IPACKAGE OS240809.content WAS PARTIALLY STAGED TO THE SMPNTS.

I added another mod27 volume to the storage group and restarted the job.  This 
run ended with RC=0 however, I got this in the output:

GIM64700IFILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z ALREADY
  EXISTS AND WILL NOT BE TRANSFERRED.

I look in the filesystem and this pax file doesn't exist.  How do I convince 
SMP/E that the file isn't there and it needs to get it again from IBM.  I don't 
really want to delete the entire order and re receive it as the receive job ran 
for 6 hours before failing.
Hmmm... that is suspicious.  Are you sure you're looking in the same 
directory and file system that SMP/E is looking in?


Not only does SMP/E look to see if the file already exists before 
downloading, it also calculates and compares the hash value for the 
existing file to ensure it is complete and accurate.  The GIM64700I 
message implies SMP/E both found the file and the calculated hash 
matches the expected value.


If truly the file does not already exist, then open a Case with IBM 
Support against SMP/E.


Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.

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

load modules

2020-03-05 Thread Nai, Dean 
Howdy,

   Anyone know a way to see if a linklst load mode is being used? We made a 
userexit change and I wanted to see if it was using the new load module and not 
the old one…thanks

Dean








>

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

2020-03-05 Thread Peter Relson 
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.

Then, here's what I played with (my load module was FOO with alias BAR), 
copying PDS to PDS:

-- ISPF copy of FOO: did only FOO (I thought ISPF COPY by default did 
aliases; guess not)
-- ISPF copy of FOO and BAR: did both, but BAR was standalone, not an 
alias of FOO
-- IEBCOPY with "COPY" and SELECT MEMBER=FOO: did just FOO, preserved the 
EP at BAR
-- IEBCOPY with "COPY" and SELECT MEMBER=FOO and SELECT MEMBER=BAR.
   Did both, BAR is an alias, preserved the EP of FOO at BAR, preserved 
the EP of BAR
-- IEBCOPY with "COPYGRP" and SELECT MEMBER=FOO: did just FOO, preserved 
the EP at BAR
-- IEBCOPY with "COPYGRP" and SELECT MEMBER=FOO and SELECT MEMBER=BAR.
   Did both, BAR is an alias, preserved the EP of FOO at BAR, preserved 
the EP of BAR
-- IEBCOPY with "COPYGROUP" and SELECT MEMBER=FOO: 
   Did both, BAR is an alias, preserved the EP of FOO at BAR, preserved 
the EP of BAR 
-- IEBCOPY with "COPYGROUP" and SELECT MEMBER=FOO and SELECT MEMBER=BAR.
   Did both, BAR is an alias, preserved the EP of FOO at BAR, preserved 
the EP of BAR

So I did get the described difference between COPYGRP and COPYGROUP but 
not the loss of the entry point offset that Charles described.

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