Reviewed and revised, July 2020
CONSOLE=<idformat>{,drivername}
CONSOLE establishes an internal identifier for the instance, and optionally a terminal driver. Over the years is has devolved to become a nearly bottomless pit of complexity and confusion, but fortunately, in 99% of the cases, you can just set it to the following:
CONSOLE=NETUNIQUE,<tdvname> ; windows networks
The <tdvname> parameter should be either PCTDVG or PCTDV, with the only difference being that the PCTDVG version implements certain GUI improvements, such as the conversion of text message boxes to Windows dialog boxes.
Historically, certain national replacement character set variations of the terminal driver were supported, such as PCUK and PCFR. This function has been taken over by the CHARSETsp directive.
The NETUNIQUE option on the CONSOLE directive generates a unique identifier for each A-Shell session, made up of the computer name, followed by a colon and a numeric suffix indicating the instance number. The computer name may be set via the Windows Control Panel, using the Networks applet under W9x and the System applet in subsequent versions. Other options exist, but are for all practical purposes obsolete now.
You can see these identifiers with SYSTAT/C. You can also retrieve your own identifier with the subroutine GETUSN.
If you establish meaningful computer names, then these console identifiers are probably more useful than AMOS-style job names. But since job names are so embedded in ASB applications, A-Shell also generates them using the TSKAAA, TSKAAB, etc. format. If you don't like the dynamically generated job names, you can override them by using the j <jobnam> command line switch, or you can create a cross-reference association between console identifiers and job names using TRMDEF statements.
Because the console device name is used by the TRMDEF parameters, the CONSOLE statement must occur before any TRMDEF specifications.
History
2015 May, A-Shell 6.1.1408: Windows enhancement: A-Shell now detects duplicate machine names. Previously, this would have led to the nth instance on machine 2 overwriting the JOBTBL record for the nth instance on machine 1. In order for this to work, you must run the installer/updater to update each workstation, rather than manually installing the update by copying files. It is also important to update the six system commands, described in the next topic, although the installer will normally take care of this for you.
The installer/updater establishes a unique identifier for each machine and saves it in the HKLM section of the registry, to be used to determine whether an instance with the same machine name as an existing instance is actually the same machine or not. If so, then the new instance can safely overwrite the old one. But if not, an error message is displayed and the new session is not allowed to start.
The error message will indicate the machine name, the user name and jobname of the offending existing instance, and the unique identifiers (8 hex digits) for the two machines. You can use the SYSTAT/CU switch to display the unique identifiers for existing sessions, which may be helpful in tracking down the offending duplicate-named machine.
Note that duplicate named machines can cause all kinds of problems for Windows networking, but it is not always detected. This feature should help avoid the ensuing problems in both A-Shell and in the network in general.
Also note that the issue only affects P2P networks; ATE, Terminal Server, and Unix systems are not subject to the problem and are not affected by the update.
