16 replies to this topic

[Bill Loven]

I may get Blasted from some of the old dogs for what I am about to say but here goes.

Hurray, Hurray, Hurray. It has taken me three years, but I finally unpluged our old Green Screen application.

All of our remote sites are now off of unix and are now running Windows Advanced Server with Web Client and are 100% GUI.

Our Main Office is still unix and 100% GUI, but by the end of this year, it to will move to Windows Advanced Server.

With our Main Office on Unix, it to is running Web Client. All of our Development is on Windows Advanced Server and ported to unix.

I built our GUI environment so the User never has to use a mouse if they dont want to. The still have the speed of the Green Screen data entry, but use accelerator keys for all buttons.

.(Period) Enter and /(Slash) Enter have been disabled.

Again, Hurray, Hurray, Hurray.

[Bob Filipiak]

Bill,


Bah


Humbug!



Bob Filipiak


PS> If your users want that, then fine - let them have it.

I prefer - from a programming point green screen.
GUI has too dammed many "options" that are not easy to absorb. (Old dog, new tricks)

[Rob Donovan]

Hi,

Glad to see that you managed to convince your company to do that.

I've had quite a hard time in the past trying to convince companies to spend money to do that.

If its done well, then its just as quick as Green Screen. But you need to think in a different way for GUI... Its not good enough just to turn screens from Green Screen -> GUI, you have to 'redesign them' to make them better and more suited to the GUI way of working.

I still think that coding on the other hand is far quicker in Green Screen (Pro AIDE etc), since there is no good GUI editor out... yet.

Rob D.

[Bill Loven]

Rob, you are correct. We redesigned everything with our user's input. Our main goal is presentation. What does the user need to do their job better and with less effort. No one has lost their job, but productivity is now so high, we are not replacing people when they leave.

Our management reconigzed this and has given us the go ahead. We still have to plan our work and stick to the schedule.

The biggest selling point was training and infrastructure. Most of our user community is young and have grown up in the GUI world. When they first saw our Green Screen app they thought it was a joke.

Training on our Green Screen App would take three to five weeks before they could work alone. That requires two people not being productive.

With our GUI app, training takes about two days.

I have also taken advantage of including various Active X controls.

I sure would like to see some Green Screen App do that.

Have a Great Day.

[Fred Marker]

Congratulations! Sounds like a job well done.

Please keep the Forum posted on your experiences with the Web Client.

Thanks

Fred

[Mike Schoen]

So how exactly did you make the gui apps as fast as greenscreen?
In my experience, even simple things (like @MOD, simple non-paging screens) the responsiveness of the GUI client was not near as fast as greenscreen for things like entering through fields or typing in data.

Is there some secret mystery setting which makes it faster?

[Bill Loven]

I have set all input fields as auto complete. I have also added logic, at different points, that refresh fields that may have caused a file read. I also use, exclusively, memory files and are only written to our data bases when the Ok button is fired. This means I do not have to worry about rollbacks.

Our remote locations are using ProIsam. ProIsam does not have rollbacks so the memory files keep us form having half baked transactions.

The memory files also brevent record locks and add to our speed.

The writes from our memory files to our databases are very fast.

At the main office, we use Oracle.

Now I have seen some GUI apps that were slow, but they were loaded on the client and not run from the server as ProIV does.

We have spent a lot of time tuning our app, normalizing our databases and concentrating on speed. It seeems to have worked.

[Tony Waszkiewicz]

Hi Bill,

I would be interested in knowing of any problems/issues/tips you have found with memory files.

How many concurrent users do you have, are they doing "heavy" processing or data entry, any "heavy" batch jobs?

regards

[Rob Donovan]

Hi Tony,

I've used memory files.

They are very quick compared to ProISAM / Oracle tables to read.

They only problem with them is for some unknown reason the memory that is used for storing records is not released back to the O/S when you delete records.

This means you have to be a bit careful, because you could end up having a large amount of memory 'reserved' for each user, and on large user systems, this could 'eat' into alot of memory.

I did suggest back when 5.0 first introduced memory files, that the memory is given back to the O/S, but they didnt want to do that

Rob D.

[Chris Mackenzie]

They only problem with them is for some unknown reason the memory that is used for storing records is not released back to the O/S when you delete records.

I guess if one P4 mem file record size = 1 o/s pagesize that would
be practical, otherwise not.

[Bill Loven]

Chris, I have about 70 concurrent users at one time on a Unix box with 2 processors and 2Gig of memory for each procrssor.

The only problem I have found with memory files is that the record size is set to the ProIv minimum. I have a record larger than the miminum, I had to split it into two files and but it back together on the write.

May average number of memory files per user is seven.

I will post later on Web Client issues.

[Joseph Bove]

Bill,

Blatant curiousity question:

Getting rid of Green Screen does not necessitate moving to an MS platform. Why did you folks couple the death (or more gently put - the gradual phase out of) green screen with abandoning Unix?

Regards,

Joseph

[Bill Loven]

Joseph, a good queston.

We were a SCO shop. Our remote locations waer on SCO 5 and our main location is on SCO 7. We had to go to SCO 7 becaues SCO 5 did not support Oracle. We did not beleive that SCO was the long term answer. At the time we made the decision to swith to Window Advanced Server, Redhat was not multi processor.

Now I am not a great Windows Fan, but it provides us with access to more consultants than SCO.

Also, most of the purchased software we have seen or bought, only runs on Windows Advanced Server. Moving away from Green Screen to GUI had little to do with moving away from Unix.

Bill.

[Lewis Mccabe]

Bill,

We are VERY interested on your web client issues. On PRO-IV's site they mention that in going the all web client route, you eliminate the need to install and update the PRO-IV client on each PC. This is because it is automatically downloaded if a newer version is encountered. We love the idea and would like all our users (both remote and local) to go this route if web client is robust enough.

Are we there yet?

Thanks.

Lew

[Bill Loven]

Lewis,

I beleve that we are there.

Here are the Good things about Web Client.

1. We no longer have to touch ever computer with a MCF Client update.
2. We can take advantage of Active X controls.
3. All screens have the same interaction with the user as with the MCF Client.
4. A .cab file is used intead of the MFC Client.

Here are some of the bad things about Web Client.

1. We had to change the screen setting to 1024 X 768. Some of our users compalined that it make their window Icons to samll. This prevents the window from having a horizantal scroll bar.
2. Because of the Address Bar, when you launch Web Client, you will have to move your screens up one line.
3. List boxes and paging screens may not fit within the window. We had to adjust the size of these.
4. You will have to spend some time adjusting your font size to make everthing fit.
5. The ProIV error box does not fit within the window. You have to move it with your mouse to close it.
6. You have to logon as administrator to load a new .cab file becaues it has to register the .ocx.

We did all of this while we were determining if this was going to be our long therm strategy and it is.

ProIV is working on changing the way .cab files are loaded that does not require an administrator logon.

The overall response from our user community has been very positive.

HTH
Bill