Won't network print to home computer

[Bill Franke]

Hi, I've got 3 computers networked together using ME. I have a serial printer (a Brady PC-LINK) on Computer 1 and am able to print to it from computer 2 and 3 using this format:
STX$=CHR$(2)
Brady=FREEFILE
OPEN "\\Tom\TLS" FOR OUTPUT AS #Brady
PRINT #Brady, STX$;"Q"; 'clear image memory

etc.
"\\Tom" in this case is computer 1.
The problem I'm having is that I can't print to the printer from computer 1. Nothing happens. I know I can make it work by directly accessing COM 2, but I often upgrade this program for all three computers and I want to be able to do that in one version, not two.
Hope this makes sense.
Thanks

------------------

[Gary Stout]

Bill,
I have never used a serial printer myself, but have ran into situations where I needed certain options for one computer that I didn't need or want on another..... for example an application running on the main computer or server, I might want an option to backup data, but I don't want that option on a workstation. so I disable that feature on the workstation end.

What I have done to accomidate this is create a small text file that I call OPTIONS.DAT and I place it in the path, usually in \windows\system or \windows\system32. In my case, the OPTIONS.DAT file contains the name of the computer...ie SERVER

Then within my code, I open OPTIONS.DAT and read its contents and store its value in a global variable, then close the file.

Then I can do something like this....

If UCASE$(Option$) = "SERVER" then
blah blah blah
elseif UCASE$(Option$) = "CLIENT" then
do this instead
end if

This way I only have to maintain 1 program to be used on multiple computers. It took me a while to come up with this plan... I use to maintain 3 copies of the same program with slight changes to accomidate a certain computer configuration or printer configuration....what a PAIN in the a$$. This approach work out real well. This worked out especially good in cases where a local printer on a server was LPT1 but a workstation that already had a local printer needed to print to the servers printer and mapped as LPT2. With the above IF-THEN-ELSE, this was pretty easy to work around. It is really a simple solution to what I think you are describing as your problem.

HTH,




------------------
Gary Stout
[email protected]

[Bill Franke]

Thanks for replying Gary, If I understand you correctly, you are basically (no pun intended) making a printer driver for DOS. I think it will work, but I was hoping for something more simple. It doesn’t matter that it is a serial printer by the way, I can’t get the server printer to print to an LPT port either, but all the other net computers will print to the server’s printer just fine. It seems like there ought to be an easy way around this. If no one has any other suggestions, then I’ll try your plan.
Thanks

By the way, I should have said "server" rather than "computer 1." The server won't print to it's own port using network jargon: OPEN "\\Tom\TLS" FOR OUTPUT AS #Brady.

Bill Franke

------------------

[Gary Stout]

Bill,
My method is not really a driver of any kind. It basically just directs the program in one of two directions depending on which machine it is on (as read from OPTIONS.DAT) or in your case if you can make it print with one command to the network printers and another command to the local printer, then by reading the external OPTIONS.DAT file and using the IF-THEN-ELSE routine, you can direct the program the route that it needs to go to accomplish the correct commands for each printer.

Maybe this will clarify a litle....



------------------
Gary Stout
[email protected]

[Lance Edmonds]

If you can redirect LPT1 to COM2 on that PC (ie, via the DOS MODE LPT1=COM2 command), you should be able to use:

IF <running on another pc> THEN 
  pt$ = "\\server\share"
ELSE
  pt$ = "LPT1"  ' Use BIOS I/O by using "LPT1" rather than "LPT1:"
END IF
OPEN pt$ FOR OUTPUT AS #1  
PRINT #1, "...da da da"
CLOSE #1

...and it "should" be redirected through COM2 if MODE is doing its thing. That way all you need to do is alter the port string from a configuration, such as described by Gary above.

The alternative would be to provide two print routines - one that uses OPEN "\\server\share", and the other that uses serial comms code instead (see the SERPRINT.FAQ file installed with PB/DOS for more info). Again, your program would need to be able to select between the two routines.

Depending on the OS you are running, you might be able to use the UNC name method by bouncing the print job to another PC, when then redirects the print data back to the first machine again. I've not done that for a _long_ time, but I did use that method to solve a very similar problem on an old Win3.11 network. IIRC, there was a description of how to do it in one of the .TXT files that was included in the Win3.1x installation in the C:\WINDOWS folder.

Yet another approach would be to consider using a parallel-to-serial converter, and simply connecting the printer to the local LPT port (much as I described initially above).


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Bill Franke]

Thanks you guys, I'll try these things, but it still seems to me that a server ought to be able to "see" it's own port some way.

Bill Franke

------------------

[Lance Edmonds]

AFAIK, that is only possible under Windows NT/2000/XP due to the more limited UNC support the various other versions of Windows offer.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Bill Franke]

Going back to an old post:

I got this thing to work using the following code:

Brady=FREEFILE
Computer_ID=FREEFILE
OPEN "C:\EDS\EDS.ID" FOR INPUT AS #Computer_ID
LINE INPUT #Computer_ID, ID$
CLOSE #Computer_ID
IF ID$="TOM" THEN 'make this work on the host computer
OPEN "com2:9600,n,8,1,DS0,CS0,CD0,RS,ME" FOR OUTPUT AS #Brady
ELSE
OPEN "\\Tom\TLS" FOR OUTPUT AS #Brady
END IF

PRINT #Brady, STX$;"n"; 'put printer in inches mode
PRINT #Brady, "190000800000003"+"EDS"+FS$(1) 'record structure
PRINT #Brady, "E" 'print
PRINT #Brady, STX$;"c"; 'form stop position

CLOSE #Brady

It works great! Just one problem though, if I print using the host computer, I can’t print from any network computer. Or if I print first from any network computer, I can’t print from the host computer. I get the following message on the host computer:

“There was an error writing to COM2 for the printer (TLS PC LINK). Cannot access the port. It may be in use by another program. Quit other programs and try printing again.”

We have to shut off the (host) application and start it up again to be able to print from the other computer. I don’t understand this since I CLOSE the file after each time I print.

Any help would be appreciated.

------------------

[Lance Edmonds]

This problem used to be solved in Win 3.x & Win9x by adding the following line to SYSTEM.INI in the [386enh] section, and rebooting the PC:

COM[i]n[/i]AutoAssign=1

..where the n is the serial port number.

This tells Windows that it can reassign the port to another application 1 second after it has been closed, rather than leaving it assigned until the program is closed.

This method should still work in later versions of Windows, since Windows will automatically import SYSTEM.INI settings into [various parts of] the registry. Don't be surprised if the SYSTEM.INI entry is removed after the reboot though... thats just Windows doing its job.

Please let us know if this helps!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Luther]

Let's have a little Halloween word play fun, OK?

You've already stated this is a network operation! OK, if this is
a frequently and repetitively used data set you need printed you can
always write a custom print 'server' executable for it.

You write the data to a specific file or collage of library files or
a master file with a list of increasing but known pointer positions.
The file or files are on the box with the desired printer on it that
you know works.

Then you write a dedicated little executable for servicing this set
of data. You load it with the needed data and let it run in a separate
session on that box. In your routine(s) you provide semaphore action
so that this print routime will not go off printing when another job is
printing, or .. if the operating system has decent spooling; use it.

If a little file is present; do or do not do this or that. If it is not
present; do or do not do this or that. When finished remove or modify
the little file to offer whatever sign on the tree is needed in the
woods for the next little venturer to see.

Then your custom little 'executable' just camps by the fireside, where
it periodically takes a look at who all else is around the fire! Not
too often so as to make a pest of itself, you know, grin. When an
appropriately marked guest shows up at the gathering, there is this
quiet little agreement reached. The required little printing job is
done, by agreement, (But who knows who knows the agreement, gring?) off
in the woods, by your little print ghoul! Your little print ghoul goes
back to sitting by the fireside and nobody is the wiser, chuckle.

When this little background task is finished, you either delete the
visitor from the gathering, or you stack the corpus in the write(sic)
pile, either end to end, or pointed to helter-skelter in the write way,
huge smiley.

You don't have to limit this scenario to printed data. You can slice
and dice all kinds of communicative bits of thingees this way and direct
them to not only a printer, but box 'em with other bits of thingees ..
or .. communicate them with other channels to other headless horsemen
round the same or other similar campfires on this or even other gobbl'em
up node machines. Forward march! Even backwards if you need to.

In some cases I have half a dozen of these little disk file aware little
PowerBASIC rogues operating in background sessions, even as DOS-VDM
sessions with no screen activity at all on a box. They do everything
from being an alarm clock and playing music in the morning, (as I'm
writing this) to printing billing invoices for automated data forwarding
on the same box, dumped into to directories, even by old FIdoNet BBS
software utilities across TELNET and the internet from afar! Cheeze,
what's an old Fido dog still doing around at a Halloween party?

Why, you can even make 'im bark when a new guest arrives this way
at the campfire site ...

Modern networking, the file systems it offers, plus semaphore and flag
control file techniques can do WONDERS for your PowerBASIC PB 3.5 for
DOS happiness. And if your little server application is backwoods
smart, it won't even fire up if the trails through the woods aren't
there because you aren't connected to the network! Simple trace file
not found error trapping will keep you out of the woods when there is
no woods into which to venture or it is full of teddy-bears having
another picnic at which you don't want to be caught!



Of course, the operating system you are using does have a bit to do
with all this. It must be able to pre-emptively run all these wonderous
little headless horsemen at the same time while orchestrating their
little tasks around the campfire. Wouldn't want to bring the party to
a premature halt, now, would we? Works best, so I've found, on OS/2
since it's pre-emptively able to even thread-level manage even a dozen
or so deals like this at one time across even multiple CPU's just fine,
even in good old DOS!

But you can get away, sometimes, with one of these little servants in
WIN-95/98 or so, if you do a good job of time slice releasing with
certain parts of your code. Maybe more will work at the same time in
later versions of WIN-NT and so on, I don't know. Haven't attended such
a party yet, smile. Might try that some day in the future as you can
run any version of WIN as a guest under OS/2 ... GDRFC, but not yet.

For the few who are OS/2 oriented here, smile wider. Warpstock 2003
in San Francisco last week was highly informative as to the past and
future. Even your old 1970-80's style 8250 UART assembler library code
merged in with PB 3.5 apparently will still work just fine, fully
supported past, present and into the all this future with full driver
and defect support for an indefinite period of time past December 31,
2006. Per published data now from officialese slides and talks, a
major Total Content Option (TCO) client of the claimed $48,000,000,000
contributed total of the IBM owner's profitable position for that has
been guaranteed full contract support now out to the year 2019.

Heck, 22,000,000 fully support IBM DOS installations, world wide, can't
be all that wrong, no? The number was published! Yes, still supported,
access to hardware and all.

Wonderful news for PB 3.5 and perhaps future fans of it, like you, and
what the new version of PB 3.5 will become. Especially like those
who huddle round all those fires in the sand out at Ocean Beach. Watch
the fog roll in, spend Halloween night protected from it. Current
costs for a year of support for OS/2 are less than even the $76 ticket
you can get if yor car is still in the parking lot on All Hallow's 'Een
when they come writing tickets, if you haven't got it moved to a better
operating platform by the time they get to it out there at the beach!

Bill, all it takes is to know where to park the car and who to let go
riding in it while you're all cozy and warm around the fireside networking
with all your friends! You just get up at the right moment, light up
the poi, twirl them all around and watch the sparks fly in all directions,
then go back and put a little more juice in the pot and wait again!

"Awesome ... What a dude!"

Happy Halloween.




------------------
Mike Luther
[email protected]



[This message has been edited by Mike Luther (edited October 29, 2003).]

[Bill Franke]

Lance your fix worked great! Thanks alot. Luther, I have a hard enough time with analogies when I find them in theology. I only remotely understood yours as applied to networking. But thanks for trying. Unlike most of you creative programmers out there, I’m very pragmatic when it comes to my computer and right now it works, so I’m leaving it alone.

BF

------------------