Re: smp/e question - PTF relinks, but missing CSECTs.

[Seymour J Metz]

I would probably have called his boss and recorded it, then let my boss here 
the recording. But all's well that end's well. 


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Edward Gould <edgould1...@comcast.net>
Sent: Friday, May 25, 2018 8:38 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: smp/e question - PTF relinks, but missing CSECTs.

> On May 25, 2018, at 12:39 PM, Jesse 1 Robinson <jesse1.robin...@sce.com> 
> wrote:
>
> I'm sympathetic to the argument that new stuff should be investigated, but 
> the problem is whether that really happens in practice. We've all met the 
> sysprog who meticulously codes parameter defaults as a kind of in-your-face 
> documentation so that 'we will all know' what's happening. Then years later 
> the defaults change, but the user-coded list does not get updated. Call me 
> Pollyanna, but I'm willing to trust the latest default.
>
> As for getting inconsistent results, I suspect that SMP/E results can be 
> influenced by the particular mix of elements being processed in a given run. 
> That is, applying SYSMOD-A and SYSMOD-B in the same step might uncover a 
> sinkhole that applying one sysmod or the other alone would not. This problem 
> is very difficult to detect in development and may require a lot of customer 
> activity to unearth.
>
> .
Jess1,
*YEARS* ago with a well known vendor I was trying to apply a zap (gotten in 
Hardcopy from the vendor) the module was right but the csect did not exist in 
the module flushed the zap, I called the vendor and the person I talked to 
started to argue with me about how I coded the zap. I was annoyed and said fine 
I will fax you the output. I faxed him the sheet of paper.. I did not hear back 
from him in an hour so I called him. He said I had coded the zap wrong, I 
looked at the zap again because I do not miscode zaps. I did this on the phone 
with him. I said the first column is blank and then the word "name” and then 
there is the module name and a blank and the csect name,  the rest of the card 
out to 72 is blank. What is wrong with it? He said you must be a beginner you 
never code zap statements like that. I said EXCUSE me that is how a the first 
zap statement is coded, I do this daily with another vendor and that is by the 
book how its done.  He told me I was wrong and not to bother him again. I said 
what? He hung the phone up on me. I went to the boss and explained to him what 
had transpired and he took a look at my zap statements and he said OK we will 
get him on the line. The guy hung up the phone and soon as he heard the 
company. My boss called the marketing rep and explained what was going on, the 
marketing rep followed the top-down chart as to who the guys boss was. 5 
minutes later we get a call from the guys boss and explains that the guy had a 
bad day. We explained the situation and he said what you are telling me you are 
correct, let me check with another technician he puts us on hold (with lousy 
music on top of it). The technician gets back on the the phone and said there 
was a typo on the sheet and its being faxed to all the customers as we speak. I 
said OK, but the treatment I got from this other technician was just wrong and 
a customer should never be treated that way. He said he will take it up with 
his management. My boss was surprised at me speaking up like I did, but I was 
pissed. The next day I called in with a small question on a wording of a zap 
and what sequence it was supposed to go on. A technician got on and I asked the 
question and he said he was happy we had caught the issue. I said OK thank you. 
He said was I going to report him? I said no why should I, you handled the call 
correctly. He said the technician I had talked to yesterday was fired.



> .
> 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 <mailto: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: smp/e question - PTF relinks, but missing CSECTs.

[Edward Gould]

> On May 25, 2018, at 12:39 PM, Jesse 1 Robinson  
> wrote:
> 
> I'm sympathetic to the argument that new stuff should be investigated, but 
> the problem is whether that really happens in practice. We've all met the 
> sysprog who meticulously codes parameter defaults as a kind of in-your-face 
> documentation so that 'we will all know' what's happening. Then years later 
> the defaults change, but the user-coded list does not get updated. Call me 
> Pollyanna, but I'm willing to trust the latest default.
> 
> As for getting inconsistent results, I suspect that SMP/E results can be 
> influenced by the particular mix of elements being processed in a given run. 
> That is, applying SYSMOD-A and SYSMOD-B in the same step might uncover a 
> sinkhole that applying one sysmod or the other alone would not. This problem 
> is very difficult to detect in development and may require a lot of customer 
> activity to unearth. 
> 
> .
Jess1,
*YEARS* ago with a well known vendor I was trying to apply a zap (gotten in 
Hardcopy from the vendor) the module was right but the csect did not exist in 
the module flushed the zap, I called the vendor and the person I talked to 
started to argue with me about how I coded the zap. I was annoyed and said fine 
I will fax you the output. I faxed him the sheet of paper.. I did not hear back 
from him in an hour so I called him. He said I had coded the zap wrong, I 
looked at the zap again because I do not miscode zaps. I did this on the phone 
with him. I said the first column is blank and then the word "name” and then 
there is the module name and a blank and the csect name,  the rest of the card 
out to 72 is blank. What is wrong with it? He said you must be a beginner you 
never code zap statements like that. I said EXCUSE me that is how a the first 
zap statement is coded, I do this daily with another vendor and that is by the 
book how its done.  He told me I was wrong and not to bother him again. I said 
what? He hung the phone up on me. I went to the boss and explained to him what 
had transpired and he took a look at my zap statements and he said OK we will 
get him on the line. The guy hung up the phone and soon as he heard the 
company. My boss called the marketing rep and explained what was going on, the 
marketing rep followed the top-down chart as to who the guys boss was. 5 
minutes later we get a call from the guys boss and explains that the guy had a 
bad day. We explained the situation and he said what you are telling me you are 
correct, let me check with another technician he puts us on hold (with lousy 
music on top of it). The technician gets back on the the phone and said there 
was a typo on the sheet and its being faxed to all the customers as we speak. I 
said OK, but the treatment I got from this other technician was just wrong and 
a customer should never be treated that way. He said he will take it up with 
his management. My boss was surprised at me speaking up like I did, but I was 
pissed. The next day I called in with a small question on a wording of a zap 
and what sequence it was supposed to go on. A technician got on and I asked the 
question and he said he was happy we had caught the issue. I said OK thank you. 
He said was I going to report him? I said no why should I, you handled the call 
correctly. He said the technician I had talked to yesterday was fired.

 

> .
> 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: smp/e question - PTF relinks, but missing CSECTs.

[Jesse 1 Robinson]

I believe that a radical restructuring of a load module represents a strong 
case for ++DELETE and re-add of the affected element. Some changes are too 
disruptive to handle via update. Of course a delete is also disruptive and 
invariably accompanied by HOLD data to the effect that the PTF cannot be 
RESTOREd. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, May 25, 2018 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: smp/e question - PTF relinks, but missing CSECTs.

On Fri, 25 May 2018 17:39:03 +, Jesse 1 Robinson wrote:
>
>As for getting inconsistent results, I suspect that SMP/E results can be 
>influenced by the particular mix of elements being processed in a given run. 
>That is, applying SYSMOD-A and SYSMOD-B in the same step might uncover a 
>sinkhole that applying one sysmod or the other alone would not. This problem 
>is very difficult to detect in development and may require a lot of customer 
>activity to unearth. 
> 
Indeed.  Does this happen when SYSMOD-A delivers a new ++MOD element and 
SYSMOD-B delivers ++JCLIN adding that ++MOD element to an existing load module?

-- gil


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

Re: smp/e question - PTF relinks, but missing CSECTs.

[Paul Gilmartin]

On Fri, 25 May 2018 17:39:03 +, Jesse 1 Robinson wrote:
>
>As for getting inconsistent results, I suspect that SMP/E results can be 
>influenced by the particular mix of elements being processed in a given run. 
>That is, applying SYSMOD-A and SYSMOD-B in the same step might uncover a 
>sinkhole that applying one sysmod or the other alone would not. This problem 
>is very difficult to detect in development and may require a lot of customer 
>activity to unearth. 
> 
Indeed.  Does this happen when SYSMOD-A delivers a new ++MOD element
and SYSMOD-B delivers ++JCLIN adding that ++MOD element to an existing
load module?

-- gil

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

Re: smp/e question - PTF relinks, but missing CSECTs.

[John McKown]

On Fri, May 25, 2018 at 12:43 PM Seymour J Metz  wrote:

> My song "PUT Process" was motivated by real incidents. JES2 service was
> especially bad; they would issue a PTF with a packaging error and the fix
> would again have a packaging error.
>

​Yeah, I remember "JES2 level sets". Unfortunately, I don't remember if I
liked them or despised them.​


>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: smp/e question - PTF relinks, but missing CSECTs.

[John McKown]

On Fri, May 25, 2018 at 12:39 PM Jesse 1 Robinson 
wrote:

> I'm sympathetic to the argument that new stuff should be investigated, but
> the problem is whether that really happens in practice. We've all met the
> sysprog who meticulously codes parameter defaults as a kind of in-your-face
> documentation so that 'we will all know' what's happening. Then years later
> the defaults change, but the user-coded list does not get updated. Call me
> Pollyanna, but I'm willing to trust the latest default.
>

​I'm a bit like that latter. I tend to code all the known parms of any kind
of "configuration" member even if all I'm doing is restating the default.
One reason, IIRC, was a vendor put out a either some maintenance or a new
version which changed the default on something. And after I implemented it,
I got a ton of complaints that "the product is broken" because the
programmers depended on the previous, now changed, default. ​



>
> As for getting inconsistent results, I suspect that SMP/E results can be
> influenced by the particular mix of elements being processed in a given
> run. That is, applying SYSMOD-A and SYSMOD-B in the same step might uncover
> a sinkhole that applying one sysmod or the other alone would not. This
> problem is very difficult to detect in development and may require a lot of
> customer activity to unearth.
>

​Yeah, I vaguely remember something long ago where I had some such problem.
I eventually had to try doing a APPLY S(one-entry) GROUPEXTEND to put
things on more slowly. And I had to figure out the "correct" order myself
too. I.e. I could apply A, then B and A would succeed & B fail, but if I
did apply B, then A -- everything was fine. I really got P.O.'d as I
recall. I'm now pretty much too old to bother. That's why our "maintenance"
philosophy in the past was to RECEIVE each RSU as it was announced. And do
_nothing_ with it; unless there was a specific need. We would simply order
an new IPO/CPDO/whatever about every 6 months. And install a completely new
z/OS image on new volumes -- new RES, DLIB, & SMP volumes. This is likely
easier in our very small, single production image + sandbox, environment.



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

-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: smp/e question - PTF relinks, but missing CSECTs.

[Seymour J Metz]

My song "PUT Process" was motivated by real incidents. JES2 service was 
especially bad; they would issue a PTF with a packaging error and the fix would 
again have a packaging error.


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
Sent: Friday, May 25, 2018 1:39 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: smp/e question - PTF relinks, but missing CSECTs.

I'm sympathetic to the argument that new stuff should be investigated, but the 
problem is whether that really happens in practice. We've all met the sysprog 
who meticulously codes parameter defaults as a kind of in-your-face 
documentation so that 'we will all know' what's happening. Then years later the 
defaults change, but the user-coded list does not get updated. Call me 
Pollyanna, but I'm willing to trust the latest default.

As for getting inconsistent results, I suspect that SMP/E results can be 
influenced by the particular mix of elements being processed in a given run. 
That is, applying SYSMOD-A and SYSMOD-B in the same step might uncover a 
sinkhole that applying one sysmod or the other alone would not. This problem is 
very difficult to detect in development and may require a lot of customer 
activity to unearth.

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, May 25, 2018 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: smp/e question - PTF relinks, but missing CSECTs.

(It's Friday; SPAM is above suspicion.)

On Fri, 25 May 2018 16:41:56 +, Jesse 1 Robinson wrote:

>I don't see any problem with the BYPASS statement except that it's needlessly 
>specific. BYPASS(HOLDSYSTEM) without the list of types should not only 
>suffice--it does for me--but also hedges against the addition of some new 
>holdsys type that you also want to bypass but overlooked in the inventory.
>
OTOH, if a new holdsys type appears it might bear investigation.

>Coincidentally we're also working an SR for a different link edit problem with 
>a System Automation module. Truth is, as good as SMP/E is, it cannot overcome 
>packaging errors.
>
No, testing by the supplier should do that.  But the cafeteria-style service 
allowed by SMP/E may make it impractical that a customer could install.

And I know of a case (ISV, not IBM) where a PTF passed testing only because of 
a dirty target zone.  The problem was first detected in the field.

-- gil


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

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

Re: smp/e question - PTF relinks, but missing CSECTs.

[Jesse 1 Robinson]

I'm sympathetic to the argument that new stuff should be investigated, but the 
problem is whether that really happens in practice. We've all met the sysprog 
who meticulously codes parameter defaults as a kind of in-your-face 
documentation so that 'we will all know' what's happening. Then years later the 
defaults change, but the user-coded list does not get updated. Call me 
Pollyanna, but I'm willing to trust the latest default.

As for getting inconsistent results, I suspect that SMP/E results can be 
influenced by the particular mix of elements being processed in a given run. 
That is, applying SYSMOD-A and SYSMOD-B in the same step might uncover a 
sinkhole that applying one sysmod or the other alone would not. This problem is 
very difficult to detect in development and may require a lot of customer 
activity to unearth. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, May 25, 2018 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: smp/e question - PTF relinks, but missing CSECTs.

(It's Friday; SPAM is above suspicion.)

On Fri, 25 May 2018 16:41:56 +, Jesse 1 Robinson wrote:

>I don't see any problem with the BYPASS statement except that it's needlessly 
>specific. BYPASS(HOLDSYSTEM) without the list of types should not only 
>suffice--it does for me--but also hedges against the addition of some new 
>holdsys type that you also want to bypass but overlooked in the inventory.
> 
OTOH, if a new holdsys type appears it might bear investigation.

>Coincidentally we're also working an SR for a different link edit problem with 
>a System Automation module. Truth is, as good as SMP/E is, it cannot overcome 
>packaging errors.  
> 
No, testing by the supplier should do that.  But the cafeteria-style service 
allowed by SMP/E may make it impractical that a customer could install.

And I know of a case (ISV, not IBM) where a PTF passed testing only because of 
a dirty target zone.  The problem was first detected in the field.

-- gil


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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Tom Marchant]

On Fri, 25 May 2018 11:19:58 -0500, Paul Gilmartin wrote:

>SYSLIB?  SYSLMOD?  Whatever.  I don't believe SMP/E cares about SYSLIB
>DD statement images in Binder JCLIN.

It does with CALLLIBS.

-- 
Tom Marchant

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

Re: smp/e question - PTF relinks, but missing CSECTs.

[Paul Gilmartin]

(It's Friday; SPAM is above suspicion.)

On Fri, 25 May 2018 16:41:56 +, Jesse 1 Robinson wrote:

>I don't see any problem with the BYPASS statement except that it's needlessly 
>specific. BYPASS(HOLDSYSTEM) without the list of types should not only 
>suffice--it does for me--but also hedges against the addition of some new 
>holdsys type that you also want to bypass but overlooked in the inventory.
> 
OTOH, if a new holdsys type appears it might bear investigation.

>Coincidentally we're also working an SR for a different link edit problem with 
>a System Automation module. Truth is, as good as SMP/E is, it cannot overcome 
>packaging errors.  
> 
No, testing by the supplier should do that.  But the cafeteria-style service
allowed by SMP/E may make it impractical that a customer could install.

And I know of a case (ISV, not IBM) where a PTF passed testing only
because of a dirty target zone.  The problem was first detected in the field.

-- gil

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Jesse 1 Robinson]

I don't see any problem with the BYPASS statement except that it's needlessly 
specific. BYPASS(HOLDSYSTEM) without the list of types should not only 
suffice--it does for me--but also hedges against the addition of some new 
holdsys type that you also want to bypass but overlooked in the inventory.

Coincidentally we're also working an SR for a different link edit problem with 
a System Automation module. Truth is, as good as SMP/E is, it cannot overcome 
packaging errors.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, May 25, 2018 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but 
missing CSECTs.

On Fri, May 25, 2018 at 10:41 AM Seymour J Metz <sme...@gmu.edu> wrote:

> What was on the APPLY statement?
>

​It is my standard. The BYPASS _might_ be part of the problem, but I really 
don't see why it would cause _this_ error.

  SETBOUNDARY (MVST100)
  .
  APPLY
 ASSEM
 JCLINREPORT
 GROUPEXTEND
  BYPASS(HOLDSYSTEM(ACTION,DELETE,DOC,DEP,AO,IPL,
EC,DYNACT,MULTSYS,EXIT,DOWNLD,
RESTART,ENH,MSGSKEL))
 SOURCEID (
   RECNTS29
  )
 RETRY(YES)
.​

​RECNTS29 is the name that I assigned to the latest RSU that I downloaded just 
a month or so ago.​



>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
Maranatha! <><
John McKown


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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Seymour J Metz]

ObSchiller Against stupidity the gods themselves contend in vain. You can't win 
an argument with the invincibly ignorant, no mater how many times you ask them 
to RTFM. My condolences.


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, May 25, 2018 12:19 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Fri, 25 May 2018 07:37:53 -0500, John McKown wrote:

>On Fri, May 25, 2018 at 7:26 AM Tom Marchant wrote:
>
>> On Fri, 25 May 2018 12:20:18 +, Allan Staller wrote:
>>
>> >Check the releted DDDEF's and the SYSLIB/CALLLIB concat.
>>
>> SYSLIB? The SYSLIB DDDEF is for assemblies, not for link edits.
>
>​True for SMP/E usagre. The Binder, at least in batch, uses the DD SYSLIB
>for autocall (CALL option). However, SMP/E, when it scans the ++JCLIN, will
>notice any Binder SYSLIBs. It will store the last qualifier as a DDDEF name
>in the appropriate LMOD. When the Binder is invoked for that LMOD​, SMP/E
>will dynamically allocate the DDDEFs in the LMOD entry to some SMPn DD
>name and pass that name as the alternate SYSLIB name to the Binder.
>
SYSLIB?  SYSLMOD?  Whatever.  I don't believe SMP/E cares about SYSLIB
DD statement images in Binder JCLIN.  But the DDNAME on INCLUDE statements
must match the DLIB NAMED on the ++MOD MCS.

I once had a heated argument with a co-worker who observed that the SYSLMOD
DSN in JCLIN was not an existing data set, and insisted that it must refer to a 
real
data set.  I tried to explain to him that what he saw was not JCL, but he 
persisted,
arguing that if each line starts with "//" it must be JCL!

>However, I don't control the LMOD entry, it was set up for me by IBM when I
>installed SMP/E and maintained by them. And, just to be complete, AOSBN is
>not mentioned in the LMOD SYSLIB equivalent. Only LINKLIB is mentioned in
>the Binder SYSMOD for this LMOD.
>
>​Again, the output from SMP/E and the LIST LMOD XREF output can be viewed
>on Github here:
>https://secure-web.cisco.com/1sn_Ew1J2mshmQ2uFOUCcFUQR-Nj7zIylBpu90fJUGZnrxUpDYeZFKdqU_9DdZEhi9rhECSHdRo8F5ZQYu3w5FuHNgTKgsRe-RdhfGd-8Zshr-IuqkjWrR0MqgCkYH2j8ttqQgEeTDHTUJ61uHQSqSXSkdXC8PqyVxK79vzyArSvKI29vyfODMMGcJi_lduuZ2rD5GuJkfhVn2IR1syykWK_Hq9HfwGOQHBupSObIE713SOHIzWx1Ay3Czk0P3HWDAwncOso9CDhblg-frfvbdw_po06pjh_JfmL6Y08u3E_VZGHst_ACo-SGVjzUt8_PW64vTbsAFakx-8nkeczLKL3Y9CR4_OFVVzaJU62tKwLELM9Pj8ehYGMxke40LM7J6hAf4pTAg4CcI12WVGnurpvOLF6j4HCuZuvE_v1HBS9Dr9Aq9NuxBMMWJfQl0TUFSduZ2omYgfmR26afqYysbA/https%3A%2F%2Fgist.github.com%2FJohnArchieMckown%2F20d995cce8e2f201a4cf9725c4932092

-- gil

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


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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[John McKown]

On Fri, May 25, 2018 at 10:41 AM Seymour J Metz  wrote:

> What was on the APPLY statement?
>

​It is my standard. The BYPASS _might_ be part of the problem, but I really
don't see why it would cause _this_ error.

  SETBOUNDARY (MVST100)
  .
  APPLY
 ASSEM
 JCLINREPORT
 GROUPEXTEND
  BYPASS(HOLDSYSTEM(ACTION,DELETE,DOC,DEP,AO,IPL,
EC,DYNACT,MULTSYS,EXIT,DOWNLD,
RESTART,ENH,MSGSKEL))
 SOURCEID (
   RECNTS29
  )
 RETRY(YES)
.​

​RECNTS29 is the name that I assigned to the latest RSU that I downloaded
just a month or so ago.​



>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Paul Gilmartin]

On Fri, 25 May 2018 07:37:53 -0500, John McKown wrote:

>On Fri, May 25, 2018 at 7:26 AM Tom Marchant wrote:
>
>> On Fri, 25 May 2018 12:20:18 +, Allan Staller wrote:
>>
>> >Check the releted DDDEF's and the SYSLIB/CALLLIB concat.
>>
>> SYSLIB? The SYSLIB DDDEF is for assemblies, not for link edits.
>
>​True for SMP/E usagre. The Binder, at least in batch, uses the DD SYSLIB
>for autocall (CALL option). However, SMP/E, when it scans the ++JCLIN, will
>notice any Binder SYSLIBs. It will store the last qualifier as a DDDEF name
>in the appropriate LMOD. When the Binder is invoked for that LMOD​, SMP/E
>will dynamically allocate the DDDEFs in the LMOD entry to some SMPn DD
>name and pass that name as the alternate SYSLIB name to the Binder.
> 
SYSLIB?  SYSLMOD?  Whatever.  I don't believe SMP/E cares about SYSLIB
DD statement images in Binder JCLIN.  But the DDNAME on INCLUDE statements
must match the DLIB NAMED on the ++MOD MCS.

I once had a heated argument with a co-worker who observed that the SYSLMOD
DSN in JCLIN was not an existing data set, and insisted that it must refer to a 
real
data set.  I tried to explain to him that what he saw was not JCL, but he 
persisted,
arguing that if each line starts with "//" it must be JCL!

>However, I don't control the LMOD entry, it was set up for me by IBM when I
>installed SMP/E and maintained by them. And, just to be complete, AOSBN is
>not mentioned in the LMOD SYSLIB equivalent. Only LINKLIB is mentioned in
>the Binder SYSMOD for this LMOD.
>
>​Again, the output from SMP/E and the LIST LMOD XREF output can be viewed
>on Github here:
>https://gist.github.com/JohnArchieMckown/20d995cce8e2f201a4cf9725c4932092

-- gil

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Seymour J Metz]

What was on the APPLY statement?


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
John McKown <john.archie.mck...@gmail.com>
Sent: Thursday, May 24, 2018 4:33 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

URL to a Github "gist" with the output that the Listserv rejected.

https://secure-web.cisco.com/1Gz91TSt9ItPQtPLAij5Im4PzjOnDpPoeJEyHyHuCN9yw-f50iRHiTJJySBmfW7ssRLowZzlUU8HGLElgFkDIpUqoWNAE-u9LDZPlIqiRDA_zSxLfIAHXoOhvn2mEN1RHmAxFwkPUT72wLlOrdSpojHlwF_B-VkMUew1SRHpmMiCbKcHenCeiFdOye8S8EoKbKvAG4zPWjlu57rWS5HgJxwt-BfEtoNRRc8jhe6oUl1soMHfAQblCt4Lxo7PutzyT_SpQW5JV-Xy6iwW0MMhmizik_2G5I8PPuZDL7j6cTTmyNtwE9dlm4AuLSMsjStWXEVDpZ170Gb6DRrb1LcLXw-NvkNcGTtt1ZJ7a9e64uCTpgl7_4WVVbkHYqTttkie3jVHJwPCfFl847mDEt_KUVtP3Kbn2ARC96wken0Z0n3faYNmA65Vl4EjKBkSr0RTYJRzfgpzqlB0s4pU3rQHHDA/https%3A%2F%2Fgist.github.com%2FJohnArchieMckown%2F20d995cce8e2f201a4cf9725c4932092

On Thu, May 24, 2018 at 3:30 PM Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 24 May 2018 15:58:54 -0400, John Eells wrote:
>
> >Tom Marchant wrote:
> >> On Thu, 24 May 2018 13:30:20 -0500, John McKown wrote:
> >>
> >>> On Thu, May 24, 2018 at 12:40 PM Seymour J Metz <sme...@gmu.edu>
> wrote:
> >>>
> >>>> Have you looked at the MOD entries for the missing csects?
> >>>
> >>> ​Yes, they look correct to me. The entries for each MOD (missing & not
> >>> missing) points to AOSBN as where it resides.​
> >>
> >> That's fine, but what LMODS are listed as containing those MODs?
> >>
> >
> >It's the MOD entries that have subentries for the LMODs in which they
> >are included.
>
> Right. That's what I meant. When a MOD is listed, part of that data is a
> list of LMODs the module is linked into.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

--
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: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[John McKown]

On Fri, May 25, 2018 at 7:26 AM Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 25 May 2018 12:20:18 +, Allan Staller wrote:
>
> >Check the releted DDDEF's and the SYSLIB/CALLLIB concat.
>
> SYSLIB? The SYSLIB DDDEF is for assemblies, not for link edits.
>

​True for SMP/E usagre. The Binder, at least in batch, uses the DD SYSLIB
for autocall (CALL option). However, SMP/E, when it scans the ++JCLIN, will
notice any Binder SYSLIBs. It will store the last qualifier as a DDDEF name
in the appropriate LMOD. When the Binder is invoked for that LMOD​, SMP/E
will dynamically allocate the DDDEFs in the LMOD entry to some SMPn DD
name and pass that name as the alternate SYSLIB name to the Binder.

However, I don't control the LMOD entry, it was set up for me by IBM when I
installed SMP/E and maintained by them. And, just to be complete, AOSBN is
not mentioned in the LMOD SYSLIB equivalent. Only LINKLIB is mentioned in
the Binder SYSMOD for this LMOD.

​Again, the output from SMP/E and the LIST LMOD XREF output can be viewed
on Github here:
https://gist.github.com/JohnArchieMckown/20d995cce8e2f201a4cf9725c4932092


>
> --
> Tom Marchant
>

-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Tom Marchant]

On Fri, 25 May 2018 12:20:18 +, Allan Staller wrote:

>Check the releted DDDEF's and the SYSLIB/CALLLIB concat.

SYSLIB? The SYSLIB DDDEF is for assemblies, not for link edits.

-- 
Tom Marchant

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[John McKown]

On Fri, May 25, 2018 at 7:21 AM Allan Staller  wrote:

> Sounds like a SMP/E Configuration error. Check the releted DDDEF's and the
> SYSLIB/CALLLIB concat.
> Other SMP/E error messages?
>

​That is the only error message. Not really an SMP/E error, just an
unacceptable RC from the Binder​ due to the lack of some MODs being
INCLUDEd.

-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Allan Staller]

Sounds like a SMP/E Configuration error. Check the releted DDDEF's and the 
SYSLIB/CALLLIB concat.
Other SMP/E error messages?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, May 24, 2018 3:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

Message below, with attached output, was reject by the Listserv because it had 
too many lines (>1000)

-- Forwarded message -
From: John McKown <john.archie.mck...@gmail.com>
Date: Thu, May 24, 2018 at 3:19 PM
Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.
To: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu>


On Thu, May 24, 2018 at 2:55 PM Longabaugh, Robert E < 
robert.longaba...@ca.com> wrote:

> You can do a LIST MOD(modname) XREF to find the load modules that a
> given module resides in.
>

​Thanks. On the specific MOD that I'm looking at, it does indeed show that
IRRCSU00 is referenced by IRRENV00. On the running system, IRRCSU00 is indeed 
within IRRENV00 (according to AMBLIST). Likewise, if I do a LIST LMOD on 
IRRENV00, the MOD IRRCSU00 shows up. But on the APPLY output,
IRRENV00 fails to link properly because IRRCSU00 is "SYMBOL IRRCSU00 
UNRESOLVED.  MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY"
​. Other IRR* modules also get that messages. All the MODs which do _not_ get 
the message have an INCLUDE AOSBN(module) shown in the Binder output.
So, somehow, it appears to me that IRRCSU00, et al., should have a similar 
INCLUDE AOSBN(IRRCSU00) statement given to the Binder, but it does not.

​ ​
I have attached a .txt file to this email which shows the Binder output from 
the APPLY (just for this one LMOD) along with the LIST LMOD() XREF output. 
Hopefully it won't get stripped out by the list server.
​ ​

 >I'm going to do a complete disk-level restore of the target system

> >(sandbox).
>
> And the Global zone as well, I hope. Otherwise you will have a global
> out of sync with the target zone.
>

​Yes, I will restore _all_ the dedicated z/OS SMPE volumes.​ They contain all 
of the SMPE datasets & distribution data sets. I will revert to being in the 
state I was in before I did the APPLY.



>
> >I had a number Sx37 abends which may be the main problem.
> >Perhaps resizing those libraries (after disk restoration) will solve
> >this problem.
>
> Not likely, IMO.
>
> --
> Tom Marchant
>
>
--
Once a government places vague notions of public safety and security above the 
preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown


--
Once a government places vague notions of public safety and security above the 
preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

-

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Paul Gilmartin]

On Thu, 24 May 2018 12:55:01 -0500, Tom Marchant wrote:
>
>>OK, y'all probably know that I'm on a very back level system -- z/OS 1.12
>>and we're even back level on maintenance. I'm trying to get more up to
>>date, mainly for "fun & profit". Anyway. There are a number of RACF modules
>>which were hit and SMP/E tries to relink them. The problem seems to be that
>>some CSECTs are missing in the relink.
>
>Was this something that happened during the APPLY of a PTF?
>Did the PTF include JCLIN?
>What MCS statements are in the PTF?
> 
There's also the effect of the ++MOD CSECT(...) option to consider.
If CSECT() is absent, the default is the name of the MOD element.
ISPF SMP/E panels might show this.

Can you create a disposable instance of your CSI (Shmuel insists
that includes PDSes)?  In that do a ++DELETE of your load module
and re-install the JCLIN to create it and note what happens.

>AFAIK, normal behavior of SMP/E when applying a PTF that contains a 
>replacement ++MOD is that all LMODs that contain that module are relinked. 
>The original load module (or program object) is included, and the module 
>from the PTF is included. In this way, all of the CSECTs in the load module 
>are retained, and the one supplied by the PTF replaces the original.
>
>>They are in the LMOD in the running
>>LINKLIB. In the output, I see the binder output which tries to relink the
>>module. I see the missing CSECTs. The CSECTs which are not missing are have
>>Binder " INCLUDE AOSBN(csect)" in the binder's input stream. The CSECTs
>>which are needed are in AOSBN properly, but there is no INCLUDE for them.
>>
Are there any REPLACE commands in the listed SYSLIN?  These are a consequence
of the ++LMOD CSECT() option.

>>I've never had anything like this happen before. I've been looking around
>>in the current SMP/E manual and I _might_ be able to "fix" all the LMOD
>>entries using UCLIN. But this seems to be dangerous to me.
>
>I wouldn't do that.
>
>>Any suggestions other than a stiff shot of something "nice" and "soothing"?
>
>PMR.
>
Against 1.12?  John's last idea is more promising.

-- gil

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Edward Gould]

> 
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
> John McKown <john.archie.mck...@gmail.com>
> Sent: Thursday, May 24, 2018 10:14 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.
> 
> OK, y'all probably know that I'm on a very back level system -- z/OS 1.12
> and we're even back level on maintenance. I'm trying to get more up to
> date, mainly for "fun & profit". Anyway. There are a number of RACF modules
> which were hit and SMP/E tries to relink them. The problem seems to be that
> some CSECTs are missing in the relink. They are in the LMOD in the running
> LINKLIB. In the output, I see the binder output which tries to relink the
> module. I see the missing CSECTs. The CSECTs which are not missing are have
> Binder " INCLUDE AOSBN(csect)" in the binder's input stream. The CSECTs
> which are needed are in AOSBN properly, but there is no INCLUDE for them.
> 
> I've never had anything like this happen before. I've been looking around
> in the current SMP/E manual and I _might_ be able to "fix" all the LMOD
> entries using UCLIN. But this seems to be dangerous to me.
> 
> Any suggestions other than a stiff shot of something "nice" and "soothing"?
> 
> --
> Once a government places vague notions of public safety and security above
> the preservation of freedom, a general loss of liberty is sure to follow.
> 
> GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)
> 
> 
> Maranatha! <><
> John McKown

John,
Long ago and far away I think I had something similar to your issue.
After a lot of research (we kept all SMPE output) IBM was surprised and a 
little pissed as we had hardcopy proof. IIRC it was an issue with with IPO (yes 
that old) building process. My memory is stretched here but I think IBM quietly 
put out a replacement for most of the DLIB (that was the problem). It was I 
think about 30 or so modules. There was a note in the PMR about it but it is so 
long ago, frankly I have forgotten a lot of the specifics. It is worth 
following up on, IMO.

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[John McKown]

URL to a Github "gist" with the output that the Listserv rejected.

https://gist.github.com/JohnArchieMckown/20d995cce8e2f201a4cf9725c4932092

On Thu, May 24, 2018 at 3:30 PM Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 24 May 2018 15:58:54 -0400, John Eells wrote:
>
> >Tom Marchant wrote:
> >> On Thu, 24 May 2018 13:30:20 -0500, John McKown wrote:
> >>
> >>> On Thu, May 24, 2018 at 12:40 PM Seymour J Metz 
> wrote:
> >>>
>  Have you looked at the MOD entries for the missing csects?
> >>>
> >>> ​Yes, they look correct to me. The entries for each MOD (missing & not
> >>> missing) points to AOSBN as where it resides.​
> >>
> >> That's fine, but what LMODS are listed as containing those MODs?
> >>
> >
> >It's the MOD entries that have subentries for the LMODs in which they
> >are included.
>
> Right. That's what I meant. When a MOD is listed, part of that data is a
> list of LMODs the module is linked into.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Tom Marchant]

On Thu, 24 May 2018 15:58:54 -0400, John Eells wrote:

>Tom Marchant wrote:
>> On Thu, 24 May 2018 13:30:20 -0500, John McKown wrote:
>>
>>> On Thu, May 24, 2018 at 12:40 PM Seymour J Metz  wrote:
>>>
 Have you looked at the MOD entries for the missing csects?
>>>
>>> ​Yes, they look correct to me. The entries for each MOD (missing & not
>>> missing) points to AOSBN as where it resides.​
>>
>> That's fine, but what LMODS are listed as containing those MODs?
>>
>
>It's the MOD entries that have subentries for the LMODs in which they
>are included.

Right. That's what I meant. When a MOD is listed, part of that data is a 
list of LMODs the module is linked into.

-- 
Tom Marchant

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

Fwd: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[John McKown]

Message below, with attached output, was reject by the Listserv because it
had too many lines (>1000)

-- Forwarded message -
From: John McKown <john.archie.mck...@gmail.com>
Date: Thu, May 24, 2018 at 3:19 PM
Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing
CSECTs.
To: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu>


On Thu, May 24, 2018 at 2:55 PM Longabaugh, Robert E <
robert.longaba...@ca.com> wrote:

> You can do a LIST MOD(modname) XREF to find the load modules that a given
> module resides in.
>

​Thanks. On the specific MOD that I'm looking at, it does indeed show that
IRRCSU00 is referenced by IRRENV00. On the running system, IRRCSU00 is
indeed within IRRENV00 (according to AMBLIST). Likewise, if I do a LIST
LMOD on IRRENV00, the MOD IRRCSU00 shows up. But on the APPLY output,
IRRENV00 fails to link properly because IRRCSU00 is "SYMBOL IRRCSU00
UNRESOLVED.  MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY"
​. Other IRR* modules also get that messages. All the MODs which do _not_
get the message have an INCLUDE AOSBN(module) shown in the Binder output.
So, somehow, it appears to me that IRRCSU00, et al., should have a similar
INCLUDE AOSBN(IRRCSU00) statement given to the Binder, but it does not.

​ ​
I have attached a .txt file to this email which shows the Binder output
from the APPLY (just for this one LMOD) along with the LIST LMOD() XREF
output. Hopefully it won't get stripped out by the list server.
​ ​

 >I'm going to do a complete disk-level restore of the target system

> >(sandbox).
>
> And the Global zone as well, I hope. Otherwise you will have a global out
> of sync with the target zone.
>

​Yes, I will restore _all_ the dedicated z/OS SMPE volumes.​ They contain
all of the SMPE datasets & distribution data sets. I will revert to being
in the state I was in before I did the APPLY.



>
> >I had a number Sx37 abends which may be the main problem.
> >Perhaps resizing those libraries (after disk restoration) will solve
> >this problem.
>
> Not likely, IMO.
>
> --
> Tom Marchant
>
>
-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown


-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[John Eells]

Tom Marchant wrote:

On Thu, 24 May 2018 13:30:20 -0500, John McKown wrote:


On Thu, May 24, 2018 at 12:40 PM Seymour J Metz  wrote:


Have you looked at the MOD entries for the missing csects?


​Yes, they look correct to me. The entries for each MOD (missing & not
missing) points to AOSBN as where it resides.​


That's fine, but what LMODS are listed as containing those MODs?



It's the MOD entries that have subentries for the LMODs in which they 
are included.  So, let's assume for the moment that none of the members 
of AOSBN are packaged as ++PROGRAMs, which would not be relevant in this 
context.  You have to LIST the MODs for all the members of AOSBN to see 
which target library load modules and program objects are made up using 
one or more of the MODs from that DLIB data set.  Note that those load 
modules and program objects thus identified might also include MODs that 
represent members from other DLIB data sets.


Probably more to the point, if you want to know which MODs are 
associated with a particular LMOD, then LIST LMOD(name) XREF will tell 
you.  Each of those MODs can point to a different DLIB data set; it's 
not unusual for a load module to include MODs from several different 
DLIB data sets.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Longabaugh, Robert E]

You can do a LIST MOD(modname) XREF to find the load modules that a given 
module resides in.


Example:

SET BDY(CAIT0) .
LIST MOD(V37ALLOC) XREF .

Output shows that the module is in several load modules, none of which match 
the module name.

  NAME  



V37ALLOC  LASTUPD = RO97974  TYPE=UPD   

  LIBRARIES   = DISTLIB=ACTVMOD0

  FMID= CCTVC50 

  RMID= RO97974 

  LMOD= V37BTL00  V37BTL01  V37BTL02  V37BTL03  V37BTL04  
V37BTL05  V37BTL06  V37BTL07  V37BTL08
V37BTL09  V37BTL10  V37BTL11  V37BTL12  

  SYSMOD HISTORY  = SYSMOD   TYPE   DATE   MCS   -- 
STATUS --   
CCTVC50  FUNCTION  13.330  MODULEAPP

RO20699  PTF   13.330  MODULEAPP

RO44774  PTF   13.330  MODULEAPP

TR84363  APAR  15.265  MODULEAPP

RO84363  PTF   15.267  MODULEAPP

RO85335  PTF   15.323  MODULEAPP

RO97974  PTF   17.268  MODULEAPP


Doing the reverse and listing an LMOD will show the modules that it needs.  It 
does not show the physical presence of the modules, just the status in the CSI.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, May 24, 2018 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.



On Thu, 24 May 2018 13:35:06 -0500, John McKown wrote:

>I'm going to do a complete disk-level restore of the target system 
>(sandbox).

And the Global zone as well, I hope. Otherwise you will have a global out of 
sync with the target zone.

>I had a number Sx37 abends which may be the main problem.
>Perhaps resizing those libraries (after disk restoration) will solve 
>this problem.

Not likely, IMO.

--
Tom Marchant

--
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: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Tom Marchant]

On Thu, 24 May 2018 13:35:06 -0500, John McKown wrote:

>I'm going to do a complete disk-level restore of the target system
>(sandbox).

And the Global zone as well, I hope. Otherwise you will have a global 
out of sync with the target zone.

>I had a number Sx37 abends which may be the main problem.
>Perhaps resizing those libraries (after disk restoration) will solve this
>problem.

Not likely, IMO.

-- 
Tom Marchant

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Tom Marchant]

On Thu, 24 May 2018 13:30:20 -0500, John McKown wrote:

>On Thu, May 24, 2018 at 12:40 PM Seymour J Metz  wrote:
>
>> Have you looked at the MOD entries for the missing csects?
>
>​Yes, they look correct to me. The entries for each MOD (missing & not
>missing) points to AOSBN as where it resides.​

That's fine, but what LMODS are listed as containing those MODs?

-- 
Tom Marchant

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[John Eells]

A MOD entry represents a member of a DLIB data set.  Each DLIB data set 
member may contain one or more sections, like CSECTs.  (Those CSECTs 
residing in a particular DLIB member might or might not be known to 
SMP/E, depending on how the product was packaged.  But SMP/E really acts 
on the MODs.)  To create a load module (in a PDS) or a bound program 
object (in a PDSE), one or more MODs are included to create the output 
member.  Which ones are included is specified using LMOD keywords on the 
++MOD statement and JCLIN for "linkedit" steps, and the LMODs in which a 
MOD is included are stored in its MOD entry.


Now you have load module (or PO, but for convenience just load module 
hereafter) in a target library.  When an FMID has been applied and 
accepted without any of its PTFs, the sections in the load module are 
identical to the content of included DLIB members.


Now, you put on a PTF that affects one of the MODs but not all of the 
MODs in the load module.  If SMP/E included all of the MODs from the 
DLIB, and the new MOD in the PTF, that would be OK...the first time. 
But now, a second PTF comes along.  It affects a different MOD in the 
load module.  If SMP/E includes the MODs from the DLIBs and the new MOD 
from the PTF, it will regress the first MOD's content in the load 
module.  We hate it when this happens.


So SMP/E instead cleverly includes the new MOD from the PTF and the load 
module from the target library instead.  This reuses the other content 
of the load module and prevents regression.


Does that answer your question?

Finally, if you are missing CSECTs in the output load module that were 
present in the input load module after installation some PTFs, and they 
were not explicitly deleted in the PTF packaging, Something Is Very 
Wrong.  What it might be is difficult to say without more information.


John McKown wrote:


​No, but why would IBM do INCLUDE statements for some MODS but not others
in the same distribution library (AOSBN)?​






​Yeap. I did all that. There is a CALLLIBS for SCEELKED and a SYSLIB for
LINKLIB. What seems missing to me are the LKED "INCLUDE AOSBN(csect)"
statements. There are some a number of those for other CSECTs. But none for
the missing CSECTs. To my way of thinking, if you INCLUDE some MODS from
AOSBN, then it is reasonable to INCLUDE other, used, MODS which are
refereced and exist in AOSBN. And the "missing" CSECTs are indeed in the
target zone with AOSBN as the library in which they reside.​


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Allan Staller]

++ DEL action holds?

Normal SMPE action is "include smpwrk(new module)"
  "include original load module"
  "name(load module) replace"


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, May 24, 2018 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Thu, May 24, 2018 at 12:40 PM Seymour J Metz <sme...@gmu.edu> wrote:

> Did you do anything equivalent to NCAL?
>

​No, but why would IBM do INCLUDE statements for some MODS but not others in 
the same distribution library (AOSBN)?​



>
> Have you looked at the MOD entries for the missing csects?
>

​Yes, they look correct to me. The entries for each MOD (missing & not
missing) points to AOSBN as where it resides.​



>
> Have you looked at the LMOD entry?
> CALL?
> CALLLIBS?
> NOCALL?
>

​Yeap. I did all that. There is a CALLLIBS for SCEELKED and a SYSLIB for 
LINKLIB. What seems missing to me are the LKED "INCLUDE AOSBN(csect)"
statements. There are some a number of those for other CSECTs. But none for the 
missing CSECTs. To my way of thinking, if you INCLUDE some MODS from AOSBN, 
then it is reasonable to INCLUDE other, used, MODS which are refereced and 
exist in AOSBN. And the "missing" CSECTs are indeed in the target zone with 
AOSBN as the library in which they reside.​



>
>
> --
> Shmuel (Seymour J.) Metz
> https://apac01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.
> gmu.edu%2F~smetz3=02%7C01%7Callan.staller%40HCL.COM%7C2b4701f7858
> b43677c1708d5c1a479f0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636
> 627834556113168=1wKt0vGfixpwBNQcjJroWl6LXVu4aqmBUXz8zLfE2%2Fc%3D
> =0
>

--
Once a government places vague notions of public safety and security above the 
preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

--
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: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[John McKown]

Thanks to all. After all this work, my boss has informed me that everything
I have done is unnecessary. I was looking at this to stage up to our
(hopefully) getting a z12BC and a new version of z/OS (probably the lowest
version which can still be ordered "to minimize changes"). Of course, a big
problem might be lack of compatibility PTFs on 1.12 versus 2.n . In any
case, I'm going to do a complete disk-level restore of the target system
(sandbox). I had a number Sx37 abends which may be the main problem.
Perhaps resizing those libraries (after disk restoration) will solve this
problem.

On Thu, May 24, 2018 at 12:55 PM Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 24 May 2018 09:14:20 -0500, John McKown wrote:
>
> >OK, y'all probably know that I'm on a very back level system -- z/OS 1.12
> >and we're even back level on maintenance. I'm trying to get more up to
> >date, mainly for "fun & profit". Anyway. There are a number of RACF
> modules
> >which were hit and SMP/E tries to relink them. The problem seems to be
> that
> >some CSECTs are missing in the relink.
>
> Was this something that happened during the APPLY of a PTF?
> Did the PTF include JCLIN?
> What MCS statements are in the PTF?
>
> AFAIK, normal behavior of SMP/E when applying a PTF that contains a
> replacement ++MOD is that all LMODs that contain that module are relinked.
> The original load module (or program object) is included, and the module
> from the PTF is included. In this way, all of the CSECTs in the load
> module
> are retained, and the one supplied by the PTF replaces the original.
>
> >They are in the LMOD in the running
> >LINKLIB. In the output, I see the binder output which tries to relink the
> >module. I see the missing CSECTs. The CSECTs which are not missing are
> have
> >Binder " INCLUDE AOSBN(csect)" in the binder's input stream. The CSECTs
> >which are needed are in AOSBN properly, but there is no INCLUDE for them.
> >
> >I've never had anything like this happen before. I've been looking around
> >in the current SMP/E manual and I _might_ be able to "fix" all the LMOD
> >entries using UCLIN. But this seems to be dangerous to me.
>
> I wouldn't do that.
>
> >Any suggestions other than a stiff shot of something "nice" and
> "soothing"?
>
> PMR.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[John McKown]

On Thu, May 24, 2018 at 12:40 PM Seymour J Metz  wrote:

> Did you do anything equivalent to NCAL?
>

​No, but why would IBM do INCLUDE statements for some MODS but not others
in the same distribution library (AOSBN)?​



>
> Have you looked at the MOD entries for the missing csects?
>

​Yes, they look correct to me. The entries for each MOD (missing & not
missing) points to AOSBN as where it resides.​



>
> Have you looked at the LMOD entry?
> CALL?
> CALLLIBS?
> NOCALL?
>

​Yeap. I did all that. There is a CALLLIBS for SCEELKED and a SYSLIB for
LINKLIB. What seems missing to me are the LKED "INCLUDE AOSBN(csect)"
statements. There are some a number of those for other CSECTs. But none for
the missing CSECTs. To my way of thinking, if you INCLUDE some MODS from
AOSBN, then it is reasonable to INCLUDE other, used, MODS which are
refereced and exist in AOSBN. And the "missing" CSECTs are indeed in the
target zone with AOSBN as the library in which they reside.​



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

-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Tom Marchant]

On Thu, 24 May 2018 09:14:20 -0500, John McKown wrote:

>OK, y'all probably know that I'm on a very back level system -- z/OS 1.12
>and we're even back level on maintenance. I'm trying to get more up to
>date, mainly for "fun & profit". Anyway. There are a number of RACF modules
>which were hit and SMP/E tries to relink them. The problem seems to be that
>some CSECTs are missing in the relink.

Was this something that happened during the APPLY of a PTF?
Did the PTF include JCLIN?
What MCS statements are in the PTF?

AFAIK, normal behavior of SMP/E when applying a PTF that contains a 
replacement ++MOD is that all LMODs that contain that module are relinked. 
The original load module (or program object) is included, and the module 
from the PTF is included. In this way, all of the CSECTs in the load module 
are retained, and the one supplied by the PTF replaces the original.

>They are in the LMOD in the running
>LINKLIB. In the output, I see the binder output which tries to relink the
>module. I see the missing CSECTs. The CSECTs which are not missing are have
>Binder " INCLUDE AOSBN(csect)" in the binder's input stream. The CSECTs
>which are needed are in AOSBN properly, but there is no INCLUDE for them.
>
>I've never had anything like this happen before. I've been looking around
>in the current SMP/E manual and I _might_ be able to "fix" all the LMOD
>entries using UCLIN. But this seems to be dangerous to me.

I wouldn't do that.

>Any suggestions other than a stiff shot of something "nice" and "soothing"?

PMR.

-- 
Tom Marchant

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

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Seymour J Metz]

Did you do anything equivalent to NCAL?

Have you looked at the MOD entries for the missing csects? 

Have you looked at the LMOD entry?
CALL?
CALLLIBS?
NOCALL?


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
John McKown <john.archie.mck...@gmail.com>
Sent: Thursday, May 24, 2018 10:14 AM
To: IBM-MAIN@listserv.ua.edu
Subject: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

OK, y'all probably know that I'm on a very back level system -- z/OS 1.12
and we're even back level on maintenance. I'm trying to get more up to
date, mainly for "fun & profit". Anyway. There are a number of RACF modules
which were hit and SMP/E tries to relink them. The problem seems to be that
some CSECTs are missing in the relink. They are in the LMOD in the running
LINKLIB. In the output, I see the binder output which tries to relink the
module. I see the missing CSECTs. The CSECTs which are not missing are have
Binder " INCLUDE AOSBN(csect)" in the binder's input stream. The CSECTs
which are needed are in AOSBN properly, but there is no INCLUDE for them.

I've never had anything like this happen before. I've been looking around
in the current SMP/E manual and I _might_ be able to "fix" all the LMOD
entries using UCLIN. But this seems to be dangerous to me.

Any suggestions other than a stiff shot of something "nice" and "soothing"?

--
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

[SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[John McKown]

OK, y'all probably know that I'm on a very back level system -- z/OS 1.12
and we're even back level on maintenance. I'm trying to get more up to
date, mainly for "fun & profit". Anyway. There are a number of RACF modules
which were hit and SMP/E tries to relink them. The problem seems to be that
some CSECTs are missing in the relink. They are in the LMOD in the running
LINKLIB. In the output, I see the binder output which tries to relink the
module. I see the missing CSECTs. The CSECTs which are not missing are have
Binder " INCLUDE AOSBN(csect)" in the binder's input stream. The CSECTs
which are needed are in AOSBN properly, but there is no INCLUDE for them.

I've never had anything like this happen before. I've been looking around
in the current SMP/E manual and I _might_ be able to "fix" all the LMOD
entries using UCLIN. But this seems to be dangerous to me.

Any suggestions other than a stiff shot of something "nice" and "soothing"?

-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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