Fortran Cobol EDI - sgml/signature GitHub Wiki

Flat to Hierarchical Roundtrip

================================================================================
MONOLITHIC ASCII WALL CHART
HL7 v2 <-> HL7 v3/FHIR COMPATIBILITY ENGINE
WITH DUPLICATE AVOIDANCE, IDEMPOTENCY, AND TESTABILITY
================================================================================

                                      +-----------------------------+
                                      |          START INPUT        |
                                      |   Incoming HL7 v2 or FHIR   |
                                      +-----------------------------+
                                                      |
                                                      v
                            +-------------------------------------------+
                            |  Detect Message Type (v2 or v3/FHIR)      |
                            +-------------------------------------------+
                                    |                           |
                                    |                           |
                              (HL7 v2)                     (HL7 v3/FHIR)
                                    |                           |
                                    v                           v
         +----------------------------------+   +----------------------------------+
         | HL7 v2 Parser (Regex / Flat)     |   | HL7 v3/FHIR Parser (Tree)        |
         | - split segments                 |   | - XML or JSON parser             |
         | - split fields                   |   | - nested structures              |
         | - delimiter logic                |   | - references and arrays          |
         +----------------------------------+   +----------------------------------+
                                    |                           |
                                    +-------------+-------------+
                                                  |
                                                  v
                     +------------------------------------------------------+
                     |   Convert to Canonical Python Model (Neutral Form)   |
                     |   - unify patient/order/obs structures               |
                     |   - normalize identifiers                            |
                     |   - flatten or expand as needed                      |
                     +------------------------------------------------------+
                                                  |
                                                  v
                            +-------------------------------------------+
                            |     Determine Target Output Format        |
                            +-------------------------------------------+
                                    |                           |
                                    |                           |
                              (HL7 v2)                     (HL7 v3/FHIR)
                                    |                           |
                                    v                           v
         +----------------------------------+   +----------------------------------+
         | Emit HL7 v2 (Flat Output)        |   | Emit HL7 v3/FHIR (Tree Output)   |
         | - deterministic segment order    |   | - preserve structure             |
         | - positional fields              |   | - preserve semantics             |
         | - delimiter based                |   | - include extensions             |
         | - no recursion                   |   | - support references             |
         +----------------------------------+   +----------------------------------+
                                    |                           |
                                    +-------------+-------------+
                                                  |
                                                  v
                     +------------------------------------------------------+
                     |        APPLY COMPATIBILITY RULES (1 - 10)            |
                     +------------------------------------------------------+
                                                  |
                                                  v
                                      +-----------------------------+
                                      |         FINAL OUTPUT        |
                                      |   HL7 v2 or HL7 v3 or FHIR  |
                                      +-----------------------------+
                                                      |
                                                      v
                                      +-----------------------------+
                                      |             END             |
                                      +-----------------------------+


================================================================================
RULE 1: FLATTEN NESTED STRUCTURES (FHIR -> HL7 v2)
================================================================================

FHIR Tree
   |
   v
+---------------------------------------------+
| Check Resource ID in "seen" set             |
+---------------------------------------------+
   |                         |
  Yes                       No
   |                         |
   v                         v
Skip resource          Add ID to "seen"
                             |
                             v
                 +-----------------------------+
                 | Flatten Fields Deterministically
                 | - stable field order
                 | - no random values
                 +-----------------------------+
                             |
                             v
                 +-----------------------------+
                 | Emit HL7 v2 Segments        |
                 +-----------------------------+

Avoiding Duplicates:
- Track each FHIR resource by unique ID.
- Maintain "seen" set during flattening.
- Emit one HL7 v2 segment set per unique resource.

Ensuring Idempotency:
- Same input tree -> same flattened segments.
- Stable ordering, no randomness, no timestamps.

Ensuring Testability:
- Pure function: flatten(fhir_obj) -> [segments].
- No global state.
- Snapshot tests compare exact segment strings.


================================================================================
RULE 2: COLLAPSE ARRAYS INTO REPETITIONS (FHIR -> HL7 v2)
================================================================================

FHIR Array
   |
   v
+-----------------------------+
| Stable Sort Array           |
+-----------------------------+
   |
   v
For each element:
   |
   v
+-----------------------------+
| Hash element                |
+-----------------------------+
   |
   v
Duplicate?
   |                         |
  Yes                       No
   |                         |
   v                         v
Skip element          Append as "~" repetition
                             |
                             v
+-----------------------------+
| Emit HL7 v2 Repetition      |
+-----------------------------+

Avoiding Duplicates:
- Hash each element; skip if hash already seen.
- Use index-based repetition for clarity.

Ensuring Idempotency:
- Stable sort + stable hashing.
- Same array -> same "~" joined field.

Ensuring Testability:
- collapse_array(arr) -> "val1~val2".
- Test duplicates, different orders, empty arrays.


================================================================================
RULE 3: MAP REFERENCES TO IDs (FHIR -> HL7 v2)
================================================================================

FHIR Reference (e.g. "Patient/123")
   |
   v
+-----------------------------+
| Check Reference Cache       |
+-----------------------------+
   |                         |
  Hit                       Miss
   |                         |
   v                         v
Return cached ID      +----------------------+
                      | Resolve Reference    |
                      | (deterministic)      |
                      +----------------------+
                                |
                                v
                      Store in Cache
                                |
                                v
                      Return ID
                                |
                                v
+-----------------------------+
| Emit HL7 v2 ID              |
+-----------------------------+

Avoiding Duplicates:
- Cache reference -> ID mapping.
- Reuse same ID for repeated references.

Ensuring Idempotency:
- Deterministic resolution.
- Stable fallback IDs (no random UUIDs).

Ensuring Testability:
- resolve_reference(ref) -> id.
- Mock lookup layer; test missing and repeated refs.


================================================================================
RULE 4: PRESERVE SEGMENT ORDERING (HL7 v2 OUTPUT)
================================================================================

Unordered Segments
   |
   v
+-------------------------------------------+
| Apply Fixed Ordering Table                |
| e.g. ["MSH","PID","PV1","ORC","OBR","OBX"]|
+-------------------------------------------+
   |
   v
+-----------------------------+
| Check Singleton Duplicates  |
| (e.g. MSH, PID)             |
+-----------------------------+
   |                         |
Duplicates?                 No
   |                         |
   v                         v
Keep first, drop rest   Continue
   |
   v
+-----------------------------+
| Emit Ordered Segments       |
+-----------------------------+

Avoiding Duplicates:
- Enforce one instance for singleton segments.
- Log or drop extras deterministically.

Ensuring Idempotency:
- Fixed ordering table.
- Same unordered input -> same ordered output.

Ensuring Testability:
- order_segments(list) -> ordered_list.
- Test shuffled, missing, and extra segments.


================================================================================
RULE 5: PRESERVE SEMANTIC RICHNESS (HL7 v2 -> FHIR)
================================================================================

HL7 v2 Segment
   |
   v
+-----------------------------+
| Infer Structure via Regex   |
+-----------------------------+
   |
   v
+-----------------------------+
| Build FHIR Resource         |
+-----------------------------+
   |
   v
Resource with same logical ID?
   |                         |
  Yes                       No
   |                         |
   v                         v
+---------------------+   +---------------------+
| Merge fields        |   | Add new resource    |
+---------------------+   +---------------------+
   |
   v
+-----------------------------+
| Deduplicate Identifiers     |
+-----------------------------+

Avoiding Duplicates:
- Use logical ID (e.g. patient ID) as key.
- Merge resources instead of duplicating.

Ensuring Idempotency:
- Deterministic regex rules.
- Stable UUID5 for new IDs if needed.

Ensuring Testability:
- expand_v2(segment) -> resource.
- Test repeated segments, missing fields, out-of-order input.


================================================================================
RULE 6: HANDLE UNMAPPABLE FIELDS (Z-SEGMENTS / FHIR EXTENSIONS)
================================================================================

Field Unmappable?
   |
  Yes
   |
   v
+-----------------------------+
| Hash Raw Value              |
+-----------------------------+
   |
   v
+-----------------------------+
| Check Extension/Z Cache     |
+-----------------------------+
   |                         |
  Hit                       Miss
   |                         |
   v                         v
Reuse existing         +----------------------+
extension/Z-seg        | Create deterministic |
                       | name: "ext-<hash>"   |
                       +----------------------+
                                |
                                v
+-----------------------------+
| Attach to Output            |
+-----------------------------+

Avoiding Duplicates:
- Hash raw value; reuse same extension/Z-seg.

Ensuring Idempotency:
- Name derived from hash only.
- Same raw value -> same extension name.

Ensuring Testability:
- wrap_unmappable(raw) -> envelope.
- Test identical, different, and empty values.


================================================================================
RULE 7: INFER STRUCTURE FROM PATTERNS (HL7 v2 -> FHIR)
================================================================================

HL7 v2 Segment
   |
   v
+-----------------------------+
| Match Against Regex Rules   |
+-----------------------------+
   |
   v
Ambiguous Match?
   |                         |
  Yes                       No
   |                         |
   v                         v
+---------------------+   +---------------------+
| Attach metadata     |   | Build resource      |
| (e.g. "ambiguous")  |   +---------------------+
+---------------------+
   |
   v
+-----------------------------+
| Deduplicate Resources       |
+-----------------------------+

Avoiding Duplicates:
- Use segment index + type as key.
- Merge when mapping to same resource.

Ensuring Idempotency:
- Regex rules are fixed and deterministic.

Ensuring Testability:
- infer_structure(segment) -> dict.
- Test malformed, repeated, and ambiguous segments.


================================================================================
RULE 8: CANONICAL PYTHON MODEL (THE BRIDGE)
================================================================================

Input (HL7 v2 or FHIR)
   |
   v
+-----------------------------+
| Normalize Identifiers       |
+-----------------------------+
   |
   v
+-----------------------------+
| Merge Duplicate Resources   |
+-----------------------------+
   |
   v
+-----------------------------+
| Produce Canonical Model     |
+-----------------------------+

Avoiding Duplicates:
- Primary keys inside model.
- Deduplicate identifiers and references.

Ensuring Idempotency:
- Same input -> same canonical representation.
- No time or randomness.

Ensuring Testability:
- to_canonical(input) -> model.
- Round-trip tests: v2 -> model -> v2, FHIR -> model -> FHIR.


================================================================================
RULE 9: PURE FUNCTIONS ONLY
================================================================================

All Transformations
   |
   v
+-----------------------------+
| No Global State             |
| No Randomness               |
| No Time-Based Values        |
+-----------------------------+
   |
   v
+-----------------------------+
| Pure Deterministic Output   |
+-----------------------------+

Avoiding Duplicates:
- All dedup logic explicit in arguments, not hidden state.

Ensuring Idempotency:
- Pure functions guarantee same output for same input.

Ensuring Testability:
- Easy unit tests and snapshot tests.


================================================================================
RULE 10: STABLE SORTING AND STABLE HASHING
================================================================================

Input List
   |
   v
+-----------------------------+
| Stable Sort                 |
+-----------------------------+
   |
   v
+-----------------------------+
| Stable Hash for Identity    |
+-----------------------------+
   |
   v
+-----------------------------+
| Deterministic Output        |
+-----------------------------+

Avoiding Duplicates:
- Use hash to detect duplicates.
- Use sort to keep consistent ordering.

Ensuring Idempotency:
- Stable sort + stable hash = repeatable results.

Ensuring Testability:
- stable_sort(list) -> list.
- Test duplicates, shuffled input, identical elements.


================================================================================
END OF MONOLITHIC ASCII WALL CHART
================================================================================

S-Expr to EDI Roundtrip

;; -----------------------------------------------------------------------------
;; Why S-expressions Score So Well
;;
;; 1. Explicit hierarchy
;;    EDI loops and segments form a tree. S-expressions are a native tree
;;    structure, so nesting and scope are unambiguous.
;;
;; 2. Ordered elements
;;    EDI requires strict ordering of segments and elements. S-expressions
;;    preserve order by definition.
;;
;; 3. Deterministic structure
;;    No attribute-vs-element ambiguity (as in XML). No unordered object keys
;;    (as in JSON). Every node is an ordered list.
;;
;; 4. Lossless representation
;;    Every segment, element, composite, and qualifier can be represented
;;    exactly. Nothing is flattened or inferred.
;;
;; 5. Perfect round-trip behavior
;;    Because S-expressions are structured, ordered, and unambiguous,
;;    EDI → S-expr → EDI can be fully reversible with no loss of information.
;; -----------------------------------------------------------------------------

;; Original EDI
;; NM1*IL*1*RIVERA*ALEX****MI*12345~
;; DMG*D8*20010412~

;; EDI → S-expression
(
  (NM1
    (entity-id-code "IL")
    (entity-type-qualifier "1")
    (last-name "RIVERA")
    (first-name "ALEX")
    (middle-name "")
    (name-prefix "")
    (name-suffix "")
    (id-code-qualifier "MI")
    (id-code "12345")
  )
  (DMG
    (date-format "D8")
    (birth-date "20010412")
  )
)

;; S-expression → EDI (round-trip)
;; NM1*IL*1*RIVERA*ALEX*** *MI*12345~
;; DMG*D8*20010412~

COBOL vs QBasic: Lack of Function Boundaries — System Limitations and Counterexamples

Format	Topic	COBOL Limitation (Why AI Struggles)	QBasic Limitation (Why AI Struggles)	Inline Assertions
Fixed‑Width Records	COBOL Native Data Format	Paragraphs operate on global WORKING‑STORAGE; no return values; record parsing interwoven with I/O; PERFORM chains hide logic boundaries	Must manually slice fields with MID$/LEFT$/RIGHT$; no native record layouts; global variables dominate; no encapsulated parsing routines	Rare; COBOL lacks inline assertion syntax; requires custom IF/STOP RUN patterns
Line‑Oriented Text / Console I/O	QBasic Native Data Format	COBOL requires explicit READ/WRITE and FD structures; console‑style line I/O is non‑idiomatic; logic becomes procedural and stateful	Programs intermix INPUT/PRINT with logic; no separation of concerns; global state and linear flow prevent isolated testable units	None; QBasic has no assertion keyword; only manual IF/PRINT/STOP checks
Binary Files	Packed / Raw Binary Data	COBOL relies on PIC, COMP, COMP‑3, and REDEFINES; binary interpretation tied to global state; no isolated decoding routines	QBasic lacks native packed‑decimal or binary structures; manual byte decoding required; global variables and linear flow prevent modular parsing	None; both languages require manual guard checks rather than inline assertions

COBOL vs QBasic: Data Format Comparison

1. Fixed‑Width Record Files

COBOL

native support through PIC clauses
copybooks define exact byte positions
no parsing logic required
ideal for batch processing and large files

QBasic

must manually MID$ / LEFT$ / RIGHT$ each field
no native record layouts
error‑prone for large or complex files
workable for small files, tedious for large ones

2. Variable‑Length Record Files (VLR / VSAM / QSAM)

COBOL

supports OCCURS DEPENDING ON
supports REDEFINES for multi‑layout records
integrates with VSAM/QSAM on mainframes
efficient for mixed‑record‑type files

QBasic

no native variable‑length record structures
must manually parse line lengths
no concept of REDEFINES or multi‑layout records
possible but fragile for production use

3. Pipe‑Delimited / Tab‑Delimited / Custom‑Delimited Text

COBOL

UNSTRING handles delimiter‑based parsing
easy to map fields into working‑storage
stable for large batch jobs

QBasic

must manually FIND / INSTR delimiters
must manually slice substrings
easier than fixed‑width because delimiters guide parsing
still lacks structured record definitions

4. COBOL‑Friendly Binary Formats (COMP, COMP‑3, COMP‑5)

COBOL

native support for packed decimal and binary formats
PIC clauses map directly to binary encodings
ideal for financial and high‑precision numeric data

QBasic

no native packed‑decimal support
must manually decode bytes
cannot interpret COMP‑3 without custom routines
impractical for enterprise binary formats

5. Flat‑File Hierarchical Formats (non‑EDI, non‑HL7)

COBOL

segment‑based parsing fits REDEFINES and IF logic
easy to process multi‑record‑type files
common in legacy batch systems

QBasic

must manually detect segment identifiers
no native multi‑record‑type structures
workable for small files, brittle for large or complex ones

6. Custom Copybook‑Driven Enterprise Formats

COBOL

designed specifically for these formats
copybooks define structure, alignment, and types
extremely stable and maintainable
ideal for long‑lived enterprise pipelines

QBasic

no copybook equivalent
must manually code all field offsets and types
difficult to maintain
not suitable for enterprise‑scale structured formats

Non Enterprise EDI Training Paths for Universities, Colleges, and Nonprofits

This document lists practical ways for academic institutions and nonprofits to teach Electronic Data Interchange without enterprise licensed software. All content uses plain ASCII, no text decoration, no contractions, and no non ASCII characters.

Open Source EDI Tools for Instruction

These tools allow hands on EDI parsing, validation, and mapping without enterprise licensing.

BOTS EDI (Python) — Open source EDI translator with mapping, routing, and validation. Suitable for instructional labs.
node x12 (JavaScript) — Lightweight X12 parser for MIS and integration courses.
pyx12 (Python) — Strong support for HIPAA X12 transactions. Common in public health and nonprofit health IT programs.
Smooks (Java) — Open source transformation engine that supports EDI to XML or JSON mapping.

Standards Body and Nonprofit Aligned Education

These organizations provide low cost or free educational materials.

ASC X12 — Webinars, primers, and standards documentation for supply chain and healthcare EDI.
UN CEFACT — Free EDIFACT guides and training modules for international logistics and trade.
WEDI — Nonprofit healthcare EDI education used by public health agencies and nonprofit clinics.
HL7 — Often paired with healthcare EDI in academic programs. Offers student memberships and training.

Academic Programs That Commonly Teach EDI

These programs typically rely on open source tools and public documentation.

Community college health informatics programs — Often include HIPAA X12 transaction sets using pyx12 or open source validators.
Supply chain and logistics programs — Teach 850, 855, 856, and 810 fundamentals using open source examples.
Public health informatics programs — Use X12 for eligibility, claims, and remittance training.
MIS and Information Systems programs — Introduce EDI as part of B2B integration and data exchange modules.

Community and Nonprofit Training Paths

These options are accessible to nonprofits, libraries, and community technology groups.

Open source workshops — Python or JavaScript meetups teaching pyx12, BOTS, or node x12.
Public sector training — State Medicaid agencies often publish free 834, 835, and 837 training materials.
Community technology programs — Some literacy or logistics nonprofits use EDI to teach data exchange fundamentals.

Open Educational Resources

These materials are free and widely used in academic settings.

GitHub repositories with sample X12 files and mapping examples.
University published supply chain EDI lecture slides.
Public Medicaid and Medicare companion guides.
Open access textbooks on B2B integration and data interchange.

Summary

Universities, colleges, and nonprofits can build strong EDI training programs without enterprise tools by combining open source EDI engines, standards body education, academic curricula, community workshops, and open educational resources.

What type of institution or program are you planning to support with this training material?

EDI Boilerplate

Boilerplate: Custom EDI Integration with Washington State Health Care Authority (HCA)

overview

This integration exchanges HIPAA‑compliant X12 EDI transactions with the Washington State Health Care Authority (HCA).
Estimated time: 1–2 days to document scope and architecture.

history of edi and cobol

edi and cobol emerged in the same era, both designed to standardize business data processing across large organizations.
cobol was created in 1959 to support business‑oriented batch processing on mainframes using fixed‑width records and deterministic file layouts.
early edi standards in the 1960s and 1970s adopted the same fixed‑record philosophy because most trading partners processed data on cobol‑based systems.
edi’s segment‑based structure mirrors cobol’s record‑oriented file handling:
- predictable field positions
- strict ordering rules
- deterministic parsing
mainframe environments used cobol programs to generate edi outbound files, validate inbound files, and reconcile control numbers.
edi control numbers were modeled after cobol batch control totals used in nightly processing cycles.
edi adoption grew in industries dominated by cobol systems such as healthcare, banking, and government.
the result is a tightly linked ecosystem where edi standards evolved to accommodate cobol’s constraints and strengths.
Estimated time to document historical dependencies: 1–2 days.

similarities between cobol copybooks and edi segment definitions

both define data structures using rigid, predetermined formats.
both rely on hierarchical grouping:
- cobol uses levels (01, 05, 10)
- edi uses envelopes (ISA, GS, ST)
both enforce strict field ordering with no implicit reordering allowed.
both use fixed semantics for each field:
- cobol PIC clauses define type and length
- edi element definitions define type and length
both require deterministic parsing:
- cobol reads by byte position
- edi reads by segment and element position
both use control totals or identifiers to ensure file integrity.
both assume batch‑oriented processing rather than interactive transactions.
both require external implementation guides to interpret business‑specific rules.
Estimated time to align copybook and segment semantics: 2–4 days.

edi transactions supported

270 eligibility inquiry
271 eligibility response
276 claim status inquiry
277 claim status response
834 enrollment
835 remittance advice
837 claim submission
Estimated time to confirm transaction set requirements: 2–5 days.

transport mechanisms

HCA uses secure file transfer channels such as:
- SFTP with SSH keys
- AS2 with X.509 certificates
- HTTPS endpoints for specific programs
Estimated time to select and configure transport: 3–10 days.

authentication

SFTP
- SSH keypair exchange
AS2
- X.509 certificate exchange
HTTPS
- mutual TLS or OAuth depending on program
Estimated time to complete authentication setup: 2–7 days.

system components

inbound gateway
- receives EDI files from HCA
- validates transport‑level security
- stores raw payloads in immutable storage
edi parser
- parses X12 segments
- validates ISA/GS envelopes
- validates segment counts and control numbers
transformation engine
- maps EDI segments to internal canonical format
- applies HCA‑specific business rules
outbound gateway
- assembles X12 envelopes
- generates control numbers
- signs and transmits files to HCA
acknowledgment handler
- processes TA1, 999, and 277CA acknowledgments
- updates job status and retry logic
audit and monitoring
- logs all transmissions
- stores control numbers, timestamps, and correlation IDs
Estimated time to build core components: 4–12 weeks.

edi envelope requirements

ISA segment
- fixed‑width fields
- sender/receiver IDs assigned by HCA
- control number incrementing rules
GS segment
- functional group identifiers per transaction type
ST/SE segments
- transaction set control numbers
- segment count validation
Estimated time to implement envelope logic: 3–7 days.

onboarding steps (no registration fees)

complete the HCA trading partner registration form
submit organization details including:
- legal entity name
- contact information
- technical contact
- preferred transport method (SFTP, AS2, HTTPS)
generate SSH keys or X.509 certificates for secure transport
send public keys or certificates to HCA for validation
complete connectivity testing with HCA’s test environment
complete EDI validation testing for each transaction type
receive approval to move to production
no fees are charged at any stage of registration or testing
Estimated time for onboarding: 2–6 weeks.

error handling

transport errors
- connection failures
- certificate expiration
- authentication failures
edi structural errors
- invalid segment order
- incorrect segment counts
- mismatched control numbers
business rule errors
- missing required HCA fields
- invalid member identifiers
- invalid provider identifiers
acknowledgment errors
- TA1 rejection
- 999 rejection
- 277CA rejection
Estimated time to implement error handling: 1–3 weeks.

retry logic

retries are triggered when:
- transport fails
- no acknowledgment is received within the HCA SLA
retry intervals follow exponential backoff
retries stop when:
- a positive acknowledgment is received
- a fatal rejection is returned
Estimated time to implement retry logic: 3–7 days.

security requirements

all EDI files are encrypted in transit
all EDI files are encrypted at rest
access is restricted to machine users and integration roles
audit logs are immutable and retained per compliance requirements
Estimated time to implement security controls: 1–3 weeks.

operational workflow

inbound
- HCA sends EDI file
- system receives and stores raw file
- parser validates structure
- transformer maps to internal format
- system processes business logic
- system generates acknowledgments if required
outbound
- system generates EDI payload
- transformer maps from internal format to X12
- envelope is assembled
- file is transmitted to HCA
- system waits for acknowledgments
- job status is updated
Estimated time to finalize workflow automation: 2–4 weeks.

monitoring and observability

track:
- file receipt timestamps
- file transmission timestamps
- control numbers
- acknowledgment status
- error categories
alert on:
- missing acknowledgments
- repeated rejections
- transport failures
- certificate expiration
Estimated time to implement monitoring: 1–2 weeks.

compliance

HIPAA
HITECH
HCA trading partner agreements
X12 implementation guides for HCA programs
Estimated time for compliance review: 1–3 weeks.

Training

                ┌───────────────────────────┐
                │   START: Free Resources   │
                │   (Open Mainframe Project │
                │    + GNUCobol compiler)   │
                └─────────────┬─────────────┘
                              │
                              ▼
                ┌───────────────────────────┐
                │   Step 1: Basics          │
                │   - Learn COBOL syntax    │
                │   - Hello World program   │
                │   - Free tutorials (e.g., │
                │     Open Mainframe, GNU)  │
                └─────────────┬─────────────┘
                              │
                              ▼
                ┌───────────────────────────┐
                │   Step 2: Data Division   │
                │   - Variables, records    │
                │   - Free GNUCobol docs    │
                │   - Practice with text    │
                │     files on Linux/Unix   │
                └─────────────┬─────────────┘
                              │
                              ▼
                ┌───────────────────────────┐
                │   Step 3: Procedure Div.  │
                │   - Control flow (IF, PERFORM) │
                │   - Free online exercises │
                │   - Run with GNUCobol     │
                └─────────────┬─────────────┘
                              │
                              ▼
                ┌───────────────────────────┐
                │   Step 4: File Handling   │
                │   - Sequential files      │
                │   - Free sample datasets  │
                │   - Practice batch jobs   │
                └─────────────┬─────────────┘
                              │
                              ▼
                ┌───────────────────────────┐
                │   Step 5: Projects        │
                │   - Build payroll system  │
                │   - Student records app   │
                │   - Use only free OS +    │
                │     GNUCobol compiler     │
                └─────────────┬─────────────┘
                              │
                              ▼
                ┌───────────────────────────┐
                │   Step 6: Community       │
                │   - Join Open Mainframe   │
                │   - Contribute to GitHub  │
                │   - Share free resources  │
                └─────────────┬─────────────┘
                              │
                              ▼
                ┌───────────────────────────┐
                │   GOAL: COBOL Fluency     │
                │   - Legacy maintenance    │
                │   - Modernization skills  │
                │   - 100% free stack       │
                └───────────────────────────┘

Git Profiles

Consultant / Group	Platform	Focus Area	GitHub Profile (COBOL Mention)
Michael Coughlan (COBOL Tutorial Author)	GitHub contributor	COBOL education, tutorials, modernization strategies	https://github.com/Apress/beg-cobol-for-programmers
Abhishek Ranjan (Mainframe Blogger)	GitHub contributor	COBOL, JCL, DB2, mainframe modernization	https://www.linkedin.com/pulse/compromising-artificial-intelligence-security-part-1-2-ranjan
Joe Gulla (TechChannel)	TechChannel articles and “z/OS and Friends”	COBOL and z/OS modernization	https://github.com/joeproit/COBOL
Johnny B. (Ionică Bizău)	Codementor consultant, blogging/podcasting	COBOL, mentoring, modernization strategies	https://github.com/IonicaBizau
Sheldon Linker	Independent consultant/blogger	COBOL and database modernization	https://github.com/sheldonLinkerInvista

Emulators

Rank	Language/Standard	Automatability %	Reasoning	Runtime Limitations	Free Emulator / Online Compiler URL	Average Job Openings per Year (US, 2025)
1	VBScript	90%	Simple, lightweight scripting language; highly automatable by AI due to limited syntax and narrow scope	Windows-only runtime, deprecated in modern environments, limited cross-platform support	https://www.tutorialspoint.com/vbscript/try_vbscript.php	~500–1,000 (mostly legacy maintenance)
2	Perl	85%	Text-processing powerhouse; AI can easily generate regex and automation scripts, though legacy quirks exist	Inconsistent portability, performance overhead with large datasets, regex complexity can cause runtime errors	https://onecompiler.com/perl	~2,000–3,000 (finance, bioinformatics, sysadmin niches)
3	Delphi	75%	High-level, strongly typed language; AI can automate GUI and business logic, but ecosystem is smaller today	Windows-centric runtime, limited modern library support, weaker community maintenance	https://blog.cybelesoft.com/running-delphi-application-web-browser/	~1,000–2,000 (ERP, manufacturing, niche enterprise apps)
4	Ada	65%	Verbose, safety-critical language; AI can generate boilerplate and enforce patterns, but complexity is higher	Strict compiler checks, runtime safety constraints, limited ecosystem outside defense/aerospace	https://onecompiler.com/ada	~500–1,000 (defense, aerospace, safety-critical systems)
5	Fortran	55%	Scientific/numerical language; AI can automate routines, but legacy dialects and performance tuning add difficulty	Multiple dialects, runtime differences across compilers, optimization required for HPC workloads	https://onecompiler.com/fortran	~1,000–1,500 (HPC, scientific computing, aerospace research)
6	Cobol	45%	Business data processing language; verbose and rigid, AI can automate record layouts, but legacy quirks reduce ease	Mainframe dependency, runtime tied to proprietary systems, batch processing constraints	https://onecompiler.com/cobol	~2,000–3,000 (banking, insurance, government mainframes)
7	6502 Assembly	20%	Low-level assembly for an 8-bit processor; extremely granular, hardware-specific, and least automatable	Hardware-specific runtime, manual memory management, no abstraction layers, error-prone execution	https://www.masswerk.at/6502/assembler.html	<100 (retro hobbyist/emulator projects only)

COBOL

JSON Equivalents

{
  "analogy": {
    "javascript": {
      "associated_format": "JSON",
      "description": "JavaScript naturally produces and consumes JSON for structured data exchange."
    },
    "cobol": {
      "associated_formats": [
        "fixed-width records",
        "copybooks",
        "batch files",
        "VSAM datasets"
      ],
      "definitions": [
        {
          "format": "fixed-width records",
          "definition": "Data stored in strict column positions and lengths, commonly used in COBOL for payroll and banking."
        },
        {
          "format": "copybooks",
          "definition": "Reusable COBOL code blocks that define record layouts and field structures for consistent data handling."
        },
        {
          "format": "batch files",
          "definition": "Collections of records processed sequentially in scheduled jobs, typical in mainframe COBOL systems."
        },
        {
          "format": "VSAM datasets",
          "definition": "IBM's Virtual Storage Access Method files, used by COBOL programs for indexed and sequential data storage."
        }
      ]
    }
  }
}

Switch/Case

PROCEDURE DIVISION.
    DECLARE-VARIABLES SECTION.
        01 OPTION PIC X VALUE '1'.

    Main-Process.
        DISPLAY "Choose an option (1, 2, 3): ".
        ACCEPT OPTION.
        EVALUATE OPTION
            WHEN '1' GO TO Option-One
            WHEN '2' GO TO Option-Two
            WHEN '3' GO TO Option-Three
            WHEN OTHER GO TO Invalid-Option
        END-EVALUATE.

    Option-One.
        DISPLAY "Option 1 Selected".
        GO TO Main-Process.

    Option-Two.
        DISPLAY "Option 2 Selected".
        GO TO Main-Process.

    Option-Three.
        DISPLAY "Option 3 Selected".
        GO TO Main-Process.

    Invalid-Option.
        DISPLAY "Invalid Option".
        GO TO Main-Process.

    STOP RUN.

Loops

GOTO Statement

IDENTIFICATION DIVISION.
PROGRAM-ID. SpacebarLoop.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 KEY-CHAR PIC X.
01 CONTINUE-LOOP PIC X VALUE 'Y'.

PROCEDURE DIVISION.
    Main-Loop.
        DISPLAY "Press any key (press SPACE to stop): "
        ACCEPT KEY-CHAR
        IF KEY-CHAR = SPACE
            MOVE 'N' TO CONTINUE-LOOP
        ELSE
            MOVE 'Y' TO CONTINUE-LOOP
        END-IF
        IF CONTINUE-LOOP = 'Y'
            GO TO Main-Loop
        END-IF.
    STOP RUN.

PERFORM Statement

IDENTIFICATION DIVISION. PROGRAM-ID. SpacebarLoop.

DATA DIVISION. WORKING-STORAGE SECTION. 01 KEY-CHAR PIC X. 01 CONTINUE-LOOP PIC X VALUE 'Y'.

PROCEDURE DIVISION. PERFORM UNTIL CONTINUE-LOOP = 'N' DISPLAY "Press any key (press SPACE to stop): " ACCEPT KEY-CHAR IF KEY-CHAR = SPACE MOVE 'N' TO CONTINUE-LOOP ELSE MOVE 'Y' TO CONTINUE-LOOP END-IF END-PERFORM. STOP RUN.

Fortran

ISO Date

program validate_iso_date
    implicit none
    character(len=19) :: isoDate
    integer :: year, month, day, hour, minute, second
    logical :: isValid

    isoDate = '2023-12-31T23:59:59'

    read(isoDate(1:4), '(I4)') year
    read(isoDate(6:7), '(I2)') month
    read(isoDate(9:10), '(I2)') day
    read(isoDate(12:13), '(I2)') hour
    read(isoDate(15:16), '(I2)') minute
    read(isoDate(18:19), '(I2)') second

    isValid = .false.
    if (year >= 1000 .and. year <= 9999) then
        if (month >= 1 .and. month <= 12) then
            if (day >= 1 .and. day <= 31) then
                if (hour >= 0 .and. hour <= 23) then
                    if (minute >= 0 .and. minute <= 59) then
                        if (second >= 0 .and. second <= 59) then
                            isValid = .true.
                        endif
                    endif
                endif
            endif
        endif
    endif

    if (isValid) then
        print *, 'Valid ISO 8601 date'
    else
        print *, 'Invalid ISO 8601 date'
    endif
end program validate_iso_date

Fortran Cobol EDI - sgml/signature GitHub Wiki

Flat to Hierarchical Roundtrip

S-Expr to EDI Roundtrip

COBOL vs QBasic: Lack of Function Boundaries — System Limitations and Counterexamples

COBOL vs QBasic: Data Format Comparison

1. Fixed‑Width Record Files

COBOL

QBasic

2. Variable‑Length Record Files (VLR / VSAM / QSAM)

COBOL

QBasic

3. Pipe‑Delimited / Tab‑Delimited / Custom‑Delimited Text

COBOL

QBasic

4. COBOL‑Friendly Binary Formats (COMP, COMP‑3, COMP‑5)

COBOL

QBasic

5. Flat‑File Hierarchical Formats (non‑EDI, non‑HL7)

COBOL

QBasic

6. Custom Copybook‑Driven Enterprise Formats

COBOL

QBasic

Non Enterprise EDI Training Paths for Universities, Colleges, and Nonprofits

Open Source EDI Tools for Instruction

Standards Body and Nonprofit Aligned Education

Academic Programs That Commonly Teach EDI

Community and Nonprofit Training Paths

Open Educational Resources

Summary

EDI Boilerplate

Boilerplate: Custom EDI Integration with Washington State Health Care Authority (HCA)

overview

history of edi and cobol

similarities between cobol copybooks and edi segment definitions

edi transactions supported

transport mechanisms

authentication

system components

edi envelope requirements

onboarding steps (no registration fees)

error handling

retry logic

security requirements

operational workflow

monitoring and observability

compliance

Training

Git Profiles

Emulators

COBOL

JSON Equivalents

Switch/Case

Loops

GOTO Statement

PERFORM Statement

Fortran

ISO Date

Obscurity

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️