Quiz: From Batch to Real-Time: A Full Migration Project
Multiple Choice
1. Why does the HSA payment system use persistent MQ messages instead of non-persistent messages?
a) Persistent messages are faster b) Persistent messages survive queue manager restart, ensuring no transactions are lost c) Non-persistent messages cannot carry JSON payloads d) DB2 requires persistent messages for SQL access
2. What is the purpose of the backout threshold (BOTHRESH) in the MQ queue definition?
a) To limit the number of messages on the queue b) To move "poison messages" to a dead-letter queue after N failed processing attempts c) To set the maximum message size d) To control the queue's persistence setting
3. Why does HSA-EVENTS check for duplicate messages before processing?
a) MQ always delivers messages exactly once b) MQ's guaranteed delivery may result in duplicate messages after failure/restart scenarios c) Duplicate checking is required by DB2 d) The MQ API requires it
4. What does the optimistic locking technique in HSA-EVENTS' UPDATE statement accomplish?
a) It prevents other programs from reading the account during the update b) It detects if another transaction modified the account between the SELECT and UPDATE, preventing lost updates c) It improves UPDATE performance by 50% d) It ensures the UPDATE runs within a specific time limit
5. In the reconciliation program, what does a "batch-only" record indicate?
a) The real-time system processed the transaction faster b) The batch system processed a transaction that the real-time system missed c) The batch system is running ahead of real-time d) A normal timing difference that resolves itself
6. Why is the 30-day zero-mismatch criterion so demanding?
a) Because the MQ specification requires 30 days of testing b) Because the system processes financial transactions where any error rate is unacceptable c) Because DB2 needs 30 days to build statistics d) Because CICS transactions require a 30-day warm-up period
7. Why does CLM-ADJUD continue to write to the batch flat file during the parallel-run period?
a) Because MQ cannot handle the full transaction volume b) To allow both the batch and real-time paths to process the same transactions for comparison c) Because the flat file is used for reporting d) Because the batch system cannot be modified
8. What is the purpose of the HSA-MONITOR program?
a) To replace the reconciliation program b) To detect real-time system problems (queue depth, error rates) before they affect production c) To start and stop the MQ queue manager d) To generate JSON messages for the API
9. In the cutover plan, why is the batch infrastructure preserved for 30 days after cutover?
a) Because VSAM files take 30 days to delete b) To provide a rollback path if the real-time system proves unreliable c) Because the JCL cannot be removed while jobs are scheduled d) Because DB2 needs batch access for maintenance
10. What is the "and" pattern used when modifying CLM-ADJUD for real-time processing?
a) Using AND in COBOL conditional statements b) The program does everything it did before AND also sends MQ messages, ensuring both paths work c) Running the batch AND real-time systems on the same LPAR d) Using DB2 AND VSAM simultaneously
Short Answer
11. Explain the difference between synchronous (REST API) and asynchronous (MQ) communication. Give one advantage and one disadvantage of each for the HSA payment use case.
12. What is a "poison message" in the context of MQ processing? How does the system prevent a poison message from blocking the queue?
13. Describe the merge-compare algorithm used in HSA-RECON. Why is it efficient for reconciliation?
14. Why did the migration project require cross-organizational training (Derek learning MedClaim, James learning GlobalBank)? Give a specific example from the chapter.
15. Explain why the cutover was scheduled for a Friday evening instead of, say, Monday morning. What operational considerations drove this timing?
Design Questions
16. The current system processes HSA payments for one partner (MedClaim). How would you extend the architecture to support multiple partners (e.g., 10 different insurance companies, each sending claims to GlobalBank)? What changes would be needed to the MQ design, the consumer program, and the monitoring?
17. Design a "circuit breaker" pattern for HSA-EVENTS: if the DB2 error rate exceeds a threshold, the program should stop processing messages temporarily and alert operations, rather than continuing to fail. Describe the data structure, the logic, and the recovery procedure.
18. If the 30-day parallel run revealed a consistent 0.01% mismatch rate (about 1 mismatch per day), would you proceed with cutover? What investigation would you perform? What would need to change before you would approve cutover?
Answer Key
1. b) Persistent messages survive queue manager restart. Non-persistent messages are lost if MQ restarts, which would mean lost financial transactions.
2. b) After N failed attempts (backcounts), the message is moved to the dead-letter queue instead of blocking the main queue. This prevents "poison messages" from halting all processing.
3. b) MQ's guaranteed delivery ensures messages are not lost, but after failures (network, queue manager restart), messages may be delivered more than once. Idempotent processing with duplicate detection handles this safely.
4. b) The AND HSA_BALANCE = :WS-HSA-BALANCE condition in the UPDATE detects concurrent modification. If another transaction changed the balance, the UPDATE affects zero rows, and the program handles the conflict.
5. b) A batch-only record means the batch path processed a transaction that the real-time path missed. This indicates a bug in the real-time path or a timing issue.
6. b) Financial transactions demand zero error rates. Even 0.01% means real money incorrectly processed. The 30-day criterion builds statistical confidence that the system is reliable.
7. b) Writing both the flat file and MQ messages allows both paths to process every transaction. The reconciliation program compares results, proving the real-time path produces identical outcomes.
8. b) Active monitoring detects problems (growing queue depth, error spikes, DLQ messages) in real time, enabling intervention before they affect end users or accumulate into larger failures.
9. b) Preserving the batch infrastructure provides a rollback path. If the real-time system fails catastrophically within the first 30 days, batch can be reactivated within minutes.
10. b) The "and" pattern means CLM-ADJUD does everything it always did (adjudicate, write flat file) AND also sends MQ messages. This ensures batch continues to work during parallel run.
11. Synchronous (REST): Advantage — immediate response/confirmation. Disadvantage — if GlobalBank is down, MedClaim's adjudication blocks. Asynchronous (MQ): Advantage — decoupled, MedClaim keeps processing even if GlobalBank is down. Disadvantage — no immediate confirmation; eventual consistency only.
12. A poison message is one that causes the consumer program to fail every time it is read (e.g., invalid format). BOTHRESH(5) causes MQ to move it to the dead-letter queue after 5 failures, unblocking the main queue for other messages.
13. Both sources are sorted by claim ID. The program advances through both simultaneously, comparing IDs. Equal IDs → compare. Unequal → the lower ID exists in only one source. It is O(n) — one pass through both sources regardless of volume.
14. The timezone bug required understanding both systems' date handling. Derek needed to know how MedClaim generated timestamps, and James needed to know how GlobalBank parsed them. Without cross-training, diagnosing the bug would have taken much longer.
15. Friday evening provides the weekend for monitoring. Transaction volume is lower on weekends, reducing risk. If problems emerge, there are two days to fix them before Monday's full volume. A Monday morning cutover would face full volume immediately with no buffer.
16-18. Open-ended design questions. Evaluate for scalability thinking, risk awareness, and practical operations knowledge.