🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.micro.mac
Article #7322

Re: DataFrame 20

#7322
From: Paul Menon
Date: Wed, 24 Sep 1986 01:34
63 lines
3926 bytes
> Mine never takes more than 10 seconds or so to go from flashing question mark
> to smiling Mac, unless I power down or reboot without going through shut down
> (in the Finder's Special menu).  When I shut down, I turn the DataFrame off
> AFTER the Mac beeps and BEFORE the disk-with-flashing-question-mark appears.
> If you turn it off after the smiling Mac appears, then you'll have to wait
> next time you boot up while some data structures are rebuilt on the disk
> (the volume allocation bitmap maybe?).

    I have been amused as to how people shutdown their Dataframes for some 
time now, and can offer may own humorous, yet possibly sane method.  This is
how I interpreted SuperMac's instructions, and it seems the safest.
    *	Select the "ShutDown" option as per normal.
    *	WAIT FOR THE THING TO REBOOT COMPLETELY!!! ie, wait for the desktop
	to appear and the system has subsided into a state of tranquility.
    *	Switch the DataFrame off.
    *	Switch the Mac off.
	(The order of the last two actions is unimportant)
    
  For your further amusement, here are the reasons why I think this method is
	safe/fast/obvious.

    *	Nobody in their right mind would suggest an action that is only 
	possible within a two or 3 second time window.
    *	The consequences of missing this window are possibly horrendous.
	Imagine switching the hard disk off halfway through a write as the
	Mac is coming up to air.  I have not heard of any manufacturer 
	suggesting this procedure, ie switching a hard disk off while it is
	possibly doing something.  This includes SuperMac.  Maybe I didn't
	read their instructions as closely as others have.
    *	Using my interpretation, the Dataframe ALWAYS boots up in a matter of 
	seconds.  ALWAYS!
    *	Now for what I think happens.
	    *	If someone doesn't use the SHUTDOWN procedure, then the
		Dataframe will possibly be in an UNUPDATED state, ie, there 
		is a bit of housekeeping necessary such as recovering what 
		windows are open, the state of the desktop, etc...
	    *	Selecting the SHUTDOWN procedure, waiting for the desktop to
		appear, and then switching the disk off (without doing
		anything to modify what the desktop looks like, or even
		accessing the disk) ensures that the disk will reboot in an
		UPDATED state. Simple, logical, no?  Maybe it is too simple,
		but that's why I am happy with it.  All this stuff about tags,
		bitmaps and hoo-ha can be left to the experts.
	    *	If someone misses the time window, ie the Dataframe is accessed
		again before the user can switch it off, then the next time
		a bootup occurs, recovery may be necessary, if one is possible!
		this is possibly why it then takes a long time to come up.  It
		is statistically improbable for someone to always catch that
		window.

(P.S.   I congratulate SuperMac for creating a disk/software package that puts
	up with such treatment)

Paul Menon.

    Dept of Communication & Electronic Engineering,
    Royal Melbourne Institute of Technology,
    124 Latrobe St, Melbourne, 3000, Australia
 
ACSnet: rcopm@yabbie             UUCP: ...!seismo!munnari!yabbie.rmit.oz!rcopm
CSNET:  rcopm@yabbie.rmit.oz     ARPA: rcopm%yabbie.rmit.oz@seismo
BITNET: rcopm%yabbie.rmit.oz@CSNET-RELAY
PHONE:  +61 3 660 2619.
Technical Details
Message-ID: <337@yabbie.rmit.oz>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!munnari!moncskermit!goanna!yabbie!rcopm
References: <2275@psuvax1.UUCP> <202@zen.BERKELEY.EDU> <432@inuxm.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!munnari!moncskermit!goanna!yabbie!rcopm
From: rcopm@yabbie.rmit.oz (Paul Menon)
Newsgroups: net.micro.mac
Subject: Re: DataFrame 20
Message-ID: <337@yabbie.rmit.oz>
Date: Tue, 23-Sep-86 21:34:04 EDT
Article-I.D.: yabbie.337
Posted: Tue Sep 23 21:34:04 1986
Date-Received: Wed, 24-Sep-86 23:45:40 EDT
References: <2275@psuvax1.UUCP> <202@zen.BERKELEY.EDU> <432@inuxm.UUCP>
Distribution: net
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 63
Summary: Misinterpretations?, Dangerous Practice?