SCOUG-HELP Mailing List Archives

>> Next Message >>

Date:	Sat, 16 Oct 2004 06:59:49 PDT7
From:	"Harry Motin" <hmotin@sbcglobal.net >
Reply-To:	scoug-help@scoug.com
To:	< "scoug-help@scoug.com" > scoug-help@scoug.com >
Subject:	SCOUG-Help: Multiple Traps

Content Type: text/plain

=====================================================
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".

=====================================================

Return to [ 16 | October | 2004 ]

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.