<div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not talking about windows print screen, I'm talking about Hardcopy <br>
in filePro.<br></blockquote></div><div dir="auto"><br></div><div dir="auto">I don't know why hardcopy would be any different than any other printing from fp.</div><div dir="auto"><br></div><div dir="auto">You also said something about a unix spool not passthrough print. If the default printer in pfconfig is a unix lp command, then I don't see how the server knows or cares what os the desktop is running.</div><div dir="auto"><br></div><div dir="auto">I think the setup is not described in enough detail.</div><div dir="auto"><br></div><div dir="auto">Log in from one of the win7 machines where printing works, and from the win10 machine where printing doesn't work.</div><div dir="auto"><br></div><div dir="auto">Run "set |sort |less" on each. (if you don't have less installed, then capture and view any other way. pg, more, vi/view etc...)</div><div dir="auto"><br></div><div dir="auto">Anything different that could affect printing? There are env variables that affect both the spooler and fp's notions of default printer destination, or could inadvertantly affect printing in some indirect way like, totally contrived example:</div><div dir="auto"><br></div><div dir="auto">The env is set up to do passthrough after all, PFPT=on (or true or whatever), and your fp/termcap has a scoansi entry that includes PN & PS, abd only the scoansi entry has it, and TERM or PFTERM is set to scoansi on most desks, but it's set to something else like xterm on the new desk.</div><div dir="auto"><br></div><div dir="auto">It's not literally exactly that, because the break key would not be Del, and you couldn't miss that. It's an example only.</div><div dir="auto"><br></div><div dir="auto">Are you logging in as the same user on both working and non-working desks? There is a gotcha with sco osr5 printing where a newly added user might not have permission to use the printing system at all until you manually add them in scoadm (or figure out how the default got changed and change it back, I forget the details myself)</div><div dir="auto"><br></div><div dir="auto">It could be anything, until you describe the setup more, to remove some of the infinite possibilities.</div><div dir="auto"><br></div><div dir="auto">Follow the trail from fp yo the printer. What is fp going to try to do when you say Y to hardcopy? You have to look at all fp env vars to determine that. For instance, the PFCONFIG var, if it exists, says where to load the fp config file from, which may override the file pointed to by fppath vars. So, it's possible for two different desks to load two entirely different config fles, which may contain 2 entirely different sets of pfprinter and other variables.</div><div dir="auto"><br></div><div dir="auto">Now you hopefully know what fp should try to do, next depends on what that was. Was pfprinter the same fp printer name like printer1 on both? Was the definition of printer1 the same on both? was PFPT either on or off or absent the same on both? Was the defintion of printer1 a normal valid lp command line? Can you successfully use that same lp command, as that same user, from a shell prompt, on both?</div><div dir="auto"> </div><div dir="auto">-- </div><div dir="auto">bkw</div></div>