S++Business systems language
ENGLISH EDITION · OCTOBER 15, 2026
ContentsComplete book

Appendix F — Sources and Verification Evidence

This appendix provides concepts, source, execution and performance references. Concepts form one system; remaining cross-document issues are separately tracked in editorial records, outside the narrative.

F1 Theory and Methods

Reference Coverage
S++ Concepts and Applications Service model, decomposition, quantum services, polymorphism, separation and performance
S++ Modeling Shop participants, identity, agreements and storage
Scenario Composition Design Categories, dependency groups and scheduling
Application Framework Design Runtime, technical handling and transactions

The neighboring spp repository must be obtained separately. Relative source references require that checkout beside this repository.

F2 Language and Engineering Specifications

Topic Reference
Meaning and participation Business model boundaries
Query, identity and control Participant execution
Calculation rules Atomic calculation
Representation and rounding Numeric semantics
Quantum bounds Call bounds
Ownership, commit and recovery Transaction/storage
Environments and resources Deployment/physical configuration

Petstore counts retain the separate baseline in F7. Bank source and newly added capabilities are checked against main revision 0fafa21d. Specifications state goals and constraints, source expresses implementation, and runtime records evidence specific paths. No single layer replaces the others.

F3 Petstore Functional Verification

October 13, 2026 technical-service verification records 1,123 passing tests: language 362, runtime 617, generator 105, Petstore 39, with zero failures, errors or skips. Coverage includes matching, compilation, phases, access rejection, observer isolation, concurrency and replay. Remote proxies use controlled transport, without real cross-JVM acceptance. The Petstore example shows all-service tracing. Capability comes from main revision 65c766fc; this book cites existing records.

October 13 failure handling records 1,104 develop tests: language 356, runtime 607, generator 105, Petstore 36, all passing without skips. Reservation evidence covers insufficient stock, ordinary-save fault and replay. Framework tests separately establish real JDBC settled inverse before fail. Petstore used LOCAL, not real distributed TCC/external quantum acceptance. These are cited records, not tests rerun for the manuscript.

October 12 final regression records 1,080 passing tests: lang 340, appframe 581, generator 105, appframe-seata 20, Petstore 34; no failures, errors or skips.

That record also covers complete Chrome flows in develop, three-JVM testing with four isolated file databases, and shop restart. After shutdown, checks compare fund totals, per-goods stock/supply and per-transaction delta sums.

Temporary log paths identify original evidence; independent environments must rerun commands to obtain their own results. Known limitations cover opening retries and split zero recovery, detailed in recovery design. Functional regression is not Appendix C's serial/parallel benchmark.

F4 Verification of the Bank Deposit Case

The bank deposit case has completed its migration to current syntax and runtime protocols. Its production source uses only SPP, APP and PHY, with no handwritten production Java. SPP does not use try/catch/throw; generated Java and runtime internals can still use exception handling for technical failures. Historical source remains for rule comparison, not as current executable examples.

This section checks the case against main revision 0fafa21d and cites existing repository evidence. The manuscript update did not rerun bank tests. The latest verification record preserves commands, results and scope by batch:

Verification Batch Result Scope
October 13, 2026 clean develop joint regression 1,226 tests; zero failures, errors or skips Language 366, runtime 628, generator 107, bank case 86, Petstore 39; internal recipient accounts, historical snapshots and included fault/concurrency tests
Subsequent testing bank regression 86 tests; zero failures or errors, two skips Separate quantum and ordinary H2 data sources in one JVM; two LOCAL-only commit-fault tests skipped
Independent reversal-preview tests Two passing tests in each of develop and testing No preview writes; formal reversal preserves later deposits; missing originals are rejected without side effects
Chinese workbench verification Backend tests and browser flows pass in both environments Exact decimal display, negative-amount rejection, preview, reversal, receipt lookup and mobile layout; see workbench acceptance

Split-storage testing does not constitute complete acceptance of real network distribution, XA, Seata AT or TCC. Independent JVM restart and forced exit after confirmed settlement cover their specified persistence paths, not automatic resolution of interrupted or unknown commits. Later targeted tests must not be added together and represented as one unexecuted joint regression.

The completion audit identifies implemented scenarios, storage, transactions and technical capabilities. The 86-entry historical migration inventory lists evidence, differences and unmigrated parts entry by entry. Those 86 historical entries and the 86 JUnit tests above are different measures; equal numbers do not establish one-to-one equivalence.

Known issues retain boundaries for committed ordinary Saga recovery, persisted pending authorization and cross-process resumption, automatic confirmation of unknown settlement, and durable auditing of every invocation. A split-storage failure can restore quantum funds while leaving ordinary committed facts. The system explicitly reports RECOVERY_REQUIRED and handled=false, not complete rollback.

Source mapping gives current directories and original rule locations. Source derivation, mathematical expectations, demonstration inputs, generated execution comparisons, original COBOL execution and bank-confirmed results represent different evidence levels. Case success does not establish every bank policy or original-system output equivalence.

F5 QService References

The neighboring qservice repository's SPP boundary contract and quantum design describe commands, durable identities, lookup and recovery.

It has separate artifacts and baselines. Verify the backend protocol actually integrated; independent-project tests do not extend to arbitrary deployments.

F6 Using Evidence

Parsing establishes accepted expression; compilation checks artifacts; runtime exercises paths; fault/restart tests cover specified recovery. Performance needs workload/resources.

For each claim, identify participants, behavior and configuration, then input, expectation, result and fault scope. These connections make conceptual arguments reviewable as engineering practice.

F7 Petstore Code-Size Statistics

The figures in this section describe their recorded source baseline. Subsequent English/USD presentation and expanded source formatting change physical line counts; they do not retroactively change these measurements.

On October 13, 2026, source at book branch 5b9b182c was measured; that manuscript change did not alter demo source. develop generation began with no existing generated Java directory, excluding stale files. Run at root:

mvn -pl petstore-demo -am package -DskipTests -Dspp.environment=develop

Inputs are .spp, .enum, .app and .phy under petstore-demo/src/main/spp/; output is .java under petstore-demo/target/generated-sources/openapi/src/main/java/. Excluded are tests, pages, resources, build scripts, generator and shared runtime dependencies. Java includes both S++ and OpenAPI generation. Reproduce in a clean directory and recount after source/tool changes.

Category Files Physical Lines Including Blanks/Comments Code Lines
SPP 63 1,104 999
Enums 2 25 18
APP 4 126 117
PHY 4 222 214
Inputs total 73 1,477 1,348
Generated Java 962 131,107 100,151

Models account for 64,431 code lines, services 21,031, interfaces/handlers 14,535, and mapping/configuration 154. Model and request/response expansion is substantial; every line is not independently designed business logic.

This script removes blank, line-comment and block-comment lines while preserving comment symbols in strings and brace-only lines. It fits this source, not every language construct:

from pathlib import Path
import re

pattern = re.compile(
    r'"(?:\\.|[^"\\])*"|\'(?:\\.|[^\'\\])*\'|//[^\n]*|/\*[\s\S]*?\*/'
)

def code_lines(source):
    def remove_comment(match):
        token = match.group()
        if token.startswith(("//", "/*")):
            return "\n" * token.count("\n")
        return token
    source = pattern.sub(remove_comment, source)
    return sum(bool(line.strip()) for line in source.splitlines())

source_root = Path("petstore-demo/src/main/spp")
java_root = Path("petstore-demo/target/generated-sources/openapi/src/main/java")
for suffix in (".spp", ".enum", ".app", ".phy", ".java"):
    root = java_root if suffix == ".java" else source_root
    files = sorted(root.rglob("*" + suffix))
    sources = [path.read_text(encoding="utf-8") for path in files]
    print(suffix, len(files),
          sum(len(source.splitlines()) for source in sources),
          sum(code_lines(source) for source in sources))

SPP can place multiple declarations/calls on one line, while Java formatting, accessors and request/response types expand lines. This is version-specific scale, not a universal expressiveness, productivity or speed ratio. Exact handwritten Java comparison requires an independent implementation with equivalent business, capability and acceptance. The following is an estimate by responsibility.

Estimate with Common Java Frameworks

Assume Spring Boot + MyBatis + Lombok, existing reusable components, no separate remote interface for every internal operation and no manually expanded accessors. Lombok provides model boilerplate, MyBatis SQL mapping and Spring declarative transactions. Their source is dependency, not project-maintained code. See Lombok Data, MyBatis Mapper and Spring transactions. Documentation establishes capabilities; estimates are the book's engineering judgment, not vendor benchmarks.

Maintained Content Estimated Lines Basis
Models, DTOs and enums 1,000–2,000 Four domains, reused models and Lombok
Entries, conversion and mapping 1,000–2,000 34 scenario boundaries
Orchestration, calculation and eligibility 3,000–5,000 Approximately 90–150 per scenario including shared rules
Persistence, SQL, mappings and schema 2,000–4,000 Facts, snapshots, version conditions and associations
Conservation, idempotency and recovery integration 2,000–5,000 Bilateral deltas, bounds, original confirmation and phase recovery
Domain calls, environments and technical errors 1,000–2,000 Local/remote adaptation, resources and environment selection
Total 10,000–20,000 Java, SQL/Mapper and necessary configuration

Responsibilities are allocated to avoid duplication: business rejection belongs to scenario/checks; timeout confirmation to recovery/technical handling. Proposed general cache pruning and full security/governance not yet implemented in the case are excluded, as is developing the shared framework itself.

A conventional monolith with local transactions, merged models, less domain adaptation and only local rollback may need 6,000–10,000 lines. That narrower scope omits domain deployment and its confirmation/recovery and is not an equivalent-capability baseline.

Mature accounting, idempotency and coordination middleware reduces handwritten code; building such general facilities can exceed these ranges. Formatting also matters. Ten to twenty thousand describes maintenance scale, not an exact productivity multiplier or development time.

F9 COBOL and S++ Code Size in the Bank Case

The count was made on October 14, 2026, using case source and reference documents at repository revision 92ed491b. Original COBOL and COPYBOOK files were read from the local bank-source directory, without modification or copying their contents into this book. That directory must be obtained separately. File inventories and figures are preserved in the appendix's count results.

Source Scope and Deduplication

The “directly located for analysis” scope selects nine COBOL programs identified by program filename or specific line references in the source documentation. Located analysis means there is a source-tracing basis; it does not mean every branch of each program has been migrated.

Program Source Responsibility Physical Lines Lines Excluding Blanks and Comments
GSA01102 Front-office acceptance of a general deposit 2,325 1,820
KSADEP0 Deposit core, repayment allocation and reversal 4,197 3,508
CSAQRY1 Account eligibility and acceptance checks 2,654 1,867
KSAFEE0 Fee entry point 384 310
CSAFEE0 Fee rules 415 331
CCMDAT1 Calendar and day counting 2,856 2,563
CSAPRD2 Deposit and agreement accrual products 483 315
CSAPRD4 Overdraft accrual products 237 154
GCCBAAR Accounting-rule integration and configuration-source analysis 605 542
Total Nine programs 14,156 11,410

Active COPY statements in those programs directly reference 135 COPYBOOKs. Nested references add another 26, yielding 161 distinct files. A shared COPYBOOK is counted once by actual file, even when several programs or repeated statements reference it. Invocation and expansion counts do not multiply it.

The broader “all related” scope selects 22 programs explicitly mentioned in the source documents and actually present in the original directory. It includes dispatch, query and configuration programs. It does not recursively expand every CALL dependency and is not the size of the entire banking system.

Source Scope COBOL Programs Distinct COPYBOOKs Program Physical Lines COPYBOOK Physical Lines Total Physical Lines Total Lines Excluding Blanks and Comments
Directly located for analysis 9 161 14,156 23,488 37,644 22,589
All related programs mentioned in documentation 22 192 20,626 24,961 45,587 28,358

See the direct-source inventory and all-related-source inventory for per-file figures. They contain locations and counts, not bank source contents.

Current S++ Source

Only production SPP, enums, APP and PHY are counted. Historical material, Java tests, test inputs, web pages, build scripts, generated Java, and shared compilers and runtime frameworks are excluded.

Source Category Files Physical Lines, Including Blanks and Comments Lines Excluding Blanks and Comments
SPP 34 1,037 973
Business enums 1 6 6
APP 2 48 48
PHY 2 38 38
Total 39 1,129 1,065

SPP and enums total 979 nonblank, noncomment lines describing the business models, services, scenarios and finite value sets maintained in this case; APP and PHY add 86. Several S++ statements currently share a physical line. Line ratios therefore do not directly measure algorithmic complexity, work or productivity.

Counting and Reproduction

Physical lines follow each file's original line breaks. COBOL nonblank, noncomment counts use fixed-format processing: exclude lines whose seventh column is * or /, take content from columns 8–72, remove inline comments following *>, and count remaining nonempty lines. Sequence columns and right-hand identification areas are not code. Data definitions, COPY directives, procedures and control declarations still count; these are not business-statement counts.

COPYBOOKs follow the same rule. SPP, enums, APP and PHY remove // and /* … */ comments while preserving comment symbols in strings, then count remaining nonempty physical lines. COPYBOOKs are not expanded and repeatedly counted inside every program.

The reproduction script takes the original COBOL root directory. Run from the repository root:

python3 book/附录/统计资料/count-bank-code.py /path/to/original/cobol-root \
  --output-dir /tmp/bank-demo-code-count

The root must contain the original program and COPYBOOK category directories. The script writes two source inventories and a summary JSON. Changes to source or reference documents can change scope and results; recount and identify the revision. Neither current scope contains unresolved or ambiguous COPYBOOK references.

Limits of the Comparison

Source and implementation sizes help explain how concentrated the expression is; they do not prove equivalent conversion of every source line. Entire source programs include other transaction modes, shared configuration and unmigrated branches. The S++ case covers business paths explicitly implemented and verified.

Role and service models concentrate their rules, participating relationships and execution boundaries. Tools supply repetitive implementation, and APP/PHY connect storage and runtime facilities. The case still depends on shared frameworks, uses demonstration configuration for accounts and external facts, and retains authorization-resumption and ordinary Saga recovery limits described in F4. Dividing all source lines by case lines does not establish an unconditional compression factor or full replacement.


Appendix Contents · Full Book Contents · Previous