Re: Input fails when on key calls function that opens Window.

In article <4sop1m$jre@ns2.aladdin.net>, Dave Ingledew <ingeldew@aladdin.co.uk> writes >Hi all you Informixers. > >I wonder if anybody has any experience of the following and any >possible work round. > >I have recently installed 4gl RDS vers 6.01 UD7 on my SCO machine. >I have previously used vers 4.11 and vers 1.03 without problem and the >operating system seems very stable, in use for 3 to 4 years. > >My problem concerns the use of an input statement, within this is an >ON KEY (F2) statement which calls a lookup function which opens a >window and provides the user with options from which they can select. >Standard stuff, I've done it hundreds of times before without problem >until today. One look up routine on returning, bombs the input >statement. The program just terminates and core dumps. > >I have tried all sorts of things. such as.. > >Stripping the lookup function to it's bare essentials, in the end I >just opened a window sleep 3 and closed it again. This didn't bomb out >immediately on returning but did when I tried to move to other fields >within the input statement. Displaying a form in the window or opening >the window with a form caused it to bomb. > >I've stripped the input statement of everything except the ON KEY >statement and that didn't cure it. I've tried not returning anything >from the lookup but to no avail. > >The only thing that seems to work is to reduce the number of fields in >the input statement. Seven fields seem secure. Eight fields and it >falls over. > >What is even more frustrating is that I use virtually the same input >routine later on in the program and it works with all eight fields. > >If I was using Windows I'd suspect that I'd run out of memeory but >surely Unix doesn't suffer from that. In any case the program is not >that large, 580 lines, 17k tiny by comparison to some of the stuff >I've written in the past. > >I would be most grateful if any body can point me to a solution. I'll >contact Informix next week but I suspect I'll get the usual guff about >sending all the source and a months wait. > >Dave Ingledew ( Very Tired Informix programmer ) > Any chance you could show us the source. I've had some problems with v6.01 of 4GL but 6.02.UC1 (on a clients Pyramid) cured them. 6.03.UC1 is the latest release I've seen although some here mentioned 6.04.??? I've never had any real problems with Informix tech. support but I always supply them with a test program. i.e. spend some time getting a small test program together BEFORE calling them and let the person who logs my call know that I have a test program. I started this after one guy who obviously had had a bad day got a little annoyed that I didn't have one. First time I've heard of an Informix guy sounding a bit annoyed almost thought you guys weren't human.. Now they have caught on that I have a test program they actually see pleased to talk to me. I actually was complemented the other day by a tech support person for the details that I e-mailed them. I never get a months wait 24hrs is about the limit. One time I raised a call whilst one client site when I didn't realise I would be told not to use the phone by a machine room operator on client site. Fortunately I could work around the problem but when I got back to the office a week later and had forgotten all about the call guess who called me at around 10-10:30 in the morning...apparently the support engineer had left messages for me every day all week!!! I think I've learnt one thing about Informix support - you get much better support if you take the time to a) get all the version numbers together that they require:- Informix tool,Engine, UNIX. b) Get a small test case together and document it in a mail message/fax eady to send. THEN raise the support call. Remember Informix support guys are human, try viewing it from their end. They need a way to reproduce the problem or else they can't solve it. You just waste one anothers time if you don't do the above. Also try to have some patience and understanding, take the time to explain things slowly and clearly and clarify what you say until the support engineer understands your problem. DO NOT stop explaining if you think there is any doubt that the engineer has not exactly understood your problem. Remember every new support engineer has to take their first support call and this may be the one - imagine how nervous you'd be with your supervisor monitoring your progress and it's your first day and your trying to make a good impression....or....your mother just died that day....or your dog just died....or whatever.....taking support calls isn't always easy...help the support engineer NOT the other way around...that way you get better support. To all you tired Informix programmers out there - what problems have you had with support?? -- David Williams