SCOUG Logo


Next Meeting: TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!








SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999


The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2021, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

August 2001


 Dear Mr. Know-It-All 

Mr. Know-It-All has the answers to even the really tough questions.


Question:

I've got a problem with an application. It keeps telling me it cannot find some file, but it does not show a file name in the error message. What can I do?

Answer:

OS/2 includes a very capable tracing facility. It can capture data about almost any system event. It can answer this question easily.

The Trace Facility is an optional component, so you if you don't have it installed, now is the time to run Selective Install.

Once you have it installed you need to configure it. Add the statement:

  TRACEBUF=63
to config.sys and reboot. This tells the kernel to allocate 63Kbytes, the maximum, for the trace buffer. The Trace Facility stores the trace data in memory until it is retrieved. Since the buffer is fixed size, old data will eventually be overwritten. Sometimes the hardest part of using the trace is limiting the captured data so that the events you are really interested in are not overwritten before you have a chance to retrieve them.

To use the Trace Facility you need to tell the kernel which events to capture. This is done with the TRACE command. The syntax of the command options are typically IBM, but using the command is otherwise straight forward. You can select the events and processes to be traced and you can start, stop, suspend and resume tracing.

To make using the trace tools a bit easier, I've supplied a small script. Copy it to the clipboard and use it to create a .cmd file. I called this one FOpenTrc.cmd. You can name it whatever you like. Don't forget to edit the drive letter, if your system does not boot from the C: drive.

::------------ cut here ----------------
:: FOpenTrc.cmd

start tracefmt

setlocal

:: Needs to run from trace directory.  
:: Replace c: with boot drive letter.
c:
cd \os2\system\trace

echo Use Ctrl-C to quit

trace off

:loop

:: Set up trace and clear buffer
:: Note Trace codes are decimal here

:: 98 DosOpen2 post
:: 99 DosOpen post
:: 255 DosOpen2 pre
:: 256 DosOpen pre
:: 424 DosOpen2Compt pre
:: 425 DosOpen2Compt post

echo on
trace on KERNEL(98,99,255,256,424,425)
trace /r
@echo off

echo Tracing resumed, press enter to suspend...
pause >nul
trace /s
echo Tracing suspended, press enter to restart...
pause >nul

goto :loop
::------------ cut here ----------------

The script does two things. It starts the Trace Formatter and it starts the Trace Facility. Once the Trace Facility is running, the script loops and lets you suspend and resume to trace. Wnen you are done with the script, press Ctrl-C to kill the script and type

  trace off
from the command line to turn off the Trace Facility.

It is important to suspend tracing as soon as possible after you have captured the events of interest. Otherwise, they might be overwritten.

To use to Trace Facility to find the name of the mystery file:

  • Start the trace script you created in a command line window.
  • Wait for the Trace Formatter to start.
  • Switch back to the trace script window.
  • Press Enter to suspend the trace.
  • Do what ever you need to get the application to just before the point where it generates the "file not found" message.
  • Switch to the Trace Formatter window.
  • Use the File -> Recapture option to read in the contents of the trace buffer. This gets rid of the really stale trace data.
  • Switch to the script window.
  • Press Enter to resume the trace.
  • Make the application generate the error message.
  • Switch to the script window.
  • Press Enter to suspend the trace.
  • Switch to the Trace Formatter window.
  • Use the File -> Recapture option to read in the contents of the trace buffer.
  • Scan the trace buffer for the failing file open request. The most recent entries will appear first.

Now for an example, using the command line to generate the error. Set up as described above. When ready to generate the error, switch to an unused command line window and type:

  copy xxx yyy >nul 2>nul
This should fail without reporting any useful error information, just like your other application.

Switch to the script window and press Enter to suspend the trace and continue as described above to retrieve and inspect the formatted trace data. You should find a set of reports similar to:

  (OS) DosOpen2 Post-Invocation
  Event [9]  Major [5/0x0005]  Minor [98/0x0062]
    PID [1655/0x0677]  Length [6]  Time [18:23:43.29]
  Action = FFFF   Handle = 0000
  Return Code = 006E

  (OS) DosOpen2 Pre-Invocation
  Event [10]  Major [5/0x0005]  Minor [255/0x00ff]
    PID [1655/0x0677]  Length [48]  Time [18:23:43.29]
  Return IP=4285  CS=DFD7
  Filename = D:\TMP\0\xxx
  Mode = 0040   Control = 0001
  Attrib = 0000   Size = 0000 0000
The Pre-Invocation report shows the file name.

The Post-Invocation report shows that the file open request failed with error code 6E. Translating the error code from hexadecimal to decimal and checking the handy error list in the "Control Program Guide and Reference" tells us that the code indicates:

  110   ERROR_OPEN_FAILED
          Open/create failed due to explicit
            fail command.
This is what we expected. Now you can go find the name of that mystery file.

This is just a small example of the power of the Trace Facility. It can be used for troubleshooting many other kinds of problems. If you have a problem and are wondering if a trace can help you diagnose it or if you have a trace setup question feel free to contact me.


Curious or in doubt, you can ask Mr. Know-It-All
OS/2 is his specialty and sharing solutions is his passion
Mr. Know-It-All lives in Southern California.


The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.