Clearing IPC on iSeries

serenity_now

Active Member
Hi All,

What does everyone do (if anything) to clear IPC Values on the iSeries server? We hadnt restarted or ended JDE services for quite a few months and one users were unable to submit jobs to the iSeries server. They were getting IPC values like the one below:

IPC2100009 - Krnl33466RspQ not created, unable to add resource name to hash table. Please increase the avgResourceNameLength parameter (current value 15) in the JDE.INI file.

I opened a case with Oracle, but they werent a lot of help, pretty much pointing me to a article that says not to change your JDE.ini file.

In this case ending JDE services and clearing IPC did the job. My question is, do people automate this somehow? Do you normally end JDE services once or twice a week and clear IPC? Also, is it true that JDE Services must be ended in order to clear the IPC?

Thanks for any input
 
For me it's as simple as signing on to the iSeries as account ONEWORLD, then menu option 7 after services are stopped.
 

Attachments

  • 155382-ONEWORLD Menu.JPG
    155382-ONEWORLD Menu.JPG
    95.8 KB · Views: 176
My question is, do people automate this somehow? Do you normally end JDE services once or twice a week and clear IPC?

We run a simple CL program every evening that ends services, clears the IPC, and restarts services.
 
On our iSeries we restart the JDE subsystems every night after End of Day processes. In our CL we clear IPC and delete all JDE related SQL packages.
 
[ QUOTE ]
For me it's as simple as signing on to the iSeries as account ONEWORLD, then menu option 7 after services are stopped.

[/ QUOTE ]

Yea, I know I can do this. But how often do you stop services and do this?
 
Does anyone have a sample CL Script that stops services, clears temp packages, clears IPC and starts services? Been looking around and kind find a lot.

Thanks
 
Not often...so it's not that big a deal here. If you're looking for a more frequent occurance, you may consider scripting something...but it sounds like you may have to craft it yourself.
 
Every night before our production backup we end our JDE subsystem and delete all JDE related SQL packages. Once the backup is complete we restart our JDE services. We use 3 different CL commands.
Here is what we use on our iSeries
PGM
CHGLIBL LIBL(B7334SYS QTEMP QGPL)
ENDNET
DLYJOB DLY(180)
CLRIPC
MONMSG MSGID(CPA0701 CPF9999) EXEC(GOTO END)
DLYJOB DLY(60)
END: RETURN
ENDPGM

PGM
GRTOBJAUT OBJ(B7334SYS/R*) OBJTYPE(*SQLPKG) USER(*PUBLIC) AUT(*ALL)
DLTSQLPKG SQLPKG(B7334SYS/R*)
END: RETURN
ENDPGM

PGM
STRNET
DLYJOB DLY(180)
END: RETURN
ENDPGM
 
Hi Randy,

Thank's for the script, my problem was the *SQLPKG was growing very fast (we're running under 8.12, V5R4, TR8.96) lately it was hit my 700G DASD very fast, 5% every three days. I did clean everything according to JDE standard (WRKOBJ *ALL/*ALL *SQLPKG) but the speed of growing was very fast. Any idea was it coming from?

Thank you.
 
My best guess… you have some kind of leak in the query engine. Are you current on all of your database fixpacks?

A couple of expert webinars you should register for:

DB2 for i Autonomic Index Advice - Garbage or Gospel? – IBM’s Mike Cain
https://www1.gotomeeting.com/register/449917945

Accessing Non-Relational Data Using SQL – IBM’s Dan Cruikshank
https://www1.gotomeeting.com/register/379277369

And then there's the DASD issue. The easy way would be with a product...
http://www.s4isystems.com/products/s4idasdplus.html

More cowbell!!
 
Hi Gal,

Thank you for the info, I will try to chew this stuff.

Will be back soon.

Rgds.
 
[ QUOTE ]
Every night before our production backup we end our JDE subsystem and delete all JDE related SQL packages. Once the backup is complete we restart our JDE services. We use 3 different CL commands.
Here is what we use on our iSeries
PGM
CHGLIBL LIBL(B7334SYS QTEMP QGPL)
ENDNET
DLYJOB DLY(180)
CLRIPC
MONMSG MSGID(CPA0701 CPF9999) EXEC(GOTO END)
DLYJOB DLY(60)
END: RETURN
ENDPGM

PGM
GRTOBJAUT OBJ(B7334SYS/R*) OBJTYPE(*SQLPKG) USER(*PUBLIC) AUT(*ALL)
DLTSQLPKG SQLPKG(B7334SYS/R*)
END: RETURN
ENDPGM

PGM
STRNET
DLYJOB DLY(180)
END: RETURN
ENDPGM

[/ QUOTE ]

One thing I would recommend also is to end subsystem QUSRSYS so that all ODBC connections are terminated. If you don't do this, sometime you can't get a lock on the SQLPKGs to delete it because a QZDASOINIT job has it locked. After SQLPKGs are deleted, you can start the subsystem back up.
 
Cha,

I bet QUSRWRK was the intended target.

I strongly recommend that all administrators confirm where there QZASOINIT jobs are running before using that recommendation. I have worked on many systems where ODBC jobs are sent into there own subsystem for management purposes.

-Ethan
 
Back
Top