@Haile With u[2] = 0 use abserr = 1e-4  (also written 0.1e-3):
 

p1:=dsolve({sys}, numeric, abserr = 0.1e-3,continuation=cont,maxmesh=2048);

@tsunamiBTP Your last definition of T1 suffers from the problem I described earlier.
You have   T1 := m-> 2*sin(alpha)*(diff(S11, t));
When T1 is applied as in
T1(7);
the first that happens is that the input (7) is evaluated (there is not much to do, 7 is 7 after all).
After that the formal parameter m is replaced by 7 in the unevaluated body of the procedure, i.e. in 2*sin(alpha)*(diff(S11, t)).
But in fact there is no m there to be seen, so no change is made.
You need unapply!
##
When should we consider two procedures equal?
My answer would be that they should have exactly the same content. Yours don't.
Consider the following three simple procedures:

p1:=proc(x) local y; y:=x^2; y end proc;
p2:=proc(x) x^2 end proc;
is(eval(p1)=eval(p2)); # false
p3:=proc(y) y^2 end proc; # p1 with just a name change
is(eval(p3)=eval(p2)); # true

Let me add that I'm no big fan of using is and would never in my wildest dream have thought of applying is to compare procedures.

@Kitonum I don't think that this is a bug. A named procedure evaluates to its name.
So what you need to do is
 

is(eval(f1)=eval(f2));

which returns true.

Why do you want Maple 6? Since then there have been 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 2015, 2016, and 2017.

In any case the correct address for your inquiry is the maplesoft website:
maplesoft.com

I ran your code in Maple 2017.3 and didn't have any problem.
The plot:

What is the value of N?
The variable tot is not really used for anything, just assigned to 0.
Did you mean this code to run immediately after a restart? 

@Mariusz Iwaniuk Yes, only minute changes need to be made to the answer I gave in your link:
 

restart;
ode:=diff(y(x), x$3)+diff(y(x), x$2)+y(x)=1; 
#Now only 2 points, but with an additional requirement at 0, in this case D(y)(0) = a, where a is to be determined so that y(1) = 0:
#
p:=a->dsolve({ode,y(0)=0,y(2)=1,D(y)(0)=a},numeric,output=listprocedure);
#
p1:=proc(a) local Y1; Y1:=subs(p(a),y(x)); Y1(1) end proc;
#Just exploring the ground:
plots:-odeplot(p(-1),[x,y(x)],0..2);
#Now looking for a zero for p1, i.e. a value for a for which y(1) = 0 using a = -1 as an initial guess:
A:=fsolve(p1,-1);
p(A)(1);
plots:-odeplot(p(A),[x,y(x)],0..2);

@vv Yes, but that is to be expected since [0.3333] will remain [0.3333] after evaluation, whereas the evaluation of [0.3333]+[0] will involve doing 0.3333 + 0, which (with Digits=3) will result in 0.333.

@vv I see! Thank you.
It is important for this example that u is a name assigned to 0.3333 (when Digits=3).
When you take the number itself:

[0.3333+0] = [0.3333] + [0];

you get 0.333 = 0.333.

To make automatic simplification come first on both sides in the name assigned case we can do
 

'[u+0]' = '[u] + [0]';

which evaluates to [u] = [u]  and after %; to .3333 = .3333.
 

@vv Sorry, I don't get it.
Can you shows us such an example?

I'm not able to explain everything here, but will just mention two points that play a role:
1. The input of a floating point number alone as in 1.23456;  leaves all decimals even though Digits < 6. Only if arithmetic with floats come into play as in 1.23456 + 0; is Digits respected.
2. Automatic simplification kicks in here before arithmetic with floats:
 

1.23456;
%+0;

and here:
 

u:=1.23456;
u+0;

Thus the output as a consequence of point 1 is 1.23456 in both cases.

@gkokovidis It appears that in this case replacing the upper limit 5 by 5.0 doesn't actually give a result coming from numerical integration.
What happens is that numerical integration is indeed tried, but it fails after a valiant attempt, so it falls back on exact integration using method = ftoc (as it happens).
Try the following code and you will see this statement printed near the end:

" int: Numeric integration routines did not produce an answer, falling back to exact integration. "

restart;
infolevel[int]:=5:
g :=  sqrt(1/(1-x^2));
CodeTools:-Usage(int(g, x = 0 .. 5.0));

Using L:=int( g, x = 0..5)  followed by evalf(L)  is in this case much faster because time is not wasted trying to integrate numerically.
This fails because it doesn't fall back on exact integration (as designed).
 

restart;
g :=  sqrt(1/(1-x^2));
evalf(Int(g, x = 0 .. 5));
#int(f,x=0..5, numeric); # This is just an alternative syntax

I never tried those two buttons before. But they surely don't work for me either.
I'm using the exact same: Firefox 58.0.1 under Windows 10 (64 bit).

@acer Thanks for the explanation.
Just for the record, on my 64 bit Maple on Windows 10 I get the error
Error, (in Optimization:-LPSolve) invalid input parameter to external routine
for the 4 examples in your worksheet using hardware floats combined with method=activeset.

@tomleslie I wonder what your system is. I'm using Maple 2017.3 64 bit on Windows 10.
I checked the Maple versions 17.02, 18.02, 2015.2, 2016.2, and 2017.3 for problems with the examples in their respective help pages for LPSolve (which is being used by Maximize).
All but Maple 17.02 had critical failures (and at the end resulting in a crash) unless Digits:=16 (or above)!