File-Based Debugging Utility for PROIV
This utility was designed to facilitate debugging on PROIV by writing your debug string from PROIV
to a text file named C:\Temp\S_DEBUG.TXT on your workstation PC.
It uses PROIV's LINK_CLIENT_VAR command, which works with DLL library functions.

To install, copy the attached file V_UTIL.DLL to the PROIV Client (also known as the MFC) directory.
Then create the global logic DEBUGF (see below) and use in the appropriate place in your logic.
For example:
DEBUGF('This message will be written to C:\Temp\S_DEBUG.TXT')

It has been tested on PROIV 4.6, 5.5 (may work on 4.0 but can't remember) on Windows, UNIX, and Alpha.

Advantages:
Faster than writing to a PRO-ISAM file, or using the SYSTEM command
File size limited only by operating system
Message written immediately, e.g. no need to commit

When to use
It is most effective when debugging a batch-type or long running process, where a simple UMSG is inadequate.
For short processes, we have another global logic called DEBUG, which is based on DEBUGF but uses UMSGs to output to the screen instead.
Feel free to modify the global logic below to suit your purposes.

Global Logic: DEBUGF

001 P PARMS($$_DEBUG_MSG)
002 * -----
003 * If the first character is ^ (caret), only the message is written (i.e. no extra details)
004 FOR #LP = 1 TO 2
005 IF $$_DEBUG_MSG(1, 1) = '^' THEN
006 #ST = LINK_CLIENT_VAR('V_util.MsgToFile', %IN% $$_DEBUG_MSG)
007 ELSE
008 #ST = LINK_CLIENT_VAR('V_util.MsgToFile', %IN% @CURFUNCT(1, 8)
009 + ' ' + PIC(@CUR_LS, '99') + '.' + PIC(@CUR_FL, '99')
010 + '.' + PIC(@FLD, '999') + ' ' + $$_DEBUG_MSG)
011 ENDIF
012 IF #ST = 0 THEN
013 LOOPEXIT
014 ELSE
015 UMSG('Debug file locked temporarily by another process.'
016 + CHAR(13) + 'Click OK to retry.', -1)
017 ENDIF
018 ENDFOR

Note: if the code above is shown without proper indentation (as shown in the preview), it's because the editor seems to have removed the spacing.


Example of Output File (C:\Temp\S_DEBUG.TXT)

Time Function SF.FL.FLD Debug message
-------- -------- --------- --------------------------------------------------
16:49:14 S_LOGIN 01.00.036 User SYS logged in
16:49:14 S_MENU 02.00.004 AFTER FLD 4: Branch=GB@

Legend:
Time: This is the local time (i.e. time on workstation)
Function: The current function name (i.e. @CURFUNCT)
SF: The current cycle, LS, or 'S'ub-'F'unction seq number (i.e. @CUR_LS)
FL: The current file seq number (i.e. @CUR_FL)
FLD: The current field number (i.e. @FLD)

Final Notes
This utility has been been useful in locating some problems that would otherwise have been very difficult to find. Hope the PROIV community will find it as useful as it has been for us!

Tony,

This looks very interesting. Thanks for sharing with everyone.

I notice the UMSG about the file being locked. Is there a potential problem inserting the DEBUGF into a high volume concurrent use system?

Regards,

Joseph

Hi Tony,

You dont seem to have attached the DLL file...

Rob D.

Hi All,

"I notice the UMSG about the file being locked..."

If you open up the S_debug.txt file at the precise moment that it is being written to with a text editor that opens up the file with read and write access (such as Notepad), you will receive the warning message. Once the file has been opened in your editor, you can click OK on the message and a second attempt is made to write the debug message. The message will be written even if the file was initially opened with write access. This ensures that you don't miss any vital debugging messages while you examine the current details.

If you use a text file viewer only (i.e. one that does not open up the file for write access) you will not receive this warning message because the file is not locked while it attempts to open it. There are probably lots of text viewers out there, but the one I use is called ListXP, which is fast, memory efficent and has 'tailing' functionality.

One more note, as suggested by its name, this utility is designed only for development and not for live systems. While it is fast, there is still an overhead incurred in writing to disk. There are no other concurrency issues that I'm aware of.

Note: this message thread (should now!) contain the attachment.

Enjoy!

Hi Tony,

Thanks for publishing the utility, it'll save us lots of frustrating time entering through user messages only to go past or forget what's gone before and have to start again! Excellent, could have done with this years ago.

As we are VIP users I did try to amend the global logic slightly and replace the PIC(@CUR_LS, '99') with @CURLSNAME and PIC(@FLD, '999') with @CURFLDNAME, but it was having none of it. I assume this is because 'V_util' requires a fixed format at the start of the record?

It's no problem as I can always add the fields into the debug message within DEBUGF if I need to.

Thanks again

Dave Allen

Hi Dave,

There shouldn't be any reason why it doesn't work. The DLL was written to accept a PROIV string. The only thing that you should see differently is that the titles will no longer align nicely with your debug messages.

Silly question, but did you replace PIC(@CUR_LS, '99') in its entirety with @CURLSNAME or just the @CUR_LS part? And what error message(s) did you receive?

We are still using Dev Studio, but plan to move to VIP shortly. When the time comes, I'll update the DLL to be intelligent and try to work out the column widths depending on what information is passed to it.

We've actually been using this utility for about four years. Should have posted it sooner, though, possibly.

Regards

Tony, Thanks. I have used it some and it workd great.

Bill

Tony,

Yes, I did replace the entire PIC but on running the function it just hung when it reached the logic (and did not update the text file). Then, the only way out was to terminate the session (Ctrl-Break didn't work).

I then tried a number of formatting variants, each time reducing the number of elements within the string. Essentially, whenever I ran it with at least one of the 'NAME' variables it hung. If it didn't have any in it worked.

I have just now tried adding the following line to the logic after the PARMS line:

$$_DEBUG_MSG = @CURFLDNAME + ":" + $$_DEBUG_MSG

This shouldn't cause any problems (should it?), but on running it hangs once more. My conclusion, therefore, is that it is the variables that are the problem, well, certainly within VIP!

Thanks

Dave

Dave,

It does sound like VIP does not like the two variables, @CURLSNAME and @CURFLDNAME. We haven't moved over to VIP yet, but when we do in a few month's time, I'll look into it. For the time being, just stick with the original variables.

Have you found any uses for it yet?

Regards

Hi Tony,

I tried to use the .dll, but failed.

I get the error message:
182 EXTERNAL SUBROUTINE NAME NOT FOUND IN NAMES TABLE - V_util.MsgToFile

Details from Error message file are:
Cause: A subroutine name has been specified in a LINK statement that does not represent a
valid external subroutine.
Action: Modify the subroutine name to represent the external subroutine name established in
the external subroutine names table.

Question:
How do you make it a "valid external subroutine" ?

What I did:
a) copied your .dll into C:\ProivClient - does not work
copied your .dll into C:\PRO55 - does not work

Where have I gone wrong? What should I do?

Thanks & Regards,
-vijay

i also have the same error message

182 - EXTERNAL SUBROUTINE NAME NOT FOUNF IN NAMES TABLE - V_utilMsgToFile

What should i do?

problem solved. Try putting v_util on gloviaclient or proivclient of own PC, it worked!