Re: ODBC versus JDBC question

wrote:

Or just use the prestart job entry commands.... From a performance
perspective moving them out of QUSRWRK/QSYSWRK does not provide much impact
and adds to the system startup/shut down complexity. Adding a memory pool
just for those jobs and moving the prestart jobs into that memory pool is
really is the key.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Charles Wilt
Sent: Tuesday, October 07, 2014 1:37 PM
To: Midrange Systems Technical Discussion
Subject: Re: ODBC versus JDBC question

Better solution would be to route the jobs to separate subsystems via
iNav...

http://wiki.midrange.com/index.php/QZDASOINIT
http://www.centerfieldtechnology.com/PDFs/August-2005-Newsletter.PDF

Charles

On Tue, Oct 7, 2014 at 2:28 PM, Paul Nelson <nelsonp@xxxxxxxxxxxxx> wrote:

They'll care, because management is issuing edicts about getting
performance improvements. The JDBC stuff has two-way activity with the
system (sending transactions from Siebel and getting responses back).
If those connections can be re-routed to QSQSRVR jobs, I can isolate
and put a governor on the ODBC connections.

Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Jim Oberholtzer
Sent: Tuesday, October 07, 2014 1:09 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: ODBC versus JDBC question

They won't and don't care. All they care about is connecting and
being able to run queries. (a good thing BTW)

Treat both servers the same. They both run SQL to the database. Pure
work management and system administration.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Paul Nelson
Sent: Tuesday, October 07, 2014 12:59 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: ODBC versus JDBC question

Will do. Thanks, everyone.

Now to see if the Java programmers know what this means.......... :-(

Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Jim Oberholtzer
Sent: Tuesday, October 07, 2014 12:47 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: ODBC versus JDBC question

QZDASOINIT and QSQSRVR are the two jobs you need to review.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Paul Nelson
Sent: Tuesday, October 07, 2014 12:20 PM
To: 'Midrange Systems Technical Discussion'
Subject: ODBC versus JDBC question

I have a client who has people and applications connecting to the i
with both ODBC and JDBC connections.

I know that ODBC runs in QUSRWRK, and I've been able to throttle back
the priority of those jobs in the past to maintain interactive
performance in the past. Does JDBC run in the same subsystem, and is
there a way to differentiate between the two types of jobs?

Thanks

Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at

http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at

http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.