CHGCMDDFT Hosed My System

[Guest.Visitor]

Kim, Changing this default is not altering any authorities. The issue at hand is twofold. First, making the CHGJOB command have a default value of 30 for the DLYWAIT parameter is an issue. The authority needed to change the parameter to 30 is higher than what your users are configured for. I don't think changing the DLYWAIT to default to 30 is the answer here. I would consider changing it to 30 for virtual devices only; not everyone. The second issue may actually be the problem. It seems when you changed this parameter, many people called, which indicates alot of people are running the CHGJOB command. What are they changing? Are they changing job priorities or timeslices? If so, then that might be the reason for the timeouts on the virtual devices. You should dig a little deeper to see why they are executing the CHGJOB command. That might be the reason for the timeouts. Another thing you may want to check would be to see if there are any batch jobs running in the same subsystem(s) your virtual devices are running in. Hope this helps. Doug.

[Guest.Visitor]

Thanks for the reply Doug. I could kick myself for not thinking this through before I made the change! I ended up just changing the QINTER Class which I should have done in the first place and definitely knew better! Although the initial problem was mainly with the virtual devices, they also occured on IP and ET devices. I just need to reverse the change I did 9CHGCMDDFT) and get this system back to it's normal self. My users (approx. 1500) normally don't encounter even a hickup on this system so needless to say, I am just sick about this.

[Guest.Visitor]

Doug...problem solved. I had to issue CHGCMDDFT CMD(CHGJOB) NEWDFT('DFTWAIT(*SAME)'). Removed JOBCTL from profiles and processes are back to normal. THANK THE GOOD LORD! Hey...and thank you for taking the time to help me out with this!

[Guest.Visitor]

Kim, Glad I could help. Glad your users are back to normal. Good to see that they don't even encounter hiccups! Must be the good old 400. I (unfortunately) have been moved off of it and onto a non-400 platform (unix). Needless to say, I am experiencing massive withdrawl, and experience hiccups way more than I am used to. Funny thing is that this is 'acceptable'. What's the point??? The system is supposed to "RUN", not take baby steps and stop all the time. I can't stand it!! By the way, just out of curiosity (and you don't have to answer), what state are you in? Glad I could help! Doug.

[Guest.Visitor]

We were experiencing interminent time-outs on several Virtual Devices. Recovery instructions within the Help Text detailed changing the default wait time (which was set to 10). I processed the command CHGCMDDFT CMD(CHGJOB) NEWDFT('DFTWAIT(30)'). Immediately after making this change, the phones started ringing. Processes were erroring out with "Profile Name" is not authorized to change either parameters Run priority, Time slice, Purge, Time slice end pool, or Default wait time. Recovery for this is to grant *JOBCTL to the profile/s which for security purposes is not an option. I've reported this to IBM and thus far have received no fix information. I can't believe changing this default would alter any authorities. I would welcome any suggestions...this is keeping me awake at night and I'm starting to get cranky! Thanks in advannce.

[Guest.Visitor]

I'm in Mason Michigan. Just a few miles south of Lansing. Although I do work on other systems, the iSeries is far and above my preference. My normal interactive activity on the system here is between 1000 and 1200 so any problems are noticible by alot of users! We currently have 17 iSeries systems in the U.S. and Canada. I hope to retire before anyone "pulls the plug" on these systems! Thanks again.