Short answer: don't use functions / subs.  Write everything inline within one script.

Button scripts can have subs / functions, but BOI scripts cannot (for the exact reason you mentioned).

This is possible with a bit of a workaround.

When using this approach, i set up one script named however i need it to be and then i set up another script file with the same name but with "_Procedures" appended to it. 

For example, TestUDS.vbs and TestUDS_Procedures.vbs.

TestUDS is the script assigned to an event and TestUDS_Procedures gets read and executed by TestUDS.

Here is what the the contents of TestUDS should be.  Note that i have the "On Error *" lines commented out.  This is so if there is an issue while setting up or testing, it will cause a hard error.  You'll also notice there is an Execute and ExecuteGlobal line.  The former is fine to use if one of your subs or functions in the procedures file will never have to call a sub or function in the procedures file.  Based on your example, this is not the case, so you would have to use the ExecuteGlobal line.

' On Error Resume Next
sProceduresFileName = "TestUDS_Procedures.vbs"
sProceduresFileParentFolderPath = "CM\Script\"
nConstForReading = 1
Set oFileSystemObject = CreateObject("Scripting.FileSystemObject")
sPathRoot = "" : sPathRoot = oSession.PathRoot
If CBool(oSession.CS) Then sPathRoot = oSession.PathCSRoot
sProceduresFilePath = sPathRoot & sProceduresFileParentFolderPath & sProceduresFileName
If oFileSystemObject.FileExists(sProceduresFilePath) Then
	' Execute oFileSystemObject.OpenTextFile(sProceduresFilePath, nConstForReading).ReadAll()
	ExecuteGlobal oFileSystemObject.OpenTextFile(sProceduresFilePath, nConstForReading).ReadAll()
End If
Set oFileSystemObject = Nothing
' On Error GoTo 0

The procedures file can be any valid VBScript.  Here is a sample.  You can include code outside of subs and functions as well as inside.  You can manage scope of variables within subs and functions by appropriately using the "Dim" statement.  You can further manage trapping errors by appropriately place the "On Error *" lines 

' On Error Resume Next

sTest = "Test"
Call subProcedure()
oSession.AsObject(oSession.UI).MessageBox "", "" & sTest

Sub subProcedure()
	' On Error Resume Next
	oSession.AsObject(oSession.UI).MessageBox "", "" & sTest
	sTest = "subProcedure"
	Call subProcedure2()
	' On Error GoTo 0
End Sub

Sub subProcedure2()
	' On Error Resume Next
	Dim sTest
	oSession.AsObject(oSession.UI).MessageBox "", "" & sTest
	sTest = "subProcedure2"
	' On Error GoTo 0
End Sub

' On Error GoTo 0

Final note, one benefit i really like about this approach is that you only have to recompile the scripts when making changes to the contents of the script assigned to the event.  You can make changes on the fly to the script containing the procedures without having to recompile and relaunch the task.  This is really useful when testing/debugging/developing as you don't have to recompile and relaunch the task after every change made.

ah, thanks David.  and your answer came with a bonus too!  Compiling every time the change is made and restarting the task slows down the development quite a bit.  This will expedite the process, especially debugging, very much.

Your advice on the difference for the button scripts actually help me quite a bit on other script projects i am working on!  So, thank you very much Kevin!