Judging from the cursor, you must be coming from an Oracle background. If you remove the cursor, this will go faster. As for the data conversion error, check the accts table to see what the bal and cbal columns are defined as.
ALTER PROCEDURE [dbo].[ChkBal] @Pan varchar(50), @pAct varchar(50) OUTPUT, @pBal money OUTPUT, @pCBal money OUTPUT
declare @wkStat int
set @wkStat = 0
select @pAct = acctno, @pBal= bal, @pCBal = cbal
where acctno = @pan
if @@error <> 0
set @wkstat =1
I think the conversion error must be coming from the call to the inner stored procedure. Parameters are passed in order, unless otherwise specified, so you want to have either:
exec ChkBal @Pan, @pAct out , @pBal output, @pCbal output
In this case, I would probably just pass them in order, as the first example.
IMO passing unnamed params is fragile.
if someone adds a parameter in the middle of the list in the sproc definition, the code calling the sproc with unnamed params is broken. Or, if a parameter is removed, the call may continue to "work" but produce unexpected results.
I always use named params in sproc calls for this reason. also it's more readable - you don't have to remember which param is which if they are named.