|
It is OPM COBOL.
no there is no record locking issue here, and I have checked the activation group. It is OK.
But one thing, I don't know if this could help:
as we have opened a pool of socket connections, it means that one JOB on the iSeries could be used over and over again, by different users. We have noticed the performance issue starting after 70-80th connection, as if the resources allocated to this job are over the limit, while the CPU is OK, RAM is OK, but as if the resources of this job became limited, causing a performance issue for all users connected to this job. We are sure that a job is used only after the previous user has finished his work, no intersection between jobs.
It is only a possibility, we are not certain of this, but for iSeries experts, maybe it would mean something...
________________________________
De : Imad Moukaddam
Date d'envoi : lundi 19 mai 2014 17:57
À : java400-l@xxxxxxxxxxxx
Objet : Cobol programming issues
Hi
Well this is a difficult one to explain :
We have developed a web application (JAVA) that launches COBOL programs through SOCKET programs. Everything is working just fine.
When we started to increase number of users through a performance tool, we have noticed a strange behavior on the COBOL programs, as they were running very slow (for some transactions, average time was in the range of 10-15 sec.). Upon drilling down, we found that a simple READ statement (COBOL side) is consuming about 110 ms, which is huge comparing to the normal status (average time was less than 1 ms normally)!
We have checked the following:
CPU is OK
Memory is ok
No locks (we are reading PF in OPEN OUTPUT mode)
The hard disk is a data center, known to support heavy usage
Any ideas?
Thanks
Imad
[http://www.sab2i.com/fichiers/20130204105607_ecologie.png] Pensez à l'environnement, n'imprimez ce message que si nécessaire ! Please, consider the environment before printing this email.
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.
As an Amazon Associate we earn from qualifying purchases.
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.