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

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

2707.0. "Error drawing lines in local transport?" by PEACHS::BELDIN () Thu May 03 1990 11:52

	A customer running a benchmark program that draws 100k lines
	using XDrawSegments gets the following error:

	X Protocol error detected by server: request length incorrect: internal
	Xlib error

	Failed request major opcode 66 X_PolySegment
	Failed request minor opcode 0 (if applicable)
	Resource 0x0 in failed reguest (if applicable)
	Serial number c(?) failed request 12(?)
	Current serial number in output stram is 

	(this was off a fax, so the (?) indicate what was garbled by the
	 low-res fax)

	Customer was running this via DECNET transport from an Ultrix
	machine (VS3100) to a GPX running VMS 5.2.  Customer also has
	a problem running the program with local transport.

	I have been unable to reproduce this with either local, DECNET, or
	tcp/ip transport on a vs3100 running VMS 5.3-1.  A suggestion was
	made to the customer to limit the number of lines being drawn
	at once.  

	Any ideas on this type of problem?

	Rick Beldin
	CSC/AT

T.R	Title	User	Personal Name	Date	Lines
2707.1		DECWIN::FISHER	Prune Juice: A Warrior's Drink!	`Thu May 03 1990 13:25`	13
	At connection setup, the server tells xlib what the maximum size request it will accept is. Xlib is responsible for breaking up requests such that they never exceed this size. It would appear that the Ultrix xlib is not breaking up the request properly. When you say it fails for the customer on Local, do you mean that it fails running locally on Unix (using Unix domain or something) or do you mean using the local transport from VMS to VMS? Please make sure that this problem gets reported somehow (via SPR or QAR) if it is not resolved quickly. It should not happen. Burns
2707.2	Problem is unrelated to transport	STAR::VATNE	Peter Vatne, VMS Development	`Thu May 03 1990 13:55`	8
	I believe this problem to be unrelated to the transport used. The problem has more to do with the version of DECwindows server being run. I don't remember if there was a problem with a large number of segments being drawn with VMS 5.2. However, from your testing, it sounds like if the customer upgraded to 5.3, the problem may go away. I'll let someone else confirm whether there really was a problem that has now been fixed.
2707.3		GILROY::klee		`Thu May 03 1990 14:44`	6
	UWS2.2 Xlib does break up large XDrawSegments requests. UWS2.1 Xlib may not have, though. I wrote a simple program that draws 100K segments and it works fine using either local or TCP/IP transport (both server and client on Ultrix UWS2.2). Ken
2707.4	More info	PEACHS::BELDIN		`Thu May 03 1990 15:50`	17
	>When you say it fails for the customer on Local, do you mean that it fails >running locally on Unix (using Unix domain or something) or do you mean using >the local transport from VMS to VMS? Talked to customer who described the scenario that he setup: uvax II/gpx running VMS 5.2 displaying to Ultrix workstation. got the errors listed. Also on VAXstation 3100 on VMS 5.3 when running with local transport. Symptom is that window appears and then you can click twice. Once this happens the window disappears. I was unable to reproduce this either on VMS 5.3-1 or VMS 5.3. Rick
2707.5	Yep Xlib bug	STAR::ORGOVAN	Vince Orgovan	`Mon May 07 1990 19:13`	5
	MIT Xlib releases R1, R2, and R3 didn't break up XDrawSegments requests if they were too big to fit within the server's maximum request size. MIT corrected this with R4. On VMS, you could see this problem on releases before VMS V5.3.
2707.6		STAR::KLEINSORGE	Fred Kleinsorge, VMS Development	`Tue May 08 1990 10:29`	6
	Is there a call that the user can find out from Xlib what the biggest size is? So that we don't have to hardcode size limits to work around this. _Fred
2707.7	look inside the Display structure...	GSRC::WEST	Variables don't, Constants aren't	`Tue May 08 1990 12:37`	7
	I don't know of any call but you can look at the element max_request_size in the Display structure. This element is populated by the server at connection time. -=> Jim <=-
2707.8	XMaxRequestSize	TOOLEY::B_WACKER		`Wed May 09 1990 10:50`	1
	Try XMaxRequestSize, new in v2