COMPUTE WS-MAX-SUB = (LENGTH OF WS-STRING / LENGTH OF WS-INPUT-ITEM).
PERFORM UNTIL WS-SUB > WS-MAX-SUB
ADD 1 TO WS-POS
MOVE WS-STRING (WS-POS:LENGTH OF WS-INPUT-ITEM) TO WS-INPUT-ITEM (1:)
IF WS-INPUT-ITEM NOT NUMERIC
MOVE WS-SUB TO WS-ERROR-SUB
MOVE WS-MAX-SUB TO WS-SUB
END-IF
ADD 1 TO WS-SUB
ADD LENGTH OF WS-INPUT-ITEM TO WS-POS
END-PERFORM.
IF WS-ERROR-SUB > ZERO
DISPLAY 'SUB-STRING = ', WS-ERROR-SUB, ' IS NOT NUMERIC'
DISPLAY 'PLEASE REVIEW THIS DATA - VALIDATION PREMATURELY TERMINATED'
END-IF.
In this code, WS-MAX-SUB resolves as 30. The first '~' appears in WS-STRING at position 11 and subsequently at the "current' position plus 11. In between each '~', you'll find 10-bytes of data (a single sub-string).
This is based upon each sub-string being 10-bytes, which is the LENGTH OF WS-INPUT-ITEM.
WS-ERROR-SUB is set to the current value in WS-SUB when the current sub-string (found in WS-INPUT-ITEM) is NOT NUMERIC. When the PERFORM is completed, it's checked for a non-zero value. The PERFORM will be exited prematurely when the first NON NUMERIC sub-string is found.
Joined: 03 May 2010 Posts: 154 Location: Kuala Lumpur
Bill O'Boyle : As I mentioned earlier, I've some other input data in between numeric data like date, time & texts. So I can't follow your code. More are less it is checking each and every byte, which I've already used.
Bill Woodger:
1. I'm agreeing with your for replace NUMVAL with normal MOVE statement.
2. Anything <= SPACES will be non-process-able values(some times low-values). So I thought it is better to validate > SPACES.
3. If I follow UNSTRING with COUNT option,
a. I've to declare and process 30 more variables for COUNT
b. If there is SPACE in the input it will COUNT that as well. so I can't able to populate ZERO based on count.
for example: input = ' 1254', then count will be 6, so I'll populate 4 zeroes in front. So the values will be '0000 1254', which is incorrect.
Same goes for input = ' ' (all spaces), then count will be 10.
If I use INSPECT then it will replace all leading spaces into zeroes.
Am I missing anything ?
As for understand coding: We have number of programs coding and will have same structure as this, no need to go back and check what is the initial 'VALUE' for the TEMP variables as we follow 'SPACES' and 'ZEROES' for all TEMP variables we are using in whole program.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
One tip; If you're going to check each byte to be NUMERIC, check for NOT LESS THAN ZERO (X'F0') and NOT GREATER THAN '9' (X'F9'). This will generate two Assembler CLI (Compare Logical Immediate) instructions, which is far cheaper than a straight away NUMERIC check, which generates the far more expensive Assembler TRT (Translate and Test) instruction, utilizing a 256-byte translate-table built by the compiler and uses this byte-value as a displacement into the table (relative to zero), where the calculated table-address (when valid) will contain a X'00'.
Having attempted to understand your parsing/validation dilemma was a struggle, but apparently, there are hidden anomalies, which were not well documented, so my suggestions are over and good luck.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
If checking byte-for-byte, do as Mr Bill says. The advanntage of IF ... NUMERIC for multiple bytes is that the instruction "stops" as soon as it finds a non-numeric. For one byte, this is not an advantage.
For the rest, if you're happy, we're happy.
The code will be tested.
I don't think an individual user will notice difference in response time.
I think if we really knew what you wanted, the provider of the message could have done more for you.
Let's let you get on with it, and stop pointing out stuff which you already know or are uninterested in.
You know all the details. We don't. Means we spend more time that necessary, only to get things patted away by you.
Next time, give us all the information up front, please.