Main Page

From intERPrise
(Redirected from Main Page)
Jump to navigationJump to search

intERPrise Naming Conventions and Coding Standards

V1.1 – APPROVED (23 January 2019)

Introduction & Background

It is important for all participants to understand and acknowledge that the architecture, especially the (database) components that will be delivered by TEMBO using AO, will by nature adhere to strictly enforced naming conventions and coding standards. Kindly review the graphic depiction http://www.i-nterprise.org/about.html of the intERPrise architecture carefully? This is a FOUNDATIONAL consideration.

Fundamental to the intERPrise architecture, is the ABSOLUTE implementation and enforcement of true data centricity (http://datacentricmanifesto.org/principles/) at the lowest possible layer within the DB2 for i database.

This means that ALL validations are enforced by way of *BEFORE triggers on the database and that entity relationships are enforced with the various available DB2 for i constraints. Secondary processing MAY be by way of *AFTER triggers, as optimal solution, where it makes sense.

Additionally, all participants should note that ABSOLUTE separation between the database and the rest of the application will be enforced. Any integration will occur at the I/O Services layer and above, implementing the provided standardized “Error Handling” processes. No deviation from this will be considered for inclusion in the standard public repository, unless formally adopted by the intERPrise standards committee.

All of the intERPrise database components (metadata repository {aka data dictionary}, validation rules repository, tables {aka physical files}, logical layer {aka logical files, indexes, views}, constraints, triggers, IO Services and Enterprise Services – a genuine “data-centric”, modern DB2 implementation that are “self-aware” and “self-enforcing”) are managed by AO in an integrated, cohesive manner. A copy of AO has been made available to the participating intERPrise developers – see Use of Adsero Optima.

All the IBM i source and resulting objects can however be managed manually, using standard IBM i functionality, without requiring AO. AO simply manages and enforces this in a cohesive, comprehensive and holistic fashion.

During the Synon 2E (S2E) “harvesting“ process all functional definitions are retrieved from the internal S2E files, and internal AO files are populated with relevant “harvested” information. This is particularly important to acknowledge with regards to ANY validations found within the S2E models and action diagrams.

All data validations found within the S2E models are stored in the AO Validation rules Repository.

An additional consideration in all intERPrise provided components is how best to leverage ILE, RPG IV, DB2 for i and standard IBM i functionality (such as *MSGF, *USRSPC, *USRIDX, Pointers, subsystems, etc.), combined with developer productivity. This immediately place short data (aka internal) names on the agenda. Most heritage developers are intimately familiar with the naming conventions in use for the past 30+ (actually since the announcement of CPF and the System/38 in 1978) years and this naming scheme has served most well.

Underlying this entire issue though, is the fact that IBM i enforces a 10 character HARD limit on ANY object name. See https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rbam6/rbam6objnamrules.htm for more detail, if in doubt. This despite all the changes around how source may be stored on the platform and perceptions that “long, more descriptive” program names and other objects names can be defined.

It is vital that all participants acknowledge that the 10 character object name (QSYS.LIB file system) is fundamental to the intERPrise naming conventions, to keep everything simple, clear and concise.

The “long” name perception developers and administrators may have is exactly that; a perception. The average IBM i developers and administrators in the SMB market can do without the complications of dealing with inconsistent naming between source and objects, especially in an environment where you may potentially deal with thousands of objects. This becomes particularly relevant in 24-hour production installations, where serious program malfunctions usually occur in the dead of night and immediate fixes are expected and demanded.

Sections

  1. Target Audience
  2. Source Repository and location of source files
  3. Supported Operating System Releases
  4. Supported programming languages
  5. Recommended IDE Release
  6. RDi Extension Names
  7. General IBM i naming conventions/principles applied
  8. Open Source tooling
  9. Use of special characters in source and object naming
  10. Use of FULLY FREE format RPG source
  11. Length of object and source member names
  12. Line length of source members
  13. Comments in Code
  14. Use and leveraging of standard IBM i objects and architecture
  15. Standardized Error Handling
  16. ABSOLUTE separation between the database and the rest of the application
  17. Function/Procedure ↔ Modules ↔ *SRVPGM
  18. Suggested maximum number of elements/components
  19. Use of Source code “Copy Books”
  20. Prototypes (External)
  21. Compiler Directives
  22. Use of libraries (schemas)
  23. Source Files
  24. “Delivery” channel or “user interface”
  25. JSON standards
  26. Enhancing procedures/functions
  27. Definition of database layer components that will be delivered by AO
  28. Database components naming conventions
  29. Validation rules
  30. Use of surrogate keys in the database
  31. Central Metadata Repository (aka “Data Dictionary”)
  32. RLA and SQL result set processing
  33. Standard Code templates
  34. MakeFile (or BUILD) Utility
  35. High Availability/Continuous Operations considerations
  36. Security Implementation
  37. Unacceptable coding constructs
  38. Documentation
  39. Use of Adsero Optima™ (AO) by intERPrise participating developers

Some additional background on naming of database components