Ending QZDASOINIT jobs on AS400

  • Thread starter Crazy_About_JDE
  • Start date
Crazy_About_JDE

Crazy_About_JDE

Well Known Member
I've been doing a lot of reading about QZDASOINIT jobs--AS400 Client Access ODBC connections. Does anyone on the list have knowledge or an opinion of what are the short- and long-term ramifications of manually ending these jobs when they get above 1.5% CPU?
 
Short and long term are the same.

These are database connections so if you just arbitrarily start ending them then very bad things will happen. ie. UBE 'bombs' in the middle of a job. Users get lost database connections, etc.

Why would you want to end them if they go above 1.5% CPU? I've seent them go up to 25% on a regular basis on smaller AS/400's

Colin
 
The QZDASOINIT (or just INIT) jobs are prestart jobs used by the QUSRWRK SBS. The number that start, the number of uses they have before they end and the min/max that the system keeps track of are setup in the Job Entry for the INIT job (DSPSBSD QUSRWK > Opt 10 > Opt 5 on the QZDASOINIT to view the settings).

These jobs are used by any ODBC/JDBC connection - not just OneWorld (Crystal Reports, Portals...).

If you have a lot of outside connections (aside from HTTP and Telnet) coming into your iSeries, make sure that you are killing the correct one (opt 5 on it and then opt 1 to find out the attached user ID).

Most of these jobs will sit there "listening" for a new connection and should not take up an abundance of CPU % (if they are, then I would certainly look at the open files and see what it is doing).

More than likely, these are used for queries that return to the users screen (menu travel, painting the grids and finds). If you kill one, you'll be effecting that persons interactive transaction.

I am "pretty sure" that if they resubmit that statement/transaction again - it will grab the next idle INIT job.

The only gotcha's that I would be worried about is if that job has an abundance of CPU - it is either caught in a loop or tied to a run-away-session. I would certainly note the jobs information (name/user/number) and watch it after you end it.

you can find the IP Address of the connection using that INIT job in the JOBLOG. (Or if you can not view joblogs there is somewhat trickier way to trace - you can go into NETSTAT opt. 3, and look at open connections - sort them by activity and look at open jobs to find the IP Address of the connection that way.

Not sure if my drawn out answer made sense or even answered your question. INIT jobs are a great place for performance tricks and performance nightmares.

Kristian
 
Tim:

Ramifications: Users start calling IT asking “where is my report”, or “every time I click on this, it never comes back” etc.

Chances of all SQL queries being so optimized to always run under 1.5% are slim to none. If I was going to end jobs like you intend to, I would ramp up my tolerance threshold significantly (50 fold or so).

Jen
 
The pre-start jobs are used to optimize performance. Not setting them correctly could hinder performance.

Check out this doc I found writen by JDE GATS group.
 

Attachments

  • 90307-ttdk_AS400_Prestart_Jobs - for performance.doc
    92 KB · Views: 1,286
Thank you for writing, Colin. At some point in the past--two years?--someone in our department discovered that if two or more users complained that OneWorld response time was abnormally slow, we could get fast results by killing any INIT jobs running above 2% CPU. The practice has become more common over the recent months, hence my interest in learning more.

Do you think killing INIT jobs could result in corrupted user overrides?
 
Tim - I would certainly not develop the habit of 'When in doubt, Cancel it out.' That's a rut that people get in with messages, they automatically cancel them without looking into what caused it.

Killing INIT jobs because they "appear" to be taking up more than 2% is not a good practice. Remember, the CPU that appears in WRKACTJOB is not always realiable. Especially if the operator stays in there and hits F5, instead of F10. A real usage statistic is through WRKSYSACT (which is a licensed add-on - $$). Spikes in CPU are common and should not result in killing a job.

If this has become a problem, I would do a little more of the pro-active approach and look at some performance tunning, rather than stay in a reactive mode and end users jobs.

Just my two-more-bits though.

Kristian
 
We are heavily using the QDAZOINIT jobs, which run SQL calls to our production data from our business intelligence tool.

There is a way to optimize your system so these jobs don't "take over" and slow down your system and other batch jobs. You would have to understand what function you have using them before taking these steps

These prestart jobs can be configured to run below other batch jobs on the system and be more efficient.

We changed the QDASOINIT prestart jobs to have an initial number of jobs of 20, threshold of 11, additional number of jobs 10, and maximum number of uses at 3 (some people believe this should be 1). We then created a custom class with a run priority below our other batch jobs. Our batch jobs are 30 and this class uses 50. This seemed to help the most.

However, note that this is in a WORLD environment, I noted that the OneWorld white paper from a previous post is suggesting almost the opposite of this. The set up in that white paper would actually almost take our system down. There may be a difference because of the high level of other batch and interactive jobs on our system. Yet, we have found that the more uses these jobs are allowed, the less efficient they become, an issue which IBM has yet to address.

I hope this helps.
 
This post made me have a look at my system, I see our jobs are set number of uses at 200. We have been live on this for a couple years now. Wondering if there woudl be a benefit to changing this?

I do notice sometimes we end up with jobs out there a week old showing up as active or taking up resources with a date of a few days ago in the job log. We do not end services on our machine nightly or even monthly. Once every three months for a full package build.

Would it make sense to move that to a lower number? And what would that achive?

Nick
 
There seems to be a lot of questions on this posting, and I have seen the same type of questions in the past at other forumns. Attached is a document that I have created to go over all the tips and tweaks to squeeze as much performance from the iSeries that you can for OW. Hope this answers any questions.

As a note - this is my own personal comments and note to reflect of PeopleSoft or my company. Please make changes wisely, since most performance changes effect the system entirely - not just a OW environment.
 

Attachments

  • 90423-Tweaks for performance.doc
    55 KB · Views: 1,430
Please DO NOT CONFIGURE A ONEWORLD OR E1 SYSTEM WITH WORLD SETTINGS ON THE ISERIES!!!!! Sorry for the caps, but what works for World, a green screen app, not client server, does NOT work well for E1. Those of you co-existent...well, you earn your keeps every day!
smile.gif
If you want proof...contact Oracle GATS or IBM. You can not treat E1 on a iSeries like World...end of story! You can't and should not even have auto-tune turned on if you are running E1 on that box/LPAR just as an example. It's documented, verified by both ORCL and IBM...just remember...World is green screen...E1/OW is client server. What works for one doesn't play well with the other.

As others have said in this post, and though I haven't chimed in because they all were correct...DON'T kill these jobs unless you've either determined it's hung, causing issues (because it's hung
smile.gif
), or you like making work for yourself.

Regards,
 
Kristian,

Thank you for taking the time to put this document together. I just
browsed through and found a few things which I had to learn the hard way,
Good Job !!!
 
Jim,

Good point. Having run a co-existent shop for 5 years, World and OneWorld are like comparing Apples and... PC's.

World runs a 5250 emulator which (by default) connects to the iSeries through QINTER, using the memory in *INTERACT. World is written in RPG - which is native to the AS400.

OneWorld (by defualt) connects to the iSeries through QUSRWRK, using memory in *BASE (or a seperate sharepool that you create). OW is also (mostly) written in C (although not being a programmer and not understanding the OW tool, I am assuming it is C), this is not native to the AS400.

Do not confuse tunning World as the same to tune OneWorld. When we ended co-existance we had to upgrade from an 830 to a 570 to handle the same amount of users, but for OW.

This thread should pertain to the INIT prestart jobs which effect OW and other ODBC connections.

The time that these jobs will affect World is when they absorb all the available memory making everything run slow - including the World telnet jobs.

Kristian
 
Excellent post...and I didn't mean to come down on you...just seen too many shops that treat E1 the way they tried to treat World on the iSeries...and it just "don't" work!
wink.gif


Your post will help lots out there.

Regards,
 
The generally accepted theory is...and this is if you are only concerned with E1, that each user takes up about 5-7 ODBC connections. However, as is usual in the "real" world, E1 is often not the only app running on your iSeries.

Regards,
 
Back
Top