[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

808.0. "Global Sections, Ada, and DECwindows problem" by 35884::LONGNECKER (GSRC, Co Springs, DTN 522-6589) Fri May 19 1989 13:07


  ***** H E L P ***** H E L P ***** H E L P ***** H E L P ***** H E L P *****


                     Apparent Global Section Corruption


     I have a customer who is developing some display software using
DECwindows.  They are also using (or attempting to use) global sections to
communicate with other processes.  The application is written in Ada.
The customer is experiencing corruption of the data in the global section.
I took a look at it and found that (apparently) DECwindows is grabbing P0 space
during initialization for its use and fails to detect that some of it is 
already in use (namely for the global section).

     I took the customer's application and stripped out most of the extraneous
STUFF from the code to provide the smallest subset that still causes the
problem to occur.  The code example is located at

     NAAD::DUA2:[LONGNECKER.PUBLIC]

Included in the directory is a READ_ME.DOC file that talks about how to
build/run the example software.  Please note that this is NOT where I
get my mail....e-mail to GSRC::LONGNECKER.

Oh yes....we're using VMS 5.1 on a VAXstation 3200 (LAVc satellite off of a
microVAX 3600).  Ada version is 1.5-44.  Don't think it matters, but one never
knows.....nothing else about this makes any sense to me, either!!! 

Also, please note that the customer is developing this application as a
prototype demonstration for one of THEIR customers.  The date for the
demo is mid-June, so they're understandably ANXIOUS to have this issue
resolved.


     !!!  THANKS TO ANYBODY WHO CAN SHED SOME LIGHT ON THIS FOR ME!!!

Andy

Government Solutions Resource Center
Colorado Springs, CO


(This note has also been entered in the Ada conference.)

T.R	Title	User	Personal Name	Date	Lines
808.1		PSW::WINALSKI	Paul S. Winalski	`Fri May 19 1989 13:49`	27
	I doubt that this problem has anything to do with Ada, per se. Global sections work just fine in DECwindows applications. I have an application involving three cooperating processes communicating via a 2-MB global sectiion. One of the processes uses DECwindows. I have never seen any data corruption. I don't have the time to rummage through all your sources--could you post the $CRMPSC and/or $MGBLSC calls here? One possibility I can think of: VMS DECwindows by default uses shared memory transport, which is implemented using a global section. If they are initializing DECwindows before their own $CRMPSC call, and if their $CRMPSC call specifies explicit P0 space addresses using the INADR argument, as opposed to mapping the section any old place using the SEC$M_EXPREG bit, then if DECwindows happened to map its section to addresses that overlap the user's INADR address range, the user's section will overmap DECwindows's section and you will see the behavior you observed. If the above is the case, then the problem should go away if the user program does the $CRMPSC or $MGBLSC call before initializing DECwindows. The problem also should not occur if SEC$M_EXPREG is in effect. There's also a flag called SEC$M_NO_OVERMAP, but the description in the system services manual is vague and I'm not sure it's relevant to this problem. --PSW
808.2		QUARK::LIONEL	in the silence just before the dawn	`Fri May 19 1989 14:26`	9
	Also, check to see that none of the data structures you are using to map the shareable image have initial values in the record definition. This would cause each process to reset the structure to the initial values when you map the section. (I presume, without looking at the sources, you are using address representation clauses to cause the association between data structure and global section memory.) Steve
808.3		43248::LESLIE	Andy �� Leslie, CSSE	`Fri May 19 1989 22:25`	8
	If you have a serious customer problem then escalate it. Don't rely upon this notes conference or any other. PLEASE SUBMIT AN SPR - for the sake of your customer! - Andy
808.4	Problem caused by using P1 space	51887::OLAV	Do it in parallel!	`Sun May 21 1989 16:43`	8
	The problem is caused by the user program using P1 space instead of P0 space to allocate the shared memory. The code fragment used comes from an example posted in the VAX Ada conference and is maybe distributed in some course materials. I have posted a warning and given a correct programming example in the Ada conference. Olav
808.5	Ignorance is Bliss	8345::LONGNECKER	GSRC, Co Springs, DTN 522-6589	`Mon May 22 1989 21:07`	11
	The fix provided by Olav in the Ada conference (TURRIS::ADA, note 527.16) did indeed fix the problem I was having. Many thanks. The global section mapping routine was provided to us out of a customer support center, so it's probably in pretty wide-spread use. Note that the actual fix in Olav's SHARED_MEMORY package can be easily applied to the CREATE_AND_MAP_SECTION function, for those of you already using it extensively. Andy