Screen Recognition Prerequisites<\/h2>\n\n\n\n
The following prerequisites must be satisfied before Screen Recognition\nwill operate:<\/p>\n\n\n\n
- The StayLinked Server and Administrator running at least version 10.0.0 Build 140. This article pertains to the features included in the product version displayed in the page header of the document.<\/li>
- A Terminal Emulation (TE) License must be installed on StayLinked Server.<\/li>
- A Screen Recognition License must be installed on StayLinked Servers older than v12.1.<\/li>
- The end-user application must present application screens in a structured and consistent manner.<\/li>
- The features described in this article can significantly increase the hardware requirements of the StayLinked Server process on your server platform. Monitoring of processor and JVM memory requirements should be performed during implementation of advanced StayLinked features.<\/li><\/ul>\n\n\n\n
How Screen Recognition and Screen Reformatting Works<\/h2>\n\n\n\n
For Telnet Host Entries that have recognition screens defined and have screen recognition enabled, the Screen Recognition and Screen Reformatting functions will be performed each time the application screens are presented to the telnet client. <\/p>\n\n\n\n
Application Screen Presentation Events <\/h3>\n\n\n\n
When an end-user host application displays a new screen, or updates some\npart of the screen, or moves the cursor on the screen, this causes the Telnet\nServer to send \u2018screen update\u2019 instructions to the Telnet Client. In the StayLinked\nTelnet Client, these \u2018screen update\u2019 instructions are evaluated and converted\ninto a specific type of \u2018Application Screen Presentation Event\u2019. There are four\nkinds of these screen presentation events and only two of these will cause\nscreen recognition and reformatting to be processed by the server.<\/p>\n\n\n\n
FULL-SCREEN UPDATE \u2013<\/strong> When the Telnet Server sends \u2018screen\nupdate\u2019 instructions to the Telnet Client which cause the entire telnet screen\nto be repainted, then a FULL-SCREEN UPDATE event is triggered. All full-screen\nupdate events will cause the StayLinked Server to perform screen recognition\nprocessing.<\/p>\n\n\n\n
PARTIAL-SCREEN UPDATE \u2013<\/strong> When the Telnet Server sends \u2018screen\nupdate\u2019 instructions to the Telnet Client which causes only a portion of the\ntelnet screen to be repainted, then a PARTIAL-SCREEN UPDATE event is triggered.\nAll partial-screen update events will cause the StayLinked Server to perform\nscreen recognition processing.<\/p>\n\n\n\n
SINGLE-CHARACTER UPDATE \u2013<\/strong> When the Telnet Server sends \u2018screen\nupdate\u2019 instructions to the Telnet Client which causes only a single character\nof the telnet screen to be repainted, then a SINGLE-CHARACTER UPDATE event is\ntriggered. All single-character update events are ignored and no screen\nrecognition processing will occur as a result of this type of event.<\/p>\n\n\n\n
CURSOR-MOVEMENT UPDATE \u2013<\/strong> When the Telnet Server sends \u2018screen update\u2019 instructions to the Telnet Client which causes only the cursor to be moved to a new location, then a CURSOR-MOVEMENT UPDATE event is triggered. All cursor-movement update events are ignored and no screen recognition processing will occur as a result of this type of event.<\/p>\n\n\n\n
Structure and Consistency in Application Screens <\/h3>\n\n\n\n
These features depend on the ability to consistently describe the layout of a specific screen. The description of a specific screen is composed of a collection of \u2018Recognition Strings\u2019 that describe screen text that may or may not appear in a specific location of the screen. It is crucial for accurate and reliable screen recognition that these application screens are presented in a structured and consistent manner, where the screen will be recognized each and every time it is displayed. Some host platforms and emulation types lend themselves to consistent and structured screen display events. The 5250 (AS\/400-iSeries-i5 platform) and 3270 (Mainframe platform) emulation types implement \u2018record format\u2019-based screen designs that lend themselves to displaying application screens in a consistent manner. The VT100\/220 (Windows and Unix platforms) emulation types implement stream-based screen rendering that is free-format in design and is not inherently consistent in presentation of application screens. Due to these implementation differences, VT emulation screens can be more challenging to implement screen recognition.<\/p>\n\n\n\n
An example of a structured and consistent application screen is the 5250 sign on screen: <\/p>\n\n\n\n
![\"\"](\"https:\/\/portal.staylinked.com\/sl\/kb\/wp-content\/uploads\/2019\/09\/Recognition.4.jpg\")
<\/figure>\n\n\n\nThis screen can be recognized because there are many screen text elements that can be used to describe this screen, and those text elements will only be displayed in specific locations. Even if the user provides invalid authentication information, the screen remains consistent with only the addition of an error message displayed on row 24, like this:<\/p>\n\n\n\n
![\"\"](\"https:\/\/portal.staylinked.com\/sl\/kb\/wp-content\/uploads\/2019\/09\/Recognition.5.jpg\")
<\/figure>\n\n\n\nOn the other hand, here is an example if a loosely structured application screen that is used to log on to an HP\/UX Unix machine, where a scrolling, command-line style is implemented: <\/p>\n\n\n\n
![\"\"](\"https:\/\/portal.staylinked.com\/sl\/kb\/wp-content\/uploads\/2019\/09\/Recognition.6.jpg\")
<\/figure>\n\n\n\nIn this case, there are fewer screen text elements to be used for recognition, and in the case of a invalid log on attempt, the screen layout changes and is not consistently formatted as shown here:<\/p>\n\n\n\n
![\"\"](\"https:\/\/portal.staylinked.com\/sl\/kb\/wp-content\/uploads\/2019\/09\/Recognition.7.jpg\")
<\/figure>\n\n\n\nThis particular screen can be used for a \u201cone-time recognition\u201d event\nwith an auto-response to perform an automated logon but would not be easily\nusable for screen reformatting where a very consistent screen presentation is\nrequired for screen reformatting to be successful.<\/p>\n\n\n\n
Be aware that the application determines how these screens are presented. It is important for accurate and reliable screen recognition and reformatting that these application screens are presented in a structured and consistent manner.<\/p>\n\n\n\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nScreen\nRecognition Order of Operations\n\n\n\n<\/h3>\n\n\n\n
When an application screen presentation event occurs, the following\nactions will be processed in this specific order:<\/p>\n\n\n\n
STEP 1) SCREEN RECOGNITION \u2013<\/strong> The presented screen will be evaluated to\ndetermine if it matches any of the screens that have been defined to be\nrecognized for this Telnet Host Entry. The recognition screen is identified by\none or more \u2018Recognition Strings\u2019 that describe screen text that may or may not\nappear at a specific location on the current screen. Each \u2018Recognition String\u2019\nelement is described by a Screen Row, a Screen Column and the String text.\nThere is an option to specify whether the Screen text must match or must not\nmatch. There is an option to specify whether the Screen text matching is\ncase-sensitive. In addition to one or more \u2018Recognition Strings\u2019, an optional\ncursor location can be defined that will be evaluated to determine whether the\nscreen matches or not. If all of the \u2018Recognition Strings\u2019 and any specified\ncursor location are determined to match the current presentation event,\nprocessing will continue with Step 2, otherwise the screen presentation event\nis handled as a standard telnet screen and will be presented to the user on the\ndevice \u201cas-is\u201d.<\/p>\n\n\n\n
STEP 2) SCREEN VARIABLES \u2013<\/strong> Once the screen is determined to be a match, the server will determine if any \u2018Screen Variables\u2019 have been defined for this screen and will collect the values for the variables. These \u2018Screen Variables\u2019 provide the ability to capture data from the recognized screen for use in Host APIs, Auto-Responses or Screen Reformatting for this or other recognized screens. Each \u2018Screen Variable\u2019 element is described by a unique ID, a Screen Row, a Screen Column and a Length to describe where to retrieve the variable from the recognized screen. A screen variable can have \u2018local scope\u2019 and the value will be available for use only in the current recognized screen. A screen variable can also have \u2018global scope\u2019 and the value will be available for use in any recognized screen. Additionally, screen variables can be created with \u2018static\u2019 values which are pre-defined and will not be scraped from the current screen.<\/p>\n\n\n\n
STEP 3) HOST APIs \u2013<\/strong> After processing and collecting values for\nany screen variables, the server will process any \u2018Host APIs\u2019 that are defined\nfor this screen. The \u2018Host APIs\u2019 provide a mechanism by which the client\nbehavior can be controlled on the device, or other actions can be taken. The\nHost APIs can perform many functions including common tasks like sending\naudible beeps to the device, disabling the scanner laser on the device, display\na message dialog on the device, instruct the device to perform Text-to-Speech\nor Speech-Recognition voice functions, update the StayLinked Connections List\nwith information about the device, the user, or other values, and many other\nfunctions. The Host APIs can be configured to be processed for a specific\ninstance of the recognized screen, using instance values like *ALL, *EVEN,\n*ODD, 1 or >1 to describe when to perform the Host API for this recognized\nscreen. There is an option to specify that the Host API only be performed if\nthe presentation space event is a \u2018Full Screen\u2019 event and another option to\nspecify that the Host API only be performed if the application is transitioning\nfrom a specific recognized screen to this recognized screen. Screen variable\nvalues that were collected in STEP 2 can also be used as Host API arguments.\nFor example, a variable collected from the 5250 Device Name (WSID) on the\nAS\/400 Sign On Screen can be used by a Host API to update the \u2018Device Name\u2019\ncolumn in the \u2018Connections List\u2019 displayed in the StayLinked Administrator.<\/p>\n\n\n\n
STEP 4) AUTO-RESPONSES \u2013<\/strong> After processing Host APIs, the server will\nprocess any \u2018Auto-Responses\u2019 that are defined for this screen. The\n\u2018Auto-Responses\u2019 provide a mechanism by which a response script can be entered\ninto the recognized screen. The Auto-Responses can be used to perform many\ncommon tasks like automatically logging on to the telnet server, automatically\ndismissing message screens, pre-loading some fields on the recognized screen\nand just about anything else that can be imagined. The Auto-Responses can be\nconfigured to be processed for a specific instance of the recognized screen,\nusing instance values like *ALL, *EVEN, *ODD, 1 or >1 to describe when to\nrun the response script for this recognized screen. There is an option to\nspecify that the response script only be processed if the presentation space\nevent is a \u2018Full Screen\u2019 event and another option can specify that the response\nscript only be processed if the application is transitioning from a specific\nrecognized screen to this recognized screen. Screen variable values that were\ncollected in STEP 2 can also be used as response script elements. For example,\na screen variable used to collect an \u2018Order Number\u2019 value from a previously\nrecognized screen can be used to preload the \u2018Order Number\u2019 field in the\ncurrent recognized screen.<\/p>\n\n\n\n
STEP 5) INPUT MODIFIERS \u2013<\/strong> For any screen that is displayed to the\nuser, one or more Input Modifiers may be defined. These input modifiers can be\nused to change keyboard, scanner or voice input to meet any special\nrequirements imposed by a specific screen. You may specify what type of input\nis allowed, \u2018Keyboard Only\u2019, \u2018Scanner Only\u2019 or \u2018Voice Only\u2019. You may modify the\n\u2018Case\u2019 of character input to this screen, forcing \u2018Upper Case\u2019 or \u2018Lower Case\u2019 or\n\u2018Original Case\u2019. You can define screen-specific key remapping, for example you\ncan convert a [tab] to be an [enter]. \nAnd you may add a special scan prefix, scan suffix and apply regular\nexpressions to any barcode that is scanned into the recognized screen.<\/p>\n\n\n\n
STEP 6) SCREEN REFORMATTING \u2013<\/strong> After processing Auto-Responses, the server will process any \u2018Screen Reformatting\u2019 that has been defined based on the displayable columns and rows for the current device. For example, if the device is currently configured to display 21 columns and 16 rows, and if there is a reformatted screen that has been designed for 21 columns and 16 rows, then the reformatted screen will be displayed on the device instead of the host application screen. When a reformatted screen is designed, a host \u201cscreen map\u201d can be used that references the application screen layout. Using this \u201cscreen map\u201d a new reformatted version of the screen can be designed to fit on the device display. The new reformatted screen can contain various elements, like \u2018constant text\u2019 that was not displayed on the original host screen, \u2018variables\u2019 that were collected from the host screen, \u2018copy blocks\u2019 of text that are copied from the host screen, and \u2018input fields\u2019 that are linked to existing input fields on the host screen. The Screen Reformatting feature is a powerful way to use existing \u2018full-screen\u2019 host applications on \u2018small-screen\u2019 devices without having to create new screens within the original host application or change the original host application logic.<\/p>\n\n\n\n
Special Mnemonics <\/h2>\n\n\n\n
Integrated throughout StayLinked is the ability to map keys, create scripts and provide input to the telnet host via mnemonics. These values appear in square bracket characters that contain the keyword or combination. Some of these values are specific to individual areas within StayLinked. For example, the [enter] mnemonic would work in any StayLinked input as a carriage return plus a line feed. Another example, the [radio_stats] mnemonic represents a client-only feature that opens the client window to show current radio information. Screen recognition and reformatting has several custom mnemonics that only operate in the recognition and reformatting dialogues. Most of these mnemonics are fairly self-explanatory as their tags suggest their intended use. <\/p>\n\n\n\n
[encrypt #,%%]<\/strong> \u2013 This mnemonic is used to cause scripted text to be\nencrypted in the configuration files. There are two arguments provided to this\nmnemonic, the first is a unique sequence number and the second is the text to\nbe encrypted. An example would be the use of a 5250 logon sequence in a\n\u2018Startup Script\u2019. In this case, your script for logon could be entered like\nthis: [encrypt 1,myuserid][fldext][encrypt 2,mypassword][enter] The text\nenclosed in the [encrypt #,%%] mnemonic will be stored in the configuration\nfiles in an encrypted format and will no longer be displayed in clear text in\nthe Administrator user interface.<\/p>\n\n\n\n
[cursor row#, col#]<\/strong> \u2013 This mnemonic is used to move the current\ntelnet cursor location to a specific row and column. This scripting mnemonic is\nused for both VOICE input processing and for Screen Reformatting input\nprocessing.<\/p>\n\n\n\n
[inputloc row#, col#]<\/strong> \u2013 This mnemonic is used to the next user\ninput to be targeted to a specific row and column. This scripting mnemonic is\nused for Screen Reformatting input processing.<\/p>\n\n\n\n
[defer_recognition]<\/strong> \u2013 This mnemonic would be added to any event in\nwhich you want to prevent recognition from repeating.<\/p>\n\n\n\n
[force_recognition]<\/strong> \u2013 This mnemonic would be used when the current\ninput or presentation event should trigger a (re)recognition immediately,\nregardless of the presentation of the emulation screen.<\/p>\n\n\n\n
[force_reformat]<\/strong> \u2013 This mnemonic would be used when reformatting\nshould be enforced to ensure that partial screen updates do not prevent the\nreformatting of the screen to your users.<\/p>\n\n\n\n
[regexgroup #]<\/strong> \u2013 This allows the use of stored regex groups from a previous regular expression capture in future screens. Setting # to 0 will clear the stored regex group values. [regexgroup next] is a feature added in server v16.2<\/strong> allowing the SmartTE Server to provide the next sequential Regex Group for Auto-Response processing rather than attempting to use specifically numbered [regexgroup ##] mnemonics<\/p>\n\n\n\n
[wait] <\/strong>\u2013 This script mnemonic is used for VT emulation to cause the\nprocessing to wait for the next telnet screen presentation event to occur\nbefore continuing with further script processing.<\/p>\n\n\n\n
[send] <\/strong>\u2013 This script mnemonic is used for VT emulation to force the\ncurrent script segment to be sent to the host immediately.<\/p>\n\n\n\n
This list includes mnemonics that are only valid in screen recognition and reformatting. There is a large list of valid mnemonics available in the keyboard maps section of the Administrator. There is also more information on mnemonics and their usage in the StayLinked Administrator User Guide and special mnemonics appendix.<\/p>\n\n\n\n
Capturing Screen Maps<\/h2>\n\n\n\n
One of the most important steps in recognition and reformatting is the use of screen maps. Screen maps are a snapshot of the host screen. These maps can then be used in the design tool to set recognition strings, capture variables and create the side-by-side view of a reformatting screen from the original screen to the new design. Capturing a screen map is done from the Administrator\u2019s connections list by right clicking on a session with the current screen and selecting View > Export Screen Map, or by setting a keyboard map entry to the mnemonic [screen_map]. It can be important to organize the naming of screen maps based on use or order of appearance, so name prefixes (q.v. 01.signon) that sort your screen maps may be helpful over time. Screen maps that are used in any recognition events cannot be deleted as long as a reference exists.<\/p>\n\n\n
<\/p>","protected":false},"excerpt":{"rendered":"
This article has been created to provide an introduction to the screen recognition features available within StayLinked. As a thin-client solution, StayLinked is ideal for adjustments and enhancements to many emulation environments. These advanced features provide a flexible mechanism by which the StayLinked Server can recognize screens, collect information from…<\/p>\n","protected":false},"author":7,"comment_status":"open","ping_status":"closed","template":"","format":"standard","meta":[],"ht-kb-category":[42],"ht-kb-tag":[],"yoast_head":"\n
Screen Recognition Overview – StayLinked<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.staylinked.com\/knowledge-base\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Screen Recognition Overview – StayLinked\" \/>\n<meta property=\"og:description\" content=\"This article has been created to provide an introduction to the screen recognition features available within StayLinked. As a thin-client solution, StayLinked is ideal for adjustments and enhancements to many emulation environments. These advanced features provide a flexible mechanism by which the StayLinked Server can recognize screens, collect information from...\" \/>\n<meta property=\"og:url\" content=\"https:\/\/portal.staylinked.com\/sl\/kb\/knowledge-base\/screen-recognition-overview\/\" \/>\n<meta property=\"og:site_name\" content=\"StayLinked\" \/>\n<meta property=\"article:modified_time\" content=\"2026-02-12T22:14:09+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/portal.staylinked.com\/sl\/kb\/wp-content\/uploads\/2019\/09\/Recognition.4.jpg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"14 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebSite\",\"@id\":\"https:\/\/portal.staylinked.com\/sl\/kb\/#website\",\"url\":\"https:\/\/portal.staylinked.com\/sl\/kb\/\",\"name\":\"StayLinked Knowledge Base\",\"description\":\"Partner Portal Resources and Support\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":\"https:\/\/portal.staylinked.com\/sl\/kb\/?s={search_term_string}\",\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/portal.staylinked.com\/sl\/kb\/knowledge-base\/screen-recognition-overview\/#primaryimage\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/portal.staylinked.com\/sl\/kb\/wp-content\/uploads\/2019\/09\/Recognition.4.jpg\",\"contentUrl\":\"https:\/\/portal.staylinked.com\/sl\/kb\/wp-content\/uploads\/2019\/09\/Recognition.4.jpg\",\"width\":652,\"height\":300},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/portal.staylinked.com\/sl\/kb\/knowledge-base\/screen-recognition-overview\/#webpage\",\"url\":\"https:\/\/portal.staylinked.com\/sl\/kb\/knowledge-base\/screen-recognition-overview\/\",\"name\":\"Screen Recognition Overview – StayLinked\",\"isPartOf\":{\"@id\":\"https:\/\/portal.staylinked.com\/sl\/kb\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/portal.staylinked.com\/sl\/kb\/knowledge-base\/screen-recognition-overview\/#primaryimage\"},\"datePublished\":\"2019-09-18T15:36:44+00:00\",\"dateModified\":\"2026-02-12T22:14:09+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/portal.staylinked.com\/sl\/kb\/knowledge-base\/screen-recognition-overview\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/portal.staylinked.com\/sl\/kb\/knowledge-base\/screen-recognition-overview\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/portal.staylinked.com\/sl\/kb\/knowledge-base\/screen-recognition-overview\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/portal.staylinked.com\/sl\/kb\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Articles\",\"item\":\"https:\/\/portal.staylinked.com\/sl\/kb\/knowledge-base\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Screen Recognition Overview\"}]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","_links":{"self":[{"href":"https:\/\/portal.staylinked.com\/sl\/kb\/wp-json\/wp\/v2\/ht-kb\/1472"}],"collection":[{"href":"https:\/\/portal.staylinked.com\/sl\/kb\/wp-json\/wp\/v2\/ht-kb"}],"about":[{"href":"https:\/\/portal.staylinked.com\/sl\/kb\/wp-json\/wp\/v2\/types\/ht_kb"}],"author":[{"embeddable":true,"href":"https:\/\/portal.staylinked.com\/sl\/kb\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/portal.staylinked.com\/sl\/kb\/wp-json\/wp\/v2\/comments?post=1472"}],"version-history":[{"count":2,"href":"https:\/\/portal.staylinked.com\/sl\/kb\/wp-json\/wp\/v2\/ht-kb\/1472\/revisions"}],"predecessor-version":[{"id":5888,"href":"https:\/\/portal.staylinked.com\/sl\/kb\/wp-json\/wp\/v2\/ht-kb\/1472\/revisions\/5888"}],"wp:attachment":[{"href":"https:\/\/portal.staylinked.com\/sl\/kb\/wp-json\/wp\/v2\/media?parent=1472"}],"wp:term":[{"taxonomy":"ht_kb_category","embeddable":true,"href":"https:\/\/portal.staylinked.com\/sl\/kb\/wp-json\/wp\/v2\/ht-kb-category?post=1472"},{"taxonomy":"ht_kb_tag","embeddable":true,"href":"https:\/\/portal.staylinked.com\/sl\/kb\/wp-json\/wp\/v2\/ht-kb-tag?post=1472"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}