Update#2:
NULL will be treated as an undefined value.
When you query back this row, you will get undef - there is no distinction between NULL and undef. NULL and undef mean the same thing: there is no data, i.e. the value is "unknown".

I asked for, but didn't get the schema (what kind of field each of these variables is stored as). However it appears to me that these NULL values relate to text fields (either char() or varchar()).

Since you are creating the DB, I would put a null string instead of NULL for these text fields. A null string is not "undefined" and you won't get "undef" values as a result of a query. You could also put in some application specific string like "UNKNOWN", "NOT_SPECIFIED" or whatever. It is possible to store the string "NULL" or "null" instead of undef, but that could get confusing.

On input when creating the DB:

#!/usr/bin/perl -w
use strict;

my $line = "36,'', NULL, '', 'on', '', 300";
my @tokens = split(/\,\s*/, $line);
foreach (@tokens)
{
   $_ = "''" if $_ eq 'NULL';
   print "$_\n";
}

__END__
36
''
''
'' ## NULL is now an empty string
'on'
''
300
[download]

On output if undef values exist:

foreach (@tokens)
{
   $_ //= '';  #sets undefined value to empty string
               #the // operator (new in Perl 5.10) tests
               #for "defined-ness" instead of truthful-ness.
   print "$_\n";
}
[download]

==== original post continues ==
# each line has 14 comma separated tokens
# this does not appear to "jive" with your input statement
# Note: lost variable names due to reap of your subsequent post.
# Keep posting in the same thread - don't start new threads.
# To display this takes a 100 char line - no problem.
# but this wraps in Monk format

Show the create table statement for this DB.

Could be that you on input, put "" instead of the string NULL.
But what is "right" depends upon the values that are allowed when you create the table.

__DATA__
3,  0, 0, 3,  2, 'on', 'host_description - Hard Drive Space',      '',
+ NULL, '', 'on', '', 300, ''
4,  0, 0, 4,  1, '',   'host_description - CPU Usage - System',    '',
+ NULL, '', 'on', '', 300, ''
5,  0, 0, 5,  1, '',   'host_description - CPU Usage - User',      '',
+ NULL, '', 'on', '', 300, ''
6,  0, 0, 6,  1, '',   'host_description - CPU Usage - Nice',      '',
+ NULL, '', 'on', '', 300, ''
7,  0, 0, 7,  2, 'on', 'host_description - Noise Level',           '',
+ NULL, '', 'on', '', 300, ''
8,  0, 0, 8,  2, 'on', 'host_description - Signal Level',          '',
+ NULL, '', 'on', '', 300, ''
9,  0, 0, 9,  2, 'on', 'host_description - Wireless Transmits',    '',
+ NULL, '', 'on', '', 300, ''
10, 0, 0, 10, 2, 'on', 'host_description - Wireless Re-Transmits', '',
+ NULL, '', 'on', '', 300, ''
[download]

Update:

When you create the DB, I would suggest that you not use "" as a value.
Give each field a value that makes sense, e.g. 'on' or 'off'. Don't fiddle with stuff like "the null string means 'off' ", if you mean off, say 'off'.

3,  0, 0, 3,  2, 'on', 
4,  0, 0, 4,  1, '',   # 4,  0, 0, 4,  1, 'off'
5,  0, 0, 5,  1, '',   # 5,  0, 0, 5,  1, 'off',
6,  0, 0, 6,  1, '',   # 6,  0, 0, 6,  1, 'off', 
7,  0, 0, 7,  2, 'on', 
8,  0, 0, 8,  2, 'on', 
9,  0, 0, 9,  2, 'on', 
10, 0, 0, 10, 2, 'on',
[download]

You could encode 'on' to be '1' and 'off' to be 0, but that optimization is often not needed. It could be necessary, but often it is not. Encoding "" to mean 'off' is, in my opinion not a good idea.