Endevor

  • 1.  BSTXCOPY - Is this trip really necessary?

    Posted Oct 22, 2018 09:54 AM

    So I was presented with a challenge the other day.... how to select a member that may be anywhere in a concatenation list of PDS' and then use the first-found member in that list. In other words, the functionality of JCLLIB concatenation of PROCs but for use in-stream such as a SYSIN statement for a sort step or any other parameter file used in JCL.

     

    The challenge is that IBM hasn't extended the functionality delivered with JCLLIB into other potential areas. And you cannot concatenate PDS' in an IEBCOPY job... it only wants one. 

     

    BUT our dear friend Endevor comes to the rescue with BSTXCOPY. You CAN concatenate PDS' on the input side and it WILL look through them in the concatenate order to find the member that matches the name you provide. Yay! 

     

    However, after giving the necessary instructions to my user, he got back to me saying it would not work with the generic batch userid they use for jobs because it didn't have access to Endevor. It worked fine with his userid though. 

     

    So after turning on ESITRACE, I determined that BSTXCOPY (because it runs under NDVRC1) is checking the userid for access to environments before allowing the utility to run against specified libraries. 

     

    Does this not seem unnecessary? I understand the workaround is to create a batch userid security profile, but....

     

    Opinions and thoughts welcome!  



  • 2.  Re: BSTXCOPY - Is this trip really necessary?

    Broadcom Employee
    Posted Oct 23, 2018 04:19 AM

    John

     

    Just to mention that, although IEBCOPY will indeed not read from a concatenated DD, it can still use multiple input DD's by:

     COPY OUTDD=OUT,                        X

                INDD=(DD1,DD2,DD3,........)

     

    IEBCOPY will look for the selected member(s) in the ddnames spacified in the INDD= parameter in the specified order and, once it finds the member in one of them, it will not continue searching. This might fulfill your needs, as far as you don't need dozens of input files.

     

    About BSTXCOPY, what happens to it is that it is just a re-packaging of processor utility BSTCOPY together with a stub that performs endevor initialization so that the utility can run. For this reason, it needs C1DEFLTS and all the endevor stuff, including security, although it is certainly not going to use much of it.

     

    You could setup a dedicated C1DEFLTS module to be used only by BSTXCOPY. This C1DEFLTS would only need to define a dummy environment and catalog dataset. No ACM files, no ESI, no exits, NO ALTERNATE ID (extremely important) and so on. This C1DEFLTS would allow any user to run BSTXCOPY to process whatever datasets he could access (as the table does not have alternate ID).

     

    Regards - Eduard



  • 3.  Re: BSTXCOPY - Is this trip really necessary?

    Posted Oct 25, 2018 10:25 AM

    Hey John

    I use Fileaid with Lmap

    //IFMOVE IF (&C1ACTION = MOVE) THEN                     
    //DD01     DD  DSN=&DBRMLIB1,DISP=SHR,                  
    //             ALLOC=LMAP                               
    //IFMOVE  ELSE                                          
    //DD01     DD  DSN=&DBRMLIB,DISP=SHR,                   
    //             MONITOR=COMPONENTS,ALLOC=LMAP            

     

    K.