Performance and Tuning
Forward and Reverse Delta Format
Select full-Image delta format for machine-generated code, USS binary executables, or any source code where the compare is inappropriate. Change levels are not kept for Full-Image deltas, only full images of each level (like GDGs) are stored; therefore, full-image delta types can require more DASD.
Forward and reverse deltas let you manage the changes made to an element, and they have the same performance characteristics in terms of storage. The difference is in what
CA Endevorconsiders to be the base level.
- For forward deltas, the base element is the original code, and the delta levels correspond to the changes made to that code. When you want a copy of the latest version of an element,CA Endevorhas to merge the base and delta levels using the CONWRITE utility.Forward deltas are useful when elements are relatively stable, because when the element is saved,CA Endevoronly writes the changes to a file and does not rewrite the full source text.
- For reverse deltas, the base element is the current copy of the code, and the delta levels contain the information needed to return the element to its original form. When you want a copy of the latest version of an element,CA Endevor(or any other program) can ignore the delta levels and simply read the base element. This behavior also improves processor performance, becauseCA Endevordoes not need to invoke the CONWRITE utility to rebuild the element.Reverse deltas are useful when you are compiling an element frequently, becauseCA Endevordoes not have to merge in the delta files. However, when an element is saved,CA Endevorhas to replace the entire base level in addition to saving the changes in the delta library.
Backout processing requires a source output library that cannot be the same data set as the reverse delta base library.
The following table summarizes the forward and reverse delta formats.
I/O operations needed-read
I/O operations needed-write
Use for elements that:
Are updated more than read
Are in production.
Normally needed a source output library but do not need to be backed out. These files need to be kept in a standard format (such as a PDS) for utilities such as Advantage CA File Master.
For more information about the conversion process, see Converting Delta Formats.
Delta Level Management
CA Endevorprovides three methods to consolidate delta levels: Automated Element Level Versioning, Auto Consolidation, and Aged Delta Retention. Automated Element Level Versioning is the default. This method is also used with the other two methods, both of which are optional. Aged Delta Retention is managed at the system level; the others are managed at the type level. These methods are summarized in the following table:
Delta Level Management Method
Level Where Implemented
Automated Element Level Versioning
Up to 9996 delta levels are retained.
You set the number of levels to be retained up to a maximum 96 levels.
You set the number of levels that are consolidated when the number of levels to be retained is reached.
Aged Delta Retention
You set the number of months that delta levels are retained up to a maximum 999 months.
Automated Element Level Versioning
Automated Element Level Versioning limits delta levels to 9996 and is activated at the Type level.
For each Type to be activated, navigate to the Type Definition panel in foreground and set AUTO CONSOL to N and LVLS TO CONSOL to 0. If you were not previously using Auto Consolidation, and had not changed these fields, these values are already set. Alternatively, run the Batch Admin DEFINE TYPE action to set these field values for each Type to be activated.
With Auto Consolidation turned off, you may eventually run out of levels or accumulate more levels than you really need. If consolidation is disabled and an Add, Update, Move, or Transfer action results in a level number greater than 9999, the action is terminated with message SMGR176E. In this case, you could manually remove levels from the Element by transferring it to another location, deleting the Element from the source location, and transferring it back to the original source location.
Element Delta Consolidation Method
Auto-consolidation is implemented by type and lets you specify the physical level threshold at which the consolidation process is initiated and the number of physical levels to consolidate when the threshold is met. The maximum number of levels you can keep is 96.
Element data consolidation consists of the following two functions:
- Consolidation level (CONSOL AT LVL)Specifies when the consolidation process is initiated. This is the maximum number of physical levels you want stored on the system. For example, the CONSOL AT LVL parameter is set to 96. When the physical number of levels reaches 97,CA Endevorbegins the consolidation process.For the most efficient level consolidation across environments, set this parameter to the maximum value of 96.
- Number of levels to consolidate (LVLS TO CONSOL)Specifies the number of physical levels to consolidate when the threshold is met. For example, suppose the LVLS TO CONSOL parameter is set to 25, and the CONSOL AT LVL (consolidation trigger) is set to 96. An element in Production is at the maximum level 0196, and vvll 0197 is about to be moved in. Before saving the 97th level,CA Endevordoes the following:
vvllvalue until the number of physical levels specified on CONSOL AT LVL is reached.Using the same consolidation values as in the prior example, suppose an element atvvll0194 is retrieved from the production stage for modification. When it is added back intoCA Endevorat a lower stage, level 0194 is fetched back for compare and level 0195 is created. The level number is 95, but the number of physical levels is two-- 0194 and 0195. For auto consolidation to be triggered in this lower stage, 94 more changes would have to be made to get up to 96 physical levels. Auto versioning comes into play whenvvll0199 is reached, the next change would roll over to 0200, then 0201 and so on until 0290 is reached (0194+96=0290), should one more change be attempted auto consolidation would be triggered causing the lower 25 levels, 0195 through 0220, to become a new 0195, and levels 0221 through 0290 to be renumbered accordingly.Determine the maximum and minimum number of levels you want to store on the system. Using these values, you can calculate the number of levels to consolidate (LVLS TO CONSOL). The maximum value is specified in the consolidate level (CONSOL AT LVL) field. The minimum value is only used for calculation purposes. The difference between the maximum value and the minimum value is the number of levels to consolidate (LVLS TO CONSOL).Maximum level (CONSOL AT LVL)-- Minimum levelLevels to consolidate (LVLS TO CONSOL)The larger the number of levels you retain, the longer it takesCA Endevorto rebuild, because each delta level requires additional I/O operations.Verify the parameter values match for the same element type across differentCA Endevorlocations.
- Merges levels 01 through 25 together to create a single delta level (level 01)
- Renumbers the remaining levels to 02 through 72:CONSOL AT LVL + 1 97-- LVLS TO CONSOL: -- 25Minimum level 72
For more information about the type definition fields LVLS TO CONSOL and CONSOL AT LEVEL, see Defining Inventory Structures.
Aged Delta Retention Method
The Aged Delta Retention method lets you set the number of months that delta levels are retained. The maximum retention limit is 999 months. This option is inactive by default and is set on each system definition in foreground or batch. It can be set for elements, components, or both, and overrides any consolidation levels set on all type definitions in that system. This method is invoked only at the end of the mapped system location route.
When auto age level retention is set, change levels for all types in the system expire after the number of months that are specified on the system definition. The base element or component is rebuilt to reflect the changes from the deleted levels, with the base delta version and level numbers set to the last discarded version and level. The delta format you are using, reverse, forward, or full image, determines how the consolidated level is built. For reverse and full image deltas, change levels that expire are dropped. For forward deltas, change levels that expire are incorporated into the base.
Setting the age retention limits in the system definitions, to indicate how long delta levels are kept, turns on the Age Level Retention feature. You can examine what effect this will have on elements and components by using the Age-Managed Delta utility, in examine mode, to see which delta levels have expired.
Delta removal occurs at the first modification of the elements or components after turning on the Age Level Retention feature.
Example: Aged Delta Retention
In this example, the delta levels are set to expire after five months, and the element is changed and moved through the lifecycle as follows:
- The element that is named ELEMENT1 is added to stage 1 of the Test environment from stage 2 of the Production environment. The highest level of the element in stage 2 of the Production environment, which is 0103, is fetched to stage 1 of the Test environment.
- The element is updated in stage 1, Test, four times over a ten-month period. Each time the element is saved, a new level is created with the level number incremented by 01. So that after the element is saved four times, the new levels are 0104, 0105, 0106, and 0107.
- The element is moved with history to stage 2, Test. All the levels in stage 1, Test (0103, 0104, 0105, 0106, and 0107) are included in the move.
- The element is moved with history to stage 2 of the Production environment. Auto-age level retention is triggered because the element has reached the end of the map and some of the element levels are older than the five-month retention period. The result of the move with history to stage 2, Production, depends on the delta format as described next:If reverse delta(the base is a full copy of the current code):
If forward delta(the base is a full copy of the original code):
- Levels 1 thru 4 are removed, because they are older than 5 months.
- Level 4 becomes the new base level 00.
- A new base delta record is created reflecting level 4 with the following modifications:
- All level 4 change statements are removed.
- Insert and delete record counts are set to zero.
If full image delta
- Base is re-built to contain change levels 1 through 4, because they are older than 5 months.
- Level 4 becomes the new base level 00.
- A new base delta record is created. The base level 0 record reflects level 4 with the following modifications:
- All level 4 change statements are removed.
- Insert and delete record counts are set to zero.
- Levels 1 through 4 are removed, because they are older than 5 months. The full image deltas for level 0 through level 3 are deleted.
- A new base level record is created. The base level 0 record reflects level 4.
Regardless of the delta level format, the delta main control record (the first record in the file) is updated to reflect the new base level. In this example, level 4 is made into the new base level 0. The base record count, date, and time fields reflect level 4.The last level value and record count reflect level 4. The last level date and time fields are set to blanks.
The following chart illustrates this example and shows how delta levels are incremented and consolidated using the auto age delta retention feature.
Env: Test Stg: 1
Env: Test Stg: 2
Env: Prod Stg: 2
ELEMENT1 exists with 3 levels:
First add of ELEMENT1 causes a fetch of (0103) with a new delta level to record changes.
Delta Age Retention is active and set to 5 months. Changes are made over a 10-month period.
Delta management is not done because the element has not reached the end of its route.
Results of Move with history:
Results of Move with history: Delta management is triggered, because levels 1 thru 4 are older than the 5 month retention limit.
*In this example, at the end of the map, if the level format is:
- reverse delta, then levels 1 thru 4 are removed. Level 4 becomes the new base level 00.
- forward delta, then the base is re-built to contain change levels 1 thru 4. Level 4 becomes the new base level 00.
- full image delta, then levels 1 thru 4 are removed.
Implement Age Level Retention
To retain delta levels for a specific number of months, you can activate the Age Level Retention feature for each system in your environment. This action can help you to meet record keeping requirements for your organization or regulatory requirements. To activate this delta level management method in foreground, you can update the system definition through the online environment update facility. You can activate Age Level Retention for elements, components, or both.
By default, the age delta level retention options on all the system definitions are turned off for both elements and components. The default settings are ELEMENT=N and COMPONENT=N and the only allowable value for their corresponding RETAIN LVLS FOR fields is 0.
Follow these steps:
- On the System Request panel, select option U.The Update System Definition panel opens. The following options appear in on this panel in the AUTO AGE LEVEL RETENTION OPTIONS fields.
- (Optional) Set the ELEMENT option =Y.This activates Age Level Retention for elements of all types in the system.
- To specify how many months the element delta levels are retained, type the number of months in the RETAIN LVLS FOR field that appears next to the ELEMENT option. Allowable values are 1 to 999. The default is 999.Element delta levels are retained for the number of months specified, provided the ELEMENT option is set to Y.
- (Optional) Select Y for the COMPONENT option.This activates Age Level Retention for components of all types in the system.
- To specify how many months the element delta levels are retained, type the number of months in the RETAIN LVLS FOR field that appears next to the COMPONENT option. Allowable values are 1 to 999. The default is 999.Component delta levels are retained for the number of months specified, provided the COMPONENT option is set to Y.
After you set retention limits in the system definitions, you can examine what effect this will have on elements and components by using the Age-Managed Delta utility, in examine mode, to see which delta levels have expired.
Identify Old Delta Levels
You can identify aged element and component levels by running the BC1JRDLT utility. To identify old delta levels, edit JCL member BC1JRDLT in your installation's CSIQJCL data set to conform to your installation's standards, and then submit BC1JRDLT. The utility output report lists all elements and components that are older than the age limits set in the system definitions.
Mapping Multiple Environments
Before you implement
CA Endevor, determine the number of environments you need, and how the stages within those environments are connected. By examining your site requirements, you can build a software lifecycle that provides the most efficient path for your developers.
For example, the following diagram shows two environments (QA and PROD) with links between the first and second stage in each environment and another link between stages HOLD and PROD.
This model cannot be implemented using the basic
CA Endevorpathways, because you can only enter an environment through a single entry stage. If developers want to move an element from Stage HOLD to Stage PROD, they must use the TRANSFER action instead of the familiar MOVE action. To solve this problem, create Stage 2 to Stage 2 links by mapping the environments in the Defaults Table. Mapping lets you do the following:
- Create the logical equivalent of n stages.
- Provide developers with the ability to MOVE, ADD, and RETRIEVE elements between the linked stages.
- Create multiple entry points into a software lifecycle or join multiple lifecycles.
- Carry footprints and component lists across environments.
- Enforce Signin and Signout procedures across environments.
- Allow for copyback and integrity checking across environments.
Selecting a Library Type for Base and Delta Members
You can store your
CA Endevordata sets using PDS, PDS/E, ELIB (VSAM/BDAM), or CA Panvalet and CA Librarian.
Benefits and Drawbacks of Library Types
The following information lists the benefits and drawbacks of each library type:
- Provides a familiar and standard means of storage for the source.
- No installation issues.
- Members can be read by other utilities such as compilers.
- Directory overhead becomes inefficient if there are more than 3-4K+ members.
- Strict maintenance is required to prevent x37 abends.
- Low maintenance.
- Current technology.
- Members can be read by other utilities such as compilers.
- Benchmarks show that the performance is slower than PDS or ELIB.
- Does not allow EXCP processing.
- Low maintenance.
- Sophisticated set of utilities to manage the data sets.
- BDAM is more efficient for medium-sized directories, and VSAM is more efficient for large directories, than either PDS or PDS/E.
- Directory overhead routines are designed for many members, thereby increasing efficiency.
- You can allocate a VSAM ELIB across multiple volumes. If you initially allocate an ELIB data set across two volumes,CA Endevorhonors that allocation when ELIB expansion occurs. The expansion can be automatic when the page reserve limit is reached or explicitly performed by using BC1PNLIB. This is only for VSAM ELIB; BDAM ELIB must be allocated on a single volume.
- VSAM options can require many processing time.
- Utilities are required for expands, copies.
- Library members accessible only throughCA Endevor.
- CA Panvalet and CA LibrarianBenefits:
- Accommodates the site standard.
- Directory compression issues are eliminated.
- Source output file can be read directly by CA Panvalet and CA Librarian utilities.
- With CA Panvalet, conflicts arise withCA Endevorfootprint and comment information.
- Library members are only accessible through CA Panvalet, CA Librarian, or both.
Converting from One Library Type to Another
The BC1PNCPY utility copies data from one of the supported library formats to another supported format. This behavior lets you try different methods based on your site requirements. For example, copy a CA Panvalet library to a PDS, or copy a PDS to ELIB.
When a PDS load module is copied to a PDSE,
CA Endevorload module footprint information is retained only if the
CA Endevorprocessor utility BSTCOPY is used. Other utilities, such as IEBCOPY, cannot copy the *LOADMOD footprint. For more information, see TEC316937, How to Convert AllFusion Endevor Change Manager Load Libraries between PDS and PDSe Formats, on Broadcom Support.
CA L-Serv is a master started task that controls
CA EndevorVSAM files for Master Control Files (MCFs), packages, and ELIB (if you are using VSAM processing instead of BDAM processing). This task provides the following benefits:
- Allows for normal VSAM tuning.
- Reduces the number of file I/O operations such as opens, closes, verifies, enqueues, and dequeues.
- Provides the following standard services:
- Cross-system communications.
- Automatic job scheduling.
- Centralized logging facilities.
We recommend VSAM record level sharing (RLS) or CA L-Serv implementation to improve VSAM performance. For more information about RLS, see Using z/OS SYSPLEX VSAM Record Level Sharing (RLS) Support for MCFs and Package Data Set. For implementation information, see the
CA Common Services CA L-Serv Technical Bulletinat Broadcom Support.
Setting the RECBUFFSIZE Parameter
When you install CA L-Serv, set the RECBUFFSIZE parameter based on your site configuration. If you are using CA L-Serv to manage:
- Only MCFs and package data sets, set RECBUFFSIZE to 1 K (the size of the largest VSAM record in these files).
- ELIB VSAM files (with or without MCFs or packages), set RECBUFFSIZE to the block size of the largest library file being managed (typically 4 K).
If you are using Point in Time Recovery, set RECBUFFSIZE to 12 K.Internally,
CA Endevorblocks all non-VSAM Base/Delta records before writing to the journal files in 12 K increments.
Monitoring CA L-Serv Performance
The ongoing success of this feature requires periodic monitoring to ensure that optimal performance benefits are achieved. Monitor the system when the following changes occur:
- Any significant additionalCA Endevorload is added (for example, environments and elements).
- Any significantCA Endevordata set reconfiguration takes place (for example, splitting of Base/Delta's or changing from PDS to VSAM E-Lib).
- Any system hardware or software changes are made (for example, VTAM, CPU, or the operating system).
Evaluating Buffer Pool Usage
To see how well your buffer pools are being used, issue the DISPLAY BUFFERPOOL and DISPLAY STATISTICS SERVICE commands.
Displaying Information About the Communications Server
The DISPLAY command provides additional options to provide online information about Communication Server activity.
Using z/OS SYSPLEX VSAM Record Level Sharing (RLS) Support for MCFs and Package Data Set
VSAM record level sharing (RLS) extends the DFSMS/MVS storage hierarchy to support data sharing across multiple systems in a System/390 parallel Sysplex. This feature, available on all z/OS Sysplex systems, offers
CA Endevorthe performance and availability benefits of data sharing in a coupled-systems environment.
As a new data access mode, VSAM RLS allows multisystem access to a VSAM data set while ensuring cross-system locking and buffer invalidation. VSAM RLS uses z/OS coupling facility (CF) services to perform data set level locking, record locking, and data caching. VSAM RLS maintains data coherency at the control interval level. It uses CF caches as store-through caches; when a control interval of data is written, it is written to both the CF cache and to DASD. This ensures that a failure in the CF cache does not result in the loss of VSAM data.
The SMSVSAM server is a new system address space that is used for VSAM RLS. The data space that is associated with the server contains most of the VSAM control blocks and the system-wide buffer pool that is used for data sets opened for record-level sharing. SMSVSAM assumes responsibility for synchronizing this control block structure across the parallel Sysplex.
With VSAM RLS, multiple
CA Endevorsystems can directly access a shared VSAM data set, eliminating the need for Reserve/Release and Enqueues between
CA EndevorUsers or Batch Jobs to maintain the integrity of the
CA EndevorVSAM data sets. VSAM RLS provides for serialization and synchronization of data sets and cross-system caching. With VSAM RLS, multiple
CA EndevorUsers or Batch Jobs can have concurrent read/write access to
CA EndevorVSAM data sets.
A new attribute, LOG, defines a data set as recoverable or non-recoverable. Because
CA Endevordoes not use CICS compatible Recovery, Logging or Journaling, the LOG attribute must be set to LOG(NONE).
At OPEN time,
CA Endevordetermines if the file is defined with VSAM RLS support, and, if so,
CA Endevoropens the file with RLS.
System administration determines when RLS is used. Typically, this determination is made when the cluster is defined with the IDCAMS utility program.
Sample JCL to enable RLS support may be found in iprfx.iqual.CSIQJCL, member BC1JDRLS.
VSAM Record Level Sharing provides the following performance enhancements:
- The VSAM buffers for ALL jobs and/or TSO users are consolidated into the SMSVSAM address space, increasing the chance of a record being in memory
- The SYSPLEX Lock Manager provides record level, CI level and CA level locking between SYSPLEX systems
- Due to the first two enhancements,CA Endevoris able to bypass its own native Reserve/Release logic
- The I/O performance of the SMSVSAM address space and the SYSPLEX cache allows a significant reduction in the elapsed time required to do update I/Os.
We recommend that you use VSAM RLS or CA L-Serv.
CA Endevorprovides RLS support for Master Control Files (MCFs), the Element catalog and Element catalog index (EINDEX), and the package data set.
CA Endevorwith RLS-managed data sets, certain data set attributes must be used when allocating the VSAM cluster. As previously mentioned, LOG (NONE) must be part of the definition. Also, a share attribute of (1,3) must be part of the cluster definition.
Tuning Your Processors
When you are tuning your processors, consider the following points:
- Ensure that record formats (RECFMs), block sizes (BLKSIZEs), and logical record lengths (LRECLs) are specified correctly for the program being executed.The operating system provides the "System Determined BLKSIZE" facility, which selects the best block size for a data set (based on its RECFM, LRECL, and the track size DASD device) if it is allocated with BLKSIZE=0. You can use this facility with anyCA Endevordata sets except for linkage-editor data sets.
- Avoid recursive executions ofCA Endevorby using the CONWRITE utility to output other elements. For example, if your jobcards are stored in one file and need to be merged into every executable file, CONWRITE can perform this merge without re-invokingCA Endevor.
- Streamline processors by taking advantage of instream data (for example, DD *) and symbolics (for example, &C1SYSTEM). This step eliminates extra steps that may have been required in the past.
- Allocate all temporary sequential data sets with BC1PDSIN to ensure that they are available for other programs such as CONLIST. Allocate other data sets using traditional JCL statements for each step.
- Ensure that your JCL dispositions are properly coded to release data sets when appropriate (for example, use FREE=CLOSE).
- Delete outputs with CONDELE wherever possible.
Tuning Your Systems
When you are analyzing the general environment, consider the following points:
- Ensure that VSAM and all output libraries are properly located, maintained, and sized. Poorly tuned VSAM files can seriously degrade performance, so:
- Examine LISTCAT to analyze CA/CI splits, and reorganize if necessary.
- For highly accessed VSAM files, move the index to a cache device (remember to de-imbed the index first).
- Do not alter the attributes of the VSAM Master Control File (MCF) unless you are using CA L-Serv.
- Tune the physical placement and attributes of your files:
- Highly volatile files, such as those in development locations, perform better near the beginning of the string, while more stable files, such as those in production locations, can be located near the end of the string.
- Analyze how many files reside on a single pack, and how large they are. Split CA Endevor SCM files across multiple packs, and ensure that no other large files (such as the system catalog) share the pack.
- Ensure that your file allocations are the most efficient ones for your system.
- Consider deleting and reallocating processor outputs for major system regenerations.
- Process concurrently whenever possible. For example, if you want to recompile the entire system, specifying GEN ELEM A* K* and GEN ELEM L* Z* instead of GEN ELEM * lets the system process both halves simultaneously.
- Consider using other products to help improve library performance. For example, CA developers had an unload that required 90 minutes withCA Endevor. When they combinedCA Endevorwith two other CA products, Unicenter CA PMO and Unicenter CA QuickFetch, the unload took only 12 minutes. Unicenter CA PMO eliminates more than 90 percent of the directory search I/Os for libraries and PDSs, while Unicenter CA QuickFetch eliminates more than 90 percent of the fetch I/O for load modules in any managed program library.
- LRECL setting for variable block files:The output records from the compression routine CONCOMP3 can be larger than the input records when the input files contain binary data uploaded from other machines, or already compressed data (output from TRSMAIN).While it is not possible to predict the maximum increase in size of CONCOMP3 records, we have never seen a record increased by more than 1.6 times the size of the input record. Because the size of the output record depends on the input data, we can make predictions for specific input records, and suggest that you use the following recommendations for setting variable block files.
- Set the block size (BLKSIZE) for variable block files to 27998, which is half a 3390 DASD track. This setting size allows rapid I/O time and efficient space usage. The reason for this is that MVS puts as many records as possible in the buffer defined by the BLKSIZEs and only writes the block if the remaining space cannot hold the next record. If a BLKSIZE of 2550 is chosen, it holds a maximum of 2546 bytes; however, small BLKSIZEs are inefficient for disk use and also inefficient in I/O time.
- The logical record lengths (LRECLs) for variable block files should be at least 4 less than 27998 (that is, 27994). MVS uses what it needs and as long as the buffer allocation (LRECL'value) is large enough, it fits without problems or wasting space. There is no reason to reduce the LRECL to 255, for example. For variable or variable block files, the actual LRECL is unimportant. The LRECL does not define the length of the records. The actual size is defined in the records. The LRECL defines the maximum length of any one record. Consequently, setting a larger LRECL and BLKSIZE for variable block files is not a problem. As long as the LRECL is larger than the actual record, the record fits.
- For types that contain binary data, we recommend a VB LRECL of 2048 or less. This practice make source comparison perform more efficiently. The maximum LRECL is 13 K. This setting allows for a compression result twice as large as the input.
Virtual Inventory Configuration NoSource Option
Virtual Inventory Configurationfeature enables unchanged source code to be compiled and linked at a
CA Endevorinventory location without the requirement that the source code be copied back to that inventory area. This feature is triggered by the NoSource option on the Generate action, provided the element does not exist at the target location. NoSource can be specified on foreground or batch Generate actions. The C1BASELIB symbolic, which references the base type library, can still be used in your processor. The CONWRITE processor utility has been modified to solve the current source for the sourceless elements.
The elimination of the requirement to fetch back unchanged source code dramatically improves concurrent development productivity by reducing the possibility of out-of-sync changes being made to different copies of the same source code. For example, with this option, source code can be fetched back to a sandbox work area only when source changes are required. Another benefit is improved performance resulting from the elimination of the movement (fetch and promotion) of unchanged source code. In addition, virtual inventory configuration is used by the new Autogen action option to facilitate processing of Generate actions.
When NoSource is used, the target location coded in a Generate action contains the outputs created by the Generate processor. In addition, a
sourceless elementis created at the target. Because the element source is not fetched back to the target location, the MCF record for the element generated at the target identifies it as a sourceless element. The MCF element contains the last level timestamp of the upstream element. Base and deltas do not exist for sourceless elements, so these fields are blank in the MCF. When actions are performed against sourceless elements, the source from the next sourced element upstream from it will be used providing that the last level timestamps are equal.
How Virtual Inventory Configuration Works
For sourceless elements,
CA Endevoruses the next sourced element from up the map as the source for the generate processor. This is possible because
CA Endevorgenerate processors, for reverse and image delta elements, use the actual source type definition‘s base library data set name as the location of the element source. This library data set name is associated with the
CA Endevorsymbol known as C1BASELIB. Another way of extracting the source for an element in a processor, whether it is sourced or not, is to use the Conwrite processor utility. Conwrite is able to resolve the source for sourceless elements by looking upstream for the next sourced element.
Assuming that the element source is not at the target location and the element source is located up the map from the target, the effect of the Generate NoSource action is as follows:
- The element source is not fetched back to the target location from up the map.
- The first occurrence of the element up the map from the target location is used as input to the generate processor. This element source is used as follows:
- All target inventory C1 symbols are set with the element source inventory fields before doing the C1BASELIB substitution.
- The C1BASELIB symbol is set with the library base data set defined at the source location (up the map).
- After the C1BASELIB symbol is resolved, the target inventory C1 symbol is reset to the action's target inventory.
- After the Generate action completes, the targeted location coded in a Generate action contains the outputs created by the generate processor. The MCF element created at the target location contains data similar to a fetched back element except that the element base and delta name fields are blank and the record is marked as a sourceless element.
Elements with forward deltas must use the CONWRITE utility in their processors to rebuild the element source. This utility supports sourceless elements by using the actual source location from up the map to rebuild the element. Conwrite also supports forward and reverse deltas.