Development tools

Neil,

We've been developing in ProIV for over a dozen years and have had needs to develop a large number of ProIV source code tools that go beyond search and replace. I'm going to divide this list into two sections: Automation tools & work arounds to ProIV issues.

Automation tools:

1) We have a suite of functions that are run whenever a programmer gens a function. They accomplish the following tasks

a) Imbed background wallpaper
Setup the associated help file entries if the function is included in our on-line help file system
c) Audit the fact that a programmer made a change to the function
d) Imbed the required logic that we use for all reports
e) Imbed the logic we use to audit every function that users go into

2) End user tools so that our clients can install their own prx files. We have delved deeply into the area of ftp'ing prx files to clients and having them install them on their test systems and live systems off hours. This is a critical support feature for us.

3) Warning messages for programmers if they have failed to use SELection logic in screens / updates / reports that need it. (This has lead to problems with lost company divisions) Also, warning messages if they are trying to use the clear flag. This may have changed, but it used to be that the ProIV implementation of the clear flag was to try all records for a file in delete mode. This was exceptionally tedious for rebuilding cross-reference files that may have had nearly one million records.

4) Scratch variable assessment tool. Can be run to make sure that all scratch variables are both assigned a value and use that value. (Saves a great deal of time in finding typos)

5) Installation utilities that dynamically create non-existent ProISAM files or Oracle Tables (based on file declaration).

6) End User friendly functions for implementing ProIV security. Our applications have over 4,000 functions. Trying to implement ProIV security with the provided tools is daunting.

7) Work Log control - Our programming environment is increasing linked to our in-house tracking system. We give our programmers access to this database as they are changing functions. This is then linked to tools that let them dynamically create (and ftp) supplements to clients. This process is critical to our version control for supporting clients.

ProIV issue workarounds

1) Automated addition of SQL COMMIT ENDSQL to the end of every screen and update function. (We had a problem with ProIV not committing Oracle database changes at the end of functions.)

2) Automated installation of Infinite Loop Detected logic. (We had problems on Windows platforms with infinite loops. They would eat up 100% of the CPU and grind the system to a halt.)

...

There are other tools as well, but these are some of the major ones. Even if VIP addresses all of the issues that slow down efficiency in the native development (having to assign logic numbers as they are not automatically generated, case insensitive screens, etc.) it would have to allow us to control the consistency of our source code.

Access to the bootstraps has been critical to us in the areas of increasing productivity and creating solutions for ProIV kernel issues. In short, I don't think that I would consider moving to a development platform where I didn't have access to the bootstraps (at this time).

NO

NO

YES (If they don't blow it in the second half)


It would be possible to write a development environment using the VIP API but this would I think be impractical which is why I said no.

The native boostraps that you currently know and love possibly have only a limited life. It would be possible and desirable in the future to sit the VIP bootstraps on alternative data formats which the GEN could read directly.

On the subject of PRO-AIDE (which I have worked on in the past). If there is a desire to have a VIP view that is more PRO-AIDE like it could be developed and 'plugged in'.
Before we decide on such matters it would be better to judge VIP's design with an open mind.

Hmm, apparantly politeness gets you nowhere these days. Must remember to be rude and sarcastic in future if I want a reply from ProIV...

Native, SuperLayer, PRO-AIDE and Developer Studio are all
'Our' environments. To eventually replace them with a single
environment make good business sense.

We are working on both the Kernel and Client to improve quality and provide requested features many of which require
changes to the above even if they do not support a new feature.

The poll does not reflect the general consensus of our customer base representatives which we have worked with over
the last couple of years.

One last point if developing or maintaining your application code is made more cost effective and we provide the runtime functionality that has been requested is this not good for you?

?

So let me get this straight. The opinions of a select group of handpicked sites is a better representation of public consensus than a free public poll.

Same old thing. ProIV is not listening...

You are going to do this whether 'the general consensus' want it or not.

As for 'your' development environments I was not referring to them. I was referring to the others you have not acquired. I was referring to in house editors and some free editors that are knocking around.

There's an excellent business case for having only one development environment - it ensures that PRO-IV get all the money, and that the rest of us have to pay THEM instead of the competition when they want anything doing...

Witness Micros**t's staggering success at restricting proliferation of platforms and how much money it's made Bill Gates. And they only had to break competition law to do it! (Not that I'm suggesting that PRO-IV are breaking any laws, mind you)

Neil, just one question: what's actually WRONG with the bootstraps? They seem to work, and if it aint broke there's no need to fix it, as Uncle Albert used to say. Definitely would be nice to store the code in, say, an RDBMS, but once you have the bootstraps, that's a trivial abstraction to make (just make a set of tables in Oracle, keep the data in there and copy it back to the good old bootstraps when you want to gen everything). And if your claim that they're becoming too complex (what with x-refs to keep in line etc.) is true, then I have a sneaking suspicion that there's a design flaw there somewhere (and then again, if you kept the primary copy in an RDBMS then the x-refs become trivial to maintain, don't they).

Sure, higher level tools which extend the functionality of the base are great. But having solid technical OPEN competition makes a product better (viz Linux, still the fastest growing O/S on the planet) and makes people want to use it. If PRO-IV want to stare at their own navels, try to maximise their income from a dwindling number of customers, then preventing others from developing development environments and useful tools is the right way to go. But I'd still rather be able to evangelise about PRO-IV and what it can do, rather than have to whinge and bitch about the trivial bugs in the RUNTIME development tool that's the only one available when I know that if I only had the source, or even another tool, I'd be able to do something about it! Even huge companies know that there are 3rd parties that are better than their own - Oracle are a good example: their tools are mediocre, but get out there on the net and you'll find some FANTASTIC bits of kit available. Sun own Java, but their tools aint the best around either.

There are LOADS of development tools out here in user land that people use every day - some good and some bad. But PLEASE don't wipe them out at a stroke - it can only alienate your customers and their employees (many of whom are future decision makers for your customers).

Still, I'm looking forward to seeing VIP as I've said several times already. But for goodness' sake don't let PRO-IV make the mistake of assuming that it's good for the rest of us to foist a development environment on us, when often the needs of our businesses demand something else.

Anyway, I'm interested to hear that you haven't actually finalised this API yet. My advice is not to bother, except for tools that keep the x-refs in good order, and some proper documentation of what the variables in the filedefs actually do. The bootstraps are all the API we need - and they're how we get to the REAL functionality that PRO-IV provides. THERE'S NOTHING WRONG WITH THE BOOTSTRAPS except that they're not adequately documented.

Cheers

Dan Shannon

PS I checked the bugfix about GUI height and width in Studio and you're right, it is indeed fixed. Thanks for that.

Yep... That just about says it all

Why restrict things, it can only make things worse.

I cannot understand why the current bootstrap definitions will restrict the growth of PROIV and its functionality..

Just add more fields.

I would hardly call the bootstrap files a complicated piece of structure to understand, Anyone with a bit of PROIV knowledge can understand how they hang together, and if we destroy our development env. because we mess around with the bootstraps then its our fault, just like if I destroy the 1000 or so files and the 1TB of data on our production system, it would be my fault... I'll take the blame.

Rob D

Interesting

We are the only supplier of PROIV licences and development environments (Tell me about others used by more than a couple of sites). We are not a Microsoft, which is one reason for my open dialogues on this forum. We are not a Linux either - last count 17 commercial versions 50 custom freebies with dubious development strategy and support (don't get me wrong I love my dual 800 red hat box at home but I would not deploy a whole one). But we are the best at Kernel/Client/Dev Environment on the planet.

Oracle and most other non compiled language formats provide access to their underlying architecture via an API this is an industry standard approach and is used by ourselves and others to create tools and utilities for these products.

The bootstraps that you know yes are a basic relationship model. But you want to try to push the storage to use OO concepts and some real headaches occur. Even an RDBMS solution is not ideal. Given that XFRES and pointer structures can provide some of this it has lead us to make
a number of significant changes in designing the VIP bootstraps. For example sequences for fields and cycles are no longer used just object references.

An addition of a field would require:-

validation of point of insert
de-duplication of reference
structural insert(with spit and shuffle)
ancillary reference updates for
global calls, maps, logic, global logic updated


The above will happen as part of the VIP API and all source data elements will be exposed.

I do understand developer concerns that they will not be able to write tools etc in this new world but I can assure you that this will be possible. Without second guessing the final design of the API you will probably call global functions with published interfaced that will be responsible for reading/writing source data and triggering procedures that manage affected dependencies.

I posted against Rob's reply my mistake the threads getting
too long.

Glad to see we've found legitimate territory for some religious fervour :-)

I spend almost all my time dealing with large-scale back-end transaction processing, hence my interest in graphical development environments in pretty minimal - I find them of no real benefit in developing non-visual parts of a system.

I accept my perspective may not be typical but for what it's worth I also would prefer to see effort expended on the kernel rather than the developer's interface.

For me, the issue of bootstrap access or its equivalent is simple - the source code I write is the intellectual property of me or my clients and represents a substantial investment. I am not willingly going to use or recommend any tool that would prevent me, hinder me or charge me for processing that source code myself when I need to.

As others have already said, no one toolkit, however comprehensive, can anticipate every tool you might need and I have written many tools that were certainly not regularly required nor would have made sense as part of the 'standard' toolkit. They were nevertheless invaluable at the time.

As a bit of quantification, I would say that my understanding of the traditional bootstrap (which is good and took a long time to acquire) is worth $20,000 to $50,000 per year to me or my clients in time saved (I'm absolutely serious).

Neil is clearly saying there will be an API as a SUBSTITUTE for access to the bootstrap and that 'The API model will be published and will not required non-disclosure etc..'. However Neil has also said 'It would be possible to write a development environment using the VIP API but this would I think be impractical...' which makes me deeply nervous - WHY would it be impractical?

An awful lot of questions keep popping into my head, for example:

1/ Is this API in ProIV (I assume so but I didn't actually see anyone say so)?

2/ Assuming the API is expressed in ProIV, what form will it take. For example will it be global logics, callable functions, kernel LINK calls or even maybe bus/task based?

3/ Will I be able to use the API if I should choose to stick with an older development environment for a while or will it only be usable within VIP?

4/ What database are the bootstraps stored in for v5 and is there any choice about this?

5/ What will the performance of the API be compared to the bootstrap access we use today?

6/ Will v5 be available without VIP or is it a prerequisite (I imagine this is well-understood but I've obviously missed it somewhere)?

7/ Will the API ONLY be available WITH VIP (I'm not clear if that was implied or not)?

8/ Is VIP going to be a chargeable product (or is this still with the bookmakers)?

9/ What organization do the 'HRS' team developing this API actually work for?

10/ Will the API be available free of charge or will it be viewed as a product itself?

11/ Are ProIV committing to always make an up-to-date API (ie: including all 'boot extensions') available in production at the same time as new releases of kernel/VIP are introduced?

12/ Am I correct in thinking existing tools using traditional bootstrap access will NOT work with v5 EVEN if you continued to use only the traditional development environment(s)? In other words, all tools MUST be rewritten to use the API?


I think that's quite enough for one post...

Quote from the National Press...


'After 32 years in space NASA has finally put man on Jupiter. After not receiving a word from the crew for a few heart stopping moments before touchdown the team at Houston became extremely concerned. To everyones relief Captain Mellis was soon back on comms. He stated that he'd 'just been on the internet'.

NASA plans to study the surface of Jupiter seemed to have backfired on them. In the late 90's they discovered the captain was working on a computer virus that could wreak havoc across the civilised world. As the craft was already 29 years from earth they decided nothing could be done unless it returned to earth. It now seems the mad genious on board the craft has completed his mission and is planning to return soon.....'

Sorry Neil, I see now you'd already speculated that the answer to my question 2/ on the form of the interface was to use callable functions.

I think this might partly answer my question on performance of the interface ;-)

I suppose the fact that we're still speculating on the form of the interface might also answer the question whether it will be available in production at the same time as kernel/VIP releases?

PS. I don't know why there's a smiley in the middle of question 11/ but I expect Rob does...!

Yep,

Looks like a problem with my 'Smilies' converter!!!

I'll take a look at it.

Rob D

TVM Rob. BTW I like you much better with with gray skin.