On Thu, 9 Nov 2006 12:24:22 -0600, Brian Peterson
<[EMAIL PROTECTED]> wrote:
>Talk about doing things the "hard way"....!! Here's some ideas you might
>consider. You probably already thought of them - if so, sorry!
>...
One person's "hard" is another's "fun". I haven't had a hands-on fight
with SMP for several years and am really enjoying this. (Yup. I'm sick!)
This is the way I learn.
>...
>1) Order a new copy of the product. Perform your own RECEIVE from the
>original copy of the product. This is the "start from scratch" option.
Parallel channel. Our contract people were already chewing on this,
trying to make sure we wouldn't be ordering a new license. As I was
writing this I got word that the order has gone in. (I guess I'm glad.)
But I still want to know what went wrong here.
>...
>2) Define new Target and DLIB SMP/E CSI and Target and DLIB data sets.
>Attach this new, empty, Target and DLIB zone to the Global zone which has
>the product RECEIVEd into. ...
>
>The only objection I can imagine to option 2 would be religious, not
>rational, on the part of the MVS sysprogs.
Religious and political. That is a very rational solution, and would
work well. I''l suggest it, but I suspect I know the response.
>...
>I wouldn't attempt to reengineer the product's packaging in the way you
>apparently attempted. Life's too short!
As you can tell from my comments above, I look at this differently. The
fact that I ran into this problem tells me I don't understand SMP (as if
that surprises anybody!). The fact that only 2 modules had problems says
either I had a reasonable grasp on what I was doing or I was VERY lucky.
More of the later than the former, I fear.
A little more digging, very obvious digging that I should have done right
off the bat, showed me part of what was wrong ... and uncovered a glaring
hole in my understanding of SMP. I looked at the JCLIN (duh!) and saw
/*
//********************************************************************
//** STEP 15 **
//** **
//** MVS utility IEBCOPY will be used to COPY these two LMODs **
//** from the installation tape into a Target Library. **
//** These LMODs don't LINKEDIT well, and need to be copied **
//** to ensure an overall return code of 00 for SMP/E **
//** installation processing on this FMID. **
//** **
//** TARGLIB - SYS1.NVULIB **
//** DISTLIB - SYS1.ANVULIB **
//********************************************************************
//STEP15 EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=A
//NVULIB DD DSN=SYS1.NVULIB,DISP=SHR
//ANVULIB DD DSN=SYS1.ANVULIB,DISP=SHR
//SYSIN DD *
COPY INDD=ANVULIB,OUTDD=NVULIB
SELECT M=CNMVLC
SELECT M=CNMNVLC
/*
So why did SMP link it? Obviously it couldn't do the copy in the JCLIN
because there's noting in the DLIB until ACCEPT, but why didn't it copy
from the TXLIB. It obviously found the module in the TXLIB because that's
what it linked. Previous steps in the JCLIN had specified linking into
NVULIB. Does that make SMP always link into that library, regardless
what later JCLIN says?
Pat O'Keefe
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
