SCOUG-HELP Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sat, 8 Sep 2001 11:56:10 PDT
From:	Harry Chris Motin <hmotin@attglobal.net >
Reply-To:	scoug-help@scoug.com
To:	scoug-help@scoug.com
Subject:	SCOUG-Help: UniMaint & CDFS.IFS /W

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

Hi Peter,

Sorry to hear about your problems in getting clean *.INI files. May I
suggest the following course of action for you, based on many hard hours
of experience?:

1. First, establish a reliable system for backing up and restoring your
two OS2*.INI files, the CONFIG.SYS file and all the Desktop files.
Steven uses UniMaint's backup and restore. I use Gamma Tech Sentry to
backup. I restore by booting from floppies to a minimal OS/2 system and
then, using a couple of OS/2 batch files, I restore any generation copy
of the *.INI files, and/or the CONFIG.SYS file, and/or the Desktop that
I want (I have 20 generations).

We all have our own likes and dislikes. Any system that works, and
works reliably, is a good system. Test it out, first, before you go back
and try to clean the *.INI files.

2. Next, try to go back, and if you can, get the most recent, working
copy of the *.INI files and your desktop. Copy them to your boot system
and boot using them.

3. Clean your *.INI files, using UniMaint, checkini and cleanini and in
that order. Clean the *.INI files incrementally, making a good backup of
the *.INI files, the CONFIG.SYS file, and the Desktop each step of the
way. For example:

A. Backup these files
B. Use UniMaint to clean
C. Do a total (warm) reboot, making sure you can get back to the WPS
E. Backup the resulting system files, saving your previous backup,
above
D. Use checkini to clean the *.INI files
E. Do a warm reboot to the WPS
F. Backup the resulting system files, again saving the previous backups
F. Do incremental cleaning using cleanini (do not use all switch
options)
G. Do a warm reboot to the WPS
H. Backup the resulting system files, again saving the previous backups
I. Finally, test out the results to be sure that you have not lost
anything that should still be there.

Based on your communications on this problem, my guess is that you will
be OK using UniMaint and checkini. However, because you have so much
garbage in the *.INI files, you will have to be care and incremental
with cleanini.

If you follow something like the above, you will be OK. If something
hangs, you can go back to your previous backup and try again. Frankly, I
am not surprised that you are having problems, given the amount of stuff
in your files. It's hard to know what's good and what's bad.

After you succeed in a thorough cleaning, go through the same
process again, say, 1 week later. And then do it again. After a while
you be able to clean reliably and only have to backup your system once,
at the finish. Then, establish that as your maintenance procedure.

Honestly, you've got to do something like the above!

Here's where I'm coming from with all of the above: Recently, I was
having hardware problems (a complete system hang during some (but not
all) bootups). Before I successful traced and fixed the problem, I had
to adhere to a very rigid system backup procedure (the *.INI and
CONFIG.SYS files and the Desktop), in order to get my system back. If I
did not have that system in place, eventually I would have screwed
everything up and not been able to get up on my system. That is, I might
have had to install from scratch, possibly losing some data files.

I hope this helps.

HCM

________________________________________________________________________

Peter Skye wrote:
>
> =====================================================
> 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.
> =====================================================
>
> Steven Levine wrote:
> >
> > You don't need to open the Unimaint folder.
>
> That's good, because I can't.
>
> My system was finally free so, instead of clicking on the UniMaint
> folder, I opened a command line window, switched to my UNIMAINT
> subdirectory, and ran ICON.cmd (below). (ICON.cmd opens a directory
> folder *from* the command line.)
>
> UNIMAINT wouldn't open as an icon folder. I got a SYS3171 in
> PMSHELL.EXE and the Workplace Shell closed and reopened.
>
> Before I go chasing through my Desktop looking for a possible cause, is
> that where I should be looking? It seems to me that the contents of the
> Desktop have nothing to do with what ICON.cmd does.
>
> How about if I try this: I could try to reinstall UniMaint, although
> the SHSINST installer might bomb when it tries to write to \UNIMAINT\.
> If SHSINST did bomb, I could reinstall UniMaint *but* put it in a
> *different* directory so I could at least use it, and then I could
> delete the contents of the original \UNIMAINT\ directory from the
> command line, then remove (with rd) the UNIMAINT directory, and then run
> UniMaint from its new directory to purge any old UniMaint entries in the
> OS2*.INI files.
>
> Comments?
>
> - Peter
> _____
> Following is the Rexx code for ICON.cmd:
>
> /* The ICON command file opens the named or
> / current directory as an icon folder.
> / Examples: ICON (opens the current directory)
> / ICON H:\TEMP (opens the H:\TEMP directory) */
>
> if RxFuncQuery('SysSetObjectData') then,
> call RxFuncAdd SysSetObjectData, RexxUtil, SysSetObjectData
>
> /* Set icondir to the target directory path. */
> /* - If a path was specified on the command line, use it. */
> /* - Otherwise, use the current directory. */
> if arg() > 0 then icondir = arg(1)
> else icondir = DIRECTORY()
>
> /* Now open the folder. */
> call SysSetObjectData icondir, "OPEN=ICON"
>
> /* End of program. */
> exit
>
> =====================================================
>
> 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".
>
> =====================================================

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

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 [ 08 | September | 2001 ]

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.