SCOUG-HELP Mailing List Archives

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

Date:	Fri, 2 May 2003 16:22:11 PDT7
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-help@scoug.com
To:	scoug-help@scoug.com
Subject:	SCOUG-Help: Backup & Repair (was: Taskbar Tray)

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

Steven Levine wrote:
>
> startup.cmd gets run after OS/2 boots but before the
> WPS is started. It's a good place to initialization
> that must run after config.sys processing completes,
> but before the WPS is up and running.

Minor touchup on this. STARTUP.CMD starts before the Workplace Shell is
started, but they run in parallel. In other words, STARTUP.CMD (if it
takes a long time) will still be running when the Workplace Shell is
started.

I know this because I have a PAUSE statement in my STARTUP.CMD, and thus
STARTUP.CMD never "ends". Yet the Workplace Shell comes up just fine on
every boot.

Because STARTUP.CMD and the Workplace Shell can be executing
simultaneously, the sequence of the various items in STARTUP.CMD can be
critical. If you want to sync your hardware clock with a quick NTP call
then you might want to do this at the beginning of STARTUP.CMD so the
WPS doesn't start programs at one date-time and suddenly have it
switched to another. And when I was playing with Relish I made sure
that the NOW server was started first so the WPS wouldn't start Relish
before NOW was running (although this isn't critical because Relish will
start NOW on its own).

If I spent some time thinking about it I could probably figure out how
to start the Workplace Shell from the last line of STARTUP.CMD rather
than from a CONFIG.SYS specification, thus guaranteeing that the
STARTUP.CMD programs were executed before the Workplace Shell started.

Of course, you can START things from STARTUP.CMD if you really enjoy
having an asynchronous machine.

To circumvent this parallel execution of STARTUP.CMD and WPS, you can
run things from CONFIG.SYS with CALL= and RUN=. I use CALL= to start
new command processors that then runs .cmd files. If you want to just
play, try this:

CALL=C:\OS2\CMD.EXE /C ECHO HELLO, WORLD

which has been in my CONFIG.SYS for duckteen years, "just for fun".

And these CONFIG.SYS-started commands/programs _definitely_ complete
before either STARTUP.CMD or the Workplace Shell (with its "Restarted
Objects" plus its "Startup Folder") is started. (Hmm, maybe I should
try executing a .cmd which contains a START command and see what *that*
does.)

So lessee . . . On my machine I run programs from CONFIG.SYS, and when
they are all completed I run stuff from STARTUP.CMD and a few seconds
later I overlap that with the Workplace Shell startup which immediately
starts Restarting objects which were open/running at the last shutdown
plus the Workplace Shell also opens/starts all the objects in the
Startup Folder.

Smokin'! Ducks *can* walk and chew gum at the same time. :>

- Peter
(all lobes running in parallel)

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

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 [ 02 | May | 2003 ]

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.