Conference noted::pwv50ift

4234.0. "/PASSALL Questions Again Please!!!" by GRANPA::BARABIA () Mon Mar 31 1997 13:29

    Customer has installed some kind of Canon Printer/Copier Device with
    some kind of UNIX Pre-Processor front ending the device. The printer 
    device is attached to the Network via TCP/IP and they've tried to point
    a VMS Print Que and PATHWORKS Share to the device. Seems the /PASSALL
    qualifier associated with the Print job "confuses" the printer and jobs
    won't print, however, removing the /PASSALL qualifier from the Qued
    print job allowed the jobs to print normally.
    
    I've read previous notes discussing the /PASSALL qualifier which I
    understand is appended to all Print requests via the PATHWORKS Server
    and it is not modifiable and the basically the /PASSALL is put on the
    print request so that the VMS Print Symbiont does not append any
    control characters to the print job and the job is sent to the print
    untouched by VMS. Close?
    
    One question I can't give a good answer to is why would a job seem to
    print ok without the /PASSALL parameter on the print job? Does the 
    symbiont not append control information to the job that is then passed
    to the printer? For this paticular device above, we are going to see if
    there is a setting on the printer or pre-processing device that would
    better deal with /PASSALL.
    
    Would it be possible to maybe put together a device control library
    file that could possibly either set the /PASSALL to /NOPASSALL or send
    a character to the printer that would maybe ignore the /PASSALL or
    something along those lines. Make any sense?
    
    Imput would be greatly appreciated.
    
    Thanks,
    
    Barry A

    Barry,
    
    What symbiont is the VMS print queue using (/PROCESSOR=?)?  It's the
    symbiont which is responsible for processing the job and how a job is
    processes "differently" when that job is submitted with /PASSALL.  
    
    Way back when PATHWORKS all started, the prevalent symbiont was LATSYM;
    your comments about how things work with /PASSALL are fairly accurate
    for LAYSYM, but can't necessarily be applied to all symbionts.
    
    Paul

    Hey Paul, long time no "talk" eh?
    
    Yea, they are using a different symbiont, MULTINET_LPD_SYMBIONT since
    this is a TCP/IP served printer, is it fair to assume that the Multinet
    symbiont has trouble with /PASSALL but can interpret the print request
    better without it? Think it'd be worth hitting up Multinet for a
    possible "fix"? Did you also happen to see Note 4235? We may need to
    talke with Multinet about that, so we'll throw this at them as well.
    
    Thanks for the response.
    
    Barry

    
    Definitely talk to Cisco about their symbiont.  The ucx lpd and telnet
    symbiont behavior can be modified via logical names; maybe multinet
    has something similar?
    
    Paul