|
|
|
|
When the Printer Database file has been constructed, a Print Queue can be started. For each remote print resource, a separate queue should be initialised and started. Starting a Print Queue requires SYSPRV privilege. The VIALPPSTARTUP procedure can be used to start all required queues automatically, but note that the VIALPPSTARTUP procedure requires further privileges, please refer to Section 3.3.3. Starting queues is normally performed manually by the System Manager or automatically during system startup. You should ensure that the network transport is running, especially if LANprint queues are started during system startup, or if they are set to be autostart queues.
$ initialize/queue/start/processor=symbiont_name - _$ /on=device_name queue_name |
Here, symbiont_name should be replaced by the LANprint Print Symbiont image name, LPPSYMBIONT. The device_name parameter defines the appropriate entry in the Printer Database file (e.g. pc1_print). The /START qualifier will activate the Print Symbiont image, if it is not running already. The queue_name parameter defines the name of the VMS print queue. For simplicity, the sample VIALPPSTARTUP.COM uses the same name for the queue_name and for the device_name, as shown in the following example:-
$ initialize/queue/processor=lppsymbiont/on=dell_print dell_print $ start/queue dell_print |
INITIALIZE/QUEUE and similar commands are normally added to the LANprint package startup file, VIALPPSTARTUP.COM, and this can then be used to start the Symbiont automatically on system startup. VIALPPSTARTUP.COM is described in some detail in Section 3.3.3. Typically the following lines would be added to the site-specific startup command procedure, SYS$MANAGER:SYSTARTUP_VMS.COM for VAX/VMS v6 and Alpha VMS, or SYS$MANAGER:SYSTARTUP_V5.COM for VAX/VMS v5:-
$!
$! We invoke the command procedure to load LANprint
$!
$ IF F$SEARCH ("SYS$COMMON:[VIA]VIALPPSTARTUP.COM") .NES. "" THEN -
@SYS$COMMON:[VIA]VIALPPSTARTUP
$!
|
The LANprint package installation will generate NPDRIVER.EXE, which is a driver intended to be used as a 'front-end' for transparent spooling to a LANprint Print Queue.
Instructions for loading this driver are contained in the template VIALPPSTARTUP.COM procedure, and described in Section 3.3.3. When the driver has been loaded and the device(s) SET /SPOOLed, the transparent spooling facility can be used by directing applications to output to the spooled device or to the equivalent logical name.
For example:-
$ directory/out=NPA3: *.dat;* |
or
$ copy *.dat;* VLC$LASER: |
The transparent spooling facility can be used with applications that
don't support submitting their print output to print queues; this
allows the output to be apparently sent to a print device, but for this
device to be redirected back into a print queue. Transparent print
spooling is described further in the VMS documentation set.
3.3.3 Automatic Startup Command Procedure, VIALPPSTARTUP
This section describes the LANprint Symbiont automatic startup command procedure VIALPPSTARTUP.COM. This is supplied as a template which should be edited to define the queues that are required. In the interest of clarity, the actual text of the startup command procedure has been abbreviated here. For the full version, please refer to the command procedure itself.
This procedure requires VMS SYSPRV, OPER, SETPRV, SYSNAM, and CMKRNL privileges.
This file contains a user-modifiable section that is highlighted with comments. This section defines the 'device' names to which each queue relates, the VMS name of each queue, and logical names for transparent spooling devices. For simplicity, this file uses the 'device' name for the queue name as well, so the queue names match the entries in the database.
$! Define a symbol for the total number of queues to be started $ $ LPP_NUMQUEUES = 4 ! ** Change to suit the number of queues $ ! ** you want to use $ $! Define symbols for each LANprint queue that is to be started $ $ DEVQUE0 = "VLC_LASER" ! ** /ON=Device name for VLC Laser Printer $ ! ** This must match the 'device' name in the $ ! ** LANprint database. This will also be used $ ! ** as the name of the queue itself. $ $ LOGNAM0 = "VLC$LASER" ! ** Logical name for transparent spooling $ ! ** Must not be the same as the queue name! . . . $ DEVQUE3 = "VLC_DRAFT" $ LOGNAM3 = "VLC$DRAFT" |
This section defines symbols to assist in the startup process below. Symbols should be defined for the total number of queues to be started, and for each queue and its associated transparent spooled device. You should modify the "LPP_NUMQUEUES" line if you wish to start a different number of LANprint queues. The DEVQUE0 line defines the name that will be used for both the device_name field, corresponding to the queue's INITIALIZE/ON=device_name qualifier, and for the name of the queue itself. The device_name is used by the Symbiont to identify the database entry for the remote print server & printer. With this approach, the queue name exactly matches the name of the 'device' in the database. The sample LPPDATABASE files use a simple convention for choosing device names, such as VLC_PRINT for a server called "VLC" and a resource called "PRINT". This means that the name of the queue relates directly to the name of the server and of its print resource. You do not have to follow this convention, and indeed you can have the name for the queue completely different to the name of the 'device' in the database, with only minor changes to LPPSTARTUP.COM.
The "LOGNAMn" line provides a logical name for the transparent spooled device. The logical name and the queue name (assigned with "DEVQUEn") must be different, or VMS can get into a logical name translation loop.
The next section of the file initialises and starts the queues:
$ $! Initialise and start the queue(s) $ $ INITIALIZE/QUEUE/START/PROCESSOR=LPPSYMBIONT - /DEFAULT=(NOBURST,NOFEED,NOFLAG) /ON='DEVQUE0' 'DEVQUE0' . . . $ INITIALIZE/QUEUE/START/PROCESSOR=LPPSYMBIONT - /DEFAULT=(NOBURST,NOFEED,NOFLAG) /ON='DEVQUE3' 'DEVQUE3' $ |
The /PROCESSOR=LPPSYMBIONT qualifier provides the name of the LANprint Symbiont program image. This name is parsed with "SYS$SYSTEM:.EXE" to generate the file specification for the Symbiont. It is not possible to specify any of these filespec elements; the LANprint Symbiont image must be in SYS$SYSTEM:.
The /DEFAULT qualifier provides default settings for jobs printed on this queue. Edit them to suit your particular requirements. You may also wish to add other qualifiers.
At this stage, the queues have been initialised and
started. The next stage is to connect device units to the transparent
spooling driver and to define the logical names specified previously
(via the "LOGNAMn" symbols) to allow easy reference to the NPAn: device
names for each queue. This is all done automatically by
VIALPPSTARTUP.COM, using the LPP_NUMQUEUES setting, so you don't have
to do anything more and you can save your changes to the file.
3.3.4 Defining DCL Foreign Command Symbols
The LANprint utilities require parameters to be specified by command line arguments. In order for VMS to recognise these arguments and pass these through to the programs themselves, it is necessary for DCL foreign command symbols to be defined for each authorised user. A sample master command procedure, SYS$COMMON:[VIA]VIALPPDEF.COM, is provided for this purpose. It is unlikely that you will need to use the LANprint utilities very often after you have completed the initial setup of the package, however you may wish to activate it from the system default login command procedure or from individual users' login command procedures by including the following lines in the appropriate file:-
$! Invoke the LANprint symbol definition procedure
$!
$ IF F$SEARCH ("SYS$COMMON:[VIA]VIALPPDEF.COM" .NES. "" THEN -
@SYS$COMMON:[VIA]VIALPPDEF.COM
$!
|
Note that when the package is installed on an alternate disk, the above
lines will need corresponding modifications.
3.3.5 Configuring the DECnet Transport
The following subsections describe the steps which may
be appropriate if you wish to use DECnet as a network transport for
LANprint. Configuration of the TCP/IP support is described in
Section 3.3.6. You can use both DECnet and TCP/IP transports
simultaneously if you wish.
3.3.5.1 Configuring the Known Nodes Database
The target names of any print server systems (or print gateway systems) must be 'known' to DECnet if DECnet is to be used as a network transport for LANprint. Normally, the names correspond to the DECnet node names that have been defined for each server. These names are kept in two databases on the host - one volatile, and one permanent. These databases are managed using the DECnet Network Control Program (NCP). Different NCP commands are used to modify the volatile and permanent nodes databases.
SYS$COMMON:[VIA.DECNET]NCPDEF.COM is a DCL command procedure that is supplied to ease the process of checking and updating the DECnet databases. It prompts interactively for the name of a PC, checks both databases for a previous definition, and allows you to update or modify the definitions.
NCPDEF.COM should be invoked from an account that has OPER and SYSPRV privileges as follows:
$ @sys$common:[via.decnet]ncpdef |
NCPDEF.COM avoids you having to use NCP commands directly and reduces the scope for error. However, the following command format is appropriate if you prefer to use NCP yourself.
For example, to create an entry for PC 'Epson' in the volatile and permanent nodes databases, use the following commands:
$ run sys$system:ncp ! or mcr ncp NCP> set node 1.4 name epson ! define all PC names NCP> define node 1.4 name epson ! in both databases . . . NCP> show known nodes ! check the definitions . . . NCP> exit ! and exit from NCP |
NCP requires the user to have OPER and SYSPRV privileges. Further information on NCP can be found in the Digital Network Control Program manual, or by using NCP's HELP command.
You do not need to perform any name setup for using LANprint over
the LANlink for ARCNET or LANlink for Ethernet
transports as they perform all name resolution automatically.
3.3.5.2 DECnet Access Control
VMS DECnet software allows network access to specific nodes to be restricted, and this can prevent LANprint from making connections to remote systems. The default VMS DECnet setup allows unrestricted outgoing access so this is not normally a problem and LANprint will normally function without requiring any changes. Access can only be restricted to nodes that have already been defined with NCP, so if you have just added a node definition with NCPDEF then you can be confident that there is no access restriction placed upon it, and you can move onto the next section. If you are using LANprint in a non-PATHWORKS environment, you can also ignore this sub-section.
If you have changed the DECnet setup for the nodes you wish to access, it may be necessary to release some of the constraints to allow LANprint to operate. LANprint will report:-
SYMBIONT_2 - Error Accessing Remote Server <node_name> %SYSTEM-F-REJECT, connect to network object rejected |
when non-privileged VMS users attempt to make a connection to a node that is restricted. Privileged VMS users will not be affected by this level of DECnet access control.
You can display any DECnet access control information for a node with the following NCP command:-
$ run sys$system:ncp NCP> show node nodename characteristics |
Where nodename is replaced by the DECnet nodename of the node in question.
It is possible to restrict access to "ACCESS NONE" or "ACCESS INCOMING" and either of these will prevent LANprint from connecting to the node. The default display would show "No information available", which is equivalent to "Access = Incoming and outgoing". In order to restore full access, you should use commands such as:-
NCP> set node nodeaddress name nodename access both NCP> define node nodeaddress name nodename access both |
Where nodeaddress is replaced by the DECnet address of the node.
LANprint will also work happily with "ACCESS OUTGOING", which would still prevent connections coming into the VMS host.
It is not possible to restrict incoming access on the PCs, at least not
with PATHWORKS v4.1.
3.3.6 Configuring the TCP/IP Transport
The following subsections describe the steps which may
be appropriate if you wish to use TCP/IP as a network transport for
LANprint. You can use both DECnet and TCP/IP transports
simultaneously if you wish.
Please refer to Section 2.4 for details of TCP/IP stacks, and minimum
versions, supported.
The TCP/IP transport support included in LANprint will identify a
supported TCP/IP stack automatically and often requires no further
configuration. It will attempt to locate remote servers by using
network broadcasts and where the target system is within the same
broadcast area it is generally unnecessary to perform any
extra setup to allow the targets to be found.
However, there are some circumstances when the broadcast technique will
not succeed. Notably, when the target system is on a remote site or is
behind a router or bridge that does not forward broadcast traffic, or
when the broadcast responses are sent to the wrong place! This latter
situation can occur when the target systems are running a TCP/IP
implementation that does not expect requests from ephemeral
ports. Significant problem TCP/IP stacks include the PATHWORKS
v5.x and v6.0 TCP stacks from Digital (this fault is fixed in TCPIP.EXE
v6.0.034, available from Digital). Microsoft's TCP/IP-32 stacks all
operate correctly in this regard and do not cause this problem.
Problems with broadcasts are all handled by creating the
VIAROOT:[VIA.TCP]NBHOSTS.DAT text file as described in Section 3.3.6.2.
In rare situations you may also suffer from problems caused by the
remote system using a non-null NetBIOS name scope. The
name scope is used to subdivide NetBIOS names in a network,
sometimes using the Internet domain name as a qualifier for each site
(e.g. vector-networks.co.uk). This is very unusual, even in large
Internet domains, but it can be handled by defining a matching
NETBIOS_NAMESCOPE logical name on VMS before starting LANprint, as
described in Section 3.3.6.3.
The last item that occasionally needs to be configured is the name of
the Internet interface that should be used for communication.
Once again, this is normally determined automatically and no action is
likely to be required, but if you have a VMS system which is running
multiple interfaces at once, you can define a suitable
NETBIOS_TCPDEVICE logical name to identify the interface required, as
described in Section 3.3.6.4.
If you wish to access any nodes over wide area TCP/IP connections, or
in fact any TCP/IP nodes that are not in the same
broadcast area, or any systems that are proving unreachable in
your initial attempts, then you should add an entry into
VIAROOT:[VIA.TCP]NBHOSTS.DAT for each PC involved (create this file if
it does not exist already).
VIAROOT:[VIA.TCP]NBHOSTS.DAT is a simple text file that associates a
NetBIOS name with an IP address, in the following format:-
This is the IP address in standard decimal notation followed by one or
more space characters, and then the name of the target system IN
UPPER CASE.
3.3.6.1 Configurable Items for TCP/IP
3.3.6.2 Using NBHOSTS.DAT to Resolve Network Names
# You can enter comments like this
90.0.0.21 NTSRV
90.0.1.47 SALES
90.0.1.42 STORES
90.1.3.22 "NTX-351"
It is important that server names are specified in UPPER CASE in this file. |
If your NetBIOS names contain "-" or "/" characters then it is important that you surround the whole name with "quotation marks". |
Note that the NBHOSTS.DAT file is used to map a NetBIOS name onto an IP address, and NetBIOS names are always case-sensitive. LAN Manager server names are, by convention, always upper case so it is important that they are entered as such in NBHOSTS.DAT.
If you wish to add a comment onto a line which defines a NetBIOS name then you can do it by padding the name to 16 characters with spaces and enclosing it in quotes, and then putting the comment beyond the closing quote. We recommend that you still precede the comment text with a "#" character. The "#" characters are not significant parts of the NetBIOS name.
Once you have added an entry into NBHOSTS.DAT you should retry your
attempt to access the PC. If it still fails then ensure that you have
VMS SYSPRV privilege, that you have got the IP address correct in
NBHOSTS.DAT, and that a suitable server is running on TCP/IP
on the remote PC.
3.3.6.3 Setting the TCP/IP NetBIOS Name Scope
In the rare situations when a non-null NetBIOS name scope is required, it can be specified by issuing a command such as the following, before starting any LANprint queues:-
$ Define/System NETBIOS_NAMESCOPE "vector-networks.co.uk" |
Note that the name scope is case-sensitive, and Internet domain names
are conventionally lower case, so the quote marks (" ") that surround
the name are required.
3.3.6.4 Specifying an Internet Interface Name
LANprint's TCP/IP support searches for an Internet interface name using the following sequence: "SE0", "QE0", "DE0", "NE0", "ZE0", "XE0", "FE0", "CE0", "RE0", "WE0", "WF0", "AF0", "CF0", "FF0", "RF0", "QF0", "WW0", "CT0", "CI0", "RI0", "ep0", and "se0", and this will generally find the correct Internet interface name automatically and no user action would be required. (The last two names, "ep0" and "se0", are added for compatibility with third party VMS TCP/IP stacks and they behave as generic devices where the principal physical interface will appear behind either of these names, whatever that device may be.)
In the rare situation when the default search for an Internet interface either fails to find a suitable device, or when it finds the wrong one (on a multiple-interface host), you can nominate a specific interface name with a command such as the following:-
$ Define/System NETBIOS_TCPDEVICE "se1" |
This example will cause LANprint queues over TCP/IP to use the second shared Ethernet interface in a TCPware or MultiNet environment, for instance.
Internet interface names are case-sensitive. Be sure to enclose a lower-case name in "quotation marks". |
|
| 
|
|
|