× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi all,

Does anyone have any tips for managing SMTP jobs that take a lot of CPU? My client has systems in 18 countries that are trying to send messages to/from each other's ERP systems. They are on 12 boxes, all at different levels of OS from V4R3 to V5R2 (yes, I know!!). On the UK box (V5R1) the problem of SMTP jobs taking too much CPU was solved by a PTF, however this has not worked on the other boxes. Or maybe it is still a 'hidden' problem on the UK box, which is rather big compared to the others! Applying latest PTFs has not helped, is there a strategy that will help, such as cleaning out the queues regularly or something??? What do other people do? Is there a software or tool out there that will help? Should they be doing this another way than SMTP???
Grateful for any suggestions,

cheers,

Clare

----- Original Message ----- From: "Peter Levy" <plevy@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, August 15, 2006 7:35 PM
Subject: Re: Reclaim storage question


These days most of the anomalies that RCLSTG uncovers on our systems would be invisible otherwise. They mostly involve objects left in QTEMP after jobs fail in some spectacular fashion. (Also those re-orgs IBM's database files.) As the system and O/S have advanced over the years I've seen fewer and fewer damaged objects, especially since IBM started including batteries to keep main-store from being wiped out so that MI instructions could be completed. That's not to say that such things can't happen anymore, but these days RCLSTG mostly recovers storage on disk that would otherwise have been lost forever.

In our shop we're more suspicious of RCLSTG fouling things up then we are of GO-SAVE-Option-21 completely failing on a damaged object. We don't have operators or a weekend staff so we developed an application that first does a GO-SAVE-Option-21 and then optionally does a RCLSTG (and an IPL when there are PTFs to be applied). We've done a RCLSTG on all of our systems every weekend for 3 1/2 years and we've never had a problem. Only recently we had to stop doing it on one system because the IFS portion of the save was taking 3 hours to complete, but once we resolve this problem we'll start doing RCLSTG again. ----- Original Message ----- From: Dave Snyder
 To: Midrange Systems Technical Discussion
 Sent: Tuesday, August 15, 2006 9:01 AM
 Subject: Reclaim storage question


 Since the reclaim storage question has come up again, I am wondering if
 I need to do another soon. The last one I ran was on a previous box
 (820) and that was on Feb 1, 2004. I have not done one on this new box
 (520). That was on v5r1 and we are now on v5r3. We have had no abnormal
 shutdowns since on this 520.

 We went to this 520 last October so I am not overly concerned about
 running one, but thought I would ask.

 Any guidelines or hints as to how often to run one if things are going
 smooth, as they normally do? Is there are value to watch for a certain
 threshold to trigger one?

 Dave




 ***********************************************
 PRIVILEGED AND CONFIDENTIAL:
This communication, including attachments, is for the exclusive use of the addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
 ***********************************************

-- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
 To post a message email: MIDRANGE-L@xxxxxxxxxxxx
 To subscribe, unsubscribe, or change list options,
 visit: http://lists.midrange.com/mailman/listinfo/midrange-l
 or email: MIDRANGE-L-request@xxxxxxxxxxxx
 Before posting, please take a moment to review the archives
 at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.