>Subject: SCOUG-Help: Multiple Traps 
> 
===================================================== 
If you are responding to someone asking for help who 
may not be a member of this list, be sure to use the 
REPLY TO ALL feature of your email program. 
===================================================== 
On Fri, 15 Oct 2004 08:34:53 PDT7, Steven Levine wrote: 
OK, here's all the news that is the news: 
>OK.  To repeat a prior question.  Did you make the dump on diskette or to 
>a hard drive partition? 
I made it on a single diskette (therefore, just the trap screen info). I don't have a FAT  
partition to devote to this. 
>There's not much more I can do with just the trap screen.  I might be able 
>to discover addition clues by looking at a full dump file. 
Thanks for your offer here, but I really would not ask you do to that! I have a good  
workaround to avoid the Incharge trap. I just don't like having to use it. 
>Also, if you look at only of your original trap screen posts, you wil see: 
> 
> 
>Reading A:\DUMPDATA.001 10-11-04 18:28:26 
> 
>Exception in module:          
> 
>Note that the module name is missing.  For true kernel traps, this is 
>usally a reporting error and is corrected by newer kernels.  I recommend 
>you reinstall the 14.100c kernel and see if this kernel can report the 
>actual module name. 
Yes, I uninstalled and reinstalled the 14.100c kernel at least twice. Still get the same trap  
info. 
>Finally, at I noted in a prior post, the traps screen look more like 
>process traps than kernel traps.  There is the possibility you may have 
>configured the kernel to trapdump on process traps. 
> 
>Exactly what did you put in config.sys to enable trap dump? 
> 
>If you have 
> 
> trapdump=on 
> 
>in config.sys, change it to: 
> 
> trapdump=r0 
When back and set it to TRAPDUMP=R0. It did not make a difference. System still went  
to the black screen and ATL-CTL-DEL reboot after that. 
LATE BREAKING NEWS: 
Late last night I found the source of the Incharge trap. Apparently, I had one or more  
corrupt files in the Incharge bookset. I don't know how that happened. 
What was going on was that I could use Incharge as usual (update my checkbooks,  
savings, etc.) but I could no longer configure it to do auto generation backups at exit. If I  
tried to use that feature, it trapped during the exit and backup creation. A restart of  
Incharge in that condition would produce another, immediate trap. I had to restore  
Incharge from a previous backed up generation, one that was OK. Well, I thought I was  
going back and restoring from a good backup, but I still could not configure the auto  
generation backups. So, I assumed that somehow my system had changed (I'm doing  
a lot of updates with ESCMT, etc.) and that was causing the traps. Also, I was getting  
traps with ECSMT and FileStar/2 and that was confusing the problem isolation. So, ...,  
my workaround at this point was to turn off the auto backup and do manual backups. 
Finally, I went back to a backup generation about 1 month old and tried that. That  
worked with the auto generation backup. Now, I have to reconstruct about 1 month's  
worth of data in Incharge. And I'm working on a set of REXX scripts to automate  
backups and restores, so that I don't have to relie totally on the Incharge system. 
Thanks for everyone's help during this time. I appreciate it! 
HCM 
===================================================== 
To unsubscribe from this list, send an email message 
to "steward@scoug.com". In the body of the message, 
put the command "unsubscribe scoug-help". 
For problems, contact the list owner at 
"rollin@scoug.com". 
===================================================== 
===================END FORWARDED MESSAGE=================== 
===================================================== 
To unsubscribe from this list, send an email message 
to "steward@scoug.com". In the body of the message, 
put the command "unsubscribe scoug-help". 
For problems, contact the list owner at 
"rollin@scoug.com". 
===================================================== 
<< Previous Message << 
 >> Next Message >>
Return to [ 16 | 
October | 
2004 ]
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.