Gosub/return Doesn't Work With Vm

[Harry L. Roberts]

This is a continuation of this topic: Where Did I Go Wrong?

 

 

Problem: The "return" command associated with the "gosub" command doesn't work when "gosub" directs program to go to voice mail.

 

Admin. has stated that the manual or Help file incorrectly shows how to transfer from your script to the voice mail script and return.

 

The Help file shows using the "GoTo" command and Admin. has clearly indicated that the "GoTo" command will not support the "Return" command.

 

I have verified this for my self running VG version 6.0.2322 Working Trial Version.

 

Why would I ever want to use the "GoTo" command when it appears that the "GoSub" command does the same thing and more. When by more I mean that it supports the "Return" command.

 

Back to the problem of the voice mail script not returning to the locations indicated by the calling scripts return command. I have attached my very simple script and also included a Trace Log.

VG_Trace___Script_2006_01_05.zip

[Guest RobG]

Harry,

 

FYI, I have noted in my post that I could not get the Return to work for me either after I removed the userid file to force VG to think I had the Evaluation version.

 

Perhaps it is useful for you to have this 2nd party confirmation of your problem.

 

I would think that the Support folks would look a little harder at a problem reproducible on 2 different and unrelated customer systems...

 

I still can't help but think the I (we?) screwed something up in the installation. Getting to a point to use VG is much more complex than any other software installation I have ever done. The hardware's software installation requires multiple steps. I have no other software that uses this hardware, so I can't absolutely rule out or confirm how correctly that part was done.

The software installation also requires many more steps than typical software normally does. And the only way I have seen to test the quality of the installation is to test your own scripts 3 ways from Sunday (or insert other expression of your choice) to see if they will work.

 

And if they don't work, troubleshooting and debugging seems like pot-luck black box poking.

 

Admin: Do you folks offer a VG Script Design and Debugging course? Maybe a 1/2 day interactive webinar?

 

If you teach me to fish, I won't argue with you about the best way to construct a fishing pole.

 

Hang in there Harry. Oh, by the way, I have deduced that Harry is not your real name. Stay sharp.

 

Rob G.

[Harry L. Roberts]

Is There Anyone Reading These Post?

 

I think my problem is related to the following line of code located in

 

Script: vmLm.vgs

Module: VmLmMenu

 

VG.Script_Return iLineId, "[VmLmRec]{}" 'clear the name of the last recorded message

 

The Help File Says:

 

Script_Return VoiceGuide COM Reference

 

 

Returns control of the call to the calling script.

 

Syntax

 

object.Script_Return iLineId, sRvList

 

I guess it would be ok at times to return to the calling script. But when we use the "gosub" & "return" we normally want to direct the call to a different module. Based on the description from the help file one would get the impression that it could only return to the calling script. Is this a mistake in the Help file too?

 

Is there a RV for the value of the "return" in the "gosub" / "return" command?

 

What more can I do to help solve this problem.

[Harry L. Roberts]

I'm starting to think I'm the only one working on this problem.

 

I've done some testing and here is what I have found.

 

1. Script : vmLm.vgs

Module : VmLmMenu

 

The VG.Script_Return does NOT work when entering the Voice Mail system using "gosub [VoiceMail Box xxxx] return (return path)".

 

2. Same Script/Module

 

The VG.Script_Return DOES work when the Voice Mail system is entered using "gosub [C:\Program Files\VoiceGuide\system\vm\vmLm.vgs|VmLmStart] return (return path)

 

I had to manually set the $RV[VmbId] in the calling script/module but other than that everything worked like it was suppose to. The VG.Script_Return worked perfectly.

 

 

It appears that the problem is in the direct call to the Voice Mail system using "gosub [Voicemail Box XXXX] return.

 

I can't do any further testing because I have no idea what RV is being passed for the return path. If I knew the RV I could check to see if it is being passed. Can you provide the RV or RVs that are passed for the return path?

 

The Help file mentions some RVs that apply to "GoTo/GoSub/Return" but none of them appear to me to be related to the "return" value.

 

Is anyone working on this problem?

 

If not let me know and I'll move on to some other software that will meet my needs.

[SupportTeam]

Here is an updated version of VgMulti.exe which fixes the Gosub bug mentioned.

 

Please place the .exe in the VoiceGuide directory overwriting exisitng file.

 

If you encounter any problems with Gosub/Return in this version please post trace and the example script which demonstrates the problem (.ZIPed up together).

VgMulti_6.0.2378.zip

[SupportTeam]

Here are some scripts we use to validate Gosub/Return.

GotoGosubReturn.zip

[Harry L. Roberts]

I think the fix has a bug in it.

 

When I start VG it automatically loads the default script for the trial version.

 

When I open the trace log I would normall expect to see nothing because there are no calls in progress. Instead I get the attached Trace Log.

 

It never stops. The error message just keeps repeating itself over and over. It was very difficult to actually "select all" and "Copy" the text because of the continous cycling of the errors.

 

Any suggestions?

 

BTW a very quick test of the gosub/return seems to work.

Trace_Log_1_9_2006_621am.txt

[SupportTeam]

Please stop VG, then delete the OutDialQue.mdb file from VG's \data\ subdirectory, then restart VoiceGuide.

[Harry L. Roberts]

After deleting the file my trace log still is filling with a lot of data. So much so that I can't "select all" and "Copy" fast enough to capture the data to post here.

 

Any other suggestions?

[Harry L. Roberts]

I tried to capture the Trace Log and the attached files are what I got.

 

When viewing the Trace Log live it appears to be updating very rapidly. Almost so fast that doing a "Select All" & "Copy" takes some effort. When it updates again you will lose your "Select All" selection.

 

When I pasted the information into a text editor it wasn't nearly as long as I thought it should be. Is it possible that the program is in some type of loof where it over writes the data in the trace log? Maybe it is clearing the data then writing new data.

 

I've attached 3 different files. They appear to me to be very similar.

VG_Trace_Log_2006_01_06.zip

[Guest RobG]

Harry,

 

I don't get the same continuous logging that you are reporting. The only difference between our VG s/w that I am aware of is that I am running as a Single Line Professional with OutDialing capability. Your Evaluation mode will do all that and more, so perhaps the root of the issue is in the "and more" area?

 

Rob G.

[Harry L. Roberts]

Is it normal to get the repeating information in the Trace Log on level 10?

 

Maybe I don't have a problem. Maybe it was just my logging level.

[Guest RobG]

At logging level 10, I also see the same logging activity. But I have no idea if that is normal or not. I seem to recall asking Admin where we could read/learn more about the "Logging Level" and instead got a short comment about higher levels representing higher sensitivity.

 

Perhaps the activity we are seeing at Level 10 is represents VG's continuous monitoring of the Dialogic card? Or not... As it's not in the documentation, I will wait for the feedback from those more experienced than myself... which is just about everybody else that has the product!! It just never occurred to me to try Level 10 before.

 

Rob G.

[SupportTeam]

Level 10 will result in logging of ongoing events within VG that occur even when VG is not handling any calls.

 

Sounds like you should be setting the level to 9 or lower in your case.

 

Maybe it is clearing the data then writing new data.

You're probably talking about the trace window here....

For complete logs see the MMDDvgm.txt and MMDDtw.txt files in \log\ subdirectory.

[Harry L. Roberts]

Did you look at the log?

 

Please look at the log and let me know if this is normal.

 

I will review the documents you mentioned.

[Harry L. Roberts]

I'm posting another Trace Log.

 

Please look at it to see if this is normal.

 

I do NOT recall this happening before.

 

It appears that the Trace log is continuously updated with this information. When I say continuously updated I mean that the information is "refreshed" over and over again so quickly that it was difficult to do a "select all" & "copy" command without the "select all" command being wiped out by the new update of the log before I could do the "copy" command.

 

It should be obivous that this is happening very quickly. I just timed it and it is happening about once every second to second and a half.

 

There seems to be a cycle that it goes through. I noticed this because of the verticle scrool bar on the right was changing size. There are three distinct logs that I get when I do "select all", "copy" & "paste".

 

They all look the same except the number of log entries changes.

The first 4 lines of the log are always the same.

 

The next 5 lines are always the same too. The only difference between the 3 phases of the cycle is the number of times these 5 lines are repeated. The first phase repeats these lines 5 times, the second phase repeats these lines 6 times and the 3rd phase repeats these lines 7 times. Then the cycle starts over. What is probably happening is that the log starts with the first 4 lines & the next 5 lines repeated 5 times. Then those 5 lines are repeated again for a total of 6. Then those 5 lines are repeated again for a total of 7 times. Then the log starts over from scratch. In the log I am attaching now you will see that these 5 lines are repeated 7 times.

 

I have also found out by switching the log level you can freeze the log making it easier to "select all", "copy" & "paste".

 

I do not remember this happening at all when I was troubleshooting the gosub/return problem. I'm sure I looked at every level of logging because at the time I did not know what the different levels were for.

 

Admin. Said:

 

Level 10 will result in logging of ongoing events within VG that occur even when VG is not handling any calls.

 

 

I understand that level 10 will log ongoing events when VG is not handling any calls. Are you suggesting that what I am seeing is normal?

 

Aren't there times that the system will be idle and will therefore show no logging at all even at level 10? Even for a few seconds?

 

My log is Continuous. There is no idle logging period. It just keeps on scrolling.

 

I really feel this is a problem. Please review my log and take into consideration that the log repeats over and over every one second without ever stopping.

 

It is very Frustrating to receive a reply like the last one you posted. It would appear that my previous log was never looked at and that no one even looked at your test system to see if it was doing the same thing. The question I asked was not answered. I'm asking the same question again. Is this trace log normal and is it normal for it to repeat continuously?

VG_Trace_Log_2006_01_11_0838.txt

[Guest RobG]

I looked at my log file sizes and their relatively small sizes make me think that the log level dropdown found in the Event Trace window controls the overall level of logging, not just the level of logging shown in that window.

 

Perhaps that was already obvious to you, but it certainly wasn't to me. I thought that overall logging was controlled by a bit switch in one of the configuration files (logging On or Off). If that was the case, then logging On meant that All logging was On (all levels); and the window's level selection was used to say "Show me only log entries to this particular level."

 

I now believe that while the bit switch in the configuration file is simply On or Off, the overall logging level is control by the Event Trace window. In other words, if you have the level set at zero, there will be No logging, even though the bit switch in the configuration file says logging is On. In essence, there is no need for the bit switch in the config file.

 

If the level is set at 1, any activity at that level gets logged whether you are looking at the Event Trace window or not. And so on for each level...

 

I don't have clue what level 10 is supposed to do, but I believe I see that level 10 actually forces activity from the software! Kind of like a road gang guard - it tells the s/w "I am here to watch you work, so you darn well better do something." So the s/w starts up this "Let me check for some stuff." routine.

 

I am guessing this because of what I see when I do a ctrl-alt-del to watch the cpu usage of VGMulti. My logic is that, If VG was always doing what level 10 says it is doing, then the cpu usage would always show that activity. But it doesn't. When not set to 10, it does occaisionally show the spike of "clean up" activity that I noticed in the past. Level 10 shows a fairly consistent cpu usage whether the Event Trace window is open and displaying, or not.

 

I know this does not answer your questions and I too am curious to read the answers.

 

For now. I have the level set to 1 thinking that my logs will log whatever the heck is associated with level 1. I have no idea if I would be better off with using level 3 or 6 instead, because I have no idea what the difference is.

 

All I do know is that, when I have a problem to troubleshoot, I should set the log to level 9.

 

Enjoy!

 

Rob G.

[SupportTeam]

I understand that level 10 will log ongoing events when VG is not handling any calls. Are you suggesting that what I am seeing is normal?

Yes. This logging is normal if you select 10 for logging level.

Aren't there times that the system will be idle and will therefore show no logging at all even at level 10? Even for a few seconds?

No. and setting of 10 you will get logging from processes which run all the time in VG.

My log is Continuous. There is no idle logging period. It just keeps on scrolling.

Change your logging level to 9.

 

Logging level 1 will show least info and the amount of info shown increases as you increase the logging level.

[Harry L. Roberts]

Does that mean that you have looked at my log and it appears normal?

[SupportTeam]

Yes. This logging is normal if you select 10 for logging level.

[Guest Guest]

Hi

Is there a uodate for ver 5.2 as well for this problem

TIA_YONA

[SupportTeam]

Please use this .exe. It fixes the goto/gosub errors in v5.2 of VG.

VgMulti_5.2.5026.zip