It's good overall, and for a toy or class program this is adequate, but it's been a while since I've done a review, so it's time to get super picky :).

There is a very major problem in that the IO handling is wrong. Try firing up your program, and instead of a valid number of items to sum, put in something non-numeric. It will infinite loop.

In short, scanf doesn't move forward in a stream when it doesn't consume anything¹. You'll need to either read a line at a time (fgets) and parse an integer out of the line, or you'll need to consume the rest of the line and try again (the easiest approach to that would be to loop on getline until you get a \n).

In a similar vein, your input reading in the loop to collect inputs is just wrong. All it takes is a single incorrect input and the program falls apart.

¹ It might be worth noting at this point that scanf has other problems as well.

There's also some portability issues. Before C99, variable length arrays are not required to be supported by the standard, and after C99, they're standardized but not required. This means that C99 is the only standard that requires VLA. That's a pretty precarious situation to put yourself in.

In case you're not sure what I'm talking about, arr is the variable length array since num is not a compile-time constant (there's magic going on under the hood — it's not a normal array, the compiler is just hiding that).

(Realistically, every compiler you're going to come across is going to support this. Just one of the many gotchas in C with regards to portability if you're ever going to experience a truly rare environment.)

I don't understand why the array and sum are unsigned. Seems the same functionality would work just as well if you were to allow signed numbers? The only reason I can think of for using unsigned values is if you're trying to eke out a little more range, but that's probably misguided and if a 64 bit integer isn't large enough, you're probably into arbitrary precision land.

In short, I think all of your unsigned long long stuff should just be long long int or int64_t (from stdint.h). Even though long long int is actually guaranteed to be 64 bits or more whereas int64_t is required to be exactly 64 bits (and is not required to be supported), I think int64_t is clearer to read (and realistically, if long long exists, int64_t is going to exist).

This is mildly controversial, but I'm not really a fan of short unless you're doing it because you actually need a specific size (memory constrained stuff, you're going to have a lot of them, alignment issues, etc). ints come across a bit more naturally to work with, and depending on CPU architecture, a short is probably being treated as an int anyway.

You should always compile with warnings enabled. A good compiler should have warned you…

$ clang -Wall -o sumaster sumaster.c
sumaster.c:10:21: warning: format specifies type 'int *' but the argument has
      type 'unsigned short *' [-Wformat]
        scanf("%d", &num);
               ~~   ^~~~
               %hd
1 warning generated.

As a result, I can do this (results will vary, since it's undefined behaviour):

Enter number of values to sum: -2147483645
1
+
2
+
3
=
6

The scanf() function is actually quite difficult to use correctly, especially when error handling needs to be done. For example, what happens in your program when, at the "Enter number of values to sum: " prompt, you hit CtrlD (Unix) or CtrlZ (Windows) to generate an end-of-file condition? What about if you enter A⏎? Both cases result in an infinite loop. One remedy is to rely on fgets() instead; another is to discard any bad input up to the first newline before retrying.

Since an error-tolerant number input routine is rather complicated, it makes sense to define a function for it.

Unsigned numbers are actually tricky to work with. Your num <= 0 comparison, for example, actually behaves as num == 0, since num will never be negative.

Surprisingly, your program will accept and add negative numbers as well (though, once again, it's undefined behaviour that you can't count on).

Due to these deceptive behaviours, you're better off using signed data types (and performing validation if you want to prohibit negative numbers). There is also not much point to using a data type narrower than an int. Compilers will likely pad the short for memory alignment anyway, so you wouldn't save space. A short would only make sense if you're dealing with a binary file or network protocol where the exact size matters (in which case an explicitly sized type like int16_t would be more appropriate anyway) or if you have an array that is large enough so that the space matters.

There isn't any point to storing all of the inputs in an array. You could achieve the same effect by just keeping the running total.

Suggested solution

#include <stdio.h>

/**
 * Prompts the user using the given prompt until a long long int is
 * successfully read.  If the input is not an integer, prints err_msg
 * and prompts the user again.
 *
 * Returns 1 on success, or 0 if EOF is encountered.
 */    
static int prompt_ll(const char *prompt, long long *n, const char *err_msg)
{
    do
    {
        printf("%s", prompt);
        switch (scanf("%lld", n))
        {
          case EOF:
            return 0;
          case 1:
            return 1;
          default:
            scanf("%*[^\n]");   /* Discard the rest of the bad line */
            printf("%s", err_msg);
        }
    } while (1);
}

int main(void)
{
    long long n;
    do
    {
        if (!prompt_ll("Enter number of values to sum: ", &n, "")) return 1;
        if (0 <= n && n < 256) break;
        printf("Enter a number between 0 and 255.\n");
    } while (1);
    int num = (int)n;

    long long total = 0;
    for (int i = 0; i < num; i++)
    {
        if (!prompt_ll(i ? "+\n" : "", &n, "Try again.\n")) return 1;
        total += n;
    }
    printf("=\n%lld\n", total);
}