Generally this indicates that two sessions are being assigned the same session identifier, causing the second one to overwrite the first one's jobtbl record. You can get additional confirmation of this and possibly useful background information by looking at the ashlog.log file, but in this case it seems that you've already identified the cause.
Each session attempts to establish an identifier that is unique, but which also allows detection of sessions originating from the same workstation (so that they can share a license).
Typically, that scheme consists of using the workstation's computer identifier/name and then scanning the workstation memory to identify the number of instances of ashw32.exe running, resulting in an identifier like JACKT450:02 (for the 2nd session on the machine JACKT450). You can see these identifiers using the SYSTAT/C switch.
Unfortunately, that system breaks down in sandboxed environments like you find on servers where it is impossible for one login to detect running instances another login session in the same physical machine. So over the years A-Shell has developed a set of additional techniques to try to work around the problem. For example, in many networked cases, it can query the network to obtain information about the client machine. But there are inevitably situations where none of the techniques is sufficient.
In such cases, you may be forced to use the A-Shell equivalent of the "nuclear option", by adding OPTIONS=NTTS to the miame.ini. This changes the unique identifier scheme so that it ensures uniqueness, but at the cost of losing the ability to detect which sessions are coming from the same workstation. So every session will use up a license.
If that's too drastic of a solution in a case where most of your users have multiple sessions but only a few have the unique identifier problem, then, as of 6.4.1558.2, you can use the -ntts switch on the ashw32.exe command line rather than the global OPTION in the miame.ini. In that case, it only affects that user.
