Re: V4R1 and QPASRVP

[mcrump@xxxxxxxxxxxxxx]

>Actually, I had heard that the job in question only handles initiating
>and terminating the passthru session - that once it is started, the
>passthru job no longer has anything to do with QPASRVP until ENDPASTHR.
>So is QPASRVP is ended, no one can STRPASTHR or ENDPASTHR, but all
>current PASSTHR jobs should be ok.  Is this not the case?

No.  All emulation sessions die (PC5250, Rumba, etc.).
mcrump@ballfoster.com wrote:
>
> One of the changes with V4R1 seems to be a job QPASRVP.
> This job is the target pass-through server job that is used by
> pass-thru and terminal emulation.  Prior to this pass-thru and
> terminal emulation were handled by individual jobs.  No big deal.
>
> However, it seems that for a given system there may be only
> 1 QPASRVP job.  The system value QPASTHRSVR allows you
> to control this but I haven't seen any effect on changing this.
>
> My problem with this stems from CA/400 (imagine that).  On
> occasion we will have a user who locks up or can't signon.
> They typically will reboot on their own.  Sometimes this works
> and sometimes it doesn't.  Our operators (unknown to me at
> the time - although I can't argue against it) typically then would
> end all jobs associated with the client access 'session'.
>
> Unfortunately, even though there may only be one QPASRVP
> job you will see it associated with each CA/400 device that
> has evoked terminal emulation.  What happens?  An operator
> ending jobs on an individuals PC will end the QPASRVP job
> and ALL PASS-THRU (INCLUDING PC TERMINAL
> EMULATION ) PROCESSES ON THE SYSTEM DIE.  You
> can recover but it is a little bit too late.
>
> Currently, I have stressed to everyone the importance of
> not ending jobs unless they really have to and to never end
> the QPASRVP job.  Problem is everyone (including me)
> does not have a perfect memory and I am really worried about
> the continued impact on the 'stability' of the system.
>
> 1.)  I am assuming that this is the way it should be and
> that other people on V4R1 are in the same boat.
>
> 2.) You can tell the system to start up to 100 of these jobs
> but for the life of me I can't seem to get anymore than
> one to work.
>
> 3.) Operationally, doesn't this seem to be a design flaw?
>
> 4.) What way do you have the system stop people from
> ending 1 specific job?
>
> Michael Crump
> Technical Project Leader
> Ball-Foster Glass Container Corp.
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to "MIDRANGE-L@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
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@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
+---






+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@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
+---