CL comparison validation range not working

Question

I'm validating some input; the input number should be from 1 to 255. And I try the following code. Input defined ;input DC CL60' ''

clc   input,=c'255'   
bh    loop1
clc   input,=c'1'     
bl    loop1
J     loop2 
loop1

The above validation is only working for 3 digits numbers ( from 100 to 255) But it is not working for two digit number. Could you please help me :)

Answer 1

A lot depends on how flexible you need to be with your "INPUT" field. For instance, if you need to process C'1 ', C' 1 ', C' 1', C'01 ', C' 01' and C'001' all the same way, then you have some extra work to do.

You have two choices in general. Either you can "normalize" your data into a three character field (in other words, make all the examples I mention above C'001'), or you can do some imaginative variable length compares to adapt to the size of the values you're trying to compare.

This will make more sense to you if you get a little deeper into how CLC works. If you look at the assembler listing of your program, you'll see the object code for the CLC you coded in hex...it'll be something like D5llsaaatbbb where:

• "D5" is the opcode - CLC
• "ll" is the length of the compare you're doing
• "s" is the first operand base register
• "aaa" is the first operand displacement
• "t" is the second operand base register
• "bbb" is the second operand displacement

So if your input field is indeed DC CL60' ', and it's stored at 100 bytes off of register 10 and the literal (=C'whatever') is 40 bytes off of register 12 you'd see D53BA064C028. Code enough assembler and you'll be reading these things like they were English. :)

As one of the other posters points out, the assembler defaults the length to the length of the first operand, so right off the bat, you have a problem since the comparison you're doing (clc input,=C'1') causes the assembler to generate a 60 byte compare, even though the second operand is only one byte long. If you wanted to do it this way, you'd need do code it as clc input,=CL60'1 ...'. This is why it's usually more convenient to either code the instruction "backwards" (as in clc =C'1',input) or explicitly specify the length (as in clc input(1),=C'1') so that you don't inadvertently run past the end of the field you're comparing against.

Next issue you run into is making the compare a variable length one. Many times, you'll want to figure out how many digits you have, and then compare this many digits rather than the length of the field. For instance, you might look at data coded as ' 1' and decide to skip the blanks and just check the field as a one-byte value. For this sort of thing, the execute (EX) instruction is your friend - it gives you an easy way to have a variable-length comparison.

Let's say you figure out that the user entered a single byte and thus you want a single byte CLC. Assuming the length you want is in a register, the code would look like this:

* Assume you have the length in R1
       BCTR R1,0         Don't forget lengths are 0-relative (00 = 1 byte, FF=256)
       EX   R1,MYCLC     Do the comparison using the length in R1
       J    *+10         Skip over the CLC instruction
MYCLC  CLC  INPUT(0),PATTERN       Executed instruction

The EX instruction uses the first operand to update the target instruction, and then executes it. In the example, EX uses the value in R1 to set the length in the CLC, giving you a variable-length comparison. Note the length of 0 - the object code would be D500 in this case, EX "OR's" the low-order bits of R1 with the 00 to give you the length you want. Simple, right?

The last piece of the puzzle is some parsing on your INPUT field, assuming it's a free form field that can contain things like blanks. A common need for this is finding the initial non-blank field in a longer string...here, translate-and-test (TRT) is your friend. I won't bore you with the details, but it gives you a single instruction that can scan a field to find any particular character - a non-blank or a blank, for example. A pair of TRT instructions can help you find the start and end of any delimited string, similar to strchr() in C (if you're a C programmer). A little subtraction to get some lengths, and you're all set to do what you need with the variable-length comparison explained above.

As you code more assembler, you'll figure out all the little tricks that make these tasks easier. For example, a "feature" of EBCDIC is that the hex encoding of digits are at the top of the scale: F0 to F9. That means that in many simple apps, you don't really have to deal with your case of "higher than 999" because all the alpha and typical symbols are lower than a C'0'...just checking for not less than a 0 is usually adequate for character data.

Anyway, a few of the hints here should get you going, and I'm sure you'll have no trouble getting the result you expect with a little more research.

Answer 2

When the assembler generates the length for the comparison it is based on the first operand. You do not show this in the code but my assumption it is something like

INPUT DS CL3

In this case, the instruction CLC input,=c'1' is comparing a three byte field with 1 character literal. So, you are comparing a three byte area to a three byte area that is a 1 character value so the second two bytes are undefined.

If you want to base the comparison based on the literal you could do this instead:

         clc   =c'255',input   
         bh    loop1
         clc   =c'1',input     
         bl    loop1
         J     loop2 
loop1

There are better approaches though. You could convert the input to a packed decimal format and then do a numerical comparison.

For instance, assume this is your code:

             PACK DecimalInput,Input  
             CP   DecimalInput,=P'255'  
             BH   TooHigh  
             CP   DecimalInput,=P'1'  
             BL   TooLow
JustRight    DS  0H


DecimalInput DS   PL3 
Input        DS   CL3  

Of course, you'll need to validate they are numbers or you'll end up with an S0C7.