No, simple recovery is something you change with the ALTER DATABSE
command.

Actually, once the database in in simple recovery, you cannot backup the
log at all, as it is not a meaningful operation. (The log is truncated
every now and then.)

If you are really in simple recovery mode you cannot do a log backup and
there is not reason to since you cannot recover anything from the log in
Simple mode anyway. Since the client doesn't care about recovering their db
I would put it in simple mode and then you don't have to worry about Log
backups. But you or someone should still do regular FULL backups. As for the
Log size if you switch to Simple mode you should be able to run a DBCC
SHRINKFILE to get it down to a manageable size again. But you still need x
amount of MB or GB of space to handle each days Deletes. But if you have
long running open transactions you will not be able to reuse the space in
the log from the previous deletes. If you run DBCC OPENTRAN() in that db
does it say you have any long running open transactions?  If so you need to
either commit or roll them back and find our why you are not committing
them.

This is a backup log command, and confirms that your database is using the
FULL recovery model (or perhaps BULK LOGGED but that is less likely).
Otherwise, you would have received error Msg 4208 (The statement BACKUP LOG
is not allowed while the recovery model is SIMPLE).

Right.  A backup log command will backup entries in the log.  But it will
not shrink the size of the file itself.  There is a big misconception around
that backing up or truncating the log means the size of the .LDF file will
shrink.  This is only accomplished using SHRINKDATABASE or SHRINKFILE, and
as I mentioned before (and pointed you to Tibor's great article about it),
it should be done with care.

It is possible that your transaction log still had active transactions, and
so the backup was not able to remove inactive portions of the log.  What
happens when you issue DBCC OPENTRAN against this database?

You count as a connection if you are in that database (meaning Query
Analyzer, or Enterprise Manager, or Management Studio, etc.).  But I'm not
sure why you are trying to do a restore at this point, anyway.  You are
trying to get your log file under control, yes?  If so, then as I suggested
earlier, you have two possible courses of action:

(1) set the database to simple recovery mode.  The log should not grow as
long as you are committing your transactions and the system can
self-regulate the free space in the log file.  Note though that this means
your customer will only be able to go back to the most recent full database
backup if something should go wrong in the meantime.  So, this option may
not be acceptable.  If it is, then you can take this script as a starting
point to get where you are going:

USE master;
GO
ALTER DATABASE GaincoOH SET RECOVERY SIMPLE;
GO
-- let's make sure we have a current copy before we change anything:
BACKUP DATABASE GaincoOH TO DISK = N'C:\whatever...' WITH <options>;
GO
-- let's
BACKUP LOG GaincoOH WITH TRUNCATE_ONLY;
-- note that this option is deprecated in SQL Server 2008
GO
USE GaincoOH;
GO
DBCC SHRINKFILE(GaincoOH_Log, 128);
GO

If the shrinkfile does not have the desired effect, then again, run DBCC
OPENTRAN and see if you have open transactions in that database.  If you
don't, then try the shrinkfile again.  If you do, you should be able to tell
by the age of the transaction in the results if this is something current or
something you can forcefully kill before attempting to shrink the file
again.  And I cannot stress enough that you gain nothing by making the log
file ridiculously small... I have seen people bragging that they free up
20GB on the database server, but the next day when the application times out
waiting for the log file to grow again, funny how they are nowhere to be
found...

Now set up your nightly maintenance script (or more often, if necessary) to
backup the database in full.

(2) leave the database in full recovery mode, but create a script that will
back up your log periodically.  I suggest more than once a day (here we
typically do 10 minutes or 15 minutes).  This will allow for greatest
flexibility in restore to point of time, so the maximum amount of data loss
(let's say if the server blows up) is 15 minutes, give or take.  Of course
if you put the backups on the same disk as the database, then it doesn't
matter much, if the failure is disk (which is a common enough one that it is
best practice to never put databases and backups on the same physical disk).

But you will still need to figure out why you have open transactions, if you
expect the log file to maintain itself through backups (this is usually the
reason why a log backup will not be able to free up space in the log file,
and subsequently the log file keeps growing out of control).

A