COBOL CONTINUE Statement
Master control flow and loop management with the CONTINUE statement. Learn how to improve code readability, handle conditional logic elegantly, and implement clean program structure in your COBOL applications.
Overview
The CONTINUE statement in COBOL is a no-operation statement that serves as an explicit placeholder in program logic. While it performs no actual processing, CONTINUE plays a crucial role in creating clear, readable, and maintainable code by explicitly documenting intentional "do nothing" paths in conditional structures and control flow logic.
CONTINUE is particularly valuable in complex conditional structures where certain conditions require no action, but you want to make it clear that this is intentional rather than an oversight. It helps eliminate ambiguity in code and makes the programmer's intent explicit, which is essential for long-term maintenance and debugging.
Modern COBOL programming emphasizes the use of CONTINUE as a best practice for creating self-documenting code. It represents a shift toward more explicit, readable programming styles that make code easier to understand, maintain, and modify over time.
Basic Syntax and Usage
Simple CONTINUE Statement
The CONTINUE statement has a very simple syntax - it's just the keyword CONTINUE followed by a period. Here's the basic structure:
123456789IF WS-STATUS-CODE = 'A' PERFORM PROCESS-ACTIVE-RECORD ELSE IF WS-STATUS-CODE = 'I' PERFORM PROCESS-INACTIVE-RECORD ELSE CONTINUE END-IF END-IF.
In this example, CONTINUE explicitly indicates that no action is required when the status code is neither 'A' nor 'I'. This makes it clear that the condition was considered and intentionally left without action, rather than being an oversight.
CONTINUE in EVALUATE Statements
CONTINUE is particularly useful in EVALUATE statements where some cases require no action:
123456789101112EVALUATE WS-TRANSACTION-TYPE WHEN 'SALE' PERFORM PROCESS-SALE WHEN 'RETURN' PERFORM PROCESS-RETURN WHEN 'VOID' CONTINUE WHEN 'INQUIRY' CONTINUE WHEN OTHER PERFORM HANDLE-INVALID-TRANSACTION END-EVALUATE.
This EVALUATE structure clearly shows that VOID and INQUIRY transactions are recognized but require no processing. Without CONTINUE, it might be unclear whether these cases were forgotten or intentionally left empty.
CONTINUE vs Empty Conditions
Compare the clarity difference between using CONTINUE and leaving conditions empty:
12345678910111213* Without CONTINUE - unclear intent IF WS-ERROR-FLAG = 'Y' PERFORM ERROR-HANDLING ELSE * Is this intentionally empty or forgotten? END-IF * With CONTINUE - clear intent IF WS-ERROR-FLAG = 'Y' PERFORM ERROR-HANDLING ELSE CONTINUE * Explicitly no action needed END-IF.
The version with CONTINUE makes it absolutely clear that the ELSE condition was considered and intentionally requires no action. This eliminates any ambiguity for future maintainers of the code.
Advanced CONTINUE Techniques
Complex Conditional Logic
CONTINUE becomes particularly valuable in complex conditional structures with multiple decision points:
123456789101112131415161718192021IF WS-CUSTOMER-TYPE = 'PREMIUM' IF WS-ORDER-AMOUNT > 1000 PERFORM APPLY-PREMIUM-DISCOUNT ELSE IF WS-ORDER-AMOUNT > 500 PERFORM APPLY-STANDARD-DISCOUNT ELSE CONTINUE * No discount for small premium orders END-IF END-IF ELSE IF WS-CUSTOMER-TYPE = 'STANDARD' IF WS-ORDER-AMOUNT > 2000 PERFORM APPLY-VOLUME-DISCOUNT ELSE CONTINUE * No discount for standard customers END-IF ELSE CONTINUE * No discount for other customer types END-IF END-IF.
This complex discount logic uses CONTINUE to clearly document all the conditions where no discount applies. Each CONTINUE statement makes the business rules explicit and prevents confusion about missing logic.
Loop Control with CONTINUE
CONTINUE can be used effectively in loop structures to handle special cases:
123456789101112131415161718PERFORM VARYING WS-INDEX FROM 1 BY 1 UNTIL WS-INDEX > WS-TABLE-SIZE IF WS-RECORD-TYPE(WS-INDEX) = 'HEADER' CONTINUE * Skip header records ELSE IF WS-RECORD-TYPE(WS-INDEX) = 'DETAIL' PERFORM PROCESS-DETAIL-RECORD ELSE IF WS-RECORD-TYPE(WS-INDEX) = 'SUMMARY' PERFORM PROCESS-SUMMARY-RECORD ELSE CONTINUE * Skip unknown record types END-IF END-IF END-IF END-PERFORM.
In this loop, CONTINUE explicitly documents that header records and unknown record types should be skipped. This makes the loop logic clear and prevents accidental processing of records that should be ignored.
Error Handling with CONTINUE
CONTINUE can be used in error handling to document acceptable error conditions:
123456789101112EVALUATE FILE-STATUS WHEN '00' CONTINUE * Normal completion - no action needed WHEN '02' CONTINUE * Duplicate key - acceptable in this context WHEN '10' MOVE 'Y' TO WS-END-OF-FILE WHEN '23' PERFORM HANDLE-KEY-NOT-FOUND WHEN OTHER PERFORM HANDLE-FATAL-ERROR END-EVALUATE.
This error handling structure uses CONTINUE to explicitly document that certain file status values are acceptable and require no action. This prevents future maintainers from thinking these cases were overlooked.
Tutorial: Building a Data Validation Framework
Let's create a comprehensive data validation framework that demonstrates the effective use of CONTINUE for clear control flow and explicit handling of various validation scenarios. This tutorial will show you how to build a robust system with clear, maintainable logic.
Step 1: Define Validation Structure
First, we'll establish the basic validation framework with clear data structures and control flow:
123456789101112WORKING-STORAGE SECTION. 01 WS-VALIDATION-CONTROL. 05 WS-VALIDATION-LEVEL PIC X(1). 88 BASIC-VALIDATION VALUE 'B'. 88 STANDARD-VALIDATION VALUE 'S'. 88 STRICT-VALIDATION VALUE 'T'. 05 WS-ERROR-COUNT PIC 9(3) VALUE ZERO. 05 WS-WARNING-COUNT PIC 9(3) VALUE ZERO. 05 WS-VALIDATION-STATUS PIC X(1). 88 VALIDATION-PASSED VALUE 'P'. 88 VALIDATION-FAILED VALUE 'F'. 88 VALIDATION-WARNING VALUE 'W'.
This structure defines different validation levels and status tracking. We'll use CONTINUE to handle cases where certain validation levels don't require specific actions, making the validation logic clear and explicit.
Step 2: Implement Field Validation Logic
Next, we'll create field validation logic that uses CONTINUE to handle different validation scenarios:
123456789101112131415161718192021222324252627VALIDATE-CUSTOMER-ID. EVALUATE TRUE WHEN WS-CUSTOMER-ID = SPACES IF STRICT-VALIDATION PERFORM LOG-VALIDATION-ERROR ADD 1 TO WS-ERROR-COUNT ELSE IF STANDARD-VALIDATION PERFORM LOG-VALIDATION-WARNING ADD 1 TO WS-WARNING-COUNT ELSE CONTINUE * Basic validation allows empty ID END-IF END-IF WHEN WS-CUSTOMER-ID IS NOT NUMERIC PERFORM LOG-VALIDATION-ERROR ADD 1 TO WS-ERROR-COUNT WHEN WS-CUSTOMER-ID < 1000 IF STRICT-VALIDATION OR STANDARD-VALIDATION PERFORM LOG-VALIDATION-WARNING ADD 1 TO WS-WARNING-COUNT ELSE CONTINUE * Basic validation accepts any numeric ID END-IF WHEN OTHER CONTINUE * Valid customer ID - no action needed END-EVALUATE.
This validation logic uses CONTINUE to explicitly document when no action is required for certain validation levels or conditions. This makes the validation rules clear and prevents confusion about missing logic.
Step 3: Implement Date Validation
Let's create date validation that handles different date formats and validation requirements:
1234567891011121314151617181920212223242526272829303132333435VALIDATE-ORDER-DATE. IF WS-ORDER-DATE = ZERO EVALUATE TRUE WHEN STRICT-VALIDATION PERFORM LOG-ERROR-MISSING-DATE ADD 1 TO WS-ERROR-COUNT WHEN STANDARD-VALIDATION PERFORM LOG-WARNING-MISSING-DATE ADD 1 TO WS-WARNING-COUNT WHEN BASIC-VALIDATION CONTINUE * Basic validation allows missing dates END-EVALUATE ELSE PERFORM CHECK-DATE-FORMAT IF WS-DATE-FORMAT-VALID = 'N' PERFORM LOG-ERROR-INVALID-DATE ADD 1 TO WS-ERROR-COUNT ELSE PERFORM CHECK-DATE-RANGE EVALUATE TRUE WHEN WS-DATE-TOO-OLD = 'Y' IF STRICT-VALIDATION PERFORM LOG-ERROR-DATE-TOO-OLD ADD 1 TO WS-ERROR-COUNT ELSE CONTINUE * Accept old dates in non-strict mode END-IF WHEN WS-DATE-FUTURE = 'Y' PERFORM LOG-WARNING-FUTURE-DATE ADD 1 TO WS-WARNING-COUNT WHEN OTHER CONTINUE * Valid date - no action needed END-EVALUATE END-IF END-IF.
The date validation uses CONTINUE to handle cases where certain date conditions are acceptable based on the validation level. This creates a flexible validation system with clear business rules.
Step 4: Implement Amount Validation
Now we'll create amount validation with different thresholds and rules:
12345678910111213141516171819202122232425262728293031323334VALIDATE-ORDER-AMOUNT. EVALUATE TRUE WHEN WS-ORDER-AMOUNT = ZERO IF STRICT-VALIDATION OR STANDARD-VALIDATION PERFORM LOG-WARNING-ZERO-AMOUNT ADD 1 TO WS-WARNING-COUNT ELSE CONTINUE * Basic validation allows zero amounts END-IF WHEN WS-ORDER-AMOUNT < ZERO PERFORM LOG-ERROR-NEGATIVE-AMOUNT ADD 1 TO WS-ERROR-COUNT WHEN WS-ORDER-AMOUNT > 100000 IF STRICT-VALIDATION PERFORM LOG-ERROR-AMOUNT-TOO-HIGH ADD 1 TO WS-ERROR-COUNT ELSE IF STANDARD-VALIDATION PERFORM LOG-WARNING-HIGH-AMOUNT ADD 1 TO WS-WARNING-COUNT ELSE CONTINUE * Basic validation has no upper limit END-IF END-IF WHEN WS-ORDER-AMOUNT < 10 IF STRICT-VALIDATION PERFORM LOG-WARNING-SMALL-AMOUNT ADD 1 TO WS-WARNING-COUNT ELSE CONTINUE * Accept small amounts in non-strict mode END-IF WHEN OTHER CONTINUE * Valid amount range - no action needed END-EVALUATE.
This amount validation demonstrates how CONTINUE can be used to create flexible validation rules that adapt to different business requirements while maintaining clear, readable logic.
Step 5: Implement Final Validation Summary
Finally, we'll create a summary routine that determines overall validation status:
123456789101112131415161718192021FINALIZE-VALIDATION-STATUS. EVALUATE TRUE WHEN WS-ERROR-COUNT > ZERO MOVE 'F' TO WS-VALIDATION-STATUS PERFORM LOG-VALIDATION-FAILED WHEN WS-WARNING-COUNT > ZERO EVALUATE TRUE WHEN STRICT-VALIDATION MOVE 'F' TO WS-VALIDATION-STATUS PERFORM LOG-VALIDATION-FAILED WHEN STANDARD-VALIDATION MOVE 'W' TO WS-VALIDATION-STATUS PERFORM LOG-VALIDATION-WARNING WHEN BASIC-VALIDATION MOVE 'P' TO WS-VALIDATION-STATUS CONTINUE * Warnings don't fail basic validation END-EVALUATE WHEN OTHER MOVE 'P' TO WS-VALIDATION-STATUS CONTINUE * No errors or warnings - validation passed END-EVALUATE.
The final validation summary uses CONTINUE to clearly document when no additional action is needed. This creates a complete validation framework with explicit handling of all possible scenarios.
Code Readability and Maintenance Benefits
Self-Documenting Code
CONTINUE transforms code into self-documenting logic that clearly expresses the programmer's intent:
1234567891011* Before - unclear intent IF WS-PROCESS-FLAG = 'Y' PERFORM MAIN-PROCESSING END-IF * After - clear intent with CONTINUE IF WS-PROCESS-FLAG = 'Y' PERFORM MAIN-PROCESSING ELSE CONTINUE * Intentionally no processing when flag is not Y END-IF.
The version with CONTINUE makes it explicit that the ELSE condition was considered and intentionally requires no action. This prevents future maintainers from wondering if something was forgotten.
Debugging and Troubleshooting
CONTINUE statements provide excellent breakpoint locations for debugging and can be enhanced with comments for troubleshooting:
123456789101112EVALUATE WS-RECORD-STATUS WHEN 'ACTIVE' PERFORM PROCESS-ACTIVE-RECORD WHEN 'PENDING' PERFORM PROCESS-PENDING-RECORD WHEN 'SUSPENDED' CONTINUE * DEBUG: Suspended records are skipped WHEN 'ARCHIVED' CONTINUE * DEBUG: Archived records are not processed WHEN OTHER PERFORM HANDLE-UNKNOWN-STATUS END-EVALUATE.
These CONTINUE statements with comments provide clear debugging information and can serve as breakpoint locations to verify that the correct logic path is being followed during testing and troubleshooting.
Future Enhancement Points
CONTINUE statements mark logical locations where future enhancements might be added:
123456789IF WS-CUSTOMER-TYPE = 'VIP' PERFORM VIP-PROCESSING ELSE IF WS-CUSTOMER-TYPE = 'PREMIUM' PERFORM PREMIUM-PROCESSING ELSE CONTINUE * TODO: Add standard customer processing END-IF END-IF.
CONTINUE statements with TODO comments clearly mark where additional functionality might be added in the future, making it easy to identify enhancement opportunities during code reviews and maintenance.
Practical Exercises
Exercise 1: Order Processing System
Create an order processing system that uses CONTINUE for clear control flow:
1234567* Implement processing for different order types: * - STANDARD orders: normal processing * - EXPRESS orders: expedited processing * - BULK orders: volume processing * - SAMPLE orders: no processing (use CONTINUE) * - CANCELLED orders: no processing (use CONTINUE) * Use CONTINUE to document intentional no-action cases
Solution Approach: Use EVALUATE or nested IF statements with CONTINUE to clearly document which order types require no processing. Include comments with CONTINUE to explain why no action is taken for specific order types.
Exercise 2: Employee Status Management
Build an employee status management system with various status handling:
1234567* Handle different employee statuses: * - ACTIVE: process payroll and benefits * - ON_LEAVE: process benefits only * - TERMINATED: no processing (use CONTINUE) * - RETIRED: no processing (use CONTINUE) * - SUSPENDED: conditional processing based on suspension type * Use CONTINUE appropriately for clear logic flow
Solution Approach: Create nested conditional structures that use CONTINUE to handle statuses that require no action. Document the business reasons for each CONTINUE statement to make the logic clear for future maintainers.
Exercise 3: Financial Transaction Validation
Design a financial transaction validation system with multiple validation levels:
1234567* Implement validation for transaction types: * - DEPOSIT: validate amount and account * - WITHDRAWAL: validate amount, account, and balance * - TRANSFER: validate both accounts and amount * - INQUIRY: no validation needed (use CONTINUE) * - BALANCE: no validation needed (use CONTINUE) * Include different validation strictness levels
Solution Approach: Create a comprehensive validation framework that uses CONTINUE to handle transaction types that don't require validation. Implement multiple validation levels and use CONTINUE to clearly document when validation steps are skipped.
Best Practices and Guidelines
When to Use CONTINUE
- When you want to explicitly document intentional no-action paths
- In complex conditional structures to improve readability
- To mark logical placeholders for future enhancements
- When debugging requires clear breakpoint locations
- To distinguish intentional empty conditions from oversights
- In EVALUATE statements where some cases require no action
Documentation and Comments
- Add comments to CONTINUE statements explaining why no action is taken
- Use TODO comments with CONTINUE for future enhancement points
- Document business rules that lead to CONTINUE decisions
- Include DEBUG comments for troubleshooting purposes
- Explain any complex logic that results in CONTINUE usage
- Reference requirements or specifications that justify CONTINUE
Code Organization
- Use consistent indentation with CONTINUE statements
- Group related CONTINUE cases together when possible
- Consider the logical flow when placing CONTINUE statements
- Maintain consistency in CONTINUE usage patterns across the application
- Review CONTINUE usage during code reviews for appropriateness
- Ensure CONTINUE statements enhance rather than clutter the code
Maintenance Considerations
Regular review of CONTINUE statements helps ensure they remain appropriate as business requirements evolve. What starts as a valid no-action case might later require processing as business rules change. Include CONTINUE statements in your code review process to verify they still serve their intended purpose.
When modifying code that contains CONTINUE statements, carefully consider whether the no-action logic is still appropriate. Update comments and documentation to reflect any changes in business logic that affect the rationale for CONTINUE usage.
Interactive Quiz
Test Your CONTINUE Knowledge
Question 1:
What is the primary purpose of the CONTINUE statement in COBOL?
Question 2:
How does CONTINUE improve code maintainability?
Question 3:
In which situations is CONTINUE most beneficial?