Programmer 7500/MAX_PROGRAMMERS.iso/PROGRAMS/UTILS/NOVELL/IPRINT.ZIP/IPRINT.DOC

Text File | 1990-03-19 | 8.8 KB | 186 lines

IPRINT is our own subset of NPRINT for 2.1x Netware. We have tested it (and
are using it) with ANW 2.15 rev C. It will not work on any pre-2.1x Netware,
and this probably includes ELS I.

The zip 1.02 file contains IPRINT.EXE, two .C files and one .H file.
The program was written in Turbo C 2.0.
Novell PSD "Netware C Interface" library is needed to recompiled and relink.

There is no distribution restriction or copyright or whatever applied to this
software.
This is 100% public domain software, you can use it and/or circulate in
any form you want.
On the other hand, we will do our best to correct reported problems, but
as they all say, "the software is provided "as is" without warranty of any
kind, etc, etc..."
After all, why do you think we provided the source code for?...



IPRINT was originally developed because there are some annoying bugs
in Netware printing utilities that were preventing us from using PS-PRINT
the way we intended to, i.e. using FORM management to dynamically select a
target printer out of several ran off the same queue.


The bugs are:

- The F=<form name> option does not work. It should, since form is documented
  as taking either F=<form number> or F=<form name> since 2.12 documentation
  and may be before. But the later form does not work (at least in 2.15).
  Since people tend to remember mnemonics mucho better than numbers, and
  since mnemonic provide a level of indirection that allow us to reshuffle
  the technical characteristics of the FORMS we use transparently to the
  user, we considered this as a problem.

- When the F=<form number> option is used, NPRINT fills the <paper width>
  and <paper length> fields of the Client Record Area in the Queue Block
  with erroneous data. The error is that the paper size should be given as
  two words in hi-lo bytes format, while it's actually given by NPRINT
  in lo-hi bytes format. This only occurs when F=<number> is used.
  The job profile JOB= option could not be used, since it does not retain
  the form name of the profile (although PRINTCON asks for it when the
  profile is defined <sigh>).
  The result of the hi-lo inversion is that a form that is defined with a
  132 columns width (ain't that regular?) is declared as 33792 columns wide
  (actually -31744 columns!) in the queue block. While Novell printer
  management does not seem to care, third party products such as PS-PRINT do,
  and behave strangely when given such paper specs. PS-PRINT 3.0 prints the
  right number of *totally blank* lines as the print job. Save a tree!

- Finally, we found out that PCONSOLE was putting the paper width information
  in the right order, but at the wrong place: width was instead of length
  and length instead of width, so regular 11 inches paper appeared to be 66
  columns wide and 132 lines long, which is usually untrue. This resulted
  in PS-PRINT truncating lines after column 66. Owell, at least, each number
  was hi-lo, this time, so may be I'm asking too much.


Since we needed to be able to submit print files AND to do it from the
command line, and since we could not get any official fix, we decided to
write our own "NPRINT", that we called IPRINT.
Typing IPRINT with no parm displays the following Help screen:


IPRINT - Net Print file   V 1.22  Mar 01 1990  C.m. I.R.C.I.

Usage       : IPRINT file_spec [options..]
              File_spec may be generic.

Options are :            Default

      File extension      [.LST]
      /F=Form name/number [0]
      /Q=Queue name       [Q_TEXT]
      /C=number of Copies [1]
      /T=Tab size         [8]
      /NT No tabs
      /NC Inhibit internal server copy
      /S  Silent mode. Suppress copy progression display

Differences from NPRINT are as follow:

- As can be seen above, not all NPRINT options are supported.

- IPRINT accepts both F=<form name> and F=<form number>. If no form
  parm is given, IPRINT defaults to F=0 and displays the corresponding
  form name to the user. If an illegal form name / form number is given,
  IPRINT reminds the user about legal form names. IPRINT uses the data
  in NET$PRN.DAT as we found them to be organized in version 2.15 of
  ANW (this is not documented in any official Novell documentation we
  know of). We documented the format of NET$PRN.DAT in a separate
  file (see NETPRN.ZIP in LIB 12).

- Default queue name is Q_TEXT. This is the PS-PRINT suggested queue name.
  This can be changed in the source or patched in the .EXE to some
  regular Novell queue name.
  The queue name field in the .EXE is 47 bytes long, so the queue name
  may be patch extended, as long as it's ended by a binary zero.

- Default file extension is .LST. This can be changed in either source
  or .EXE.

- The "job description" field in the banner is filled with the size and
  date/time stamp from the original file. We found that a good use for
  this usually unused field.

- IPRINT displays the number of K's it has transfered so far to the queue.
  If IPRINT output needs to be redirected, this can be disabled by using
  the /S (Silent) option.


IPRINT returns various error levels (1-16) for serious error conditions. The
error levels meaning are documented in the source. Okay, documentation
is in French (yes, there's life on the other side of the pond!), but the
mnemonic names used for the constants are kinda English. Look ahead of the
main function. If you need help, Eplex me, I do speak French. Fluently...


Philippe Auphelle [74000,3663]





Some tech matters about IPRINT:
================================


IPRINT uses an undocumented DOS function to normalize file path. The
function works from DOS 3.0 to DOS 4.01, as far as we know. Its definition is
isolated in a small separate .C module, in case one wants to change it to
some plain vanilla documented algorithm, but be warned that it ain't so
easy: The function does a helluva work from any partial path, including
finding the server name and presenting the normalized pathname (MSNET way)
as //SERVER/full path..., including when the requested file does not exist
(but as long as the partial drive/path spec given exists and is syntaxically
valid).

The default Q name we use is Q_TEXT. Can be patched to anything else right
into the .EXE file, we oversized the name string field just for that
purpose (you're allow 47 characters plus ending binary zero).

IPRINT attempts FileServerFileCopy to the Qfile. If this fails, brute force
iterative copy is done. Brute force iterative copy can be forced from
command line (/NC).
The way we check for possible FileServerFileCopy is rather rough: We attempt
it, and if it fails, we go to brute force. "Fails" is tricky to determine,
since if local server copy it's not possible, Netware still returns a 0
retcode (smells bug rather than feature). Try doing a FileServerFileCopy on
a file off a local drive to the Qfile (or any other server file, I guess):
You get a 0 retcode and a phony (kinda random) "length copied" in CX,DX. So
Netware tells you the copy went okay although it couldn't do anything.
I reported this to Novell, and I've been told that it will be taken care of
in a future release.

We minimize the problem by only attempting FileServerFileCopy if the source
file is on a network drive. This is by looking at the normalized form of the
source file path.
Even though, we still could have the two files on two distinct servers, and
we don't know how Netware would behave then (would it still ignore the
error?).
The way we try to reduce the probability of the problem being unnoticed is
by checking the returned "copied" length against the source file length. If
by bad luck, one would IPRINT a file and the returned CX:DX would by
coincidence be the exact length of the original file, IPRINT would not
detect it and merrily go its way (well, not worse than a lost hardcopy
listing, anyway! Will be blamed on the printer process <grin>!
If this would ever happen, one could use the /NC option to get a brute force
copy. I didn't spend time to find out if there was a clean, documented way
to get the name of the server a file is on from its handle. Alternatively,
finding the name of the server my queue is on would be okay. I could then
match the server name against that of the server returned ahead of the file
path by the Normalize Path DOS function.

The options that NPRINT has and IPRINT hasn't are in no way hard to implement,
we just didn't do it because we didn't have an immediate need for it. Feel
free to throw in the missing pieces (such as print flags setting, delete
print file option, etc...). But if you do so, please post the modified code
as well as its source.

If you discover problems with this program, you may report them to
me: Philippe Auphelle, [74000,3663].
I usually connect daily, but just in case I don't for a while, use
Eplex. We'll do our best to improve the situation.