Re: Odd Printer/Print Writer question -- MIDRANGE-L

I have a customer with what works out to a similair situation. They have 2500
users that Dial In to their AS/400 (no you don't want that phone bill!) and
during their sessions they print stuff.  This Stuff cannot be available to
anyone else (ie dial in and get the last guy who was on this modems reports). 
We solved the problem with a rather brute force but effective method.  We gave
them each their own *outq (please don't do WRKOUTQ on this machine!).  When they
sign on the writer is started to that *outq.  All reports go there.  When they
sign off the writer is ended by a background process so that even if they go
away rudely (modem drops for instance) the writer goes away even though the job
terminated in the middle.

It's not a problem here but you may also have to deal with data in printer
buffers.  Got no easy answer to that one!

HTH - Larry


mcrump@ballfoster.com wrote:
> 
> I have a payroll/time clock application.  We are planning on allowing 
>employees
> to inquire on their timecards and check stubs in a centralized terminal 
>method -
> I call it a kiosk.  Application security on the terminal is fairly robust with
> the use of timers and badge readers.  My problem is we want to enable an
> employee to print their information.
> 
> What I can't let happen is let someone print their check stub, run into some
> printer problem (jam, out of paper, etc.), walk away from the kiosk, have the
> problem solved, and the information prints after the employee leaves and is at
> risk of being picked up by someone else.
> 
> This kind of 'process' is completely foreign to how we have operated in the
> past.  I was wondering if anyone had some similar scenarios or any 
>suggestions.
> I am currently thinking of:
> 
> 1.) some sort of monitor environment whereby printed information is
> automatically deleted in an error situation.
> 2.) direct print from the application.
> 3.) starting and stopping the writer from within the online program with
> feedback to the program on error situations.
> 
> Of course, I would like to do this with minimal or no modification to the
> existing online program.....
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---

-- 
Larry Bolhuis         |
Arbor Solutions, Inc  | Two rules to success in life:
(616) 451-2500        | 1. Never tell people everything you know.
lbolhui@ibm.net       |
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---