Critical issue: Persistent procedure.

[ravi_gupta2u]

/* plan.p*/

&if defined(plan-library-defined) = 0 &then
&glob plan-library-defined YES
{sys/procload.i} /* Persistent procedure handler. */
&if defined(csm-plan-super-proc) = 0 and {&v9} &then
f-GetHandle("csm/plan.p":U). /* Load super-procedure. */
&else
procedure plan-getPlansForProduct:
define input parameter pc-AccountType as character no-undo.
define input parameter pc-ProductType as character no-undo.

---
--
end procedure.
&endif /* csm-plan-super-proc */
&endif /* plan-library-defined */

/* ttmvplan.p*/

&if defined(plan-library-defined) = 0 &then
&glob plan-library-defined YES
{sys/procload.i} /* Persistent procedure handler. */
&if defined(csm-plan-super-proc) = 0 and {&v9} &then
f-GetHandle("csm/TTmvplan.p":U). /* Load super-procedure. */
&else
procedure plan-getPlansForProduct:
define input parameter pc-AccountType as character no-undo.
define input parameter pc-ProductType as character no-undo.
define input parameter pf-serviceid as decimal no-undo. /* extra parameter*/
---
--
end procedure.
&endif /* csm-plan-super-proc */
&endif /* plan-library-defined */

/* xyz.w*/

run plan-getPlansForProduct in f-GetHandle("csm/plan.p") (input "abc", input "sss")

Scenerio:

- plan.p was already runing persistently
- ttmvplan.p was created newly and running persistently
- This is an webspeed application. As some unknown point of time when we try to run xyz.w screen then i get below error(mismatched param)

In the server error log(webspeed), below error is coming -
Mismatched parameter types passed to procedure plan-getPlansForProduct csm/TTmvplan.p. (3230)

My Query:
If I am trying to run plan-getPlansForProduct procedure in the handle of plan.p then
why this is being tried to call procedure written in TTmvplan.p

Please help me to understand this issue and let me know how can i resolve this?

Thanks in advance.

 

[RealHeavyDude]

The root of your issue must lie in the function ( f-GetHandle )you use to retrieve the handle of the persistent procedure.


HTH, RealHeavyDude

 

[ravi_gupta2u]

We are getting the handle in similar manner throughout the application. Even we do not always get this error. This coming randomly in server error log.
Can the problem with same name of internal procedure? Can this be avoided if keep different name of internal proceure (plan-getPlansForProduct)?

Please advise.

Below is the code of f-GetHandel:

FUNCTION f-GetHandle RETURNS HANDLE
(INPUT pc-ProgramName AS CHARACTER):
/*------------------------------------------------------------------------------
Purpose: Returns a handle for a persistent procedure already running in
memory. If it is not already running, it will be loaded in memory
and the handle stored in the temp-table.
When running version 9, a super procedure is created instead of
storing the handle in the temp-table.
-------------------------------------------------------------------------------*/
DEFINE VARIABLE lh-ProgramHandle AS HANDLE NO-UNDO.
&IF {&V9} &THEN
/*
** If the procedure has already been run, return immediately.
*/
IF CAN-FIND(t-Procedure WHERE
t-Procedure.ProgramName = pc-ProgramName) THEN RETURN THIS-PROCEDURE.
/*
** Create the record tro prevent any recursive calls.
*/
CREATE t-Procedure.
ASSIGN t-Procedure.ProgramName = pc-ProgramName.
/*
** Run the required procedure persistently.
*/
DO ON ERROR UNDO, RETRY
ON STOP UNDO, RETRY:
IF RETRY THEN
DO:
/*
** Delete the temp-table entry, so it will try again next call.
*/
IF AVAILABLE t-Procedure THEN DELETE t-Procedure.
RETURN ?.
END.
RUN VALUE(pc-ProgramName) PERSISTENT SET lh-ProgramHandle NO-ERROR.

/*
** If an error is generated, delete the temp-table entry and return.
*/
IF ERROR-STATUS:ERROR OR NOT VALID-HANDLE(lh-ProgramHandle)
THEN
DELETE t-Procedure.

/*
** Add to the super-procedure stack.
*/
ELSE SESSION:ADD-SUPER-PROCEDURE(lh-ProgramHandle).
END.

/*
** Return.
*/
RETURN lh-ProgramHandle.
&ELSE
FIND tt-Procedure WHERE
tt-Procedure.tc-ProgramName = pc-ProgramName NO-ERROR.
IF NOT AVAILABLE tt-Procedure THEN DO:
/*
** Load the procedure into memory.
*/
RUN VALUE(pc-ProgramName) PERSISTENT SET lh-ProgramHandle NO-ERROR.
IF ERROR-STATUS:ERROR THEN RETURN ?.
/*
** Create the temp-table record.
*/
CREATE tt-Procedure.
ASSIGN
tt-Procedure.tc-ProgramName = pc-ProgramName
tt-Procedure.th-Handle = lh-ProgramHandle.
RETURN tt-Procedure.th-Handle.
END.
ELSE IF VALID-HANDLE(tt-Procedure.th-Handle) THEN
RETURN tt-Procedure.th-Handle.

ELSE RUN VALUE(pc-ProgramName) PERSISTENT SET tt-Procedure.th-Handle.

IF VALID-HANDLE(tt-Procedure.th-Handle) THEN
RETURN tt-Procedure.th-Handle.
ELSE RETURN ?.
&ENDIF
END FUNCTION. /* f-GetHandle */

 

[tamhas]

The first and possibly the foremost problem here it that the include files, preprocessor commands, and indirection make it very difficult to read and understand what you are doing. Unfortunately, it sounds like you have a whole application full of this stuff.

There is mention in there of running something as a super, although we don't see what is actually done. Why not run it as super and eliminate the need for the handle?

 

[oetalker]

If it was calling TTmvplan.p, it should give error "Mismatched number of parameters passed to procedure sub.p. (3234)" and NOT err#3230.

May be you have an other version of .r with datatype issue. Recompile plan.p and try it.

 

[ravi_gupta2u]

Though i have already tried this.
But why is it trying to call procedure(plan-getPlansForProduct ) which is defined in csm/TTmvplan.p while i am trying to call the procedure which is in plan.p.

 

[ravi_gupta2u]

I am not able to get how can i get rid of this error?

- When i am running below statement, then in case of ver 9, procedures are being add
in super procedure stack. And it should pick the right procedure which is written in
plan.p but this is picking the procudre written in ttmvplan.p.

run plan-getPlansForProduct in f-GetHandle("csm/plan.p") (input "abc", input "sss")

- f-GetHandle is written in a .i.

- Is the problem lying in the pre-processor section of ttmvplan.p & plan.p or with the
code written in f-GetHandle?
- If i keep the different name of the internal proc in both .p,can this error be avoided?

Kindly suggest me as i am stuck badly.
Thanks

 

[MaximMonin]

IMHO, your code is unreadable. Maybe you have to rewrite it?

 

[ravi_gupta2u]

Sorry for trouble.

For better i am attaching the code files.

Kindly advise.

Thanks a lot.

 

[ravi_gupta2u]

Kind provide me the solution for this. Its urgent.
If you want some more info, i can provide.
TA

 

[tamhas]

The problem isn't that you failed to include the code in [ code ] tags ... since it doesn't appear that what you posted has a lot of indention anyway ... it is that it is unreadable in the best of circumstances. My sympathies is this is what most of your application looks like. It must not only be hard to figure out what is wrong, but even hard to figure out when it is working.

Short of doing the rewrite that it badly needs, I think the only way that you are going to sort it out is to put in message statements to confirm whether or no expected values are what they are at any given point. That or step through it with a debugger. I am quite sure there is some simple logic error in here, but it isn't going to be obvious to anyone in the middle of this spaghetti.

 

[ravi_gupta2u]

Flow of the attached procedure -

- plan.p was already runing persistently
- ttmvplan.p was created newly and running persistently
- This is an webspeed application. As some unknown point of time when we try to run
xyz.w screen then i get below error(mismatched param)

In the server error log(webspeed), below error is coming -

Mismatched parameter types passed to procedure plan-getPlansForProduct csm/TTmvplan.p. (3230)

My Query:

If I am trying to run plan-getPlansForProduct procedure in the handle of plan.p then
why this is being tried to call procedure written in TTmvplan.p
Here, f-GetHandle is used to add the procedure in super procedure stack or to return the handle of procedure.

Please let me know the reason causing issue & how can i get rid of this?

 

[tamhas]

You seen to be avoiding the facts. If one does run ip in handle, it absolutely will not run an ip in a different procedure than handle points to. Therefore, something is not as you think it is. Either the .r connected to handle isn't the procedure you think it is (old compile or something) or the handle has gotten changed somewhere along the line. So, put in some diagnostics. Display the handle at the point you set it and display it again when you use it. Check the .p associated with the handle. No one from outside can tell you what the problem is.

If running an IP in a super ... then no handle is needed or wanted. Then you have to rely on the rules for the order in which the supers are searched. Read the manual. This is controllable and predictable.

 

[RealHeavyDude]

Just another thought:

In order to get the handle to a specific procedure that is started persistently you don't need to keep track in a Temp-Table at all. Whenever you need such a handle you could easily do a procedure tree walk on the session which will either return a valid handle or an invalid one. if it is invalid you know that the procedure is not running and you have to start it. I prefer this method over keeping track of handle in Temp-Table because it does hold water.

This is a code excerpt from %DLC%/src/adm2/smart.i from start-super-proc:

hProc = SESSION:FIRST-PROCEDURE.
DO WHILE VALID-HANDLE(hProc) AND hProc:FILE-NAME NE pcProcName:
hProc = hProc:NEXT-SIBLING.
END.
IF NOT VALID-HANDLE(hProc) THEN
RUN VALUE(pcProcName) PERSISTENT SET hProc.

Heavy Regards, RealHeavyDude.

 

[tamhas]

Note that you could use type of code to walk through the current session tree and display the procedure names and handles which might help in your diagnosis.