× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. October 2014

Re: ODBC versus JDBC question

I agree that memory pools and prestart job definitions are the key to
controlling ODBC/JDBC.

But how can you possibly route ODBC from a given IP address to one set of
preset jobs and JDBC from another IP address to another set of prestart
jobs unless there are two sets of prestart jobs in different subsystems?

I'm not a work management guru, but AFAIK the best way to segregate &
control work independently from other work is by having it in its own
subsystem. subsystem.

Paul doesn't want to get a handle on ODBC/JDBC. He wants to control JDBC
separate from his controls on ODBC.




On Wed, Oct 8, 2014 at 8:17 AM, Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx
wrote:

Charles, with due respect that's not true, you can manage both those jobs
just as easily from the original subsystems as you can in a unique
subsystem. It's a bit easier when using custom subsystems but the work
management and such is identical in both cases. The subsystem itself
offers
no special ability to manage those jobs. It's how you set up the
subsystem memory pools, routing, and the prestart jobs that have the effect
desired.

If you really want them in separate subsystems, go for it, but it's not a
requirement for the original question.

--
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 2:24 PM
To: Midrange Systems Technical Discussion
Subject: Re: ODBC versus JDBC question

In Paul's original post, he wanted to treat ODBC different than JDBC..

The only way he'll be able to separate them 100% is by moving one/both to a
(couple of) new subsystems.

Charles

On Tue, Oct 7, 2014 at 2:49 PM, Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx
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.


--
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.