Hmmm...
First, let's clear up the ATE version. I'm not sure where that 4.4(181) is coming from, but the ATE version should be very similar or the same as the A-Shell version. Typically you can get it from the Help > About ATE dialog (top line) from within an ATE connection. Or you can use the SYSTAT/ATE option on the server to see the versions of the connected ATE clients. I kind of doubt that the version is relevant to the problem, although there was an issue with WSD printers not working prior to 6.5.1700.1, so you want to be sure you have at least that version. (But again, especially when you are using ATE to an A-Shell Windows server, there's no good reason for the ATE versions to not match the server, or at least be very close.)
When comparing the A-Shell/Windows P2P connection to the ATE connection, I'm assuming that we are talking about the same client and same 'server'. (In the P2P case, it's acting as a file server; the programs and printing would still be running on the client machine. Whereas in the ATE case, everything is running on the server; the client is usually just acting like a smart terminal, unless you are redirecting printing or other operations explicitly from the server to the client.)
The command
PRINT SHPINV = SHPINV.PQI, in the P2P case, executes on the client machine, which presumably is able to see and resolve \\MDCS01\SHIPINV (and has the proper driver for it). In the ATE case, it all happens on the server (and the server needs all of that).
So I guess my next question would be whether if you are sitting at the server's console (rather than connecting via ATE), does that same PRINT command work? (That takes ATE out of the picture.) If not, then if you go into something like Notepad and print, do you see that printer in the list of available printers? And does it print from Notepad? If you can't physically get to the server to try this, maybe you can use Remote Desktop to do it.
My guess is that the server is missing the driver, or has some other Windows or network-level problem with talking to those printers. That might be easy to solve just by running the Add a Printer utility to add them to the server.
Alternatively, if you are connected with ATE, you can redirect printing to go through ATE (which I believe will work, because it's essentially the same environment as the P2P client). To do that, you would have to create PQI files on the server which contained:
DEVICE = AUXLOC:. In the ATE Configuration (Settings > Connection Properties) you can select the printer you want to redirect the AUXLOC: virtual printer device to, or use the Prompt option to have it always prompt you. If you want the application to be able to select the printer without the user's intervention, you have to create PQI files on each workstation (in ATE's dsk0\001007 directory), and then append the ATE PQI name to the
DEVICE = AUXLOC: in the server's PQI file, e.g.
DEVICE = AUXLOC:SHPINV. In that case, the
PRINT SHPINV=<file> command on the server would redirect to the ATE client, telling it to use its own SHPINV.PQI file, which would contain
DEVICE = \\MDCS01\SHPINV. (Note that the PQI names on the server and ATE clients don't have to match. But since the contents will differ, you need to keep them separate. Some people find it more natural to use the same names, while others find it easier to use different names to they don't get mixed up.)
