Re: SELECT block enhancement?

Here's another wrinkle, Mark, that's very similar.  I run into this all the time.  The basic design pattern is this: I am checking a record for some condition.  If the condition is met, great.  If not, then I have to check a different file.  Very similar to yours.  I'd like to see something like this:

CHAIN (X:Y:Z) ORDERLINE;

SELECT;

    WHEN OL_QTYREM = 0;
        STATUS = '90';

    WHEN OL_LINETYPE = 'C';
        STATUS = '80'';

    // It didn't match either condition, so now I have to check the header
    NOSELECT;
        CHAIN (X:Y) ORDERHEADER;

    WHEN OH_DIVISION = 'USA';
        STATUS = '60';

    OTHER;
        STATUS = '40';

ENDSL;

In this pattern, I always have to chain to the order line, but I don't always have to chain to the header.  Depending on how often the lines match one of the first conditions, this could significantly reduce my I/O.  So the compiler would see the "NOSELECT" clause and would execute that code prior to moving ahead to the next WHEN statement.

The is the kind of code that ends up in an IF/ENDIF block now, which isn't necessarily bad, but it does start indenting:

IF OL_QTYREM = 0;
    STATUS = '90';
ELSEIF OL_LINETYPE = 'C';
    STATUS = '80'';
ELSE;
    CHAIN (X:Y) ORDERHEADER;
    IF OH_DIVISION = 'USA';
        STATUS = '60';
    ELSE;
       STATUS = '40';
    ENDIF;
ENDIF;


On 1/28/2019 11:38 PM, mlazarus wrote:

I'm throwing this out there to see what people think of the idea.

Has anyone run into the need to have a "NEXT" or "CONTINUE" or "NOBREAK" opcode in a SELECT block?  It would move on to the next WHEN condition instead of exiting the entire SELECT block.

GotIt = *Off ;

SELECT ;
WHEN X = 1 ;
CHAIN FILE1 ;
IF %Found( FILE1 ) And DeleteFlag1 = *Blank ;
   GotIt = *On ;
ELSE ;
   NOBREAK ;
ENDIF ;

WHEN Not GotIt ;
CHAIN FILE2 ;
IF %Found( FILE2 ) And DeleteFlag2 = *Blank ;
   GotIt = *On ;
ELSE ;
   NOBREAK ;
ENDIF ;

WHEN Not GotIt ;
CHAIN FILE3 ;
IF %Found( FILE3 ) And DeleteFlag3 = *Blank ;
   GotIt = *On ;

ENDSL ;

  This is a simple example, but it demonstrates a desire to have a "cascading" set of conditions, using the existing SELECT structure, but allowing the next set of condition(s) to be executed, instead if needing to repeat the previous conditions or adding an exit value for nested conditions.

  We've all found ways around it, but I think it would be a nice addition.  It's basically the opposite of C's break opcode.

 -mark