overload of xc864 limit?

This is a 8051 chip, i.e. a 8-bit processor that will suffer whenever it does 16-bit operations.

Don't use an int variable unless a char variable is too small. See for example the index variable in your strcmp2() function. By the way - have you checked if your function is smaller than the Keil function? If the Keil function is written in assembler it may win significantly from your indexed code.

Don't use a variable when a constant can be used.
puts(array);
In this case, the compiler will have to add code to initialize array[] with values before you send it. That consumes a huge amount of code compared to the use of the text constant "AT+JRES" stored directly in the flash.

And why do you later bother to clear the contents from array[]. Isn't it enough to initialize a uchar to 0, to remember that you have 0 valid characters in the array?

Don't use software delays generated by busy loops like:

while (i<100) i++;

The compiler can - if you turn on optimization - decide to remove the loop, since there are no side effect in the loop, other than to assign the value 100 to i.

Don't use magic constants when you don't have to. The C language has characters constants '\r', '\t', '\n', '\b', ... available. And if you really do have to use constants, use enum or #define to give them a name. Same code size, but easier to read - and no need to have a comment "10 en decimal = <LF>"

You did try earlier with:

sprintf(array,"AT+JSEC=1,1,1,04,1111");

But sprintf() is string-print-formatted and you don't have any formatting. The function when assigning a string to a character array is strcpy().

As noted, your main() contains a large number of repetitions that performs just about the same thing, but with different modem strings. Break out the functionality into a separate function, and just send the string constant as a parameter to this function. That will save you a huge amount of code space.

Create a function that converts a number represented as hexadecimal ASCII string to the numeric value. If you need to convert very large numbers, you can do it in two steps. Let one function convert the string into an array of bytes. Then you can either keep and use this array as is, or convert to 16-bit or 32-bit values.

Do you really need an array of 7 long, i.e. may any of the seven numbers be larger than 65535, the max range of an unsigned 16-bit integer?

Most developers normally write all comment in english. This has several advantages. You may post your code to an international forum and way more people will understand the comments and be able to help you. If you later work for a larger company, that company may have english as official company language, i.e. requiring that all official documents, design documents, ... has to use english. The reason being that you may have to work in a team with other developers from other countries. And big companies often buys and sells products and code libraries in deals with companies from other countries.

In the end - you will be easy to shrink your code to half the current size by just writing modular code and think about reuse.

This is a 8051 chip, i.e. a 8-bit processor that will suffer whenever it does 16-bit operations.

Don't use an int variable unless a char variable is too small. See for example the index variable in your strcmp2() function. By the way - have you checked if your function is smaller than the Keil function? If the Keil function is written in assembler it may win significantly from your indexed code.

Don't use a variable when a constant can be used.
puts(array);
In this case, the compiler will have to add code to initialize array[] with values before you send it. That consumes a huge amount of code compared to the use of the text constant "AT+JRES" stored directly in the flash.

And why do you later bother to clear the contents from array[]. Isn't it enough to initialize a uchar to 0, to remember that you have 0 valid characters in the array?

Don't use software delays generated by busy loops like:

while (i<100) i++;

The compiler can - if you turn on optimization - decide to remove the loop, since there are no side effect in the loop, other than to assign the value 100 to i.

Don't use magic constants when you don't have to. The C language has characters constants '\r', '\t', '\n', '\b', ... available. And if you really do have to use constants, use enum or #define to give them a name. Same code size, but easier to read - and no need to have a comment "10 en decimal = <LF>"

You did try earlier with:

sprintf(array,"AT+JSEC=1,1,1,04,1111");

But sprintf() is string-print-formatted and you don't have any formatting. The function when assigning a string to a character array is strcpy().

As noted, your main() contains a large number of repetitions that performs just about the same thing, but with different modem strings. Break out the functionality into a separate function, and just send the string constant as a parameter to this function. That will save you a huge amount of code space.

Create a function that converts a number represented as hexadecimal ASCII string to the numeric value. If you need to convert very large numbers, you can do it in two steps. Let one function convert the string into an array of bytes. Then you can either keep and use this array as is, or convert to 16-bit or 32-bit values.

Do you really need an array of 7 long, i.e. may any of the seven numbers be larger than 65535, the max range of an unsigned 16-bit integer?

Most developers normally write all comment in english. This has several advantages. You may post your code to an international forum and way more people will understand the comments and be able to help you. If you later work for a larger company, that company may have english as official company language, i.e. requiring that all official documents, design documents, ... has to use english. The reason being that you may have to work in a team with other developers from other countries. And big companies often buys and sells products and code libraries in deals with companies from other countries.

In the end - you will be easy to shrink your code to half the current size by just writing modular code and think about reuse.