Option 4: Batch and Export Gateway (DCS Level 1 assured + Level 2)

Solution overview

This solution intercepts outbound data flows from JLTS -- nightly batch feeds to national systems, weekly summary reports, and any ad-hoc data exports -- and applies DCS labeling and filtering before the data leaves the mainframe environment. Unlike the TN3270 proxy (Option 3) which handles interactive access, this component handles data at rest and data in transit to external consumers.

This is also where STANAG 4778 assured labeling (cryptographically bound metadata) can be applied, since the gateway produces new output files rather than modifying data in place.

Scenario reference

Addresses: Scenario 03 -- Legacy System DCS Retrofit DCS Level: Level 1 (Assured Labeling on export) + Level 2 (Filtered exports) Dependencies: Option 1 (shadow label store) Optional dependency: Option 2 (user attribute store) -- only needed if exports are filtered per-recipient

The problem

JLTS has three categories of outbound data flow, none of which are currently labeled or filtered:

1. National batch feeds (nightly)

Eight national logistics systems receive nightly data feeds from JLTS via FTP. Each feed is a flat file (fixed-width EBCDIC records) containing supply requests, movement updates, and status changes relevant to that nation. The feeds are generated by batch COBOL programs that run under JCL.

Current state: Each nation's feed contains all records, regardless of classification or releasability. The French feed includes records marked (informally, by convention) as REL_TO:GBR,USA only. The batch programs have no concept of filtering by recipient nation.

2. Weekly summary reports

COBOL batch programs generate formatted reports (print files) distributed via secure email to NATO HQ staff and national representatives. Reports include logistics summaries, supply status, and movement tracking.

Current state: All recipients receive the same reports with the same content, regardless of clearance or nationality.

3. Ad-hoc exports

Occasionally, JLTS administrators extract data using DB2 utilities (DSNTEP2, SPUFI) for special requests -- audit queries, exercise planning data, or one-off reports. These are unstructured and unpredictable.

Current state: No controls beyond RACF authorisation to run the DB2 utility.

How it works

Architecture

The gateway sits between JLTS batch output and the delivery mechanisms (FTP, email, file transfer):

Gateway processing pipeline

For each batch output file, the gateway performs:

Step 1: Identify the output

The gateway is configured with a manifest of known batch outputs:

batch_outputs:
  - job_name: JLTS_FRA_FEED
    output_dataset: JLTS.FEEDS.FRANCE
    recipient_nation: FRA
    record_format: FIXED
    record_length: 400
    key_position: {offset: 0, length: 10}
    key_table: JLTS.SUPPLY_REQUESTS

  - job_name: JLTS_WEEKLY_RPT
    output_dataset: JLTS.REPORTS.WEEKLY
    recipient_clearance: NC  # report distributed at NC level
    format: PRINT

Step 2: Look up labels

For each record in the output file, the gateway extracts the primary key and queries the shadow label store (Option 1) for the record's classification and releasability.

Step 3: Filter by recipient

For national feeds, the gateway filters based on the recipient nation's attributes:

• Records classified above the feed's target classification → removed
• Records with releasability restrictions excluding the recipient nation → removed
• Fields within records that exceed the recipient's clearance → redacted (replaced with spaces or a redaction marker)

For reports, the gateway can produce multiple versions at different classification levels, or a single version filtered to the lowest common clearance of the distribution list.

Step 4: Apply STANAG 4778 labels

This is where the gateway adds real value beyond the TN3270 proxy. Because the gateway produces new output files (not modifying data in place), it can:

1. Generate a confidentiality metadata label per ADatP-4774 for each record or document
2. Bind the label to the data using a digital signature per ADatP-4778
3. Include the label in the output file as a header, sidecar file, or embedded metadata (depending on the output format)

This produces assured Level 1 labels -- cryptographically bound, tamper-evident, standards-compliant. The shadow labels inside DB2 are basic Level 1; the export labels are assured Level 1.

Step 5: Sign and deliver

The gateway digitally signs the complete output file (providing integrity for the file as a whole) and delivers it through the existing FTP/email channels.

Integration with existing JCL

The gateway integrates into the existing batch schedule by modifying the JCL job streams. Instead of:

//STEP1    EXEC PGM=JLTSFEED
//OUTPUT   DD DSN=JLTS.FEEDS.FRANCE,DISP=(NEW,CATLG)
//STEP2    EXEC PGM=FTPBATCH
//INPUT    DD DSN=JLTS.FEEDS.FRANCE

The JCL becomes:

//STEP1    EXEC PGM=JLTSFEED
//OUTPUT   DD DSN=JLTS.FEEDS.FRANCE.RAW,DISP=(NEW,CATLG)
//STEP2    EXEC PGM=DCSGATEW
//INPUT    DD DSN=JLTS.FEEDS.FRANCE.RAW
//OUTPUT   DD DSN=JLTS.FEEDS.FRANCE,DISP=(NEW,CATLG)
//LABELS   DD DSN=JLTS.DCS.LABELS
//CONFIG   DD DSN=JLTS.DCS.CONFIG(FRAFEED)
//STEP3    EXEC PGM=FTPBATCH
//INPUT    DD DSN=JLTS.FEEDS.FRANCE

The COBOL programs are unchanged. Only the JCL is modified to insert the gateway step between output generation and delivery. This is a low-risk change that the existing operations team can manage.

Ad-hoc export controls

For ad-hoc DB2 extracts, the gateway can't intercept directly (the user is running SQL interactively). Options:

• DB2 exit routine: A DB2 user exit that logs all DSNTEP2/SPUFI queries and flags extracts of sensitive tables for review
• Dataset-level controls: RACF rules that prevent direct write to exportable datasets without going through the gateway
• Procedural controls: Require all ad-hoc extracts to be submitted as batch jobs that include the gateway step

Recommendation: Procedural controls backed by RACF dataset rules. Ad-hoc extracts are rare (the scenario says ~15 auditors, quarterly) and can be managed through process rather than technology.

Advantages

1. Assured labeling: Produces STANAG 4778 compliant labels on exported data -- the only component that achieves assured Level 1
2. Per-recipient filtering: Each national feed contains only data that nation is authorised to see
3. Minimal COBOL changes: Only JCL modifications, not application code
4. Existing delivery channels: Uses the same FTP and email infrastructure already in place
5. Batch-friendly: Runs as a batch step, natural fit for the mainframe operational model
6. Auditable: Full log of what was included/excluded in each export and why

Disadvantages

1. Batch-only: Does not cover interactive access (that's Option 3)
2. JCL changes required: While not COBOL changes, JCL modifications still require testing and change management
3. Output format knowledge: The gateway must understand the record layout of each batch output file
4. STANAG 4778 implementation: Implementing the binding mechanism requires cryptographic libraries on z/OS (or an off-mainframe signing service)
5. Doesn't protect data at rest: Data inside JLTS DB2 remains unlabeled in the assured sense -- only exports get assured labels
6. Latency: Adds processing time to batch jobs (acceptable for nightly/weekly runs, but needs sizing)

Acceptance criteria coverage

From Scenario 03:

• ✅ AC1: Automatic Content Labeling -- Applies labels from shadow store to exports, plus STANAG 4778 binding
• ⚠️ AC2: User Attribute Integration -- Uses recipient nation attributes, not individual user attributes
• ✅ AC3: Policy-Based Access Control -- Filters exports based on recipient clearance and nationality
• ✅ AC4: Dynamic Content Filtering -- Removes or redacts records/fields in exports
• ✅ AC5: Granular Filtering -- Record-level and field-level filtering in batch outputs
• ✅ AC6: Multiple Content Types -- Handles flat files and print reports
• ✅ AC7: Seamless Integration -- JCL changes only, no application code changes
• ✅ AC8: Performance -- Batch processing, no interactive latency impact
• ✅ AC9: Comprehensive Audit Trail -- Full export audit log
• ✅ AC10: Policy Management -- Gateway configuration defines filtering rules per recipient
• ✅ AC11: Accuracy and Reliability -- Deterministic filtering based on pre-computed labels
• ✅ AC12: Mixed Sensitivity Handling -- Field-level filtering handles mixed sensitivity records

Technology stack

• Gateway program: COBOL, Java (via z/OS Java batch), or an off-mainframe service called from JCL
• Shadow label store access: DB2 SQL
• STANAG 4778 binding: Cryptographic library (IBM ICSF on z/OS, or off-mainframe signing service)
• Digital signatures: X.509 certificates managed through RACF or external PKI
• Audit logging: SMF records or external log aggregation

Implementation complexity

Complexity: Medium

The gateway is conceptually straightforward (read file, look up labels, filter, write file). The complexity is in: - Understanding the record layouts of all batch output files - Implementing STANAG 4778 binding correctly (cryptographic standards compliance) - Testing that filtering doesn't break downstream national systems that expect specific record formats - Handling the variety of output formats (fixed-width flat files, print files, potentially CSV)

Operational fit

This component is essential for any organisation that shares JLTS data with external systems. The TN3270 proxy (Option 3) protects interactive users, but without the batch gateway, nightly feeds continue to send unfiltered, unlabeled data to 8 national systems.

The batch gateway is also the natural place to achieve STANAG 4778 compliance, since it produces new files that can include cryptographically bound labels. This makes it the component that external auditors and NATO compliance reviewers will care about most.

Deployment approach: 1. Start with one national feed (lowest risk, most cooperative national partner) 2. Validate that the filtered feed doesn't break the receiving national system 3. Expand to remaining national feeds 4. Add report filtering 5. Implement STANAG 4778 binding once the filtering pipeline is stable

---

Handles outbound data flows from JLTS. Applies filtering and STANAG 4778 assured labeling to batch feeds and reports. Complements Option 3 (TN3270 proxy) which covers interactive access. Depends on Option 1 (shadow label store) for classification data.