QZDASOINIT job?

1005 pts.
Tags:
AS/400 backup
AS/400 errors
QZDASOINIT
Hi , am recieving the following error messages Message . . . . : Error occurred while calling program or procedure *LIBL/NBCUNQSN (C G D F). caused by the QZDASOINIT job. I presume this is a ODBC job that runs in QSERVER, any ideas as to what has to be done. The backup is running currently and this is the first instance i have come across such a problem

Answer Wiki

Thanks. We'll let you know when a new response is added.

Hi,

If the backup is running I suspect that it’s locked a file that this job is trying to access. Maybe it’s an idea to wait until the backup is complete and then give the job a kick with an option G?

Regards,

Martin Gilbert.

Yes, very true!  I concur with MellOrman, i find the same situation to be very true on our system.  IBM / OS-400 , or DB2 , or whatever system manages these job – should really be re-designed to maintain these jobs a lot better.  because too many of them out there can really hurt performance,.  And how hard would that be?   I mean if I can program a screen, to turn off , or kill an interactive user job , if there is over an hour of INACTIVITY, for example., and so how hard would it be for IBM to create a process that simply runs and checks these job logs of QZDASOINIT jobs for inactivity of say over 2 hours?  or even make it a QSYSVALUE– so that we can set the Q IN-Activity time to whatever we want?  … and im sure these jobs have a job log like everything else on the system right,  and so how hard is it to check that log, for any requests ?  and if there was no SQL requests, for over 2 hours, and then just kill that instance of the QZDA* JOB, so as to reduce the number of them that are spawned, or rather kill the ones that were spawned but are not really bieng used any more?  what you guys think?  should a write a suggestion letter to IBM?   Lol..  
**************************************************************************
Practically zero need for changes by IBM since there’s near zero performance impact from these jobs when they’re inactive for more than a few minutes. Also, if excess QZDASOINIT jobs are sticking around while inactive for an hour or more, it’s likely due to inappropriate configs of those pre-start job entries. Change the configs to meet the need, and they should go away.

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Mell0rman
    I normaly can any QZDASOINIT jobs causing problems. I've found them to be always a type of user connection job, either GUI query's or OPSNAV stuff. The user's either have long gone or encountered a problem and know nothing about these.
    270 pointsBadges:
    report
  • BDS1973
    Yes, very true! I concur with MellOrman, i find the same situation to be very true on our system. IBM / OS-400 , or DB2 , or whatever system manages these job - should really be re-designed to maintain these jobs a lot better. because too many of them out there can really hurt performance,. And how hard would that be? I mean if I can program a screen, to turn off , or kill an interactive user job , if there is over an hour of INACTIVITY, for example., and so how hard would it be for IBM to create a process that simply runs and checks these job logs of QZDASOINIT jobs for inactivity of say over 2 hours? Or even make it a QSYSVALUE- so that we can set the Q IN-Activity time to whatever we want? ... and I'm sure these jobs have a job log like everything else on the system right, and so how hard is it to check that log, for any requests? and if there was no SQL requests, for over 2 hours, and then just kill that instance of the QZDA* JOB, so as to reduce the number of them that are spawned, or rather kill the ones that were spawned but are not really being used any more? what you guys think? should a write a suggestion letter to IBM? Lol.
    45 pointsBadges:
    report
  • TheRealRaven
    Since the jobs will go away if inactive for excessive times if the pre-start config is appropriate for the expected workloads and since there is practically zero performance impact when the jobs are inactive for more than a few minutes and since perhaps as much as 90%+ of all systems showing such performance issues have inappropriate work management configs, it's very unclear what changes IBM should make.

    First step should always be to ensure work management configs are appropriate. Unfortunately, too few have a clear idea how to do that.
    28,795 pointsBadges:
    report
  • ToddN2000
    Another option is to adjust the timeout on the connections that are opening the QZDASOINIT jobs. We have about 20 of these active at any given time and have set the timeouts to close after a period of inactivity. 
    115,180 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: