ERROR: Array subscript out of range at line xxx column xx

[leehsin]

Hi,

I got the error shown in the title: ERROR: Array subscript out of range at line xxx column xx. There were many cases I found online asking for the similar question, but none of them came from my case. 

Here is my code:

    ARRAY codes(*)  MODIFIER1
                    MODIFIER2
                    MODIFIER3
                    MODIFIER4
                    ;

    DO i = 1 TO DIM(codes);
        IF MISSING(vsCptMod)
           & ^htCptMod.find(KEY: codes[i])
            THEN vsCptMod = i;
        IF MISSING(vsTelMod)
           & ^htTelMod.find(KEY: codes[i])
            THEN vsTelMod = i;
    END;

I couldn't find the code issue causing the error. Is there any solution available from the community?

Thanks a lot !

[Reeza]

Post the actual error message from the log.

[Reeza]

I'm assuming this is using a hash table or DS2 since FIND() isn't used that where anywhere else.

[Shmuel]

There are two find functions in your code.

in case the first find is the last member - then the next find starts from dim(codes).

I suggest to replace the coed with:

    ARRAY codes(*)  MODIFIER1 -  MODIFIER4  ;

    DO i = 1 TO DIM(codes);
        IF MISSING(vsCptMod)
           & ^htCptMod.find(KEY: codes[i])
            THEN vsCptMod = i;
   END;
   DO i = 1 TO DIM(codes);
        IF MISSING(vsTelMod)
           & ^htTelMod.find(KEY: codes[i])
            THEN vsTelMod = i;
    END;

[leehsin]

This will work. Thanks 🙂

[leehsin]

Yes, this uses hash table. Sorry I can't post the log as I have a length code with various macro variables, and the log before and after this error message have many, many variable names involved. The good news is that I found the bug in my code, and it was fixed. It was not related to the code that I initially thought about. Thank you!

[Tom]

Since you didn't post the log we can't tell which line it is talking about.  Or if there are multiple places that are indexing into an array on that line which one is causing the error.

[leehsin]

Sorry, I couldn't post the log as it was very lengthy. I found a bug and solved the problem which is another coding issue that affected the code I presented here. Thanks!

[PaigeMiller]

---

@leehsin wrote:

Hi,

I got the error shown in the title: ERROR: Array subscript out of range at line xxx column xx.

---

The log will show you which line this is, and exactly where in the line (the column number) the error happens.

[leehsin]

Yes. Thanks!

[hashman]

@leehsin :

The only  logical reason it can happen given your code excerpt:

-- the loop index I is modified in the first IF statement inside the loop to a value outside the array bounds

-- when the second IF is executed, the codes[i] reference given to the KEY argument tag in FIND gets the runaway index value 

Reasoning still further, the only instruction in the first IF that can modify index I is the FIND method call. And it can modify it only if:

-- hash variable I is defined to the data portion of the hash table 

-- the FIND call is successful

To prevent this from happening in any case - even if I is in the data portion (I don't know why it should be but you must now better) - refrain from calling the FIND method where it serves no function except finding if the key-value is in the table. You only need to check if codes[i] is in the table, not retrieve anything from it. Yet if I is in the data portion and FIND is successful, the hash value of I will overwrite the value of its PDV host variable I - that is, your array index. Thus, call CHECK instead of FIND. This method, unlike FIND, is designed to only check (as its name implies) whether the key-value is in the table and does not overwrite any PDV host variables regardless of whether the CHECK call is successful (i.e. the key-value is in the table) or not.

Incidentally, calling FIND instead of CHECK is a typical mistake made by hash newbies. Always call CHECK (and never FIND) if all you want to do is to find if a key-value is in the table. In addition to being harmless to the PDV host variables, CHECK also executes faster than FIND since it causes no data movement from the hash table to the PDV.

Kind regards

Paul D. 

[leehsin]

Hi, Hashman! I like your logic reasoning! Also I learned from you to use CHECK instead of FIND to look for a key value in hash table. Thank you so much!

[hashman]

@leehsin:

Thanks for the nice words.

Bear in mind that in order to use the hash object conscientiously, one must understand that it's merely a table in memory endowed with a number of standard CRUD operations that can be performed against it using hash methods and operators. Thus, certain methods represent certain table operations, for example:

• CHECK: Search (pure lookup, no data retrieval)
• FIND: Retrieve (i.e. search and if the key is found, extract the data from the hash to the PDV)
• ADD: Insert (either unconditional if multidata:"Y", or only if the key is not in the table otherwise) 
• REF: Insert only if the key is not already in the table   
• REPLACE: Update if the key is in the table, otherwise Insert
• FIRST/NEXT, LAST/PREV: Enumerate, i.e. scan the table items sequentially
• FIND_NEXT/DO_OVER: Keynumerate (aka Keyed Enumeration), i.e. scan the table items sequentially within a given same-key item group 
• ... and so on

The list, of course, is not exhaustive. You can find a concise introduction into this kind of concept at:

https://support.sas.com/resources/papers/proceedings17/0821-2017.pdf

And this is the concept upon which the hash book @DonH and I have written is structured, which is why its title contains the phrase "Hash Table Operations". Here's a shameless plug:

https://www.sas.com/store/books/categories/examples/data-management-solutions-using-sas-hash-table-o...

Kind regards

Paul D.

[leehsin]

Thanks again, Hashman! You extend my understanding about hash table a lot!