Endevor Version Description in Batch Output

[MELVYN JACOBS]

Hi all

 

I'm testing an upgrade from 15.1 to 16  . . .  and when I test an element move with this (Steplib/Conlib are R16 libraries)

 

//ENDES000 EXEC PGM=NDVRC1,

//             DYNAMNBR=1500,

//             PARM='C1BM3000'

//STEPLIB  DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQAUTU

//                 DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQAUTH

//CONLIB   DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQLOAD

 

the output has => VERSION 16.0 SERIAL B1600C

 

 

When I test an ELIB format with this (same library concatenation)

 

//ELIBINIT  EXEC PGM=NDVRC1,PARM='BC1PNLIB',COND=(0,NE)

//STEPLIB  DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQAUTU

//                 DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQAUTH

//CONLIB   DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQLOAD

//**

 

The output shows => VERSION 15.1  SERIAL B1501C

 

 

- so , should I be worried ? Is this expected ?  Normally I expect to see all Endevor activity "labelled" or referencing the version I am running under.

 

Thanks

[SBAshby]

You really need to check first that something hasn't happened to link list or something as this doesn't seem correct.

Do you realise that V16 goes out of support in June of this year?

Stuart

[MELVYN JACOBS]

Yes I know, I wanted to go to 17, but someone else with a bigger say wanted 16  . . .

 

anyway  . . . just wondered if anyone else gets what I get - comparing R15 & R16 load modules for BC1PNLIB, they are different ;  Footprint report indicates load R16 load module comes from CA R16 repo . . .

[Anon Anon]

Hello,

 

I would recommend executing BC1PNLIB with the following:

 

//ELIB2INT  EXEC PGM=BC1PNLIB

//STEPLIB   DD DSN=***..xxxxx.CSIQLOAD,DISP=SHR

//          DD DSN=***.xxxxx.CSIQAUTH,DISP=SHR

 

If problem still persists I would recommend opening a case with the Endevor Support team

[MELVYN JACOBS]

same result - R15 & R16 load modules look different, R16 load module seems to come from CA R16 repo (looking at Footprint report), so maybe something to do with the version header in that program,  . . . just makes me a tad nervous about anything that may not actually be R16 . . .

[Anon Anon]

Hello Mjacobs,

 

You should go into Endevor and do a footprint display of your CSIQLOAD library.

 

Locate BC1PNLIB and select option I Display load module and footprint

For release 16   the footprint time and date is 08FEB13

for release 15.1 the footprint time and date is 17MAY12

 

What do you see?

[MELVYN JACOBS]

          `     Thx, answer is 08FEB13 - I had already done a Footprint report of the library, which shows BC1PNLIB (& everything else) coming from SYSTEM = ESCM160 SUBSYSTEM = GA with that date. I have an open case with CA . . .

[MELVYN JACOBS]

We solved it - we were testing R16 with

 

//STEPLIB DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQAUTU

//                DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQAUTH

//CONLIB DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQLOAD

 

we changed to

 

//STEPLIB DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQAUTU

//               DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQAUTH

//               DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQLOAD

 

as all 3 libs are authorised & linklisted in R15.1

 

 

 

 

 

 

 

 

 

 

 

 

[SBAshby]

So the CONLIB DDname was the root cause?

[MELVYN JACOBS]

yep - tho' I'm still working thru the exact nature of it all with CA . . . it's also seemingly related to the invocation type (NDVRC1 or direct) . . .

[Eoin OCleirigh]

Hi mjacobs1.1

 

This is one of the challenges when working two two versions of Endevor at the same time.  Obviously only one version can be in the LinkList, the challenge is that Endevor will search the STEPLIB/JOBLIB/LINKLIST/LPA before CONLIB.  So if the V15.1 version is found in the Linklist, that will be loaded ahead of the version in Conlib.  Most often running with mixed releases will lead to "incompatible" table messages so it's quick to spot.  When you run utilities that can run outside Endevor(like BC1PNLIB) , then you may get further and the symptoms are less obvious.

 

The solution you found (adding the .CSIQLOAD to the STEPLIB (and doing the same for your TSO Logon procs) will work so long as all libraries in that concatenation are authorised.

 

The other fix (if you don't like Authorizing .CSIQLOAD) is to remove the .CSIQLOAD from the LINKLIST so that these modules are only found via the CONLIB DD - but you may have to revisit your 15.1 Logon Procs and/or SCMM@LIB members to make sure that they do have the CONLIB set correctly.

 

In the end the main trade-offs are performance for flexability.  Letting Endevor run from Linklist can give an overall performance benefit, but at the cost of increased complexity when managing multiple versions.  Many sites will only have this issue in their "sand-box" or test LPAR.  An on the production LPARs, if you're lucky, you only need to run one version (but I know that's not true for several sites )

 

Thanks for sharing.

Eoin

[MELVYN JACOBS]

Hi Eoin, nice to hear from you, been a - long - while . . .

 

for R16 testing we're going with fully authorised

 

//STEPLIB DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQAUTU

//              DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQAUTH

//              DD DISP=SHR,DSN=SYS1.ENDEVOR1.CSIQLOAD

 

 

 

tho' I'm wondering, for where we have this (in ISPF skeletons in our automated migration process)

 

//RETROLST EXEC PGM=NDVRC1,DYNAMNBR=1500,

//      PARM='CONCALL,DDN:CONLIB,BC1PCSV0'

 

 

 

 

 

 

 

and don't have a CONLIB DD (because the library is in STEPLIB), does this matter ?

 

 

fyi - the reply I had from CA was that if using pgm=NDVRC1 then CONLIB was searched ahead of linklist (at least that's the way it read to us), but that differed from my testing, so I've asked CA for clarification

 

cheers

 

Melvyn

[Eoin OCleirigh]

Sorry mjacobs1.1,

 

I should have seen this earlier - and now I see the question, I'm wondering if my assumptions are correct.  It may well be that if you specify the CONCALL request and don't have CONLIB allocated that Endevor will just attempt to load the module from the standard search order.  To test this I might create a handful of simple DISPALY UPON CONSOLE or WTO programs and place them in STEPLIB, ISPLLIB, LINKLIST LPAETC. and where each one differs only in the message it writes (e.g. "Hello World - from STEPLIB", or "HELLO WORLD from ISPLLIB" etc.) Each "version" of the program would have the same name - then run your test using CONCALL and see which message you get.

 

It's worth noting that running from STEPLIB (or TSO Logon Proc) is not quite the same as running from LinkList, LPA etc. and sometimes it does take a bit of investigative work to determine where a particular module is being loaded from - if you have the luxury of being able to 'play' in a sand-pit environment, you could rename the module to "exclude" it from the search temporarily and see if that changes your results.