I am currently running AREV 3.12 and are considering upgrading to OI. I know that most of you have had to do this at some point in time…Does anyone have any regrets? Anyone have any suggestions? Anyone have any major undocumented features that I need to worry about?

Thanks,

Brian

[email protected]

Did you read and re-read the White Papers on this subject? Expect everything to take at least 4 times as long as in DOS development…

Well we always like to think that with AREV you could get 90% of the functionality in a week and the remaining 10% in 3 weeks. With OI it seems more like 95% in a week and the remaining 5% in 3 months! Depends how completely "Windows" it has to be.

The Sprezzatura Group

World Leaders in all things RevSoft

That's a FACT Jack! Don't forget the infrastructure issues that you have to contend with too. But …. you can get a lot more slick stuff if you're so inclined. Good luck.

Don Miller

C3 Inc.

Hi Brian

I think if my clients knew 2 years ago, what they know now, then they never would have agreed to the conversion. But I think that may have more to do with the company which did the conversion putting their beginner programmers on the job with no plan and no idea.

Building for the function key stuff that AREV does (but OI doesn't do without coding), will take some advance planning and good understanding of commuter and promoted events. There is an opportunity to get some really slick stuff happening in OI with this but it takes planning. Resist the temptation to use event scripts on Form controls. Use promoted/commuters instead.

I would have liked my system to have a single place for input processing, and a single place for read and for write processing so that I could get validation and key processing done more efficiently. I could use a single point of read/write to help trap for 64k overflow problems. I probably would not have used bound forms for anything resembling a transaction. Maybe used as an easy way out for code/lookup tables. But if that had been done better I would need a single form with some nice parameters to reuse the same form for updating all the lookup tables… (The pick programmer speaking here).

You are also need to figure out how you are going to live without a VOC and a TCL and without reports based on TCL "scripts" or "paragraphs". A partial solution I was fond of (I have multiple clients) is a file with keys like client_id~flag_name so that I could look up client specific setup settings or flags in one catch all table. This replaced some of the function of the VOC. The advantage of having the client_id prefix was I could make up separate records for each client and one "release/update" for all the clients but only their flag would get used for them. An old No-idea system that was being used meant that I had to go and manually edit all client setups after I had applied their update. Annoying.

I don't know how you'd replace the scripting/reporting function of the Voc/MD file. Maybe Sprezz's slist would help. And OIPI is a must for standard reports. Try to avoid using Reporter for Adhoc reports, although I don't know what else there is. I wrote a fairly good export tool that allows users to create templates for exporting data to text/comma delimited files and then do their adhoc stuff in MSAccess or MSExcel. They still get me to setup the templates though.

Other tools I wrote or borrowed to facilitate development in OI were

A tool to make and apply application updates

A tool/function to write line(s) of text to a flat file.

A tool to search for text in windows, events and procedure source code

A tool to delete or update a bunch of records/fields based on a select criteria

A tool to report what Dos files are associated with attached tables.

A tool to write to a flat file all programs/scripts associated with a form - I use this to convert my forms from using event scripts to using commuter events.

I probably should have written a better key/record lookup system too. My app currently has several depending what table you want to look up the key for. It is also vaguely annoying that the option/lookup key is different in AREV (F2) to OI (F3).

Also the save report/list to a flat file has to be coded for reports using OIPI and I am not sure that it works/is available with Reporter - I think it isn't. My flat_file tool is very handy for this.

Anyone else want to list what tools they wrote to facilitate their application development?

Or the structures ie Promoted Event/Commuter event stuff? There is a fair bit on the forums about these subjects if you can find it.

Scott, LMS

One more thing

If you use forms bound to tables (you probably will)

Under the form designer database menu options make sure that "co-ordinate with table locks" and "ignore self locks" are checked. They are not by default.

I had problems where programmatic locking and form "locking" were ignoring each other and generally corrupting data, ie if you lock a record in a form, you expect the program to pay attention but it won't necessarily. It is all a flag system, it is possible to write a record programmatically ignoring locks completely. You have to program to check the flags. You also expect the form to pay attention to program locks and I was having trouble with that also.

And if you use the OI checkout, turn the lock entities check box off (default is on). If the person who checks something out goes on holidays or leaves you are going to have a really hard time getting access to the checked out stuff again if it was locked and checked out. There are hacks for this but the whole problem is best avoided.

Scott, LMS

One more thing I forgot.

If you put an edittable on your form, use the properties | more button and set the row limit to -1

This allows you a lot more rows in a table than you otherwise will get, even with the limit set to 0.

I actually wrote a system to page data through some of my edit tables. It still needs some work to be more generic but it is getting there. So my edit table has a prev page button and a next page button and a first and last page button associated with it which allows more data than will fit in the table to be accessed that way. Between the -1 setting and the paging I managed to get the edit table to go from a limit of around 50 rows before data started being eaten by it, to a limit of around 700 rows. Again a bit of planning would have meant that this particular multivalue list would have been converted to single records in their own table, but I still would have needed to display the records through a table. We just didn't anticipate the client insisting on keeping all their obsolete data in the main record. They have a gift for making 64K seem very very small.

Scott, LMS

Scott,

Do you as a developer feel that the conversion is worth all the time and effort?

Brian

Hi Brian

I think since Mike Ruane took a firm interest that things are improving around here, in terms of optimisim about product life and support.

Is converting worth all the time and effort sounds like a philosophical essay question. All I can do is ask you more questions.

Yes it is a lot of time and effort. Doesn't really matter what new platform you choose, conversion costs have to be measured against the gains. And going ahead with no plan and no understanding of your expected outcome is a waste. Also converting because "I want the *same* system with a GUI interface" is probably a waste.

The gains from having no computer system to having a useful custom computer system were quite easy to measure. But what are the gains in going from a custom, useful computer system with a character based interface (eg Dos) to having one with a GUI interface? Would your users benefit from the GUI or not? And I guess at this point I'd want to ask them, and also look at how specialized the users are. Can they/Do they use the system with no training (the gui might be better), or are they highly trained and specialised (the char based system might be better)?

What would your users expect a new system to do? And don't accept "everything the Dos/AREV system does" as an answer. Get specific. What else do they think it should do? (ie web stuff, interface with other databases, reporting, movies whatever). Can the OI platform support all this? Better ask Sprezz this than me, I don't know anything about the web linking that OI can or can't do or what is involved in getting it to interface with other systems. Can you live with the 64K limits? There are pick-like platforms that don't have this limit.

The question I didn't get to ask was - what is the benefit in going from an 8 bit system (AREV Dos) to a 16 bit system (OI) when the op sys is mostly 32 bit going on 64 bit? Will the 16 bit system stay compatible with the Operating System? (so far so good…). I confess a few our clients jumped because they thought y2K would get them. For all that time and effort, how long are things going to last? Imagine spending the price of a house on your effort and having it last 2 years. Can your company afford that? Will the system last longer? How long does it have to last to make good the cost?

I feel that support for legacy systems like AREV and OI may (has) become a self supporting industry. For a while, we all had to have the latest newest computer system, but it seems now that things are plateauing a bit. Many people are getting all that they can use out of computer systems as they are now, and upgrading only seems cosmetic (and expensive). I think the IT world as we know it didn't end at 2000 but it changed and levelled out in some places. I don't think it will stay that way forever, but like cars, there are some very old computer systems out there and I think they could easily last usefully a lot longer.

So I don't know the answer to your question. I can't even answer the question properly about my own system because the cost/benefit was never done. Possibly for a property/tenant/supplier money counting system - a gui doesn't make enough difference. Because there was no plan either, the new system is missing things the old system had, and at the same time, has new function in it that the old system doesn't have. The more bugs I kill, the happier the clients are with the new system.

Scott, LMS

"Do you remember the days at the ole school yard? We used to laugh a lot…". Going from ARev to OI is a bit like leaving school into the unknown world that we have been supposedly trained for. As much as we might want to stay within the safety and security of "the ole school yard", time marches on. Converting is surely inevitable. It's just a matter of how long do you delay it.

If you look at any ARev application, they all look about the same. The menus work the same. F9 works the same. Alt-O works the same. But…

With OI/Windows, the world is your oyster! You can do pretty much anything you want. No two OI apps look the same. You can use any font, any size, any colour, any bitmap pictures to make it look pretty, any background, active buttons, static buttons. You're not confined to much at all. There are a large number of new data entry controls to get used to which simply had no direct equivalent in ARev (Edittables, Heirachical List boxes, Radio Buttons, Check Boxes etc. etc. Then you need to learn how to drive them to do exactly what you want…

Same with reports. You can design graphs (with OIPI), use attractive proportional fonts, lines, company logos etc., etc.

The down side is that somebody has got to program all these new options and facilities.

I assume most of us who have done ARev to OI conversions, or have been using OI for any length of time have developed our own libraries of useful field-tested OI routines for doing all sorts of handy things. I would hate to have start where I did four years ago, not knowing Windows, OI, and not having these library routines available.

My advice would be to get a consultant / developer to at least convert one of your modules for you, so you can at least see what the target is and hopefully acquire some of these prewritten standardised routines useable in any application. There is a section on this website which lists OI developers which you may want to check out. For that matter, I am happy to offer my own humble services for such a task. ([email protected]). I really should get myself listed in the developer section…

Robert

Try [email protected] not [email protected]

As all programmers know, the full stop makes the difference .

Robert,

Fitting to mention Cat Stevens since he did some convertion too. To Islam.

- Oystein -

And .. be sure to look both ways when crossing the street! That's my problem in doing AREV / OI. The choices are limitless, but time is not on my side.

Don M.

Scott ..

Excellent response. Another thing to consider is that it gets increasingly difficult to market DOS-based systems into IT-dominated markets unless there's no good alternative. There are a lot of legacy-based DOS systems out there that have had Windozy shells wrapped around them but are still "green-screen" in the end. My DOS-based custom accounting systems will probably hang around a good long time since there's no big benefit in converting to Win (the users are very comfy with what they've got and are not particularly dying for anything new). However, since most of the infrastructure behind my major product line are hospital-based IS departments, there was an absolute necessity to go Win-app just to maintain my revenue stream. In fact, it is even hard to charge them much for the upgrade. They really cough at having to pay for OI bumps since they already paid for them in AREV. Short arms, deep pockets, etc.

Don Miller

C3 Inc.

Hi Don

One potential client laughed at us for having a 16bit (OI) system. They have/had a really ugly custom PICK system from Dun&Bradstreet that even D&B had given up on. And they seriously considered buying a JD Edwards system, which would cost about twice as much as paying us to port to something contemporary.

Part of the problem is that many of our potential clients are big enough to have their own teams of programmers, although being a bean counting application, they also think they can save money by spending lots on a JDEdwards style system. Same sort of people become SAP customers and spend a lot more on a rabbit-warren system than they would if they built their own, ie the customising of SAP costs nearly the same as building your own, and doesn't save any of the planning, analysis, and process documentation that most of these people want to avoid. Reminds me of the ostrich - head in sand image (and I am sure real ostriches wouldn't do that).

And even when I've seen these bureaucacies make a huge decision to build their own system, their choice of platform (short-lived), and their reasons for choosing it (slick marketing), often elimiate all benefit they might get from choosing to build their own system. Example: Choosing microsoft VB4 and SQL server, might have been a good decision in 1998 but now you'd be looking at the port-conversion over again. All that design and analyis, coding and etc, all repeated, when you really want to keep growing the system you have, and redevelop parts of it, not all of it at once. It's like building a city, then every two to four years, razing it into the ground and building it again. It would be a nice way to add the sewers, then subways, then telecommunications, then security but as with the computer systems, horribly disruptive each time.

I'd like my app to be more like a ship, that will work on any ocean (op sys), in any kind of weather (traffic) so long as the users don't steer it into a rock (format the data drive).

Scott, LMS

View this thread on the forum...