Leave feedback
  • Question

    printer spool casually blocked by StreamServe document

Enter a new topic
  • Bianca Stelter Bianca Stelter
    0 likes 4924 views

    Besides M3 output put on StreamServe Server ( StreamServ 4.1.2) which is a windows server, we want to channel output from our warehousemanagement system ( AIX server) to StreamServe Server.

    requirements: Samba client intalled on AIX server, enabling share on AIX, StreamServe Server maps shared device and StreamServe Service is started as a local user.

    New input connector listens to shared device. All seems to work fine in TEST Environment.

    After deployment of input connector in PROD Environment and restarting StreamServe Service as local user, before it was running as system user, files remain in spooler without beeing printed.

    restarting spool helps to print again but only for some time. But obviously it couldn't be a special document which causes the problem

    printers are using IP-print, novell queued, and local user has full control in printing process.

    Any idea what's going wrong here?

    Thanks, Bianca

     

    Thursday 24 June, 2010
  • Vyv Lomax Vyv Lomax Administrator
    0 likes

    Moved to Connectivity & Post Processing

    Thursday 24 June, 2010
  • Vyv Lomax Vyv Lomax Administrator
    0 likes

    It sounds to me as if you have to focus on the SAMBA connection and access rights. Is there a dip in the network conenctivity?

    What is the file size check interval on the inconnector? You could try doubling it perhaps.

    Have you tried running StreamServe Service as a windows domain user?

    Thursday 24 June, 2010
  • Henrik Wejdmark Henrik Wejdmark StreamServe Employee Administrator
    0 likes

    Let me see if I understood what your environment looks like:

    AIX: Shares a Sambashare. You also have a print server (Novell) running here to which the users print. The spool file in Novell is then written to a directory that is shared using Samba.

    Windows: Maps the samba share as a network drive (like E: = \\youraix\strsspool), and runs StreamServe who reads from this network drive.

    If I did understand it right it looks good except for one thing. I suggest that StreamServe should read directly from UNC instead of a mapped drive, ie use \\youraix\strsspool instead of E:\ on you input connector. The reason is that if you map a drive it is Windows Explorer who manages the mapping and Windows Explorer has problems in case of any network issues, access rights changes etc. For instance if you map a drive to a clustered share and the cluster switches nodes, a UNC path will see that imidiately but with a mapped drive it can take up to 20 minutes before the mapped drive notices it.

    Besides that, I would do as Vyv already suggests. Take a close look at access rights on your samba share. Also note that on teh AIX server you might have two sets of rights. First how the Samba server access the file on disk, and then how the Samba server exposes these files to the Windows client (StreamServe).

    //Cheers

         Henrik

    Thursday 24 June, 2010
  • David Shih David Shih StreamServe Employee
    0 likes

    Just to clarify: you're saying that the files are hanging in the Windows Print Spooler after being processed by StreamServe? (i.e. that the input files are gone from the Samba share on AIX, and that the StreamServe log file shows that the input files have indeed been processed)

    If that's the case, then it's probably a permissions issue. As the local user, can you send test prints from another application (e.g. Notepad)?

    If that's not the case, then what does the StreamServe log file show?

    Thursday 24 June, 2010
  • Bianca Stelter Bianca Stelter
    0 likes

    Thanks for quick answers. I think rights on Samba share may not cause the problem because

    - input from the 1. observed connector M3 is blocked in the spool, even when no other output from the share has been created before.

    Besides:

    -logfiles in StreamServ all show that processes are completed successfully.

    -test prints with local user on envolved printers are working

    Friday 25 June, 2010

 

Latest from the blogs