1. Home
  2. User Experience
  3. Device Naming and Device-Specific Variables

Device Naming and Device-Specific Variables

Workstation names can have a wide range of uses. There are several options to name or provide a custom variable to each device.

Assigning workstation names allows the value to appear in the Administrator as displayed here:

Lookup XML

Originally created for use with IBM systems as virtual workstation names, the Device Group option for prefix and suffix naming was highly limited. This was expanded with the availability of the [deviceid] variable that was configurable on each device, but still only offered one device-specific defined variable to work with. With StayLinked Server v15.5 and newer, there is now support for a wide range of device-specific variables, but server-managed in traditional StayLinked fashion. This server-side feature is called Lookup which utilizes an XML configuration file on the server to add additional variable options to each device based on the Unique Identifier.

With the initial release in 15.5, this XML file must be manually created. The best ways to find device Unique Identifiers is within the Usage Tracking feature, the StayLinkedManager Log as described in Session Persistence, or by double-clicking a session in the connections list to review the connection details.

LOOKUP.XML Formatting

Within a lookups node, each 'lu' entry will refer to the MAC address as reported by the OS used by StayLinked for that device. The lookup can also use the [deviceid] as defined on the device, with the lookup value define in the third line below as lookups key= accepting either devid or mac.

Once created, this file must be placed in the Config subdirectory of the StayLinked Server. This is the same file location as all other configuration files and does not need to be placed in the StayLinked Administrator folder structure. the initial release of this feature does not include this file in configuration export or import.

When changes to this file are made, the server process must be restarted or the configuration must be reloaded. Reloading setting is accomplished by placing an empty file in the config folder of the server named reload.xml. This file will get automatically cleaned up when the next session is started on the server, reloading all configuration.

Substituting Session Values

To perform the substitutions from this lookup table, you can use the new custom mnemonic [lookup %%%%%] where the %%%%% represents the variable name. The server will replace the [lookup %%%%%] mnemonic with the variable value if found. If the name-value pair is not found, the mnemonic will be replaced by "" (null).

For example, if the device with UID 3833510EF881 connects to the server and a script or event triggers the [lookup user] variable, the value john would be returned.

Assigning Workstation Names by Device

Prior to server version 15.5, there were only two methods of naming devices, [deviceid] or by configuring a pre+suffix value to build a name using part of the IP address. Prefix+suffix should only be used in networks with static network addressing.

Using [deviceid]

The first step is to assign each device the name it will use. This is accomplished in one of a few different ways. On many Windows-based devices or when using Android Client build 222 or higher, the Client can use the device or 'node' name entered into the operating system. Since this provides no control over persistence, StayLinked Clients also offer several methods of assigning the name within the Client configuration.

Option 1: On the device itself under the Host > Configure > Server is the ‘Use Device ID’ option. This enables the field to enter the custom name for this device. Devices configured for ‘Max Connections’ of more than one will display a table that allows for a name to be assigned to each session.

Notes

  1. If the Host menu is not visible, Android devices can re-display the menu bar with a single long tap. Other device operating systems using ‘full screen mode’ will need to have this option disabled or use one of the other options listed below.
  2. Host options are not available while in a session or attempting to connect to the server.
  3. Some hosts are case sensitive, and we recommend using all upper-case characters for workstation names.
  4. Entering the value OSNAME in this device ID value can pull the device's name in the Android OS on most Android versions.

Option 2: The value can also be populated directly in the client configuration file called staylink.ini using a text editor or from the Administrator’s connections list under; the right click menu > Commands > Edit Client INI. Add or set the entry for device_id= value to your desired workstation name.

Option 3: Using the Administrator section for Client Configuration > Client Settings you can add the setting for Server > Workstation ID and set the unique value based on the device MAC or IP address.

Option 4: This same setting is also available under the Administrator section for Client Configuration > Scan2Configure Profiles. This allows you to create barcodes that can be scanned into the client scan test in order to set the workstation name.

The next step to using a device-assigned name is by configuring the device group to gather the value from each connection. This is done in the Administrator section for Emulation Settings > Device Groups > double click your device group and type [deviceid] into the ‘Device Name Prefix’ as displayed here:

Once all configuration is in place, any new sessions falling into your device group will display the workstation name in the connections list of the Administrator. If you do not see your desired name, make sure the device is falling into the proper device group and that it has started a new session. Refreshing the connections list will show the session start time, which should be after you have saved your configuration changes.

Using [prompt_user]

Setting devices with [prompt_user] will cause the client to present a prompt to users on first launch. This value is placed in the configuration and will not prompt the user again unless the value is reset.

Note that using this mnemonic allows for customization of the message, for example: [prompt_user Custom message here] would user 'Custom message here' as the prompt message.

Using Device Names in StayLinked Scripting

Once the device name variable has been established for a connection, it can be used in various StayLinked scripts by using the mnemonic [deviceid] or [devicename]. This will work for all emulation types and is not limited to 5250 virtual devices. Connections can be easily identified in the Administrator’s connections list by matching inventory tags or device labels to this value.

Automatically Constructing Device Names by IP

Entering any value other than [deviceid] in the device name prefix will result in a name built dynamically using the prefix plus the end of the IP address as a suffix. Naming is configured by device group to identify groupings by device type, device model, or network segment. By example, devices connecting from an Atlanta location might be given an ‘ATLXXX’ style name. Vehicle mount units might be given a ‘VMUXXX’ style name. Whatever naming you choose for your environment, StayLinked will use the configuration options from the appropriate device group.

The ‘Suffix Octets’ option determines how many portions of the IP address will be added to your suffix.

Using a prefix of NULL will return a value of the suffix only, with no prefix. If you do not use the decimal suffix option, the suffix will return a hexadecimal value of two-digits per octet.

Leaving the Device Name Prefix blank will default to ‘automatic’ naming. For IBMi, this will use the server’s options for QAUTOCFG to provide a QPADEVXXXX style workstation ID.

Starting in v15.2, suffix octets can now be configured for public and private IP address use. Please review the Administrator Guide section on Device Group Administration for details on these options if your devices are using a NAT'd network address.

Dynamic Device Naming and DHCP

If your devices use a Dynamic Host Configuration Protocol (DHCP, or server assigned) address, they have the possibility of changing network address while sessions are still active. When using the IP address as part of the device name, devices can hold ownership of a name longer than they own the network address. This can often cause naming conflicts. The more devices you own, the more difficult it becomes to create static IP address reservations in a DHCP scope, or manually assign names for each individual device. Essentially, when using device names, you will need to manage either the network address, or the unique name on each device.

Our two recommendations when using DHCP with prefix + suffix naming include:

  1. Keep your DHCP lease as long as possible, preferably at least 3 days. The faster your devices acquire network addresses, the more likely they are to change address.
  2. Use a telnet inactivity timeout to terminate inactive sessions. This can be done as a host property in the StayLinked Telnet Host Entry if your application or telnet host does not provide this feature. Inactive sessions can hold on to names that might be needed by active devices.

IBM i ~ Virtual Devices and Subsystems

Originally developed for IBM i (aka. OS/400, i5/OS), StayLinked provides several options for creating virtual workstation IDs. For IBM i, this can be a critical method of getting devices to the desired application screens.

Using workstation names provided by an emulator, IBM i systems can provide different work environments for various connection types. This can be especially helpful when working with partial displays, or devices that have a small display that can’t effectively display the entire emulation screen.

The system is based on adding workstation entries to the subsystem description. While the description will display workstation entries, it does not work as an interface to add and remove entries. Once an entry is added, it cannot be adjusted, but must be removed and then re-added with the desired values. Using a workstation allocation value of *SIGNON will allow use of this subsystem for qualified workstations, while a value of *ENTER will prevent qualified workstations.

Important ~ When directing workstations to a specific subsystem, it is important to include the parameters in the desired subsystem and exclude them from other subsystems. The operating system may sometimes attach a device to any interactive subsystem that does not contain an exclusion but will typically provide connections to preferred subsystems.

There are several useful commands when configuring IBM i for workstation connection parameters:

WRKSBSD: Work with Subsystem Description. This command allows you to review the various subsystem configuration options. Using option 5 to display, select option 4 ‘Work station name entries’ to display each workstation value specified for the selected subsystem.

WRKCFGSTS: Work Configuration Status. This command is critical for reviewing the active and available workstation entries. Devices that have been varied off for security reasons must be re-enabled before the workstation will become available on the server. When using the Vary On option, the device will be set to Vary On Pending until the workstation description is used again.

ADDWSE: Add Workstation Entry. Use this command to add entries for workstation descriptions to a target subsystem. Use a value of *SIGNON to allow connections, and *ENTER to disable connections.

RMVWSE: Remove Workstation Entry. This command will remove workstation entries from a subsystem description.

Avoiding Duplicate Workstation IDs

StayLinked server build 142 and newer includes a setting to help avoid errors related to workstation names. This setting is on by default and can be disabled as an emulation property in the telnet host entry. The feature adds a character to the end of the requested name until an available name is found. This option is available to 5250 emulation hosts only and will not appear in the options for VT or 3270 hosts.

Possible Error Messages

During the use of StayLinked, your users may be presented with various error messages. These messages can provide information when the server OS is unable to provide the requested device name for your device. In each of these cases, IBM i has rejected the requested workstation name. These messages are only available for 5250 emulation.

AUTOCFG IS OFF

This message is returned when the server is reporting that it is unable to dynamically create the requested virtual device name. This may be caused if the IBM system value QAUTOVRT has reached a limit on the maximum number of virtual terminals, or if it cannot create or use the requested WSID for this session.

WSID VARIED OFF

The virtual device name already exists and is in a varied off status. This is typically caused by too many invalid sign-on attempts. StayLinked cannot automatically clear this status. See the WRKCFGSTS command in the next section.

WSID IS IN USE

The virtual device name has already been allocated to another interactive session.

WSID TIMEOUT

This is a general message that will be retuned for many different possible reasons. On servers older than build 138, the WSID timeout will be used for all of the reasons listed above.

The first step to resolving any of the messages above is to determine the virtual device name being requested for the session. This value appears in the device name column of the connections list, along with the error in the status column. Using the OS400 command:

WRKCFGSTS CFGTYPE(*DEV), you can find the device description to check the status.

Updated on August 1, 2024

Related Articles