home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / ibm / 863 < prev    next >
Encoding:
Text File  |  1992-12-30  |  3.4 KB  |  81 lines

  1. Newsgroups: comp.protocols.ibm
  2. Path: sparky!uunet!paladin.american.edu!gatech!darwin.sura.net!haven.umd.edu!decuac!pa.dec.com!e2big.mko.dec.com!nntpd.lkg.dec.com!smaug.enet.dec.com!cambria
  3. From: cambria@smaug.enet.dec.com (Michael C. Cambria)
  4. Subject: Re: Help!!! 3287 printing problem.
  5. Message-ID: <1992Dec30.214838.4114@nntpd.lkg.dec.com>
  6. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  7. Organization: Digital Equipment Corporation
  8. References:   <54360002@hpsgm2.sgp.hp.com>
  9. Date: Wed, 30 Dec 1992 20:21:33 GMT
  10. Lines: 69
  11.  
  12.  
  13. In article <54360002@hpsgm2.sgp.hp.com>, klitd@hpsgm2.sgp.hp.com (Raj PUBALA) writes...
  14. >I need some CICS and VTAM help here. Here is the following scenario:-
  15. >A user logons to a CICS application. He does a print from the application. The
  16. >output gets printed. He does it a few times and it works all the time. He logs
  17. >off from the application. Now, this user is the only user on the PU. The printer
  18. >is attached to the same PU (PU type 2, printer is 3287 and terminal is 3278).
  19. >Then he logs in to the application again. He tried printing. Sometimes it worked
  20. >and sometimes it does not. (the printing problem occurs after he logs off from
  21. >a successful print).
  22. >We did multiple buffer trace on the printer LU. Is it true that CICS will 
  23. >unbind (at least clear) the session with the printer LU after the print job
  24. >is complete? Is this true also for multiple print job on the same logon
  25. >session (without logging off and on again)? 
  26.  
  27. A PLU does not have to UNBIND a printer after printing.
  28. If another (P)LU wants to use the printer, it will "tell"
  29. the current PLU (via an Notify RU) and the RELREQ exit will be driven.
  30. The PLU will then UNBIND the printer (allowing the other PLU to us it.)
  31. I don't remember off the top of my head if CICS behaves this way or 
  32. not.  I'll drink on it.
  33.  
  34. >The buffer trace does not show a relinquishing of the printer LU after each
  35. >print job (i.e. an UNBIND from CICS to printer LU). So when the user logons
  36. >again and print from the application, it does not print.
  37.  
  38. The above explains why a PLU doesn't have to relinquish the printer after
  39. each print job.  A PLU *should* be able to print again .....
  40.  
  41. >CICS TCT shows that the session if REL (Release) when it cannot print. Usually
  42. >it shows REL and CRE (Release and Create). VTAM shows the printer LU status
  43. >to be PREALLOC-Q (which translates to printer session is queued and used by
  44. >someone else). Now remember, there is only one application using this printer LU
  45. >and there is only one user.
  46.  
  47. Is the printer predefined to CICS?  The "Create" doesn't sound right.
  48. If I remember correctly, it has to do with autoinstall.  I don't 
  49. belive that printers can be autoinstalled.
  50.  
  51. What does VTAM show as the PLU for the printer LU status of PREALLOC-Q?
  52. The applid of *some* application should be given.  Is it the CICS in 
  53. question?  Another application?
  54.  
  55. If the session is queued to CICS, there should be an LU-LU session to
  56. the printer which is causing CICS to queue.
  57.  
  58. What does cemt sho when things are working?
  59. What does VTAM show for the printer when printing is taking place?
  60. What does VTAM show for the printer when printing stops?
  61. Be sure to use ,e (ie. d net,e,id=printer)
  62. Note also the IST597I (capability slu enabled, disabled etc.)
  63.  
  64. >Any advise or confirmation? Is there a way to confirm these beside showing
  65. >a buffer trace of print jobs that does not have UNBIND or SHUTDOWN?
  66.  
  67. Do you have netview?  You can use NLDM to see the session history.
  68.  
  69. Good Luck,
  70. /Mike
  71.