The biggest problem here is likely to be the firewall at one end or the other. At the application server, ASHLPR will need to gain outbound access to whatever port the AshLPD server is listening on (default 31515). In most cases, this will not be a problem, as most firewalls are configured to stop incoming access but allow outgoing connections.
The AshLPD side is more likely to have a firewall (or just the Windows software firewall or some other "intrusion protection"). It is impossible to cover all the possibilities here, but the general requirement is simply that you open up inbound access to the port in question (e.g. 31515).
Another issue is the need to specify the IP address of the AshLPD server (i.e. the remote PC) to the application server. If the remote PC running AshLPD has a fixed IP, you can just enter it into the ASHLPR.INI file. But if it is dynamic, or if you have several remote PCs (such as home users) that want to use the same print queue name, then the solution is to add the TELNET:<port> option to the end of the COMMAND statement in the printer init file on the application server. For example, to create a printer called REMOTE that will forward print requests to the AshLPD server which is servicing port 31515 on the same remote workstation that is originating the telnet session, you would create the following ASHCFG:REMOTE.PQI file:
COMMAND = SBX:ASHLPR,0,TELNET:31515
Note that the ",0" is needed to hold the place of the print flag and to indicate that the file is not to printed on the application server (it is only to be forwarded to the AshLPD server). If you wanted to print the file ALSO on the application server, you would change the 0 to a 1 and add a DEVICE statement to indicate the name of the printer device.
