Long name support in Endevor

[Philip Gineo]

Hi, Does anyone have any words of wisdom regarding long name support in Endevor?  You're feedback would be greatly appreciated!  Thanks, Phil

[David James]

Hi Phil

 

Endevor does a very poor job of supporting long element names

You basically cannot use any of the screens. you can kind of display the elements but the names are bracketed and you cannot use any of the line commands

 

CA decided you can only use Eclipse and a plug-in to work with long element names but I think this was a very poor decision

 

You can use the batch functions, but you have to manually code the SCL

 

Unless you want to come up with some type of hash system to get the names down to 8 characters, you cannot use a normal PDS / PDSE library to store the members, they have to be located in a USS path.

CA recommends using a USS path for the base but the delta can be in a normal PDS/PDSE

 

If you have batch jobs that parse reports, Endevor will put the long element name on one line and the rest of the information on the next line (as opposed to all the information on one line)

If you use CVS files, there is a long element name field but the element name will be bracketed

[Philip Gineo]

Thanks David this is very helpful  Are you using site symbolics for the USS path?

[David James]

Phil

 

You have to use site symbolics for the base name unless you use all caps for the path name, the type screen does not allow small letters

 

I am using some site symbolics, I standardized the path names to use Endevor symbolics whenever I could

[Philip Gineo]

Thanks for the info on site symbolics!  Does this look pretty close for the type definition:

 

[David James]

A few differences

DELTA FORMAT(F/R/I/L) ===> I

For binary files, CA recommends using Image delta format ( the forward and reverse is more for source code types), we are only managing the binary JAR file, not the source code

 

SOURCE LEN   ===> 13992

USS files do not have the concept of record length. So having a small record length can confuse the system. I used 13992 based on what I read in the manuals (one half a 3390 block size plus overhead)

 

COMPARE TO   ===> 13992

Same as above

 

REGRESSION   ===> 00

I do not remember the reason for this but I had to have gotten it out of the manuals

 

David

[SBAshby]

Hi Phil,

 

I would go with log delta format rather than reverse if you are storing binaries.

It will save a lot of space compared to image.

 

Stuart

[Eoin OCleirigh]

Hi Phil/David,

 

We (CA) are aware of the limitations of LongName support today and this area is under active review.  We have an FDP (Field Developed Program) called the LongName utility that provides a proto-type LongName support in a QuickEdit like environment if you are interested, please let me know.

Some customers are also making use of the Enterprise Workbench (CMEW) as a method to support LongNames in Endevor today, but this product has been stabilized.  One correction I'd like to point out is that the CSV utility does return the true long name (it is not bracketed) in fact this is how the LongName utility works.

There are a couple of other ideas/discussions you should also check out for more information - seeEndevor QE Widescreen Support and Endevor should support ALL valid Longnames and Paths.

 

Thanks Phil for sharing Type definition appropriate for Binary types, but if you are managing ASCII or other text formats - then you may want to set the DataFormat as Text to allow ASCII/EBCDIC translation as needed.

I'd also recommend reviewing the ENUSSUTL processor utility to help you manage the LongName elements once they are in Endevor, for example to support; Package processing, backout, Shipping etc.

 

Regards,

Eoin