[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:	VAX and Alpha VMS
Notice:	This is a new VMSnotes, please read note 2.1
Moderator:	VAXAXP::BERNARDO

Created:	Thu Jan 23 1997
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	703
Total number of notes:	3722

352.0. "Workaround to use $SETRWM" by FORAT::PONS () Thu Mar 20 1997 05:48

	Hy all,

	A customer make me the next question???
	He is working with Refection and a graphic application, Decwindows,
	this application use $SETRWM, system service that works OK when was
	invoked from a graphic device like console or VXT, but when use an
	application with Reflection don't work correctly.

	After reduce a program the customer arrive to the next conclusion:

	The problem was present when application call the $SETRWM system service
	application need to return the control when invoke a resource that was 
	not available, don't wait for this resource.

	Somebody know any possible workaround???

	Thank in advance,

	Jordi

T.R Title User Personal
Name Date Lines

352.1 Check For Minimums, Code To Throttle... XDELTA::HOFFMAN Steve, OpenVMS Engineering Thu Mar 20 1997 12:05 19

T.R	Title	User	Personal Name	Date	Lines
352.1	Check For Minimums, Code To Throttle...	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Thu Mar 20 1997 12:05`	19
	The customer should consider setting up the appropriate process quotas for the expected or the peak load, and implementing "throttling" within the application to prevent overrunning the quotas. A simple check can be made at application startup, looking for the expected minimum quotas. The customer will also want to look at asynchronous programming, as it is not clear from your (brief) problem statement if the customer is using a traditional in-line-coding solution, or a solution based on threads or ASTs. One can also look at ways to divide the application up into multiple processes, with the code likely to block divided up away from the code that is less likely to block, or that is most sensitive to being blocked. sys$setrwm is a big hammer, and its setting affects a large variety of system services, RTLs, and underlying libraries. The customer should probably forget they ever saw this service.

   The customer should consider setting up the appropriate process quotas
   for the expected or the peak load, and implementing "throttling" within
   the application to prevent overrunning the quotas.  A simple check can
   be made at application startup, looking for the expected minimum quotas.

   The customer will also want to look at asynchronous programming, as it
   is not clear from your (brief) problem statement if the customer is
   using a traditional in-line-coding solution, or a solution based on
   threads or ASTs.

   One can also look at ways to divide the application up into multiple
   processes, with the code likely to block divided up away from the code
   that is less likely to block, or that is most sensitive to being blocked.

   sys$setrwm is a *big* hammer, and its setting affects a large variety of
   system services, RTLs, and underlying libraries.  The customer should
   probably forget they ever saw this service.