Do you really mean you need to label the intersection (if so, use textplot3d), or do you really mean that you want to plot the intersection (if so, use intersectplot)?  For example:

with(plots):
S:= plot3d(x^2-y^2,x=-1..1,y=-1..1, colour=tan, style=patchnogrid):
P1:= plot3d([x,0,z],x=-1..1,z=-1..1.5, transparency=0.8, colour=violet, style=patchnogrid):
P2:= plot3d([0,y,z],y=-1..1,z=-1..1.5, transparency=0.8, colour=violet, style=patchnogrid):
P3:= plot3d([x,y,0],x=-1.2..2,y=-1.2..1.2, transparency=0.8, colour=violet, style=patchnogrid

L1:= intersectplot(surface(x^2-y^2,x=-1..1,y=-1..1),surface(y=0,x=-1..1,y=-1..1,z=-1..1), 
            thickness=2,colour=red):
L2:= intersectplot(surface(x^2-y^2,x=-1..1,y=-1..1),surface(x=0,x=-1..1,y=-1..1,z=-1..1), 
            thickness=2,colour=red):
L3:= intersectplot(surface(x^2-y^2,x=-1..1,y=-1..1),surface(z=0,x=-1..1,y=-1..1,z=-1..1), 
            thickness=2,colour=red):
display([S,P1,P2,P3,L1,L2,L3],  lightmodel=light1, orientation=[60,60], 
                   view=[-1.2..1.2, -1.2 .. 1.2, -1..1.5], scaling=constrained);

The problem is that Maple uses I for the imaginary number sqrt(-1).  If you want to use I for something else, you can change this, e.g.:

> interface(imaginaryunit=j);

after which your definition of V[rms] should be OK.

Curiously, the 2-D math input parser and the 1-D Maple input parser behave differently here: in 1-D Maple input, you would have had a warning rather than an error, and V[rms] would have been defined successfully.  This behaviour is preferable, I think, since there should be no problem with formal parameters or local variables having the same name as global objects, it being understood that within the body of the procedure being defined, the name refers to the formal parameter or local variable.

Despite its name, conformal in the plots package will also plot non-conformal maps (considered as maps of the complex plane into itself).  In this case

conformal(Re(z) + Re(z)*Im(z)*I,z=-3-3*I .. 3+3*I);

@sasomao : It looks to me like a problem arising outside of Maple, perhaps in the operating system or some other software.  Perhaps you have something that runs automatically (e.g. antivirus scanning) that for some reason is shutting down the Maple jobs.

Just express the inequality in terms of x and y, and you can use implicitplot to plot the region.  For example:

> ineq:= abs(z-3) <= 2*abs(z+3);
   plots[implicitplot](eval(ineq, z=x+I*y), x = -10 .. 10, y = -10 .. 10, gridrefine=3, filled=true);

That is one solution (if y(n) = 0 for n < 0), but not the only one.  You need to specify two initial values, e.g. y(0) and y(1), in order to get a unique solution. 

@sasomao : Rather than relying on Maple's own debugging tools, you might insert code at strategic points of your program to write entries in a log file.  By looking at the last entry in the log file, you can figure out what was happening when it crashed.  Make sure to flush the file buffer after writing, to make sure it is actually written to disk (in a crash, anything still in a buffer might be lost).  Thus something like:

> logfile:= "c:/temp/LogFile.txt":
   FileTools[Text][Open](logfile):

....

   FileTools[Text][WriteString](logfile, "Reached checkpoint 1\n");
   FileTools[Flush](logfile):

....

   FileTools[Text][WriteString](logfile, "Reached checkpoint 2\n");
    FileTools[Flush](logfile):

....

It may take a few iterations of this to pin down exactly where the crash occurs.

In principle it should be possible to do with system or the Sockets package.  Of course it's not really Maple
sending the email, but rather calling some other program that does this.  For example, on a Unix system I might have system invoke mail. 

There seems to be a bug in Maple 14, causing it to return NULL.  Maple 13 does solve the system, giving

you both {x=0,y=0} and a rather awful-looking solution involving the RootOf a cubic.

You might do something like this.

pvalues := [2, 3, 5, 7]; # the values you want for p
Answer:= Matrix(nops(pvalues)+1, 4):
Answer[1, ..] := < p | x | y | z >:
for i from 1 to nops(pvalues) do
   S:= solve(eval({f1,f2,f2,f3c1,c2}, p = pvalues[i]),[x,y,z]);
   Answer[i+1, 1]:= pvalues[i];
   Answer[i+1, 2..4]:= eval(<x | y | z >, S);
end do:
Answer;

Your equations contain not only the variables you mentioned but 11 parameters (including the unknown functions u and w and their derivatives).  There is likely to be a solution involving the root of a fourth degree polynomial, but I suspect the coefficients of this polynomial will be extremely complicated. 

The problem basically is that hue is a circular scale.  See e.g. <http://www.huevaluechroma.com/071.php>.

So the maximum and minimum values are given the same hue. 

eval(z(t), sol(0));

or

subs(sol(0), z(t));

You could try something like this. Use option remember in your procedure f, so that when f(t) is called a second time with the same t the value will be retrieved from the remember table rather than being recalculated.  Then

> plot([ t -> f(t)[1], t -> f(t)[2] ], 0 .. 10, colour= [red, blue]);

readlib is not needed any more: it's a hold-over from long-ago versions of Maple that used a different model for accessing library functions.  Just use (after interface(verboseproc=2))

> print(`fsolve/sysnewton`);

Or you can use showstat instead of print: that will give you line numbers.