The way you have defined your procedures (operators) the value of h is not taken until those procedures are called. So the value of h is not relevant at the moment the procedures are created.
When your loop is finished, the value of h is 51.
You problem is really about how to create a procedure with certain parameter values explicit in the procedure body. You problem isn't really about loop indexes. The name h needn't be a loop index, in order to have your need, is what I mean by that.
One way to get around this (quite intended behavior of procedures) by Maple is to declare h as global within the procedures. Since I consider using global variables to be poor programming I don't recommend this approach.
One popular other way is to use the unapply command from an expression in which the name h has already been replaced by a value. That's often short and convenient to do, but might not always suffice (or could be awkward to do properly) if your expressions aren't something you'd want fully evaluated. For your example the wrapping call to evalf is just such a wrinkle. See below.
Another way is to substitute the current value of (the loop index) h in as a replacement for a dummy name in a procedure (which acts like a template, then). This is more keystrokes, but pretty powerful.
You haven't show us the nature of any entries in and Q[i], or and x1[i] or y1[i] (for any i). So below I'll make something up.
If neither of these two approaches work for you, then upload the full code as a worksheet (big green arrow) and I expect it could be ironed out.
I should also mention that you can print the bodies of the procedures, to see/check how the two approaches work (while differing in nature from each other). Notice how one of these has replaced all of the Q[i][j] and x and y, etc (which you may or may not want to have happen), while the other has not.
s -> evalf([s, -s])
s -> evalf(subs(x = x1(s), y = y1(s), Q))
For the simple example shown, those approaches produce the same result. I could mention that the second will be slightly less efficient to run as each call to the procedures assigned to the Z[i][j] will perform the subs work (and so there would be duplication of effort when the same procedure is called for multiple values of the input s).