SurferScript Introduction
ScreenSurfer Version 2.0GA, July 30, 1999

Page Links	TENOTEXT Tag, SurferScript Events, Global.stml, TECONNECTED Tag, TEPUTSECTION TECALL Procedural TESECTION, Screen TESECTION, PATHTO, Secure Screens, Function Key Event Transaction (URL) TESECTION, Time driven TESECTIONS, WebInput Event Section TEEVENT
Examples	Template File, TENOTEXT, Script Error Section, TEPUTSECTION TECALL TESECTION, TESECTION Screen, BOOLEAN screen recognition, PATHTO Clause, Secure Logon Screen Transaction Section Function Key Event Time-based Event

This document is the first section of the SurferScript Reference, describing the template HTML extensions used to customize the ScreenSurfer Web Gateway.

Samples and Learning

There are a number of samples distributed in the ScreenSurfer directory \screensurfer\hostserver\Templates.  The Harvard.stml demonstrates a number of the macros and techniques available for enhancing a site.

Be sure to complete or at least browse the ScreenSurfer Tutorial. Each Tutorial section starts with a useful key skills directory with links to the section describing each skill.

Syntax and Case-sensitivity

The parser for the template files is relaxed regarding the case used for tags, macros and expressions, much like browsers are relaxed regarding the case of HTML tags.

This means that, as in a number of examples, you can use any case (all lower, all upper or any mix) when defining template tags as well as embedded expression functions.

SurferScript Organization

SurferScript utilizes the concept of In-stream programming, an optimal approach to user-interfaces that are based on HTML. Since so much of HTML formatting is based on literal text, SurferScript makes HTML the "primary" language, and models its logic and functions within the HTML paradigm. This is different than creating HTML user interfaces in languages such as BASIC or C, since in these languages all "output" is displayed using functions or macros. With SurferScript, all text that occurs in the program that isn't a comment or a special SurferScript tag is sent to the browser as it is encountered as a stream.

Other tools have pioneered this approach, namely Cold Fusion from Allaire. The ScreenSurfer authors simply recognized in-stream programming as the most productive approach to HTML user interfaces and built upon the concept. Since delivery of HTML user interfaces in an emulation environment is so dynamic, SurferScript files are not built around single HTML files, but around the concept of modular sections of HTML and commands contained in one or more STML files.

Modules and Sections

In a typical web server environment, the events-to-script/html is a simple model; an HTTP "hit" is received (from a user keying-in a URL at a browser or clicking on a link) and the web server opens the corresponding file, and starting at the top displays/interprets that file.

With ScreenSurfer, the types of events are far more complex and granular making a one-to-one correspondence between events and files somewhat unwieldy. To address the modular requirements of mapping events to HTML and script, the <TESECTION> tag is used to not only identify an event (to attach the enclosed HTML and script to) but also to organize events and scripts within modules.

Any given page delivered by a ScreenSurfer application may be produced by a single section or many sections combined by the developer (and by events) into a single HTML page. Any section of SurferScript can include another section from the same STML file or a different file (using the TEPUTSECTION or TECALL tag).

Executable and non-Executable Script

---

 Screen Display, other Events and Script Sections

TECONNECTED Defines logon screens; speeds initial connection

<TECONNECTED
  WHEN Screen_row_column {IS | ISNOT} "TEXT"
      [AND Screen_row_column]
      [...]>

You typically code one or these per connection (host). The TECONNECTED tag provides ScreenSurfer with help in identifying a successful host connection. It is important to define both top and bottom text areas of a screen in a TECONNECTED tag, as many screens are created by the host using multiple writes. The TECONNECTED tag is a simple, standalone tag. To enhance or identify the initial screen, you also need a TESECTION tag (following).

TEPUTSECTION/TECALL Executes (plays) a TESECTION of HTML and TEtags

Executes/sends the specified section. Typically used for SurferScript that is re-usable across more than one screen or transaction.  Note that a multi-part name is supported; sections local to the current template file can be specified alone.  When specifying a section in a different template file, you need to include the template name (without any file extension) followed by a period and the target section.

For more information on the use of parameters with TECALL see the Procedural TESection description.

TEPUTSECTION Examples
<TESECTION ShowMenu> <TEPUTSECTION global.header> <TEPUTSECTION GetToMenu> <TEPUTSECTION PresentMenu> <TEPUTSECTION global.footer> </TESECTION>
This example shows a section of STML that performs everything by calling other sections using the TEPUTSECTION tag. Note that when it calls a section outside the current template, it must include the .STML file name in the reference.

TENOTEXT [[type=]ALL | BREAKS]Suppress output to the HTML or E-MAIL stream

This tag is particularly useful when the <TEIF> tag is used, which requires a CRLF on the same line, or a number of <TERECIPIENT> tags inside a <TEMAIL> block. When inside the <TENOTEXT> tag, all output created by SurferScript tags (including the <TESHOW>) is still output to the HTML page, so when "things get complex" inside a <PRE> or <TEMAIL> tag, surround with a <TENOTEXT> / </TENOTEXT> block and perform all HTML output with <TESHOW> expressions. Note that when you do need to include a carriage return that the "\n" sequence (backslash, 'n') can be included in your <TESHOW> output string to send a CRLF to the output stream.

Note that the optional attribute BREAKS can be used to suppress only carriage returns (line breaks)-- this can provide a comprimise between suppressing all text and supressing just the annoying line breaks that follow each SurferScript tag...

TENOTEXT Example
<PRE> <TEAREA 1 1 23 80><TENOTEXT> <TEIF Screen(24,2,2)=="PF"> <TESHOW AidButtons(Screen(24,1,80), "")+"\n"> <TEELSE> <TEDATA 24 1 80><TESHOW "\n"> </TEIF> </TENOTEXT></PRE>
The above example shows the use of TENOTEXT to enable a clear logic block inside a PRE area, without additional CRLF sequences from displaying. The TEIF checks if a PF key definition is displayed on the bottom line and outputs the AidButtons function, otherwise simply outputs that line as text.

TESECTION Defines a block of HTML, TEtags, screen and transaction identification

Note that all TESECTION tags share the following characteristics:

• Any TESECTION may be called by another TESECTION using the TEPUTSECTION or TECALL tag, whether or not that section is associated with a defined event.
• All SurferScript between the TESECTION and the next TEEVENT or </TESECTION> is associated with the section.
• You can record and subsequently view all SurferScript execution and use this to debug your SurferScript using the Compile With Trace option in the DevCenter.

TESECTION (Procedural)

<TESECTION Name>
[<TEDECLARE PARAMETER Name Type Length 
     [Use="IN|out|inout"]
     [Data="text"]>

New in version 3 of ScreenSurfer (and later releases of 2.0) is the TEDeclare Parameter, which introduces the ability to pass parameters when calling the procedural TESECTION.

Since the addition of parameters to TESECTION blocks provides a far more modular programming environment, the TECALL tag was introduced as a substitute for the TEPUTSECTION. TEPUTSECTION was originally named when SurferScript was primarily a means of streaming-out HTML (thus the "put" in the tag name). You don't "put" a procedure or function; you "call" it, so we added the TECALL as a more natural tag to use when executing procedural TESECTION script blocks.

When you declare parameters, they will work inside the TESECTION only and will work just like a TEDECLARE VAR (see TEDECLARE VAR for a description of the parameters of TEDECLARE PARAMETER).

One extension past the simple TEDECLARE VAR is the Use="IN|out|inout" attribute, which defines how a parameter is used. The out and inout types actually return data to the calling script, and because of this the expression matching an "out" or "inout" parameter type must be a single variable name. This is a logical restriction of the OUT and INOUT parameter types so that there is a sensible "target" for the returned data.

The order in which the parameters are declared (yes, you can have one or more parameters) determines the order in which they are specified in the TECALL tag). As with many SurferScript tags, the TECALL can simply include expressions separated by "whitespace" (blanks, tabs or carriage returns) but if this technique is used, all of the parameters must be included in the TECALL.

A powerful capability of the SurferScript parameters is the optional parameter which is made possible when the data="text" attribute is included in the TEDECLARE PARAMETER. When the data attribute is included, the parameter may be omitted in the TECALL tag, and at the start of the called TESECTION the parameter will be initialized with the text specified in the data attribute. Note that in order to utilize the optional parameter feature, the TECALL tag must utilize the name=value (named parameter) form.

Note that as with all TESECTION tags, any TEDECLARE VAR tag which defines a variable and is contained within a specific TESECTION, has a name associated with that section when addressed anywhere else in your template files. By defining variables inside a section (when they are associated with that section!), you give an object-oriented identity to that variable and improve the readability of your code.

TESECTION Example
<TESECTION HEADER> <TEDECLARE Parameter Title Text 100 data="The Cool Screens"> <HEAD> <TITLE><TESHOW Title></TITLE> <SCRIPT Language="JavaScript"> <!-- Hide from old browsers if (typeof(parent.SessionKey) != "undefined") parent.SessionKey=<TEMACRO SessionKey> // end hiding --> </SCRIPT> </HEAD> </TESECTION> ... Inside other sections: ... <TECALL HEADER Title="Cool Logon Screen"> <TEMACRO TERMBODY> <TEFORM> ... <TECALL HEADER> <TEMACRO TERMBODY> <TEFORM>
In the above example, the section named "HEADER" provides a "universal" top of the page output section, incorporating a nice trick for frames environments, where the active SessionKey is stored in a parent frame JavaScript variable so that menu links or buttons in other frames can utilize the SessionKey in submitting requests that maintain state. Note the use of the Header Title parameter to enable calling sections to provide parameters / set attributes of the "Header" object while calling it, to gain customization of the section's behavior. In the second use of the section, the default value of the parameter is used (by omitting the title attribute in the TECALL.

TESECTION Output Parameters Example
<TESECTION Splitter> <TEDECLARE Parameter Key text 100 use="in"> <TEDECLARE Parameter Screen integer use="out"> <TEDECLARE Parameter Row integer use="out"> <TEDECLARE var sepAt integer> <TESET sepAt=FindText(Key, "_")> <TEIf sepAt != -1> <TESet Screen=TextLeft(Key,sepAt)> <TESet Row=TextMid(Key,sepAt+1,80)> <TEELSE> <TESet Screen=0> <TESet Row=0> </TEIF> </TESection> ... <TESection ProcessInput> <TEDeclare var Screen Integer> <TEDeclare var Row Integer> <TECall Splitter Key=web.Key Row=Row Screen=Screen> ...
In this example, a "worker" TESection provides parsing of input text strings, taking a value that is a concatenation of text values separated by an underscore (like "3_4") and returning to two target integer values.

TESECTION (Screen Event)

<TESECTION [SECURE] ScreenName>
  [WHEN SCREEN_row_column {IS|ISNOT|=|<>} "text" [AND | OR...][...]]
  [WHEN SCREEN IS EMPTY]
  [PATHTO ScreenName IS Keystring]>

All screens not defined in this type of section will flow through the global.default section, so you use this tag to identify a specific screen, then follow with the HTML you want for that screen.

This tag usually will use one or more Screen_row_column IS "text" clauses to identify static text (that is consistent) on the target screen. The DevCenter includes a component which is part of most of its wizards which make the generation of this tag easy, using point and click definitions.

The WHEN SCREEN IS EMPTY clause is a special case specifically for identifying an unformatted, blank screen. This avoids the need to define 24 tests, each for a blank line of 80 characters! It is mutually exclusive with the use of the WHEN SCREEN_row_column format.

Screen HTML Page Designs

Example of BOOLEAN Combinations in TESECTION
<TESECTION StatusGood WHEN Screen_1_2 IS "STATUS" AND Screen_24_2 IS "READY" OR Screen_1_2 IS "STATUS" AND Screen_24_2 IS "WAITING"> ... <TESECTION StatusBad WHEN Screen_1_2 IS "STATUS" AND Screen_24_2 IS "ERROR" OR Screen_1_2 IS "STATUS" AND Screen_24_2 IS "DISCONNECTED"> ...
This example shows how two sections have criteria so that the same "Status" screen has up to four different text strings on line 24. Note that each OR must REPEAT the complete criteria for recognition. That is why "STATUS" is repeated in each case.

The PATHTO clause

The Screen Navigation Rule-Base is populated as all template files are compiled using each section's "PATHTO" clause.  For example, the "MAIN_MENU" screen displays any number of screens, each which returns to the main menu with the F3 key; if the screen ORDER_MAIN has the following, than ScreenSurfer will be able to handle the Web Browser "back button" to go from ORDER_MAIN to the MAIN_MENU without any errors:

PATHTO Example
In the template file named "OrderEntry": <TESECTION MAIN_MENU WHEN SCREEN_1_2 IS "MAINMENU" PATHTO ORDER_MAIN IS "[home]1[erase eof][enter]" PATHTO CUST_MAIN IS "[home]2[erase eof][enter]" PATHTO SUPPLIER_MAIN IS "[home]3[erase eof][enter]"> ... <TESECTION ORDER_MAIN WHEN SCREEN_1_2 IS "ORDERMAIN" PATHTO MAIN_MENU IS "[pf3]"> ... <TESECTION CUST_MAIN WHEN SCREEN_1_2 IS "CUSTMAIN" PATHTO MAIN_MENU IS "[pf3]"> ... <TESECTION SUPPLIER_MAIN WHEN SCREEN_1_2 IS "SUPPMAIN" PATHTO MAIN_MENU IS "[pf3]">
In the above example, if the active screen is "SUPPLIER_MAIN" and the the SurferScript tag "TEACTION GOTO OrderEnter.ORDER_MAIN" is executed, ScreenSurfer will find the path (automatically) to ORDER_MAIN and will submit a pf3 (to display MAIN_MENU) and then will do a "home", "1" and the ENTER key, to display the ORDER_MAIN screen.

Secure Screens

The next screen to be displayed which does NOT have the SECURE attribute, will cause ScreenSurfer to re-route the user through the standard ScreenSurfer port. How ScreenSurfer works with the SECURE attribute is controlled with the registry entry HKEY_LOCAL_MACHINE/Software/iE/ScreenSurfer/Config/SecurityDefault. Whenever this setting is a "0", ScreenSurfer will switch the user between a secure port and the standard port. If this setting is "1", ScreenSurfer will ignore the user's status (whether or not in a Secure Port). If you want all user communications to run through the SSL port, then simply set the SecurityDefault setting to 1, and have users access ScreenSurfer starting with the HTTPS port of your IIS machine.

Secure Logon Screen Example
<TECONNECTED WHEN Screen_1_40 is "Welcome" AND Screen_5_20 is "Press Enter to Logon"> <TESECTION WELCOME WHEN Screen_1_40 is "Welcome" AND Screen_5_20 is "Press Enter to Logon"> .... <TESECTION SECURE LOGON WHEN Screen_1_40 is "Logon" AND Screen_5_20 is "Enter UserID"> ... <TESECTION MAIN_MENU WHEN SCREEN_1_2 IS "MAINMENU"> ....
In the above example, a user starts a session through the standard ScreenSurfer port (fast, direct, efficient), on the WELCOME screen. When the users ENTERS the Welcome screen, on display of the LOGON screen ScreenSurfer with "re-route" the display of the screen and the user's entries through the configured SSL port of a Microsoft IIS Web Server that has the ScreenSurfer Security Filter installed and active. When the MAINMENU screen is displayed, ScreenSurfer will then re-route the user back to the standard ScreenSurfer port, so that the higher CPU requirements of SSL is not applied to the entire conversation.

<TESECTION SectionName>
  [WHEN TranPath_n IS "TEXT" [AND...]]>

This works just like traditional CGI calls where you identify a particular URL to be mapped to some code. Web servers typically use a unique file extension to identify a CGI call; with ScreenSurfer, it is any URL which has no file extension and is not one of the "built-in" URL commands such as /surfer/emulator, /surfer/refresh and /surfer/exit.

You map a submitted URL to a transaction TESECTION using the TRANPATH_n descriptor, where the n identifies the part of the URL starting with the first value after the /surfer/ and with forward slashes separating the transaction path parts.

The Transaction Recognition Rule-Base is populated as all template files are compiled using each transaction section's "WHEN TranPath..." clause.  Note that the compiler is very touchy about ambiguity, and will reject any transaction definitions that have insufficient detail to enable runtime differentiation.  You cannot mix both transaction and Screen_ WHEN clauses, as a Transaction section is not necessarily connected to a single screen.  You can recognize virtually any URL targeted to ScreenSurfer using up to 4 parts in the transaction name. 

Transaction Section Example
<TESECTION SearchLinks> <A HREF="<TEMACRO TRANURL 'Search/New'>"> Click Here for a New Search </A><nbsp;<nbsp; <A HREF="<TEMACRO TRANURL 'Search/Edit'>"> Click Here to Edit Current Search </A><BR> </TESECTION> <TESECTION NewSearch WHEN TranPath_1 is "Search" AND TranPath_2 is "New"> <TEACTION GETSESSION> <!-- Navigate to New Search Screen --> ... <TESECTION NewSearch WHEN TranPath_1 is "Search" AND TranPath_2 is "Edit"> <TEACTION GETSESSION> <!-- Navigate Back to previous Search Edit --> ...
In the above example, the first section, SearchLinks is used by other sections to display two links on any page, one to initiate a new search, and the other to edit the existing search. (How this is implemented on both the host application and other SurferScript variables is not important to this example.) The TEACTION GETSESSION is used in your transaction sections to connect to the right session using the required HTTP variable, "SessionKey" Note that the TEMACRO TRANURL is a great tag to use for generating a ScreenSurfer transaction link, because it will include the /surfer/ prefix as well as a URL cookie for the current screen and current SessionKey.

There is no set rule on what your transaction sections can do, as they are simply blocks of SurferScript that get executed when called from an HTML page, like any CGI request. Examples of transactions you can create in SurferScript are:

• Custom connection transactions which use TEACTION CONNECT to connect to a host, and navigate to the logon screen with the newly acquired session
• Provide context-sensitive help provided by a TEAREA tag with the AS CLICKABLE attribute
• Provide actions driven by frames-based menus (similar to the above sample). Note that if you use the Header sample described at the top of this page, you can use the parent.SessionKey variable to construct a session-connected URL from any link on any frame in the application.
• Query a database and return results with search criteria provided by the active screen.
• Use active screen data to send an E-mail to a customer
• And so on!

<TESECTION Name>
  [WHEN AidKey IS "mnemonic"]>

There are very special cases when you would define this kind of section. The most common would be to capture the PF1 Key as part of implementing a Help System.

Note that this event will only occur when the standard /SURFER/EMULATOR URL is active, which is the default URL for a TEFORM tag. Since this is the standard method of delivering ScreenSurfer screen pages, you can count on the AID section capturing the AID key when you need it to.

NOTE: When you specify an AIDKEY section, the AIDKEY section replaces standard AID key entry.

AidKey Event Example
<TESECTION Help When AidKey is "[pf1]"> <!-- The help system always does a double-write so lets avoid any timing problems --> <TEREADYWHEN StrictRecognition HelpScreen when Screen_1_2 is "Help System"> <TEACTION ENTER "[pf1]"> </TESECTION>
The above example is based on a real requirement where a mainframe application system was "flipping" systems to support the PF1 (standardized as help) key. The "flipping" in the host results in two complete screen writes (with a pause in-between), which causes ScreenSurfer to display the first screen (which says "Retrieving help..."). The new tag "TEREADYWHEN" creates a synchronous condition whereby the TEACTION ENTER will not complete until the HelpScreen criteria is met.

<TESECTION Name>
    [WHEN TimeInterval IS Seconds] 
OR  [WHEN DateTime IS YYYY-MM-DD-HH-MM-SS]
OR  [WHEN DayAndTime IS DayOfWeek-HH-MM-SS]>

Examples of DayAndTime Specifications

Sample	Description
Monday-6-0-0	Every Monday at 6am
Friday-19-0-0	Every Friday at 7pm

Time-driven Section Example
<TESECTION SystemReport When DateTime is "*-*-*-7-0-0"> <TEACTION CONNECT "LU_GROUP_1"> <TEACTION ENTER "[clear]" skipscan> <TEACTION ENTER "sysreport halran cics1 cics2[enter]"> <TENOTEXT> <!-- suppress extra line feeds, etc...--> <TEMAIL Subject="Morning System Report from HAL Incorporated"> <TERECIPIENT address="surfer@ieinc.com"> <TELOOP Name="ScreenCount" First=1 Last=10> <TESHOW "<H1>Screen "+ScreenCount+"</H1>"> <TEAREA 1 1 24 80 READONLY> <TEIF Screen(24,60,4) != "More"> <TEBREAK> </TEIF> <TEACTION ENTER "[pf8]" skipscan> </TELOOP> </TEMAIL> <TEACTION RELEASE> </TENOTEXT> </TESECTION>
This example sends an e-mail every morning at 7am, running a ficticious system status transaction which doesn't require a logon. Images of each screen are emailed to surfer@ieinc.com. Please don't really do this! Also note: Email support requires a MAPI32 subsystem to be active prior to the ScreenSurfer service, and requires a TEDECLARE MAILPROFILE tag to be activated.

TEEVENT Describes Web events, Host events or Error Exception Catching events related to the current section

<TEEVENT WebInput>
    --OR--
<TEEVENT HostEventName
     WHEN SCREEN_row_column$ {IS|ISNOT|=|<>} "text" [AND...][...]
    --OR--
<TEEVENT Catch>

The TEEVENT tag gives the template author the opportunity to execute template code at different points-in-time related to the processing of a host screen section.  The TEEVENT tag must be placed after the <TESECTION> and before the </TESECTION> (or the next <TESECTION>.

You may have more than one <TEEVENT hosteventname> tag in a given section, but only one <TEEVENT WEBINPUT> tag and only one <TEEVENT CATCH> tag is supported per section.

When you place a <TEEVENT WebInput> tag in a section, any template code existing between it and the next <TEEVENT>, </TESECTION> or <TESECTION> tag will be executed in-between the entry of user web data to the active host screen and the processing of any related AID key.  This enables your template code to read and process web variables (variable names starting with "web." can read HTML data values) as well as read/manipulate user entries to the host screen.

When you place a <TEEVENT HostEventName> tag in a section, any template code existing between it and the next <TEEVENT>, </TESECTION> or <TESECTION> tag will be executed whenever a screen update by the host from the current section matches the WHEN clause in the TEEVENT tag.  The HostEventName you use is arbitrary, and is generally only relevant for error and status reporting purposes.

When you place a <TEEVENT Catch> tag in a section, any errors that occur during the execution of your SurferScript will cause execution to jump to the SurferScript following this tag. Note that if you perform a <TESET Task.ErrorComponent=""> in this section, that you will prevent ScreenSurfer from displaying the ERROR component table, which has information to the user about the current error, but may be confusing in a live environment. Generally, the <TEEVENT CATCH> tag is very useful for situations where you know that an error will occasionally occur, such as in a section with a lot of SQL. Sometimes you would rather not have detailed error handling for the 99.9% of the time that no errors will occur...but would like a place for execution to jump to should an error occur.

Global.HOME	Used for the "home page" and any unrecognized URL if a user enters the address of the ScreenSurfer server in their browser, the SurferScript in this section will be executed and resulting HTML sent to the user's browser. If you are implementing a frames environment, you will probably put the top frameset definition in this section.
Global.default	Used for all screens not declared in a Screen TESECTION. This is the section that all "default emulation" screens are passed-through. You can modify this section all you want in order to customize the default pass-through screens of ScreenSurfer, although you should maintain the sequence of the following tags, as they are key to the provision of a reliable emulation session: <TEPUTSECTION HEADER> <TEFORM> <TEAREA 1 1 24 80> </FORM> <TEPUTSECTION FOOTER> Global.default calls two other important sections that are not required but are recommended for good consistency in your ScreenSurfer application: global.header and global.footer which provide the top and bottom of the standard emulation pages.
Global.INVALID	Used for invalid or timed-out HTTP requests where the user submits a page and no longer owns the session.
Global.NO_SESSIONS	Executed when a user has requested a CONNECT for a specific group and there are no sessions available
Global.TIMEOUT	Executed when a session times-out. Note that this is a "background" execution, which will create a file \screensurfer\hostserver\events directory\Timeout_n where n is the sessionId of the user's session. If not specified, the timed-out session is stopped completely and restarted for a new user. By including this section, you can prevent the "stop" and "restart" and position the screen to a new user logon instead.
Global.ScreenTimeOut	Executed when a transition times-out. This is at the same point that an Event Log entry is written which says "Screen Transition: Http Thread". This can occur in a TEACTION ENTER or when a user is executing pass-through emulation. The TimeOut value is set using the Screen.TimeOut variable, which is defaulted to 20 seconds. This section will be displayed to the user at the browser, or you can suppress output by the user by utilizing the TEMAIL and the Profile="DiskFile" attribute in TEMAIL to create a "dump" of the current screen and other user information. If you use the Now() function to name the file, along with Screen.SessionID, you can have a unique file for each timeout, named by session...
Global.StartUp	Executed immediately after a compile, before the HTTP port for requests is opened. This will occur at ScreenSurfer service start, or when a compile is requested from the DevCenter. This section is useful for initializing global values that are stored in a database, so that the initialization occurs once. For example, a "Server." variable can be set in this section to create combo boxes or other HTML text.
Global.ShutDown	Executed after the HTTP port has been closed and ScreenSurfer is about to clear active sessions. This occurs immediately before a compile or when the ScreenSurfer service is shutdown.
Global.ScriptError	This section will execute in place of the standard script error display, which is a table including the error component and text description of the error. An example follows which essentially reproduces what the standard script error displays. Note that if you implement this section you need to check on the availability of a session using the Task.SessionActive variable prior to including any Screen. variables if you want these to display correctly to the user. Logging to a disk file can be very effective in tracking errors; note that all script errors are also logged to the event log. Global ScriptError section that logs script error to disk <TESECTION ScriptError> <TEMAIL Profile="DiskFile" Subject='\\screensurfer\\hostserver\\Err'+Now('local',5,'')+'.html'> <html> <title>Script Error <teshow now("local")></title> <table> <H2>SurferScript Error Encountered</H2> <p><table border> <tr> <td><b>Executing Section</b></td> <td><teshow Task.ErrorSection></td> </tr> <tr> <td><b>Last recognized host connection screen</b></td> <td> <teif task.sessionactive> <teshow screen.screenid> <teelse> Not connected to a session or unknown... </teif> </td> </tr> <tr> <td><b>Failing Component</b></td> <td><teshow task.ErrorComponent></td> </tr> </table> <teif task.sessionactive> <br><br>Current Screen Follows: <pre> <tearea 1 1 screen.rows screen.columns> </pre> </teif> </temail> <html> <head> <title>Application Error</title> </head> <body> <h2>Application Error</h2> Sorry, an application error occurred...to reaccess the host, please <a href="/surfer/connect/lu_group_1">Click Here</a> </body> </html> </tesection> This example reproduces the information from the internal error handler as a user script, and instead of displaying to the user, it writes the information to an HTML file with the current date and time in the name.