Hi, Has anyone used USS Base & Delta's for storing USS long named elements? Any tips or tricks that you can share? Thanks, Phil Gineo
Hello my longtime Endevor friend.
I have created Endevor BASE USS libraries and SOURCE libraries but the Delta can not be USS so it is a standard E-LIB. maybe because I was storing the source as Forward Delta Compressed format. I have just begun this journey so I am in no way any expert but thought I would toss out what I had encountered so far. My system programmer actually loaded the mount point I just gave him my names that I wanted to us. I defined the HLQ for the BASE/SOURCE in ESYMBOLS. I included in the Site Symbolic table the HLQ which includes the Environment/System/stage as Lower case names, then I used that SYMBOL in the TYPE definition:
SOURCE O/P LIBRARY,===>,&#GENUSS1.SOURCE
I have attached the information that I got from CA to help guide me in setting this process up as I am very newbie on USS.
Thanks so much Phon, I really appreciate your feedback!
As part of our implementation, long name support is rarely used but must be tested by most of our products. In some test Endevor instances, I've created USS Base libraries and use a PDSE for the Delta. I also used REVERSE setting in the Type definition.
Since the path of the BaseLib cannot be defined, I use the ESYMBOLS table and define a symbolic for EACH stage so I can know exactly where the directory structure is located.
The File System is unique for the Endevor instance so I make sure that the VSAM file is mounted after every IPL and the mount point is a ROOT using the symbolic structure as defined by the ESYMBOLS table.
I make sure that the permissions for the file system directories are set to 777 so that there isn't any impact through access, but I understand others may want to restrict that and provide the Endevor Altid with permission to access the directories (not sure how, but there it is).
There is really no trick to this EXCEPT you need a File System large enough to handle the amount of elements to be stored within.
This is awesome Bernie - thanks so much for the information!
Our base library site symbolic uses the stage, system, subsystem and type system symbolics. This way we only need one site symbolic, or maybe two to allow a little additional flexibility in how different types are configured, for the USS base directories. I prefer standardizing the USS directory names so that the only change from stage to stage is the stage name qualifier. This consistency facilitates auditing and automation. The DELTA are stored as usual in a PDSE. We require a JAVA package name and convert that to a subdirectory name where the source code is copied. A type JAR program element is a text file that identifies the JAR files to be created and the subdirectories containing the source code to be compiled. Each line of the text program element begins with the name of the binary JAR file being created followed by the subdirectories corresponding to JAVA packages that are compiled for creating that binary JAR file. The last line must create a binary JAR file whose name matches the name of the text program element. We only generate/compile in the entry stage, thus preserving the modified date on the moves. The developers should always move all of the JAVA source to production with the JAR files but they need the JAVA source to be in the entry stage to compile, so this is a somewhat inconvenient for them given the large number of JAVA program elements that are often required to create the JAR files.
The only package back outs I see are for the listings. There is no back out for the generated binary JAR files and I do not know how to create back outs for that. I do not think JAVA or compiler output (class file) back outs are useful, the only back out that would be useful are for the executable binary JAR files and the output source does not help.
Thanks so much Mathew, great info!
We use the USS file modified date to compare the files, so it's worth building a process that maintains the modified date through the lifecycle.
Regarding the information that Phon sent, it is important that you use the &#GENUSS1.SOURCE directory is used at runtime, the &#GENUSS1.BASE directory is where the element source resides and is not backed out when you back out a package.
Thanks for your feedback Emlyn!