This list is provided to help you with some common questions asked by
users of PDFing.
If you cannot find the answer you seek here, please e-mail:
support@pdfing.com
providing as much
supporting evidence
as you can.
When TCP/IP is installed with Windows 2000 and 2003 the TCP/IP
Print Server
service is automatically started. This service also "listens" on port: 515
and thus will not allow PDFing to run! Unless you are using this
service
to print files sent from UNIX machines, you can safely stop this
service and
change the start-up options to manual. Use the Services
applet in the Control Panel to stop this
service and then
change its start up options to "manual".
The OS400 remote-writer writer will wait until PDFing (or any other
remote printer) starts to "listen" on TCP/IP port: 515. If PDFing is
started, you should check that
the TCP/IP address assigned to the output-queue being written is the
same as the
address assigned to the PC on which PDFing is running.
You can check to see whether OS400 can "ping" this PC.
If you can ping the PC from OS400 and PDFing is running, a
"firewall"
may be blocking incoming packets on port:
515.
If you can ping the PC from OS400 and PDFing is running, a
"firewall"
may be blocking incoming packets on port:
515.
PDFing "listens" on port: 515 for requests by
OS400 to send spooled-files, but "fire-walls" between OS400
and the PC running PDFing may block port: 515.
You must add an exception to these fire-walls for programs: PDFing.exe
and PDFingMailer.exe that allows these programs to open port: 515.
You can check the network status, using
NETSTAT *CNN
on
OS400 and
netstat -n
on the PC.
If all else fails, it is "just" possible that OS400 is not functioning
correctly. You can test OS400 by using another implementation of a
Windows
LPD server. I can heartily recommend the
MochaSoft
W32 LPD program.
If you can get W32 LPD running well on your PC, then PDFing will run
just as well.
home
/
support
/
top
What
does OS400 message "Remote host
system rejected the open attempt" mean?
You may see this message after executing the OS400 command
SNDTCPSPLF.
Generally this means that port:
515 on
the PC to which the spooled-file
is directed is not open. This may be because either PDFing has not been
started on the PC,
or, a
"firewall"
is blocking incoming packets on this port.
Please be aware that the "second-level" text of this error message
refers to
TELNET support, however this is misleading
and should really be
understood as referring to LPD support.
OS400 is not sending all the spooled-file data. This
sometimes occurs because
the output-queue is configured incorrectly. End the writer and check
the resulting
job-log for that writer to see which errors have occured.
Sometimes PDFing is connected to by a host that is not using the
LPR/LPD protocol.
You can open the "control-file" for the problem job (using notepad)
and look for the connecting host-name or IP address. If it is not a
connection
from your AS400/iSeries system, you should find out why this particular host is trying to connect
to PDFing
and then prevent it trying to connect in future.
When you start an OS400 "remote-writer" (STRRMTWTR) this starts a
writer job in the QSPL sub-system for user: QSPLJOB with the same name
as the output-queue. If you can locate this job, then you can view the
job-log. If you end the remote-writer ENDWTR OPTION(*IMMED) then
the job-log will be written to a spooled-file and can be viewed by
executing: WRKSPLF SELECT(QSPLJOB). The *ESCAPE and *DIAG messages in
the job log will give us a clue about the cause of these problems.
For instance, *ESCAPE message
CPF6DF9 is sent when our
transform-exit program
cannot convert a "complex" *AFPDS spooled-file because the
specified output buffer canot contain all the data converted to
PCL. An "advanced" transform-exit program is also available that
has no buffer-size limitations.
Large AFPDS spooled-files may take a very long time to be "transformed"
by the
OS400. You may configure the "LPD Job Time Out" parameter to wait for
any number
of minutes. The default is 10 minutes, you should experiment with
longer intervals.
You may also need to increase the storage allocated to the
QSPL sub-system on OS400
home
/
support
/
top
PDFing
receives spooled-files, but why
does the spooled-file stay at status: RDY
for so long?
LPR requires that you configure the local host and domain names for
your AS400
system as it sends this information to PDFing with each spooled-file.
If these are not configured correctly, OS400 will perform a
"reverse DNS look up" for this information, which will cause a
considerable delay when sending each spooled-file.
Use OS400 command CFGTCP
option 12 to
to configure the host and domain names. Use option 10 to add the host
and the fully qualified network names of
your AS400 system
to the host table.
You may need to change the translation-table that PDFing uses to
convert EBCDIC to ASCII. By default PDFing will use the translation
table for
code-page
37 but you can change the table
used to translate all
or any particular spooled-file. Please see our
national-language
web-page
for more details.
If only certain characters are represented incorrectly, you may need to
change the
translation-table that OS400
host-print
transform
uses to convert EBCDIC to ASCII. Please see our
workstation-customisation
web-page for more details.
If the font used for the text that is shown incorrectly is a
"soft-font" which is
downloaded with the spooled-file, this font may be encoded in EBCDIC
rather than ASCII.
If so, then the text will look rather odd as blanks will be replaced by
@ signs, etc. To make the text readable, go to the
[Convert] page
of the configuration or markup program and enter the text:
-RA
in the control labelled "PCL Parameters". This parameter value causes
the
text in these fonts to be rendered as readable bit-maps. It is best to
apply this
"PCL Parameter" value as selectively as possible, as it has the effect
of increasing the
PDF file-size and the text rendered in these (downloaded) fonts can no
longer be searched.
This problem may occur when the page-size is not quite big enough to
accomodate
the text. The IBM-supplied
host-print
transform
will do its best to make the text fit, but this sometimes results in
lines and
columns of text being omitted. The solution is to provide your own
work-station customisation object. See our
work-station
customisation
web-page for details.
Please note, that all OS400 PTFs must be up to date, particularly those
for printing systems. Many of the problems that our customers have
reported
were resolved by the application of the latest PTFs and the use of
MFRTYPMDL(*HP4).
This problem may occur when the spooled-file has been sent using our
utility
command SNDPDFSPLF. If the
printer-device-file does not specify
the library containing the overlay explicitly and the overlay object is
not in the
library-list of the job executing SNDPDFSPLF, then the spooled-file
sent to PDFing does not
contain the overlay.
It seems that if you cannot ensure that the library containing the
overlay is in the
library-list of the job executing SNDPDFSPLF, then you must
specify
the library name of the overlay when creating or changing the
printer-device file.
If the document was converted from an *AFPDS spooled-file,
you should check that you have configured the OS400 output-queue to
perform
host print transform
correctly. Please see
Configuring output-queues
for *AFPDS spooled-files.
Please note, that all OS400 PTFs must be up to date, particularly those
for printing systems. Many of the problems that our customers have
reported
were resolved by the application of the latest PTFs and the use of
MFRTYPMDL(*HP4).
This error may occur when converting
very large
*AFPDS
spooled files. In this case you will need to adjust the configuration
of PDFing. Go to the
[Convert]
page of the configuration program
and enter the text:
-R:800
in the control labelled
"PCL Parameters" This parameter value increases the size of the
internal
buffers used by PDFing to 800kb and should allow it to process large
spooled-files correctly.
You should check that your OS400 output-queue, has the correct
destination-options configured. The parameter should be
DESTOPT(*USRDFNTXT)
See
configuring an OS400
output-queue for further details.
You can use option
8 from WRKSPLF to
check the user-defined-text attribute
of the spooled-file. Please note that spooled-files created
before
user-print-information is set are not affected and their
user-defined-text attribute
will
not be changed.
User-print-information is never sent by
OS400 command
SNDTCPSPLF, however, you may specify tags
in the DESTOPT()
parameter of this command.
Because each tag in the user-defined-text attribute must be terminated
by a space,
included spaces are not allowed within the tag. You may include spaces
but the
tag-value must be
URL
encoded.
You should check that your OS400 output-queue, has the correct
destination-type configured. The parameter should be
DESTTYPE(*OS400)
.
See
configuring an OS400
output-queue for further details.
You can use option
8 from WRKSPLF to
check the user-defined-data attribute
of the spool-file. Please note that the
transform
process removes all the spooled-file's attributes, excepting file-name,
user-name and
user-defined-text. See
configuring
an OS400 output-queue for information
on the "transform-exit-program" that will preserve these attributes.
When using OS400 command SNDTCPSPLF,
please make sure that
you have set the destination type parameter to DESTTYP(*AS400)
If you ask PDFing to copy files to another drive name and that drive
is mapped on to another PC, the mapping will only be available for
certain
users. Because the default log-on for the NT service is the
"system account" it will not be able to find this drive.
If you want to continue using "mapped" drives, then you can change the
NT service log-on from the "services" control-panel applet. However,
the best solution is to use the Microsoft UNC
naming convention: \\ComputerName\SharedFolder\Resource,
rather than the drive:directory
convention.
This may be because the printing preferences set up for a particular
printer
are ignored when PDFing runs as a service. Because the default log-on
for the
NT service is the "system account" and it will not find any
printing preferences set up by another user-account.
You can change the NT service log-on from the "services" control-panel
applet,
so that PDFing can find the printing-preferences set by the same user
account.
No, you will have to make the connection yourself. However you have
the option to delay sending e-mail, until you are ready.
You can use any
SMTP
mail-server on any platform.
If you do not want PDFing to use the AS400/iSeries mail-server, you do
not need to start it.
You will see this message if a SMTP mail-server
is not "listening" on the specified host-name and port. You can specify
a different SMTP host-name and port on the
[System]
page
of the configutation form. You may also adjust the number
of times PDFing retries the connection and the delay between retries.
You should also check for
anti-virus
activity.
Unfortunately, SMTP port: 25 is often used by
"trojans" and other
malicious software to send unauthorised messages. Because of such
exploits,
anti-virus software running on the PC may block connections on port:
25.
You may need to add an exception to the AV software for program: PDFing.exe
and, if you are running PDFing as a service, you must also add an
exception for
program: PDFingMailer.exe
Generally speaking, a
"firewall"
on the PC
will not block outgoing connections from a PC, but this should be
checked.
You should probably increase the SMTP time out value,
on the [SYSTEM] page of the configuration program.
You may also adjust the number of times PDFing retries
the connection and the delay between retries.
You should probably increase the SMTP time out value,
on the [SYSTEM] page of the configuration program.
You may also adjust the number of times PDFing retries
the connection and the delay between retries.
You should probably increase the SMTP time out value,
on the [SYSTEM] page of the configuration program.
The Windows SDK says: WSACONNECTION ABORTED (10053) - An
established connection was aborted by the
software in your host machine, possibly due to a data transmission time
out or protocol error.
This message is not originated by PDFing, it is just reporting the
error-message
sent back to it by your email-server.
If you were able to send email to outside users before, then this error
message
will be a consequence of changes to your email server configuration.
You will need to speak to the mail server administrator. They should be
able to
change the server configuration to allow relaying.
To give you a little more background to this problem: SMTP mail servers
can be used
by anyone to relay messages and can easily be exploited by "spammers"
because there
is no password required. To counter these "spammers" the server notes
the domain used
when an SMTP client connects (this is taken from the return address)
and may refuse
to accept messages that are addressed to recipients with a different
domain name.
PDFing now supports
ESMTP authentication
of clients for email server systems, this requires a "user-name" and
"password" values to be configured. In almost all cases,
authenticated connections allow messages to be "relayed".
By default, MS Exchange uses X400 standards for email addresses. You
must
assign SMTP addresses for each recipient with an exchange mail-box as
well
as the X400 address, before PDFing can send the email to that address.
A drive mapping is only available to the user account that established
the mapping.
If you ask PDFing to copy files to another drive name and the specified
drive is
mapped on to another system, then the mapping must be available to the
user account
running PDFing. Because the default log-on for the PDFing service is
the "system account",
the service will not be able to find any mapped drives. If you want to
continue
using "mapped" drives, then you can change the PDFingMailer service
log-on account using
the "services" control-panel applet. However, the best solution is to
use the Microsoft
UNC naming convention, rather than drive:directory
naming.
PDFing can run on: Windows 2000, XP, 7, 8 and 8.1
and Server 2000, 2003, 2008, and 2012.
PDFing can convert
*SCS,
*USERASCII
and
*AFPDS
spooled-files.
*IPDS spooled-files are
not
supported. PCL data-streams (v4) can also be sent from other
operating systems that support LPD.
When you need to report a problem with PDFing, we ask you to
send us the LP*.lpr and LP*.con
files for the problem spooled-file.
These files will be in sub-folder: \PFing\Queue\Control.
You can use the [File|Open] menu option to display all of your
converted spooled-files,
then select the grid-line for the problem job and then select the
[Properties | Files] menu option to view all the
files belonging to the
problem job.
Please archive these selected files in a zip-file and
send them to us by email at:
support@pdfing.com.
Once we have these files we can begin our diagnosis of the problem.
We will then get back to you with our recommendations.
If file
LP*.lpr is not present, you will need to
change a setting on
the
[Log] page of the configuration form. The "Log
LPD Activity"
combo-box should be set to
"YES". Then re-write the
spooled-file to PDFing.