@@fetch_status is a global value for each connection.  So you cannot depend
on @@fetch_status being zero when the stored proc is executed.  If you have
previously looped thru a cursor with this connection, doing a
while(@@fetch_status=0), then when it left that loop, it was non zero, so it
is still non zero and you loop will not be executed at all.  Instead of

open od
while (@@fetch_status=0)
begin
fetch next from od into @nom1,@nom2
update products set Instock= '10000' where prodid = @nom1;
end

you want to code the cursor loop like:

open od
fetch next from od into @nom1,@nom2
while (@@fetch_status=0)
begin
update products set Instock= '10000' where prodid = @nom1;
fetch next from od into @nom1,@nom2
end

Then you are not depending on @@fetch_status being zero before your first
fetch.

The other problem with this stored proc is that it uses a cursor.  Cursor's
are almost always an ineffecient way to process data in SQL.  It is almost
always much better and faster to use a set based solution.  In your case, a
better stored proc would look like:

CREATE procedure [dbo].[automated_mark]
with recompile
as
update products
set Instock='10000'
where prodid in (select ProdID from Orders where Orders.Qty > 20);

Tom