Path Codes and Object Storage

A path code points to a set of objects, therefore a path code definition must associate a set of C components in a directory path with a set of object specifications. In this diagram, you can see how path codes are used to point to both replicated objects on workstations and enterprise servers as well as central objects on the deployment server.

This diagram illustrates the relationship between path codes and object storage:

Path Codes and Object Storage using TAM.

Path Codes and Object Storage using XML.

The different deployments by releases are:

Deployment in 9.2.0:
- Deployment Server Files “source of truth” exist in path code (include/source) folder
  - Files copy with OMW actions (Check-out/in and Transfer)
  - ESU application Package Build uses files from deployment server path code to copy to PACKAGE build folders.
Deployment in 9.2.1: Files to the Database
- With package build, files are placed in archives and stored in repository as "source of truth."
- Files are no longer stored on the deployment server path code folder as "source of truth."
- Files still exist on the deployment server and still copied with OMW and ESU application.
- Must build a full package to populate archive repository.
Deployment in 9.2.3: 64-bit available
- 64-bit conversion possible (source/include and source64/include64)
- Package Build - bitness defined by foundation.
- Code converts if 64-bit path code and build is the first time.
  - 64-bit flag on path code is not set
  - NER generated for bitness of foundation
  - NER does not update source/include (32/64) in database
  - 32-bit NER source/include "could" remain in repository
  - NER spec not needed to be converted to 64-bit - stored as spec only in archive
  - 64-bit development client still develops in 32-bit source
  - OMW check-in and ESU converts 32-bit to 64-bit and stores in archive repository
- NER stopped storing all include/source in the database repository.
- One-Click stopped delivering source files in the deployment server for any path code including planner.
- Must build a full package to create archives and extract from database to compile.
Deployment in 9.2.4: 64-bit Deployment Server Supported
- SMT9.2.4.0X64 Special Migration Tools required.
- 64-bit planner available along with ESU changes.
- ESUs (and Change Assistant) - 64-bit does not apply (copy) source files to deployment server.
- If 32-bit applied, source files get copied to path code directory on deployment server.
- Package Build - updates NER BSFN source only on deployment.
  - If delta detected between repository and files in path code folder.
- Must build a full package to create archives and maintain 32-bit to 64-bit conversion.
Deployment in 9.2.4.3: Package Build – No longer copies files to deployment server path codes
- Package build stopped copying (C or NER) source32/64 or include32/64 from the package directory to the in path code source32/64 and include32/64 directories.
- User Spec Tables created in central objects data source when Tools Rollup ESU and ASI applied to path code.
Deployment in 9.2.5: Remove E1Local Database (E1LOCAL DB)
- No local databases (Pkg Spec or Local) for clients.
  
  Must build a full package since E1Local DB is no longer built into the package.
- Client Only Packages removed – must include server in build.
- Web Package Define, Build and Deploy Options available.
  
  New service available on Deployment Server to build client portion of packages.
- Package Build - No longer updates bin32/64 or lib32/64 in path code or creates E1Local DB.
  
  Package Build creates Serialized Object Tables (F989999 and F989998) for each new full package.
- OMW no longer copies C BSFN files to deployment server, sends files only to repository tables.
- OMW provides web transfer option for spec based objects. Files are no longer copied on deployment server between path codes for project status changes.
- Files in deployment server path code folder are obsolete.