Conference hydra::amiga_v1

    I had a similar problem with my startup.  I called CLtd. about it,
    as I was using their drive.  For some reason, my startup would slow
    to a crawl.  I turns out that there is something that happens when
    you have more than one execute at a time.  If you put CD Ram: at
    the beginning of your startup sequence, that will direct any temporary
    files created by this effect to ram: and not write it to disk. 
    There was something else they mentioned about the multiple executes
    and LoadWB.  For some reason this causes the current disk (in my
    case the hard disk) to try to validate.  That was causing the slowdown.
                                     
    CLtd recommends using this startup-sequence:
                                     
    Mount DH0:                       
    DefDisk DH0:                     
    CD Ram:                          
    Execute HD-Start
                                     
    Here is what they say in their manual: "The 'CD RAM:' is included
    for several reasons.  Because AmigaDOS automatically writes a temporary
    file to the current directory whenever one script file (the startup
    sequence in this case) attempts to execute another script file
    (HD-Start in this case), assigning the current       
    directory to ram: is a lot faster than leaving it assigned to the
    floppy and if your floppy is write protected then an error would
    occur.  Also, if you assigned the current directory to the Hard
    Drive, and then did a LoadWB form the HD-Start program, the AmigaDOS
    would see the temporary file as an open file on the Hard Drive and
    attempt to VALIDATE your Hard Drive which you definitely don't want
    to do."                                              
                                                         
                                                         
                                                         
    Good Luck.
    
    Randy
    

Re: .0

You are right: nested EXECUTEs cause a temporary file to be created.  I
sort of think of this as an aspect rather than a bug.

Since the nested EXECUTE is the last thing you do before closing the CLI,
there are two ways to avoid this problem:

The first way is to do a RUN EXECUTE rather than a simple EXECUTE.  The
RUN command creates a second CLI process to execute the command file.  Since
a second CLI is executing the commands, the second command file isn't
nested, and no temporary file need be created.

The second way is to use NEWCLI command.  One of the arguments to the NEWCLI
command is a command file to execute in the new CLI.  As such, this makes
it very similar to the RUN EXECUTE case, the difference is that you should
put an ENDCLI in the secondary command file, and the secondary command file
will run with its own window.

In my startup sequence, I use a command like:

   dh0:c/newcli "con:0/100/640/45/Background Startup" dh0:s/Background-Startup

to run my hard disk secondary startup-sequence.  The big full screen
CLI window goes way and is replaced with a small (about 4 lines)
window that is just big enough to see the output from my secondary
startup-sequence (the AmigaDOS version number and the current date and
time).  The little window then goes away when the command file
executes the ENDCLI.

Re: .1

The LoadWB command is sort of unfriendly to the system.  When the Workbench
starts, it sends a diskchange message to every mounted disk on the system.
This is the software equivalent to popping the device out of the drive
and reinserting it.  The Workbench then listens for all of the operating
system messages that say a disk just came on-line, and then the Workbench
displays the device's icon.  Well, if you have a file open for output
on a disk when the Workbench does this startup junk, the system will
see the device come back on-line with an invalid bitmap, and will
reconstruct the bitmap for you.  This "disk validation" (repair) causes
the slow down.

    re .1:

    Does that mean that Execute tries three different places to put its
    temp file?  (T:, :T, current directory)

    I will try doing a CD RAM:

    I still don't understand why it is creating the file at all when there
    is no substitution.

	Paul

Re: .2

> You are right: nested EXECUTEs cause a temporary file to be created.  I
> sort of think of this as an aspect rather than a bug.

As far as I can see, the current behavior is contrary to what little
documentation I have seen, has no benefits, and has definite problems, so I
prefer to think of it as a bug.

> In my startup sequence, I use a command like:
>
>   dh0:c/newcli "con:0/100/640/45/Background Startup" dh0:s/Background-Startup

I like this.  It does what I wanted to do in a reasonable way.

	Thanks,
	Paul