New BSTXCOPY utility avavilable to copy PDS to PDSe outside of Endevor

[Roberta Jones]

BSTXCOPY UTILITY

 

BSTXCOPY is a new CA Endevor utility which performs the same functions as BSTCOPY. BSTCOPY is a processor utility and can only be executed within a CA Endevor Processor.  BSTXCOPY is an external version of this processor utility.  This utility is only available for Endevor r15.1, 16.0 and v17 via PTF. Below you will find a link for each version to the PTF.  

 

Endevor 15.1 RO75104

Endevor 16.0 Solution   RO75068

Endevor 17.0 Solution RO75121

 

BSTXCOPY can be used to copy between PDS load libraries and PDSE load libraries, from PDSE to PDSE, and from PDSE back to PDS. BSTXCOPY can copy aliases but the original loadlib member must be present in the FROM library.  The input syntax and restrictions are documented in the Extended Processor Guide, under Using Processor Utilities:  Section BSTCOPY.

 

The following JCL shows how to execute this utility. The first library in the STEPLIB contains the Endevor site specific modules (C1DEFLTS, ENDICNFG etc.):

 

//COPYEX EXEC PGM=BSTXOPY

//STEPLIB DD DISP=SHR,DSN=YOUR.ENDEVOR.CSIQAUTU                   

//                DD DISP=SHR,DSN=YOUR.ENDEVOR.CSIQAUTH                         

//                DD DISP=SHR,DSN=YOUR.ENDEVOR.CSIQLOAD                         

//SYSPRINT DD SYSOUT=*

//SYSUT3   DD UNIT=VIO,SPACE=(CYL,(1,2))                               

//SYSUT4   DD UNIT=VIO,SPACE=(CYL,(1,2))                              

//IND1     DD DISP=(OLD,PASS),DSN=YOUR.PDS.LOADLIB (PDS)                 

//IND2     DD DISP=(OLD,PASS),DSN=YOUR.PDS.LOADLIB (PDS)               

//OUTDD    DD DISP=(OLD,PASS),DSN=YOUR.NEW.PDSE.LOADLIB  (PDSE)

//SYSIN    DD *

COPY INDD=((IND1,R)),OUTDD=OUTDD                                      

   COPY INDD=((IND2,R)),OUTDD=OUTDD                                        

   

                  

 

              

[June Abercrombie]

Hi Roberta,

  Does BSTXCOPY maintain the Endevor Footprint when LOADLIB members are copied from a PDS to a PDSE?

 

June

[Roberta Jones]

Yes june .. We requested this because of the conversion that is needed for cool 5.x ... It's awesome and actually works!

 

Sent from my iPad

[SBAshby]

Hi Roberta,

 

Is there any practical advantage to setting an alias for BSTXCOPY in PDSMan?

We currently alias BSTCOPY in PDSMan for performance reasons.

 

Stuart

[Emlyn Williams]

Hi Roberta, We currently use BC1PNCPY for this, what is the advantage of using BSTXCOPY over BC1PNCPY?

 

Emlyn

[Roberta Jones]

Emlyn -

 

The new BSTXCOPY is the ONLY Endevor Utility that can be run outside of Endevor for the conversion of PDS Loadlibs to PDSe Loadlibs.  It copies Loadmodules with Aliases and the Endevor Footprint (*loadmod).  This was a TOP Requested DAR by multiple customers for years.  Since the new release of COBOL requires that you use PDSe loadlibs, this to was

created.

 

Hope this answers your question.

Roberta

[Anon Anon]

How does this relate to FASTCOPY?  Is there a way we can set up aliases on some combination of IEBCOPY / BSTCOPY / FASTCOPY / BSTXCOPY (in PDSMan??) so that BSTXCOPY is used where necessary to ensure that footprints are maintained, but FASTCOPY is used otherwise?

[Richard Rozentals]

Hi Charles,

If you use BSTXCOPY it will copy the loads(with footprints) and the alias members. You can't use 1 utility for alias members and another for loads unless you want to make this a 2 pass process.

Basically BSTXCOPY should be used whenever  you have loads that are footprinted and you are doing a copy from a PDS to PDSE, PDSE to PDSE or PDSE to PDS. FASTCOPY would be used whenever the member is not a load.

 

Does this answer your question?

Richard

[Anon Anon]

Not entirely - I was hoping that I might be able to configure things (for example) within PDSMan / EzyEdit so that when I do a "C" against a member to copy it to another library that it would use BSTXCOPY where necessary, and FASTCOPY if the BSTXCOPY functionality is not required.

 

It is a similar sort of question to that asked by Stuart Ashby above, which I don't think really got answered

 

Cheers

 

Charles

[Richard Rozentals]

It can't do that. The intent of BSTXCOPY is a utility to copy PDS to PDSE as a one time thing. So a one time conversion from PDS to PDSE.

It's not intended to replace/enhance FASTCOPY.

 

Richard

[Anon Anon]

The challenge is that, unless you adopt a "big bang" approach, which will either be not technically feasible, or feasible but very risky, you end end with some datasets which are PDS's and some file which are PDSE's, and until you access them, you don't know which they are.

 

For example, you may choose to convert all you PDS load libraries to PDSE's by stage, or by environment, or development first then Production (or vice versa)

 

The net result is that you will be doing one of the following without easily knowing which:

 

PDS ==> PDS

PDSE ==> PDSE

PDS ==> PDSE

PDSE ==> PDS

 

Ideally you want a mechanism which copes with all four scenarios, preserving Endevor footprints, without having to worry more about it (I appreciate that it is not always possible to copy a member from PDSE to PDS)

 

If BSTXCOPY can't support this, on an ongoing basis, then it only looks like half a solution

[Richard Rozentals]

Both BSTCOPY and BSTXCOPY will copy members. It will do it in all cases as above. The functionality it will not provide is being able to swap to FASTCOPY when it's appropriate.

So what I'm saying is that you can always use BSTCOPY and/or BSTXCOPY to copy LOAD members.

It will not offer the functionality or performance as FASTCOPY. 

[Karen Turner]

Hi Charles,

How often are you copying endevor load modules outside endevor?  The functionality  to substitute PDSMAN/FASTCOPY for BSTCOPY  within endevor processors already exists (see extended processors guide under BSTCOPY), but only does so when copying btwn the same format (ie, pds to pds, or pdse to pdse, BSTCOPY is always used when copying from pds  load to pdse load).  Up until the existence of BSTXCOPY, a dummy BSTCOPY processor was the only way to convert an entire pds loadlib to PDSE without losing the *LOADMOD footprints.  Now with BSTXCOPY you can convert it "outside" endevor in a simple batch job.  BSTXCOPY is not a processor utility, but rather a standalone utility.  As Rich pointed out above, you can copy an entire loadlib or individual members, but it cannot swap to FASTCOPY via a $IEBCOPY statement like BSTCOPY can.

Karen

[Anon Anon]

Hi Karen,

 

Every time we do package shipment (at the remote side)

 

Cheers

 

Charles

[Karen Turner]

Point taken.  But unless the remote lpar is licensed for Endevor (as would be the case in our shop since we only have endevor one one lpar per sysplex), BSTCOPY/BSTXCOPY aren't available.

[Anon Anon]

As I understand it, there are some Endevor utilities which you are allowed to run even where Endevor is not installed - BC1PFOOT springs to mind.  I assume (and it is only an assumption) that BSTXCOPY would be another of these.

 

Otherwise, how are we going to convert all our Production load libraries (which are on a Sysplex that does not have Endevor installed on it) from PDS to PDSE, in preparation to supporting Enterprise Cobol 5.1 modules?

 

Maybe someone from CA could clarify?

 

It sounds as though the PDS to PDSE conversion will need to be synchronized between the Master versions of the files on Development and the Production copies of these files.

[Karen Turner]

That's an excellent point that someone from CA will have to address. 

[Craig Fontaine]

Yes, you can execute it on an LPAR without Endevor installed. You may get an informational message that certain actions are prohibited (run from non-authorized library) , but it will run.

[Steve Blackett]

A couple of notes, the example posted by Roberta (thread author) has a typo in the name - it's
BSTXCOPY (not BSTXOPY) - if that's pasted from a manual then that needs fixing too.

 

The steplib troubles me as it mixes authorise d and non authorised datasets together. I thought the
CSIQLOAD would be under a CONLIB. If you're LINKLISTED of course you wouldn't need the STEPLIB anyway.

 

Noting when I run this as so:

-->

//COPYALL EXEC PGM=BSTXCOPY

 

I see the informational message:

+C1G0700I PROGRAM NDVRC1 WAS FOUND NOT TO BE AUTHORIZED                    

+C1G0701I ALTERNATE ID, ACMQ, ESI, ELEMENT AND PACKAGE PROCESSING DISABLED

 

I understand this is because BSTXCOPY is calling NDVRC1 and the authorisation is "getting lost"

 

You can remove the message by running this:

-->

//COPYALL EXEC PGM=NDVRC1,PARM=BSTXCOPY

 

Is anyone using PDSE type 2 for LOADMODS - I see differences in them when using this utility to copy from PDSE type 1 and haven't done any proper investigation yet.

[Josef Thaler]

We started using PDSE version 2 libraries for some test-environments, after I had asked CA technical Support in a support case and had gotten the following answer:

 

• "No reported problems with PDS/E version 2. No expected problems. Difference with PDS/E is in internal processing. PDS/E version 1 API's are documented by IBM to behave in the same way with Version 2. See issue activity for Details."

 

We did not yet have negative observations so far, but if you detect differences between PDSE Version 1 and 2, please let it be checked by technical support.  

[Eoin OCleirigh]

We probably need mccpe01 or Rose.Sakach to weigh in here for the definitive answer.  The Remote Footprint facility while it does not technically require a full Endevor install still has Licensing restrictions that limit where it may be used.  BSTXCOPY might come under a similar restriction.  But while we wait for an official answer, you can always transfer the files to be converted back to a platform that has the tools installed and working - in the end it might depend on your level of confidence that the 'objects' on the remote machine are (still) the same as the ones you shipped.  If that confidence level is high, just convert the 'local' ones and ship the converted libraries.  one challenge (as Steve (SteveBlackett) pointed out) when modules are"copied" by BSTXCOPY they may not compare equal (e.g. SuperC will indicate the files are not the same).  It might just be date and time stamps updated by the linker, or conversion from PDSE(1) to PDSE(2) but the challenge remains do you trust them, and/or how do you test? 

[Anon Anon]

Eoin,

 

If you "just convert the 'local' ones" (to PDSE) and ship the converted libraries, doesn't this mean that the shipment process will detect PDSE's and create temporary PDSE's for the temporary local and remote shipment datasets?  And use either IDCAMS REPRO or (more likely) FASTCOPY to do the remote copy to the (still) PDS library?

 

Doesn't this then create 2 potential problems?:

 

1) Your Cobol compile may have created an executable which has to live in a PDSE rather than a PDS and so the remote copy will fail

2) Using FASTCOPY to do the remote copy (which will almost certainly fall back to IEBCOPY if it needs to do a PDSE to PDS conversion) will mean that the footprint isn't preserved in the load module at the remote site.

 

Surely, you have to convert both the local and the remote ("Production") libraries at the same time to avoid these problems - which may be easier said than done?

 

As you say, guidance from mccpe01 or Rose.Sakach would be welcomed!

[dan.w.little]

Hi

 

When can we expect a clear answer from CA on the licensing of BSTXCOPY? 

I expect many customers may encounter a situation where they need this in the non-Endevor systems. 

Eoin suggested that mccpe01 or Rose.Sakach could answer this.

 

Dan

[Steve Blackett]

Roberta,

 

I mistakenly copied a PDSE to a PDS via fastcopy and the LLA refresh didn't take place (guessing due to dataset differences) - it issued a 0 CC, but a info message:

 

FCO117I FAMS-1 IS BEING USED FOR THIS OPERATION

 

For the BTXCOPY utility will it perform an LLA refresh in the same way that fastcopy does (if you use it correctly)?

 

Steve.

[June Abercrombie]

Hi Steve,

  From everything I have checked, the answer is No - it will not do an LLA Refresh

 

June

[Anon Anon]

June,

 

Do you know if PDSMan will do an LLA refresh if the FASTCOPY is from PDSE to PDSE (assuming that the name of the dataset is one that PDSMan is monitoring)?

[Phontilla Shuffitt]

So I implemented the BSTXCOPY Utility while I am running under V16 release of Endevor by downloading the PTF.

 

I am in the process of setting up Applicaton Code Promotion processes to copy from an Endevor shipment library to the real application execution libraries.  Is this utility a one and done process to support a PDS to PDSE conversion only, or can it be used on a regular basis to support my code promotion process?

 

Looking for recommedations from my Endevor network and CA of course.

 

Thank you,

Phon

[Anon Anon]

Couple of things:

 

When you look at the physical PDSE member, you will find that it contains the name of the original PDS whence it was copied, and also the userid of the person that ran the BSTXCOPY.  Not sure if this is intentional, or whether it's a good thing or not.

 

You can use program PDSM36 (part of PDSMan) to do compares of the PDS and PDSE load libraries, to check that they are the same, with the following parameter:

 

PARM='/SUMMARY,IGNMATCH,IGNDIR'

 

However, a couple of times this has identified "false positives", identifying a one-byte change where actually the contents were "the same".  Not sure if this is a problem with BSTXCOPY, or PDSM36.

[Richard Rozentals]

Hi,

You are correct. The BSTXCOPY will change the userid/date in the load. You can see this when you browse it. The reason is that the BSTXCOPY uses the BINDER (Linker) to do the copy. This is so it can copy/re-add the footprints in the CSECTs.

[Phontilla Shuffitt]

By the way I had an issue opened with CA and Richard was actually the support technician that helped me with it.  So as a reminder to everyone this utility should only be used to support the copy of LOAD Libraries from PDS to PDSE or PDSE to PDSE.

 

Thank you,

Phon

[Richard Rozentals]

Phone is correct.

The utility BSTXCOPY was created only to copy LOADS. It's intent was to deal with the changes between PDS and PDSE loads for the new version of COBOL. BSTXCOPY is not intended to replace IEBCOPY or any other utility.

 

Source or non LOAD members have a simpler footprint that does not require a conversion.  This footprint is stored in the directory entry. It can't be done this way for loads as the directory information has information describing how the load was linked. So the directory information for a load is fixed and is mandatory. The directory information for a source (normal member) is not fixed. It can be formatted for ISPF, blank or  as Endevor does footprint data. 

 

In the footprint manuals it gives you hints how load footprints are done in PDS and PDSE loads.  The section titled "Footprints and Load Libraries" in the footprint manual (for v16/v17) talks about the footprints in loads for PDS members. For PDSE look for the section titled "Footprints and PDS/E Load Libraries".  PDS load footprints use IDR data(ZAPIDR record) for each CSECT. For PDSE the footprints are stored in the IDRU records for each CSECT. 

 

So the BSTXCOPY will read the IDR data and convert it to the IDRU data using the IEWBIND programming interface.

 

Remember the BSTXCOPY should be used when you copy an entire PDS loadlib to a PDSE loadlib, or if you copy a PDSE to PDS loadlib. If you don't the footprinting data will be lost.

 

As for the compare. A record to record compare will always show differences. That is unless you do some sort of formatted compare to exclude differences caused by  IEWBIND.

 

Richard

[Steve Blackett]

Charles,

The testing I ran I also saw differences in the load modules via a standard 3.13 comparison.

Does it make a difference if the original elements were footprinted? Does the footprint "move" in the copied loadmodule?

 

I'll use your parms for some more testing - thanks

Btw, I have seen PDSMan will do an LLA refresh if the FASTCOPY is from PDSE to PDSE

 

Steve