#Problems with CMD
13 messages in this thread
You're trying to capture HP files, or PostScript? I assume HP files. Are
you confident the printer driver you've chosen is completely comaptible
with the HP on your network? There are several levels of HP compatibility.
Can you hex dump the file on both ends, and file compare in some way?
Yes, I set preferences for HP_LaserJet and used the "Dot Matrix" output
mode from ProPage. The HP that I was using is an HP LJ II, which is PCL
Level 4, I believe. (The HP III is Level 5.) I took a look at the file
size on the Amiga and then used Zmodem to copy from Amiga to (networked)
PC. I did this over a 9600 baud direct cable link-up with CrossTalk Mk.4
running on the PC.
Nice thing about the PCSA network. While one PC was loading the file into
my M:\tmp directory, I watched its progress on another PC (shared file
space) and, when it was finished, I asked the second PC to copy it to the
output device.
The file sizes were, by the way, identical.
I still think it's in CMD.
(But I would love to find out that I'm wrong, if it will get my files
printed!)
Chris -)—–
I've used CMD over sneakernet without problems. I turn on CMD, print
(using the Preferences HP driver), then copy the file to floppy BEING VERY
CAREFUL to do a _binary_ and not a _text_ copy, then take it to my PC for
copying to LPT1. (This is at home.) Works okay.
I bet that the CMD file is getting a bit cut off. Are you sure you're
using 8-bit protocol on the ZModem transfer? As a diagnostic, can you 1)
turn on CMD (2) type at the CLI "copy s:startup-sequence to prt:" (3)
save the resulting CMD and looking at it with a hex dump (should be pretty
ordinary). (4) doing the ZModem etc? If _that_ works okay, then there's
something strange with the WP output. If _that_ fails (but the hex dump
looked okay on the Amiga side) look at the hex dump on the PC side. A
gremlin turning 8 bit to 7 bit wouldn't change the file size.
Sounds like a reasonable test. I'll give it a try.
Does Zmodem HAVE a 7-bit mode??!
ZModem doesn't have a 7-bit mode, but the connection between you use to
transmit over might be 7-bit without ZModem detecting it. Note this is a
logical possibility only rather than a critique of perfectly-implemented
ZModem.
Ok, I think I got your point. I'll have to check. I was using AZCOMM on
the Amiga and CrossTalk Mk.4 on the PC, and a regular serial cable to
connect the two.
Chris -)—–
Ok, everyone… Here's the scoop.
I used CMD to capture the HP PCL output from ProDraw, then copied CMD_file
to a PC via Zmodem. I then copied that file to a floppy disk and moved to
another PC that had an HP printer attached. Finally, I copied the file to
LPT1:–which didn't work–'till I tried the MS-DOS /b option: bingo!
So, I determined that the CMD program was working, and that my problem must
be either in the transfer of the file from PC to VAX, or in the VAX queue
(as many of you suggested).
Well, it turns out to be a number of small things… First, the VMS file
structures are a bit goofy (from a micro point of view). If I used my PC
network to put the PC file into a shared area, and then asked the VAX to
print it, the file, from the VAX side just isn't correct. I have to do a
special copy (NFT> copy /image/noconvert/variable CMD_FILE.
DUA2:[CHRIS.TMP]CMD_FILE.LIS) to get the VAX to handle the file correctly.
I also have to make sure that I use the proper FORM when printing the file
on the VAX queue. Apparently, WordPerfect assumes *nothing* about the
state of the printer when it creates a file, so it has no problem printing
its files. The ProDraw output, however, doesn't seem to do well if the
printer was set to landscape prior to receiving the file.
Anyway, I have it working now, though I am still confused as to why
WordPerfect can produce an HP file that prints normally and the
CMD-generated files need so much assistance.
I'll continue this saga whenever I get more information…
Chris -)—–
Perhaps the preferences printer driver sends some initialization codes down
the line before it sends graphic dumps, or maybe some spooler is expecting
to initialize the printer itself. You might try starting CMD as soon as
possible, instead of just beforeyou start Pro Draw. Or, can you save the
graphic as EPS, and paste it into WP on the PC, and print that way? 🙂
I don't do an INIT PRINTER, and I generally start CMD before I even load
ProDraw. No, I think that Preferences makes some assumptions about the
setup of the printer that WP 5.0 doesn't make. I'll try doing an INIT
PRINTER to CMD and tacking that file to the top of the ProPage produced
file. Maybe that will make a difference…
Chris -)—–
Chris,
The printer driver on the Amiga only initializes the printer on
it's first output…not every time. You can get around this by going into
preferences and selecting USE on printer preferences (even though you
didn't change anything) or simply by the InitPrinter command.
The preferences method works the next time the printer is used, the
InitPrinter command works right then.
Don
Right, I think I'll try the USE method that you mentioned.
Chris -)—–
Then how did you send it from the computer to the LaserJet? Are you sure
that something isn't filtering it along the way? Maybe it needs a CTRL/Z at
the end of the file. 🙂
From the PC to the LaserJet… Well, the PC's U: drive is actually the
VAXes DUA2:[PCSA.SCRATCH_ZEUS]. So I just copy the file to U:/CHEDPL01.PRT
and a program on the VAX does a PRINT/QUEUE=CHEDPL01
DUA2:[PCSA.SCRATCH_ZEUS]CHEDPL01.PRT/DELETE for me. The queue is set for
/PASSALL, and we use this method to do all of our printing from WordPerfect
5.0 and Harvard Graphics, so it has been very well tested.
Chris -)—–