Where to now

[Peter McMurray]

Rocket has added Python to U2 and D3 come November. Why?

Millenials are now the buyers, users, decision makers in our business. The goal posts have moved and if we do not move then there is a danger of the baby going out with the bath water..

They are looking for Full Stack developers and or people who fit into one of the three major levels.

I said not too long ago that all we needed was FlashBasic and a simple link to the web. Not anymore.

If a person does not know where Python, Flask, Numpy, Pandas fit with the likes of Vue.JS, TypeScript and MySQl and Pick then they are not in the race. Certainly there will be a small market for looking after old sites just as there is a market for maintaining classic cars. If that is one's choice then fine.

Fifty years ago Dick Pick and Don Nelson got together. It is now clear that Dick was considering data storage and Don was interested in Data Retrieval - hindsight is wonderful.

Dick had one brilliant idea. Data stored in Name and Multi-value pairs stored in Name Value Items stored in a sparse array. He was perfectly correct in saying that sub values were a mistake.

Don's requirement was met by a fluid dictionary setup, albeit it is now clear that what he was really thinking of became XML and JSON.

The one issue is that the dictionaries are tied to files when they need to be tied to applications. Yes we fixed that in 1977 when we introduced application dictionaries and file schemas that are now known as Classes. We fitted strict typing in along with what is now known as Single Page Application.

We have to make sure that Dick's magnificent database design does not get lost in the arguments.

Currently we have the failure to recognise that the Microsoft battle fleet has been controlled and now drives in a positive direction that benefits all.

In D3 and U2 we have anachronisms holding things up UTF-8 is the de facto world standard for storage yet we are still messing with UTF-16. 

The VME and Update should have died with the introduction of the FSI. Thank heavens the crazy foot control pedal hardly got started.

Hanging on to XP and the like whilst ignoring the massive benefits of Windows 10 security and Office 365 is not appropriate for people selling in the current market.

It is a consultants duty to provide a sound current offering to a client. In fact in Australia if a consultant is aware of something such as a lack of security and does not inform the client, the client can sue should they suffer loss. 

I would be delighted to hear from people that are successfully integrating the FullStack solution. I am definitely working on the back end right now and paddling furiously to grasp the front.

At the moment it is like selling ice-cream to kids when I ran an ice-cream wagon I swore that nobody needed more than three colours - red, white and chocolate- the plethora of selections was terrifying.

Help in sorting the Stack selection would be great.

[George Gallen]

Do you mean a python class library to access the native U2 files?

 

Other than that, how do you add python to u2? That doesn’t make sense?

I understand supporting json or xml – that’s not a language

 

George

[Tony Gravagno]

I think this is all a lot simpler.

We have a DBMS. It an connect to anything. So just use it.

People seem to think that every new technology that comes along is game changing with respect to the MV world. What's done outside of this box has no relation to this box. Just use the tools designed for each specific purpose without the assumption that any of them are better for integration with the database. There is certainly no detail of stack development which is related to MV internal structures. If you're projecting internal structures to any other tier (reading an item into a middle-tier array and parsing out the @VMs) you're doing it wrong.

We have bindings for Java, .NET, PHP, C++, and other languages. JavaScript runs in the server. .NET runs on Linux and Mac. And now there is more native access via Python. There are also frameworks and stacks suited to deployment in mobile, web services, websites, and thick client UIs. There is a world of opportunity and choice.But all of the bindings in the world aren't going to change how MV people use the platform - or don't. Just use the tools that are available on the front-end, middle-tier, and back-end, build and sell your applications, and thrive as successful business people.

Change is the constant. Plan for change. Accept that there are more than three flavors of ice cream. Adapt. Go with the flow. Recognize that in the rest of the world there is never an expectation that one person is going to maintain an enterprise-scale application all by themselves. Partner with people who do "stack-oriented" development so that you can focus on your core functionality, and marketing and sales efforts.

If you accept the same paradigm as everyone else, and work within it rather then against it, then all of this rhetoric about the wonders of the data model and the genius of its creators will disappear in a puff of irrelevance.

So "Where to now?"

Change the patterns that you've been following for the last few decades that haven't worked.

That answers the immediate question about stacks and languages and everything else that isn't related to this DBMS.

T

[grant...@prosol.co.za]

I think Peter is 100% correct. The world has changed. We have the best data model but are limited to BASIC as the programming environment. Today’s programmers are schooled in Java, C#, Python, JavaScript, Typescript etc.

All other dbms vendors allow development in the above languages. We in MV space have mitigated it somewhat by providing client/server libraries to access our data model but on the server side we are restricted to BASIC (nothing wrong with BASIC but we are a dying breed).

I am very passionate about preserving our data model and the benefits it brings to quickly having ROI on software development. Even today one of worlds largest banking software providers still rely on the MV data model. (Temenos). But I am going off topic.

With the release of version 3 of MVON#, we now have the ability to write sever side MV code in BASIC, C#, JavaScript, Typescript and Python. This means when a BASIC program has CALL XYZ(arg1,arg2). XYY can be written in any of the above languages. There are no wrappers, Interpol or pic calls. All running in the same process.

@Tony, please moderate if this sounds more like an advert.

I would love to discuss the benefits of having server side language support for MV space

[Dick Thiot]

I think that I will throw in my 2 cents.  (Does 2 cents even make sense outside of the US? ;-) )  Grant has articulated the situation well.  We have operated with an attitude that we are somehow superior to those that aren't using MV and everyone should do it "our way".  Our data model is excellent for many situations and being able to interact with MultiValue databases in as many ways as possible makes MultiValue more mainstream.  We need to start using language that promotes the MultiValue database in positive terms and as a partner in the technology world that plays in the big sandbox.

We have connectivity to the database from most environments today yet we lack important features in many of the database flavors like object oriented support.  While I don't think that all MultiValue databases need to support the same features, Rocket has made a big step forward with support for Python for programming the server side.  It is great to see U2, jBASE, OpenQM, MVON# and others make advances to improve support for more than the original functionality of the database.  MultiValue is not a monolithic environment any longer and hasn't been for years.

MultiValue shares many features with other NoSQL databases and it is good that we have that commonality.  We can promote our benefits without being arrogant.  We need an attitude adjustment.

Thanks Grant, Tony, Pete and others who are promoting MultiValue and understanding that while technology is changing, MultiValue platforms are progressing too while maintaining many of the benefits of heritage.

Dick

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Kevin Powick]

On Thursday, 14 June 2018 17:24:37 UTC-4, Peter McMurray wrote:

Rocket has added Python to U2 and D3

Sounds groovy, but try to find any information about this on the Rocket site.  Other than a mention in a blog post, I found it next to impossible.

So much for marketing.

--

Kevin Powick

[Ryengoth]

 

  I've had better turn-around and technical support resolving business process automation and efficiency issues with Progress ABL, OpenEdge while also working within the confinement of the Infor SX.e ERP GUI environment. Frankly, I no longer see the benefit of MV over Progress and in many ways Progress provides a better mechanism for storing and retrieving large masses of world data even if the data is typed by schema. The embedded JSON and SOAP handling in ABL makes a solid case for migrating from MV in my opinion if you feel like re-writing the applications into a larger 4GL framework.

Glen

[Peter McMurray]

Actually George I mean exporting my current file schemas to an appropriate file type for inclusion in a Python, Javascript whatever file layout so that the database is treated as sacrosanct and the next layer can operate safely.

I want to see the data vetting I do in Pick with each value described as a strict object type and included in a strict file layout passed out so that the flamboyant HTML architect can perform their magic.

I still intend to do the CRUD in Pick. I would like to use UTF-8 in Pick Sort and List as it is a drop in for Pick with very minor amendment and the default encoding for languages such as Python.

If anyone doubts the ubiquity of the encoding have a look at your next Google enquiry which I believe is a GET such as

https://www.google.com.au/search?q=pick+database+file+structure&rlz=1C1CHBF_en-GBAU724AU724&oq=Pick+database&aqs=chrome.3.0j69i61j69i60j0l3.11008j0j7&sourceid=chrome&ie=UTF-8 

There have been many discussions about editors ranging from Ed and VI through UPDATE on Pick but now we have TypeScript and say Sublime combined in Visual Studio that is a new Universe of experience. 

The massive benefit being the rigour it brings to the product before it is released to production. If combined with the Pick Database schemas a much better world.

However like the ice cream there are too many choices for the middle and upper tiers which is why I ask for those with current experience to suggest..

[grant...@prosol.co.za]

Hi Peter,

We have just published extensions for Visual Studio Code for the MV market that does code highlighting, formatting, intellisense and linting (syntax checking while editing your code).

Just type MV# in in the extensions search and you can download them,

[Kevin Powick]

I largely agree.

Long ago, when hardware was expensive, interfaces were minimal, and it was just MV vs RDBMS, the choice to use MV was much easier than it is today.  Things have changed.  A lot.

MV systems allow you to prototype minimal systems very quickly, but that's about it.  Adding all the security, auditing, reporting, interface, and interoperability requirements of today's modern business systems makes MV much less competitive than it used to be.  So much so that, today, I doubt I would build a system from scratch with MV technology.

Having said that, I do agree with Tony G. that you *can* get MV to connect to and exchange data with almost any tool/system/thing.  So I wouldn't abandon any MV system that already had a significant investment of resources (time/money) put into it.

--

Kevin Powick

[Dick Thiot]

Awesome!!

[Ryengoth]

If you have the skills you can connect anything to anything. The availability of a tool to do it for you is hardly an argument against or for an environment. There's not much you can't expose and consume as a web service and that has been true for over 15 years.

Glen

[Dick Thiot]

Glen,

You are correct however, I think that many don't understand that MultiValue data can be exposed via web services.  I think in large part we hear so much about MultiValue and how it can't do this or that or the vendors haven't enhanced it or other negative sorts of comments.  I believe that this mostly comes from lack of information.  It is without question that as a market we have not done an effective job of marketing.

Dick

[Tony Gravagno]

I'm confused about the subtopics here. I'll just focus on languages for now.

There are bindings which allow external access to a database via a network/pipe. Every database has these. We've had them for years. These are both for non-MV people to use with MV, and for MV people to use in their professional evolution to develop modern interfaces.

And many databases support various languages as Stored Procedures (SP), in exactly the same way that we use BASIC in MV. SQL Server and Oracle support the CLR. Oracle, DB2, and PostgreSQL support Java SPs and others.

While Python-as-MV-SP is a nice advance, it doesn't buy the traditional MV developer much.

This was implemented to bring new people to develop new MV applications. We must rely on MVDBMS Marketing initiatives to pitch MV via Python to the world. I'm sorry but even my rosey glasses don't allow me to see that happening.

Existing BASIC application developers can bring in new talent to extend their offerings with Python to make them more extensible for other developers. I'm sorry but my glasses aren't so rosey on this topic either. With the extreme DIY disposition of traditional MV devs, I just don't see them striving toward extensibility like that. We've had this opportunity for decades now with external bindings, and it hasn't happened in a big way. I don't imagine people suddenly seeing the light on this topic.

Languages and their positioning in the topology are somewhat irrelevant. What really matters is what you do with the opportunities that are available. If you haven't had a successful rejuvenation and revitalization of your business with .NET, Java, or PHP yet, then chasing yet another paradigm with the same approach to adoption is not going to yield different results.

That's not intended to be a criticism. It's intended to be encouraging. I believe application developers can be successful with true immersion in just about any of these paradigms. I'd really like to see more business owners (MV app devs) throwing their lasso around some toolkit, moving forward, and ultimately publishing a success story. Many companies in our industry have done this. What I don't like to see are end-users who decide their VAR isn't moving as fast as the rest of the world, and taking it upon themselves to modernize what they have or leave the platform entirely.  We see that a LOT.

T

[Tony Gravagno]

Continuing my confusion on this thread, it seems the suitability of MV is also a theme...

As Kevin says, it's tough to justify development of a new app in MV these days. Not just because of the stigma of having an obscure platform, but because of fundamental issues in the current implementations. IMHO, MV is lacking in a few key areas:

1) The database structures are still primitive and limited. Sure, the non-R83 platforms support different file types, and a few platforms support the RDBMS as a backing datastore. But the key/item structures are largely unchanged. We've taken pride over the years in our ability to represent business data more effectively than RDBMS schema. But in my experience that pat on the back isn't earned with almost every new application that I write. Maybe it's just my own incompetence, but I find myself conforming my structures to the abilities of the platform. In particular, nested structures, ala XML and JSON are severely limited. Cheers to Caché where the MV implementation doesn't suffer from this old limitation.

2) Connectivity is always a cludge. Every modern application requires a simple, solid connection to access data. Connect in, do what you need, and get out - as quickly as possible. That process, independent of the business transaction, should not take more than a few milliseconds - like a web server. The MVDBMS providers have been so desperate to persist their persistent licensing that we've had to suffer for over two decades with harsh licensing, and a login/logout/workspace model that makes that connectivity difficult compared to other platforms.

3) Indexing is awful. When I have a number of criteria I want to select and process the records that meet that criteria. I don't want the server to query through every record every time I do this. I don't want to have to index for every possible combination of parameters that a user might want to select on. I do want rapid Unions on multiple lists/indexes so that I can quickly whittle down the result set. This is especially true for date ranges and ranges of numeric values. If we do need to pre-select all combinations like a BI platform, so be it, facilitate that process so that I don't need to reinvent indexing.

What this comes down to (and we've cited this often) is that MV is a great OLTP platform but it's not a great OLAP platform. It's not very resilient at-scale. This compels many of us to consider exporting data into relational environments for reporting and near-line access. It causes us to look for ways to avoid hitting the database. We may advertise that to end-users or not. They're paying for solutions, they often don't care what happens under the covers. We've seen the quote here many times "I sell applications, not a database". That's great. I just wish we could realistically recognize and address the issues that make us non-competitive, rather than forever belaboring how great this platform is that even we are often hesitant to use. With that, we'd be able to sell applications because of the database, not in spite of it.

T

[Ryengoth]

Agreed. Most importantly to me in data mining is an inability to directly compare two fields in a dictionary selection what are indexed. That was one of the first OMG moments dealing with ABL and how flexible and powerful the table use syntax was compared to SELECT and SORT in MV. If I had to start from scratch again I would definitely not go back to D3 and I would be hard pressed to re-consider QM too now.

Glen

--

[Tony Gravagno]

Dick, I think it goes deeper than this. We've had ready access to web services and related information since the late 90's. You've used the phrase "many don't understand" and "we hear... how it can't do this". To be more specific, the blame of poor Marketing must be placed at two tiers, the MVDBMS providers, and application developers.

I'm sure there will be anecdotes to the contrary but I don't recall seeing a single MV app advertised as having an API for user-defined web service access. Compare this to startups these days who wouldn't get caught dead going public without advertising an API and an encouraging developer program. I have never seen an MV app developer announce read or write extensibility to their package as a feature, to encourage end-users to link into the platform for whatever their purpose. I've never seen a MV developer asking about API development, IFTTT, or Zapier.

In the past we saw many lively discussions about SOAP and REST ... but I don't recall anyone actually implementing them and actually talking about it. We saw many discussions about mobile development - but I haven't seen a single developer here rave about their mobile app. And like the OP of this thread ... lots of discussion, again, about stacks and frameworks, lots of information available, but no one actually citing usage of anything that's on the table. (With the exception of the more technical few who do use these technologies, just not with MV.)

So let's be clear here, rather than being vague about who does or does not use the technology. MV developers simply don't use the tools that have been available for a couple decades - and we as an industry continue to lose end-users because of it.

This is not helped by the MVDBMS providers, who do not communicate platform benefits to end-users. They target their "value-add" resellers. The resellers don't communicate possibilities to end-users. End-users then leave the platform to find vendors who have a clue. Our market shrinks. And the MVDBMS providers move on to sell other products because "for some unknown reason" (duh) they're losing license revenue. I understand that communication across tiers in the channel is a sensitive topic. What I present here is an obvious problem that's plagued us for decades with no initiatives to fix it. There needs to be some attempt to fix the problem between doing nothing and what some perceive as an interference of their client/vendor relationships.

If you're concerned about people not knowing about web services, there are easy ways to fix this:

1) Encourage end-users to ask questions of their VARs.

2) Encourage VARs to get the right answers to their clients.

3) Facilitate the process of matching supply with demand. All of these MV companies pretend to have some sort of Partner program but they are, in effect, non-existent.

Keeping on-topic: "Where to now?"  How about a drive to ensure that end-users are fully aware of the strengths of the platform? How about an initiative driven by application providers to seek whatever help they need to provide whatever services their clients seek? How about driving these MVDBMS companies to hire people who are actually familiar with the platform to do their Marketing for the platform. We've seen a revolving door of new names, people who push out the same old email blasts and tweets that mean nothing in the big picture. "We have a new webinar" "We have a new product" That's not the kind of Marketing I'm talking about. That's all nice, and required, but that's maintenance, it's lower-case-M marketing. It's not the kind of capital-M Marketing that we need. It's time to try something different.

T

[Peter McMurray]

Thanks. The topic of marketing has always been a mystery to Pick suppliers - Dick never got it whilst Larry Ellison put a marketer on before the product was out of the door near over the dead body of the programming partners.

Ross Reichardt of MBS gave me the Rocket link

The doc for Python on U2 can be found in the Documentation for U2. Start here: https://docs.rocketsoftware.com/nxt/gateway.dll?f=templates$fn=default.htm, then unfold Rocket U2, then unfold UniVerse, then unfold V11.3.1. In the list of documents, you will see the link to the document on Python called Rocket U2 Python User Guide Version 11.3.1.

Yep impossible to find by normal means.

MV# for Visual Code will definitely be my next chase. Thank You.

As for the existing connections well calling one MVSP and another MVS is not very helpful as MVS does nt display well on laptops. However the lack of samples was the main drawback. When I asked I was told that anyone who knew .Net would understand the docs. Of course that skips the point that that person would not know Pick and vice versa. As others have said we have to eat and is it worth the effort most said no.

But as I said in the beginning the goalposts have moved.

Reports have always been an issue. Simple things no problem but as soon as it gets to analysis then it is into FlashBasic. We wrote a set of select front ends for our oil system. The indexing may be different with Python as I look at the GENERATE command. We shall see. 

[Peter McMurray]

Hi Grant

I think that either I am inexpert or you are ambitious :-) MV# yields no results in extension search or general google. Any ideas?

[grant...@prosol.co.za]

Hi Peter,

There are 2 sections in the marketplace, one for visual studio and one for visual studio code. You must select the code tab and then you will find them

Cheers

[James A]

I agree with most of what Tony said except for this part: "it doesn't buy the traditional MV developer much" (and from another post 'If you have the skills you can connect anything to anything.") ...because to me it seems like there is a significant difference in the way Rocket has implemented Python compared with 'traditional' external access to UV. (and btw I'm not associated with Rocket and have not used the new version of UV yet... I've only read the docs so far).

Because 'The devil's in the details' : and I see the key details as the UV Basic functions pyCallFunction and pyCallMethod; and the Python function 'u2py.call' (and there's lots more.. see below for links to the docs). Basically:

  UV Basic:   pyresult = PyCallFunction(moduleName, functionName[, arg1, arg2, ...])

  Python:   u2py.call("MYSUBROUTINE", "Charlie", None) [, ]

This means the you can start replacing existing functionality; or add new features; IN-LINE with your existing code with NO refactoring of existing code. [IF it all works as I would expect..again, I haven't tried it].

Our 30+ yr old system is a complex and heavily used; generating thousand of sets of loan documents per minute from thousands of customers like Quicken Loans; where we've guaranteed 100% uptime.  With our extensive QA and release cycles, we are months behind releasing even minor changes to our core software.. .. and any significant refactoring would require a major corporate commitment. So being able to drop in Python while changing as little as possible is the only way we'd ever be able to start migrating the core software to a new language. And of course UV programmers are getting harder and harder to find.. and 'modern' programmers do NOT want to learn it. Why would they, when they may stay only a few years and want to improve their 'marketable' skills; not learn a 50 year old language. But millions of them already know Python.. and would be happy to apply their skills to a new domain.

But the game-changing part that no one seems to have mentioned yet is that these calls 'should' enable UV Basic to use Python's 'eval'.. which enables scripting and building DSL's  (Domain Specific Language) ... from within UV BASIC!

So you can have 'code that's stored as data': scripts that can be entered into data-entry screens by users or support staff; and executed 'live'. And you can pre-load the Python environment with all the relevant transaction data and functions.... building on all the existing Python libraries to give the users all the 'domain' functionality they need while using simple and easy to learn Python syntax.

30 years ago I built our first home-grown 'scripting' language that our Customer Service and Compliance staff use to change the functionality of the system 'on the fly'; so while releasing UV/Java/Javascript code in our environment is 'major motion', these scripted expressions can be added and updated 'live'... as in 'while the customer is on the phone'.

For example, they can enable one of our 100,000 forms to print for a particular type of loan with an expression based on the loan data; for example 'if it's over the conforming limit, and is in Arizona, and the Loan to Value is over 90% or there's no Mortgage Insurance' (I won't put the actual code here..for one thing, it's proprietary.. as well as being virtually unreadable to the 'uninitiated'..;). Some of these expression do loops; call function libraries; 'translate' to other files/data; etc.

There are over 200,000 of these 'snippets' of code in a kludgy language that's currently interpreted in UV basic; so it's slow and cumbersome; and there's a high learning curve with fewer and fewer people who understand the system. (though to be fair, many of those are just simple calls to the core 'RULE's file: those are the more complex scripts; but there are still 2,300 of those).

With this new UV integration, these could be migrated one by one to Python... as well as adding more scripting to other parts of the system; with the function libraries being maintained by 'real' Python programmers; and 'business analyst' types using those functions to solve customer issues 'live on the phone'.

This type of thing could not be done with the typical 'call into UV' technologies without redesigning the entire system... which again, is not an option in our case.

- James Adrig; DocMagic

btw: googling 'universe python rocketsoftware' the first 2 hits are:

   https://docs.rocketsoftware.com/nxt/gateway.dll/RKBnew20/universe/v11.3.1/universe_u2pythonuserguide_v1131.pdf

   http://www.rocketsoftware.com/resource/rocket-universe-and-python

[Tony Gravagno]

Glen, did you see my ComparativeAQL update thread?  I haven't tried indexing, but now that you mention it, I'll bet that the dict items that it generates can be indexed. Wow, that would solve some of my challenges too. My guess is that the generated ADI would be indexed, and along with it the definitions that are referenced by that ADI. On one hand I don't have a lot of confidence that file updates would bubble up into index updates with these complex correlatives. On the other hand I can't cite a specific reason why that should not work other than prior disappointment with complex usage of the tools. (Things always work as advertised, until you actually start using them in combination with other things and then the fragile nature of the tools become apparent.

I'll test it, but if Rocket took the initiative to check that out too, it could be a huge win for them.

Thanks.

T

On Friday, June 15, 2018 at 4:16:40 PM UTC-7, GlenB wrote:

Agreed. Most importantly to me in data mining is an inability to directly compare two fields in a dictionary selection what are indexed. That was one of the first OMG moments dealing with ABL....

[Ryengoth]

 Tony, I did not see that. That would be a huge code savings as well as run-time savings if the indexing worked inherently as well. I can't count how many times I've had to store data temporarily to perform column-comparison filtering that should have been supported in the database tools already using the SELECT facility.

Glen

--

[Peter McMurray]

Thanks James for an excellent write up. 

I believe that the better Google result probably came from representations from Ross it sure got lost initially.

The bit that concerns me is

"In Python 3.0 and later, string data is stored as Unicode characters."

I sometimes wonder if the writers have a clue what they are talking about as that is akin to saying we store vegetables, send us a carrot and you may get a swede or a potato back.

Unicode is not a storage mechanism. I will do a separate thread as I have been explaining it for nigh on 10 years and still find these silly statements.

I am looking forward with great interest to the D3 release.

[Grant H]

I suppose when we have a hammer, every problem is a nail. Having a full stack language support now gives us a toolbox full of tools.

As an example, JSON is the standard today in transporting data between applications and systems. I bet every MV IT department have got the request "We need to send the Contract information in JSON format".

The best language to use for JSON is obviously JavaScript. In MVON # this how we would combine appropriate language services to give us the result.

A bit of JavaScript code in a BP File

>CT BP ToJson.js
     ToJson.js
0001 class Contract {
0002     constructor(contractId, name, duration, startDate) {
0003         this.ContractId = contractId;
0004         this.Name = name;
0005         this.Duration = duration;
0006         this.StartDate = startDate;
0007     }
0008 }
0009 function CreateJson(contractId, fileVar, jsonString) {
0010     record = new DynamicArray("")
0011     startdate = new DynamicArray("");
0012     if (Functions.READ(fileVar, contractId, record, new DynamicArray(-1), false, false, false) == false) {
0013         arg2 = ""
0014     }
0015     startDate = Functions.OCONV(new DynamicArray(record.getAttribute(37)), new DynamicArray("D4-"))
0016     contract = new Contract(contractId.ToString(), record.getAttribute(36), Number(record.getAttribute(20)), startDate.ToString())
0017     arg2 = JSON.stringify(contract)
0018 }

It has a class and a function. A File Variable is passed as an argument to JavaScript function. It READS the record, does an OCONV on a date, populates the class and returns the JSON result.

We CATALOG it so we can call it directly from BASIC 

>CATALOG BP ToJson.js Function CreateJson
ToJson.CreateJson Cataloged
>

And some simple BASIC code to OPEN the file and call the JavaScript Function

>CT BP TEST
     TEST
0001      OPEN "","CONTRACT" to fileVar else STOP 201 , "CONTRACT"
0002      CALL ToJson.CreateJson("000001",fileVar,json)
0003      CRT json

And run the code.

>RUN BP TEST
{"ContractId":"000001","Name":"TOM AND JERRY","Duration":59,"StartDate":"02-02-1993"}
>

Seamless integration with a full language stack.

[GrantH]

When you have a hammer, every problem is a nail! The reality today is there is so many ways to achieve the same end result but not all of them are the best/correct solution. Take JSON for instance. JSON has become the flavor for moving typed data between applications and processes. Obviously the best solution to produce JSON would be in javascript. 

Problem definition: My CONTRACT data is in my MV ERP system. I need to send details in a JSON format to another system. I could hand craft some BASIC code to produce the right JSON format and content or in MVON# we would use the best tool for the job. Here is some javascript code in a BP file

>CT BP ToJson.js
     ToJson.js
0001 class Contract{
0002

0003     constructor(contractId,name,duration,startDate)
0004     {
0005         this.ContractId = contractId;
0006         this.Name = name;
0007         this.Duration = duration;
0008         this.StartDate = startDate;
0009     }
0010 }
0011 function CreateJson(contractId,fileVar,jsonString)
0012 {
0013     record = new DynamicArray("")
0014     minus1 = new DynamicArray(-1)
0015     startdate = new DynamicArray("");
0016     if (Functions.READ(fileVar, contractId, record, minus1, false, false, false) == false) {
0017         arg2 = ""
0018     }
0019     startDate = Functions.OCONV(new DynamicArray(record.getAttribute(37)),new DynamicArray("D4-"))
0020     contract = new Contract(contractId.ToString(),record.getAttribute(36),Number(record.getAttribute(20)),startDate
.ToString())
0021     arg2 = JSON.stringify(contract)
0022 }

We catalog the function so that we can call it from BASIC

>CATALOG BP ToJson.js Function CreateJson
ToJson.CreateJson Cataloged
>

A small piece of BASIC code to open a file, pass the contract number and fileVariable to the javascript routine.

>CT BP TEST
     TEST
0001 OPEN "","CONTRACT" to fileVar else STOP 201 , "CONTRACT"
0002 CALL ToJson.CreateJson("000001",fileVar,json)
0003 CRT json

>RUN BP TEST
{"ContractId":"000001","Name":"TOM AND JERRY","Duration":59,"StartDate":"02-02-1993"}
>

This is an example how we can start to use a full stack of language support to meet our end goal

On Thursday, June 14, 2018 at 11:24:37 PM UTC+2, Peter McMurray wrote:

[grant...@prosol.co.za]

Hi Peter,

Don’t know if I highjacked you post with the last reply to your thread. I thought I was talking exactly to your point. If I am mistaken, I will start a new thread. Tony posted a new thread about “when to start a new thread” and I do apologies if I went off topic

Cheers

[Andrew Cole]

Before I go into my comments on the subject, I want to give a little background so I have a disclaimer. I'm currently 28 and have been involved with MV for 6 years. At work we use mvBase (d3's neglected little brother) so some of my complaints may be due to my exposure to a more obscure platform. But I would imagine this thread is directed at the...uh...problem of my generation.

1. Licensing. The licensing is atrocious. When I'm working with mySQL or Microsoft SQL, licensing is not a concern. You query the database, manipulate the data and maybe save it back. It's hard to use MVDBMS in that way with the licensing that I'm used to. Mostly because we have other users who are logged on using terminal apps in PICK/BASIC. Are there even any fully open source platforms out there? When I was learning SQL I could download and install mySQL and play with it on my own. No contacting Rocket/Zumasys/someone else to get a demo version. I could just download a version of mySQL and just experiment. Hiding behind a closed wall will not bring new people to the platform.

2. Connectivity. Trying to connect to MVDBMS is way more complicated than what most younger devs are used to. For us at work, we use MVSP but that requires an open (licensed) connection. I currently have a system in place that pools connections and I put requests through my homebrew API. Recently in my research I've noticed that d3, mvBase, and jBase have RESTful interfaces; others may too but I only know of those. It would be fantastic if there could be some sort of connectivity standard (yes I'm in dream land). I can hop from mySQL to postgre to Microsoft SQL and feel fairly comfortable in all of them due to SQL being the base and the major languages (PHP,Java,.NET,etc) have connectors for those dbs. In a dream world it would be nice for the major players to figure out a standardized connectivity solution. IMO, without an easy way to connect to the DB and manipulate the data from outside of PICK/BASIC the new kids won't want to mess with it.

3. Limitations in PICK/BASIC. If connectivity can't be fixed, there are some serious drawbacks to PICK/BASIC that need addressed. It's super simple, fast, and has a certain elegance to it. But that does not help the fact that when I'm programming in it I feel like I'm in a straight jacket. No OOP, can't create socket connections(maybe flashconnect does this?), no camelCase, and lack of a decent IDE. There's probably more I could come up with given more time but those are the biggest ones. I learned programming on Java so OOP is big for me. Lack of creating socket connections drives me through the roof. Having to program in all CAPS makes programs so much harder to read for me. I use wED for an editor and that's helped more than I can properly communicate. My first PC was Windows 98, so ED is like a foreign world. When I'm editing files in linux I use nano which blows ED out of the water as far as terminal editors are concerned. jBase's JED editor is nice as well. People my age are used to programming on IDE's with syntax highlighting, autocomplete, and being able to use a mouse. I can honestly say without us switching to Accuterm and wED I would still be railing pretty hard to move off of MVDBS. On a side note, I'm not a fan of BASIC syntax but I would be much more comfortable with it if I could use it lowercase like in VB. I much prefer syntax similar to Java and C#. OH and GOTOs. I wish wish wish I could get the other dev I work with to stop abusing GOTOs. But that's a different topic entirely.

4. Tapes...I'm still not fully up on tapes. They seem so foreign to me. I understand the concepts from history. But I laugh every time I do a T-REW. Why, in 2018 am I rewinding a virtual tape?

5. Print spoolers. Printing in any language is a pain in the butt. I find mvBase's print spooler to be a bigger pain than most though.

6. A proper way to view data graphically a la phpMyAdmin, mySQL Workbench, Oracle's tool whose name escapes me, etc.

I think that's all for now. I'm probably missing some things but that's what I've got right now. Please remember I'm still a n00b compared to most of you guys around here with 30+ years of MVDBMS experience. My intent is not to dump on MV but to help improve it. There's a certain simplicity that RDBMS do not have. I also would not be surprised if some of the problems I listed above have solutions that I'm not aware of and I would love to learn about them!

[Brian Speirs]

Hi Andrew,

Good to see you here. We need more new participants! :-)

Some comments:

There is an OpenSource version of OpenQM (and a fork of it named ScarletDME). However, it is 10-12 years old, and missing many features found in the commercial version of OpenQM.

Interfaces. Yes - everyone has their own ...

It is a long time since I used mvBASE, but if I recall correctly, mvBASE allowed variables to be in any case. It is only the keywords that need to be upper case. Watch out though - the variables are case sensitive, so 'temp' is different from Temp, which is different from 'TEMP'. Some of the behaviour of mvBASE is controlled by system switches - one of which was supposed to make the language case insensitive. It didn't work when I tried it ...

OOP is available in OpenQM, and probably in MVON#, but I wouldn't expect it elsewhere. On the other hand, OpenQM and Rocket U2 all have Python interfaces, and so you could do your OOP there (or in any other language supported by the interfaces).

Tapes - well we used VTF's when we used mvBASE, but we could have just written direct to the file system and bypassed them. That would still be a sequential read/write though.

Printing - we print everything via Excel these days, and haven't used the UV spooler at all. We were heading that way even when we were on mvBASE.

Feel free to ask questions in this forum - you will (mostly) get helpful answers!

Regards,

Brian Speirs

[Patrick Payne]

Actually jBase 5.7 now has Dynamic Objects which adds javascript inspired objects and some basic method capabilities.  Here is a link showing some examples.  https://jbase.helpjuice.com/30301-jbase/dynamic-objects-tour?from_search=24677346

At Zumasys we are very committed to connectivity and have been pushing open style Restful services for a few years now.  The new object syntax is a key component of this strategy. Our strategy is to not only emulate the other pick platforms but also improve the platform in many of the areas you are showing concern.

Example (yes this is basic code)

001     program tour
002     $option jabba    ;* this line is not needed if the file's extension is .jabba
003     equ beautify to 1
004
005     obj1 = new object("Tour")
006     obj1->name = "Socrates"
007     obj1->city = "Athens"
008
009     crt obj1->name : " lived in " : obj1->city : "."
010
011     json = obj1->$tojson()
012     crt
013     crt "Our object in JSON representation is: ":json
014     crt "Our object, when formatted, is:"
015     crt obj1->$tojson(beautify)
016
017     crt
018     crt "Our object has ":obj1->$size():" properties."
019
020     obj1->sum1(2,4)
021
022     result = obj1->sum2(obj1->sum, 6)
023
024     total = obj1->sum3(1001,2002,345,999,876,555)
025     crt "After calling sum3() the result is: ":oconv(total, "md0,")
026
027     crt
028     crt obj1->$dump(1)

001     method Tour::sum1(addend1, addend2)
002     this->sum = addend1 + addend2
003     end method
004
005     method Tour::sum2(value1, value2)
006     return value1 + value2
007     end method
008
009     method Tour::sum3()
010     result = 0
011 * Create an object that can handle each parameter, 1 at a time
011     varg = new object("$vararg")
013     print "Method Tour::sum3() was passed ":varg->size():" parameters"
014     loop while varg->size() do
015         result += varg->next() ;* Get next argument and decrement varg->size()
016     repeat
017     return result
018     end method

[Martyn]

Hi Andrew,

 

It is good to hear from younger people working in the MultiValue community.  I’m an account manager for Revelation Software in the UK and unfortunately not technical enough to give a detailed reply here.  That said, if you want to contact me through www.revsoft.co.uk and let me know where you are based, I’ll gladly ask for one of the technical guys to have a chat with you about OpenInsight (OI).  The OI10 toolset supports most of the main MV technologies (including mvBase through the dedicated OI4D3 Data Connector, so getting the benefit from the IDE would not necessarily mean a move away from your database.

 

1.      Licensing is always going to be a consideration.  However, Revelation provide an evaluation copy of the toolset which is available for download from www.revealtion.com at any time, you don’t need to ask for a copy to be provided to you manually or sit through any sales demos to get a copy.  The evaluation also comes with 30 days free support, so you can address any concerns before deciding to purchase a license.

When it comes to licensing, we have numerous options starting from £55.00 (plus £11.00) per annum for a single user OI4MV Network User License (drops to £15.80 and £3.16) for multi-server licenses of 150 or more users).  The OI4SQL, OI4MVS and OI4Cloud, don’t come with a backend database, but enable you to simply plug into your own backend database and utilise the power of OI’s IDE.

If you want a database included, then we have licensing options for our own Linear Hash database and then we have OI WORKS for developers which bundles support, upgrades and the ability to maintained deployed systems.

Yes, we have a paid licensing model which you will have to think about, but this is what keeps us in business and supporting our global client base.  The difference is that we have options and it is all concurrent user based, so it is efficient and cost effective.

2.      OpenInsight is highly connectable and we have clients interfacing with things via all sorts of methods, including web services and RevCAPI which is OpenInsight’s connection API.  The technical guys will be happy to discuss your specific goals and recommend appropriate approaches.

3.      OpenInsight’s coding language is BASIC based but optimised for modern Windows and Web programming.  It is easy to learn, quick to develop in and we often have SQL based developers come on our training courses and workshops and express how much easier things are in OI, compared to some of the other RDBMS available.

We also have a dedicated socket server (OESocketServer which is fully documented in its own manual) for managing socket based work and the built in Editor supports upper and lower case, syntax prompting, user configurable coloured coding of your code and more to make coding as easy and pleasant as possible.

The new IDE in OI 10 is much more intuitive with hundreds of properties exposed and functionality to help remove much of the code that other systems require.  OI’s Quick Events (no code events) make building systems super easy and fast and they have been extended in OI10, for even greater flexibility.

I’ve never fully understood OOP myself, but I was once told that we are very OO based with our methods and <something> else translating to OO.  Sorry, I’m not knowledgeable enough to explain more.

I think that you would like much of what OI has to offer with regards to the IDE, reporting tools and coding (and debugging) tools.

4.      Sorry, I have no concept of tapes.  I have written my own contact manager in OI and several other small systems for local clubs and my own demos, but I’ve never come across the concept of using tapes or virtual tapes in OI.

5.      OI uses the Windows Print Manager, so printing is not usually an issue in OI.  I’ve certainly never had any problems.  Design the report, run it, print it – it really should always be that easy.

6.      I’m not sure exactly what you are looking for here, but we have the System Editor which can open records and you can view the raw data and drill down through things.  This enables developers to see what data is held in what position and using which delimiters.  We also have the ability to chart data and Revelation has used this in the Management Console to produce system statistics for DB Admins.  We also have a client that used OIPI to programmatically build a report featuring complex polygons that mapped the data in a wonderful way to address a business issue.

Most of the time in OI, it is a case of simply understanding the business requirement and talking to one of our support people / consultant developers to find the best solution.  I can talk from experience that the support here is extremely good and you only usually have to ask once.  If you have to ask twice in my region, you ask me the second time and I ‘will’ find you some answers.

 

 

With regards to support and getting answers, most of the time in OI, it is a case of simply understanding the business requirement and talking to one of our support people / consultant developers to find the best solution.  I can talk from experience, that the support here is extremely good and you only usually have to ask once.  If you have to ask twice in my region, you ask me the second time and I ‘will’ find you some answers.

Sorry for the long reply, but I'm pretty passionate about MultiValue,
Martyn.

[Wols Lists]

On 21/06/18 00:48, Andrew Cole wrote:
> 5. Print spoolers. Printing in any language is a pain in the butt. I
> find mvBase's print spooler to be a bigger pain than most though.

I'm afraid that's a characteristic of nearly all modern printers. The
days of printers that you just send text to and it prints are pretty
much dead and gone.

It wasn't helped by GDI printers - cheap printers expect to receive a
bitmap, but the more expensive ones now expect to receive postscript or pdf.

SOMEBODY has the grief of writing a driver, that provides a library. If
you want to be cross-platform, that means you need to write the driver.
If you're only targeting one platform, you can get away with the library
API of someone else's driver. But even that is horribly complicated now ...

In a previous life, I had a user that generated a printout, scanned it,
and emailed the printout. I modified the program to spew the printout
into the hold file as postscript, where she could run Acrobat over it to
generate a pdf for mailing. If you want to do ANYTHING fancy you're
going to have to jump through hoops like that, and it's not just Pick
that suffers. We've just been landed with producing a newsletter, and
the havoc that using Word causes trying to get things right ...

Cheers,
Wol

[Ian Harper]

On Wednesday, June 20, 2018 at 4:48:18 PM UTC-7, Andrew Cole wrote:

1. Licensing.

2. Connectivity.

3. Limitations in PICK/BASIC.

 

Word. These are valid and serious criticisms of the MV world. I think all of the DBMS providers need to start working to correct them.

Off Topic:

When I'm editing files in linux I use nano which blows ED out of the water...

Have you heard of Micro? It's a drop in replacement for nano on Linux. I just discovered it recently and I love it.

[geneb]

On Wed, 20 Jun 2018, Brian Speirs wrote:

> Hi Andrew,
>
> Good to see you here. We need more new participants! :-)
>
> Some comments:
>
> There is an OpenSource version of OpenQM (and a fork of it named
> ScarletDME). However, it is 10-12 years old, and missing many features
> found in the commercial version of OpenQM.
>

I'm pretty sure the commercial version of OpenQM allows free use of a
single-seat instance.

> It is a long time since I used mvBASE, but if I recall correctly, mvBASE
> allowed variables to be in any case. It is only the keywords that need to
> be upper case. Watch out though - the variables are case sensitive, so
> 'temp' is different from Temp, which is different from 'TEMP'. Some of the
> behaviour of mvBASE is controlled by system switches - one of which was
> supposed to make the language case insensitive. It didn't work when I tried
> it ...
>

I don't know about mvBase, but I know in d3 if you use "compile" instead
of "basic", you can used mixed/lower/upper for everything.

It may also be a d3-ism, but you can actually access raw sockets and other
C functions via FlashBASIC - Look in the mvBase docs to see if there's
things prefixed with "%" like "%fopen", etc.

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

[Andrew Cole]

Brian - You are right, it seems I can create variables with camelCase in mvBase. I'm assuming that's "new". I don't remember being able to do that before we started keeping up with the upgrades. Until a couple years ago we were still using v1.3. Printing with excel? 

Patrick - We're actually evaluating the possibility to switching over to jBase and I've been impressed with the objects! It still seems like it's in its infancy (which it is...) but from the talks I've had with guys at Zumasys, I'm really impressed with what they're doing to further jBase.

Wol - Yeah, like I said, it's a pain in the butt for everyone. It just seems like more of a pain in mvBase. It could be just a personal problem I have too! haha

Alright, to another issue that I've remembered since my previous post. Soooo 7?

Community/Online resources. I want to say I'm really impressed with this Google group so far. I'm glad I've stumbled upon it. Part of MV being mostly locked into these "pay-to-play" structures is the lack of community support. When I was learning Java, .NET, PHP, mySQL and anything else I'm forgetting, I was searching the web for all my answers. "how do I do x/y/z" and 90% of the time I found myself at stackoverflow finding out exactly what I needed or getting inspiration for something else. Finding information the past 6 years on MV (nevermind mvBase) has been incredibly difficult. If I can't quite remember how to do a complicated SQL query, I can look it up in under a minute. If I can't form an...AQL(?) query, I'm screwed. I have no easy resources. I still don't know how to do a SELECT file IF attr1 value2 "something". Rocket's and Zumasys' documentation is ok but not great. I know Rocket had a forum for awhile but that was pretty useless in my opinion. Most threads seem to end with "call support" nor were most of the threads regarding basic topics. So, call support threads offered no solution which is super frustrating when you find your exact problem and see no resolution. Regarding the topics being more high level, I understand as most PICK guys are at a higher level than I am and know the basics. But it leaves a kind of hole in the easily obtainable knowledgebase. Now as a side note, all of my dealings with both Rocket and Zumasys support teams has been fantastic. I always get the problems I'm having resolved quickly. The downside is, no one else can learn from the problem I've had as it's been through a closed support case.

Oh one more. Aesthetics. Yes this is minor but first impressions do make a difference. When someone my age or younger comes into a job and they see programs that look like they haven't been updated in 20 years, it tends to either scare or disgust us. I'm not talking about the terminal interfaces. I'm talking about the icons and menus in various programs but I'm mostly referring to mvTerm and mvBase's Windows control panel as that's my experience. They both look like they were designed in Windows 98. As a younger developer, I see that and immediately think, oh great, this thing is old and probably hasn't been updated since I was a kid. So we start off with that negative "attitude" towards the technology as a whole despite the tech running behind it being completely fine. To Zumasys' credit though, Accuterm's recent facelift has been fantastic. So I get that it works as is, but this is more of a marketing concept I suppose. Don't start with "oh look an old probably near obsolete program" when it's fairly simple to make it look modern with some flashy icons. I've always used this metaphor when talking to devs who don't care about aesthetics. If you were in the market for a new home and you walked in to a house that was exactly what you wanted but was missing all of the trim, carpet, and was not painted would you instantly want it? Most people would ask their realtor why are you showing me this incomplete house? They would respond "it's got good bones and it works as a house. Keeps the weather out and keeps you warm. What do you care how it looks?". So yes, this is a minor point but I want other people my age starting with the right first impressions.

[Dick Thiot]

Andrew,

It's too bad that you work on mvBase.  While it is a great Pick system it is the version of MultiValue database that has seen the least advancements in the last several years.  A number of the database vendors are working hard to had modernization features to their products.  However, I also see many MultiValue applications that have run without on-going investment for even decades and now many of those sites are faced with significant tasks to modernize.

Your points are definitely appropriate and valid.  Thanks for putting them out there.  Good job.

Dick

[Steve Trimble]

Andrew:

you also need to take a serious look at QM. and run it on Linux. it will run on just about anything, even a USB stick. (really great stuff) I've done several conversions from mvBASE to QM. wasn't too bad. depends on how much your applications rely on DICT items. they can be different / difficult. the support is outstanding. I think the price per seat is $150 ea which includes 10 years of support and a AccuTerm license!!

and if you're wanting to integrate the web with mvBASE or QM, take a look at Coyote from EasyCo.

feel free to call and chat.

great to have you on board!

Computerized Data Mgmt Inc
Steve Trimble
(501) 615-8674 office

(501) 772-3450 cell / text

cdm...@gmail.com

On Thu, Jun 21, 2018 at 7:47 PM Andrew Cole <andrew...@gmail.com> wrote:

[Tony Gravagno]

Andrew - welcome to the party.

All of the points you've made have been voiced before, many times by myself. They're all valid points, but let's put some of it into perspective just to understand the ecosystem.

You find yourself working with an older mvBase system. That may not be for lack of innovations that have come over time. More likely, it could be because your company decided to stop paying support fees for a system that never broke down. So now they don't have support or upgrades, very little new information from the industry, and it seems like everything is limited to whatever is available some 20+ years ago. In this ironic scenario the stability of the platform also eventually leads to its demise.

You could also have a "value-add" reseller, aka, someone getting a commission for keeping your company in the dark ages. This scenario is also common. Many Pick resellers aren't techologists. They're average guys who knew their business well (widgets, services, whatever), found this cool thing called MVBASIC, and they decided this was their vehicle to a new career. But to a differing degree with everyone, technology can be a passion or it can be a threat, something to be embraced or something to be shunned. The label "value-add" is generously given to anyone who has created a business application for sale to new end-users. That's value to the upline DBMS provider but the degree of value to the end-users differs in many ways.

The problem with that scenario is that the end-users often don't have an IT department of their own. They look to these vendors as their Information Technology consultants. Oops. The VAR will provide excellent support for the application, but it's not unusual for some VARs to shy away from modernization - sometimes to a point of telling their clients that some things aren't possible. Many of those resellers shelter their end-users from modern advances, and international conferences (Spectrum!) where information, products, technology, and consultation are readily available. Why shelter end-users? If an end-user doesn't know what's possible (the thinking goes) they are less likely to ask their vendor for something that he can't provide. The longer an end-user believes that a GUI and ODBC aren't possible, the longer they might keep the system as is. "You don't need a GUI, the character screen is So much faster!" Well, at some point the end-user will hire a bright 22-28 year old who is more on top of things, who will tell them that not only are these things possible, but 'here' are the tools to make it happen ... and Pick isn't in that list. Queue the migration, the new expenses, termination of anyone associated with the old regime, and great wailing and gnashing of teeth.

Maybe you're running the latest v3 and you're still under support with Rocket. Maybe the time and cost of migration wasn't worth it to the company, but the support fee is. That decision should be reviewed. I mean, you're obviously concerned about the issues with the installation, but does that condition exist because there are no other options, because someone there doesn't know there are other options, or because someone there knows the options and decided against them?

We've seen those scenarios many times. Don't get me wrong - I'm not making generalizations about MV resellers. (Resellers note - if the above doesn't describe you, then it's not about you.) The guys who are on top of things use common languages, and to the end-user, for all they know, they could be running over SQL Server or MySQL (sometimes they are). What I am saying is that while it seems evident to some end-users that Pick "can't" do modern things, the reality is that it can easily do so, but some factors intercede in that process of getting from here to there. And we lament this state all the time.

Without getting into detail, all of the issues that you've cited can be overcome with mvBase or one of the other platforms. Migration may not be required. If you drive to get the company to consider changes, they will need to weigh the relative costs of enhancing what you have, migrating the application to another MV environment, or migrating out of MV entirely to another application. (I mentioned wailing and gnashing right?)

As examples:

- You can use Java, .NET, PHP, Python, C/C++, and any other language you like with MV.

- You can interface it (bi-directionally) with any API, service, protocol, or tools out there - SOAP, REST, Zapier, IoT, whatevah

- You can add a GUI with any preferred tools, thick client, thin client, mobile, MVC, MVVM, whatevah

- You can use any VCS or OS-level tools like cURL or blat or node or pip.

- You can do reporting with any software you want.

- I've done speech synthesis, voice recognition, bi-directional telephony, bi-directional SMS, generation of other document formats, and integrated with Minecraft. I even used to have my system controlling my coffee pot and lights (tip: not wife-friendly).

- We're developing a new GUI application development environment that will eventually run over most MV platforms. It's been running with a live application for at least a year now, developed over mvBase, and all sites so far running mvBase. They don't know that their web-based Tomcat-supported platform uses mvBase, nor do they care. I think That is the vision that we'd all like to see for your site and others.

I hope that sounds more like any common DBMS, Framework, CLI, or API, and less like some old system that deserves to be replaced. But we can do this with your mvBase or D3 or anything else in this industry. (Another tip: Note that this means migration to another MV product isn't "necessary" though it might be a lot more elegant.)

There are tons of details about how the connectivity is done, trade-offs of where to put components for performance or stability, managing state, locks, session pooling, etc. But now we're at the point where we know we can discuss details and preferences rather than possibilities.

There are also considerations about how to get from here to there: How many programs of the entire code set really need a GUI? What's the best way to break modules out of the linear code (with Input and Print statements) and interface them with a remote UI? And how do we get all of this into a cloud server?

As you see, the discussion can be elevated. Many companies that migrate do so believing their VAR is old and can't help them, and that their server is almost as old and incapable. We lose those sites for reasons other than the actual capabilities of the platform.

I've gone on about this topic for too long - and in my blog I've discussed it for years. Please feel free to take a look and ask questions (new threads here are good).

Best,

T

http://Nebula-RnD.com/blog

[Andrew Cole]

It seems like QM gets a lot of love around here! Steve, is coyote still usable? Just before I was hired the company I'm at redid the entire website to run on php/mySQL and interface into mvBase due to limitations(?) or issues with PIC-LAN/coyote.

Tony, some very good estimates about my position. We are on v3 of mvBase and we're even using MVSP to connect certain applications. I actually had to use java to create a connection pooling server to process the requests to interface our website into mvBase because without it we'd have severe licensing issues. The point there is that we are using some of the newer technologies to connect to MV. The one thing that's evaded me has been an easy way for having mvBase interface with Java without resorting to a server watching for file requests or having mvBase call jar files with arguments (which can get ugly with encodings). So I'm very curious as to how you accomplish bidirectional interfaces with mvBase! Also, I can't believe I've never thought about using cURL from command line with mvBase. Doh! 

And you're right, a few years ago I was the young guy who was like wow this stuff needs to go. But it has grown on me and it's not like I really want to spend the time converting old BASIC to java, php or whatever else or migrating MV data to mySQL. I feel like there is a lot of potential in MV due to its simplicity but the issues brought up in this thread are restricting it. So the other dev doesn't want to leave MV and it's grown on me and I don't want to reinvent the wheel. I know for me I'd like to get on a more mainstream MV platform (distro?) which is why we're evaluating jBASE. The kink in that plan is that apparently with d3's upcoming update, we should be able to migrate to d3 with very little effort according to support. 

[Steve Trimble]

I use it with Linux. So my configuration is:

Linux/Apache/QM/Php

Coyote is programming in Basic and HTML/Php. One thing that is does remarkably fast is to use RPC (remote procedure calls) to just about any flavor of PICK. In that environment, I have OpenQM/Linux/Apache/Coyote as a web server. Then I can have mvBASE, D3, openQM, etc has multiple dbase servers around the globe. Extract data quickly from them for real time dynamic web applications. since Coyote runs inside the dbase (ie: not outside), programming is as close to BASIC as you can get.

the speed is quite remarkable.

feel free to call.

Computerized Data Mgmt Inc
Steve Trimble
(501) 615-8674 office

(501) 772-3450 cell / text

cdm...@gmail.com

--

[Wols Lists]

On 25/06/18 02:38, Andrew Cole wrote:
> It seems like QM gets a lot of love around here! Steve, is coyote still
> usable? Just before I was hired the company I'm at redid the entire
> website to run on php/mySQL and interface into mvBase due to
> limitations(?) or issues with PIC-LAN/coyote.

Remember my post about "true Pick" and Devcom/INFORMATION? Well, when
the guys at Devcom wrote INFORMATION, they had the benefit of a lot of
hindsight, and tried to do "Pick done right".

Martin I believe was on the team at Pr1me, and he apparently has a great
attitude to customer service - if someone wants something he'll do his
best to add it.

>
> And you're right, a few years ago I was the young guy who was like wow
> this stuff needs to go. But it has grown on me and it's not like I
> really want to spend the time converting old BASIC to java, php or

> whatever else or migrating MV data to mySQL. I feel like there is *a lot
> of potential* in MV due to its simplicity but the issues brought up in

> this thread are restricting it. So the other dev doesn't want to leave
> MV and it's grown on me and I don't want to reinvent the wheel. I know
> for me I'd like to get on a more mainstream MV platform (distro?) which
> is why we're evaluating jBASE. The kink in that plan is that apparently
> with d3's upcoming update, we should be able to migrate to d3 with very
> little effort according to support.
>

If it ain't broke don't fix it :-) But write new stuff in new languages
if that's what floats your boat.

But you'll find some people (me in particular) are very strong about
voicing our belief that relational is broken, and MultiValue is the fix
... :-)

(C&D's rules are, imho, contradictory ...)

Cheers,
Wol

[Patrick Payne]

Andrew,  a couple other items.

1. I am a long time D3 user (25+) years and built out many web interfaces.  Final site was 300+ green screen users, 2000+ clients using .net based webforms app talking in via flashconnect (was coyote).  The app is now on jBase with all the same interfaces except jagent/Rest vs flashconnect and it now has a Agular app calling in via rest (angular->.net rest->jbase/rest).

2. I was a big Coyote user.  I loved the idea of a open web api into the system.  I have been with Zumasys for 2+ years now and my main focus was taking our Bravo Connector we purchased from the Nerdery and building it out to be a real cross platform web api.  It is now called MVConnect.  It adds a small C server to your platform that you can then expose pick web api's.  I took what I liked about Coyote and D3's flashconnect and built out what I wanted based on 20+ years doing web/rest api work.  MVConnect gives you a common group of functions in Pick to do web work.  The design was based on what I had used in Perl and php.  You get functions to work with headers, the body, response code, cookies, variables, etc.  We are then adding open source libraries on top for doing tokens, objects, etc.  MVConnect works on unidata, universe, openqm, d3 and jbase.  On jBase we build the web server part directly into our jAgent and it is included.  This will allow me to easily take the VSCode extensions and call MVConnect libraries for the remote access.  I am not a fan of the remote libraries such as uniobjects, jRCS, jremotec#  because just as MVON found they had to write a Node/Javascript NetObjects library for each language.  If next month GO takes over, or Ruby, or whatever the next animal is there is another re-write.  With web/api's all you need is the ajax/web client for that platform (and they all have it). 

3. (yes I am pushing jBase now).  jBase compiles code directly into C code on the platform.  All our pick commands (ED, LISTU, BASIC, COMPILE, SORT, ETC) are all O/S binaries also.  This means in jBase you really are developing C programs.  This means you can do anything from the c:\ or bash# prompt.  This means when I started playing with VSCode 6 months ago I was able to integrate reading/writing/compiling directly into VSCode with just a macro.  With jBase I code just like my .net or Angular friends in that I bring the entire project and database down to my laptop and work directly.  Therefore in VSCode directly on my windows 10 laptop I have ctrl-shift-C set to run basic/compile and ctrl-shift-R to run.  I had to do nothing to make either work as it is just a macro running stuff that the O/S can run directly.

4. VM blobs vs files.  I cannot tell you how much nicer life is now that I am not dealing with a VM file blob.  I loved my D3 system but systems such as OpenQM, jBase, Universe/Unidata all store the files directly in the normal file system.  Much nicer.  I never again have to worry about a GFE bringing my entire file system down. Plus I can now just copy the files around (with certain limitations).

btw - I really loved my mvBase systems.  I come from the Adds Mentor line, then R83 when we were the operating system on a IBM-XT with a 10 gig hard drive, then AP, D3, and now jBase.  Throw some OpenQM in there also (very nice system).  With mvBase you are seeing what is probably the most pure version of this line and it still works, talks, and acts almost exactly how my old Adds system worked.  For the classic pick guy that needed to have the system on windows with the lease amount of fuss mvBase was hard to beat.  Moving forward although....

Here is my "task" I configured in VSCode.  I created a BC program in jBase to both basic and catalog the program (plus it figures out where the source is).  Run was straight forward.

{

// See https://go.microsoft.com/fwlink/?LinkId=733558

// for the documentation about the tasks.json format

"version": "2.0.0",

"_runner": "terminal",

"tasks": [

{

"label": "compile",

"type": "shell",

"command": "BC ${fileBasename}",

"problemMatcher": []

},

{

"label": "run",

"type": "shell",

"command": "${fileBasename}",

"problemMatcher": []

}

]

}

Here it is running in VSCode terminal

Terminal will be reused by tasks, press any key to close it. > Executing task: BC NW.ORDERS.FINAL.RTNE < BASIC NW.BP NW.ORDERS.FINAL.RTNE NW.ORDERS.FINAL.RTNE "NW.ORDERS.FINAL.RTNE", 20 (offset 4) : FOR ^ parse error 1 error was found jbccom -f -d -aNW.BP BASIC_1.b failed , command returned a code of 1 jcompile: Returned an error code of 8 ** Unable to compile source NW.ORDERS.FINAL.RTNE ** NW.ORDERS.FINAL.RTNE Object NW.ORDERS.FINAL.RTNE cataloged successfully Terminal will be reused by tasks, press any key to close it.

[chandru murthi]

On Thursday, June 14, 2018 at 5:24:37 PM UTC-4, Peter McMurray wrote:

Rocket has added Python to U2 and D3 come November. Why?

Millenials are now the buyers, users, decision makers in our business. The goal posts have moved and if we do not move then there is a danger of the baby going out with the bath water..

They are looking for Full Stack developers and or people who fit into one of the three major levels.

I said not too long ago that all we needed was FlashBasic and a simple link to the web. Not anymore.

If a person does not know where Python, Flask, Numpy, Pandas fit with the likes of Vue.JS, TypeScript and MySQl and Pick then they are not in the race. Certainly there will be a small market for looking after old sites just as there is a market for maintaining classic cars. If that is one's choice then fine.

I can safely say that I, and the company I've been consulting to for the last 15 years, fall into this category. And it's a highly successful, albeit small one. I've been doing the browser-based front end (UI) to a uv system the while. I know javascript and BASIC and I don't even use frameworks (I detest JQuery) because so far, it's been easier doing the coding myself. I should say that for an *extremely* complex UI, the entire javascript code is less than JQuery's bloat.

I doubt I'll get a consensus on this one.But I take this sort of statement with a great dollop of salt.

And, Peter, this is simply wrong:

>The one issue is that the dictionaries are tied to files when they need to be tied to applications. Yes we fixed that in 1977 when we introduced application dictionaries and file schemas that are now known as Classes

...and thereby destroyed the concept of a Dictionary, *which is not the same as meta-data or classes*. File fields (should) contain invariant data, which the Dict describes. If Dicts are connected to the application and can vary, that's chaos, not Pick. A class should ideally be a set of Dict definitions (for file data,) and other elements, not something the programmer decides is currently ok for the application.

Of course, this horse has long left the stable. When Pick decided not to implement a true, easy-to-use, and strict Update process using the existing Dictionary definitions.

[Peter McMurray]

Hi Chandru

Interesting that you should raise the deadly UPDATE verb. That is the one that directly altered data in an ENGLISH style on Reality 2.4d not the dreadful editor from Advanced Pick. 

By the way that much hated editor actually managed to hide what could have been a useful feature implementing Don Nelson's desire for a link between lists with "double-declutching" "zooming" etc...

We actually took it out of the MD along with ED where the dangerous user with a little knowledge could and did cause chaos.

I have fond memories of an engineer taking a crowbar to a Reality cassette unit when one such user got a cassette in upside down. The damage Alwyn could do in a file was beyond despair.

The engineers gave him a pair of scissors and tape markers so that he could redo the tapes he destroyed when he let the replacement half inch tapes fall off and still hit the go button.

I have to both agree and disagree with you.

The files must be updated from a precise definition that is why the A dictionary attribute was there.

However tying the definition to an individual file is a disaster that frequently results in program Create Stock using say AlphaNumeric Data for the key and program Update using a Numeric key.

We define an application wide dictionary for the name value pair that make up a dictionary.

We then use that to create a File class that MUST be used by ALL programs to access the file.

We also use it to create the relevant PMV file dictionaries. including the default list 1, 2, 3 ... The latter used as Pick designed to indicate column print definitions I have seen cause tragedy.

Any other dictionaries are created as required as S types and stored in a separate master application file for safety. I have seen many a program where the designer clears and reloads the dictionary for a report.

Fine if he is the only one doing files not so hot if another contractor is called in to make extensions.

[chandru murthi]

OK, you're talking about a global Dict which is apparently application-wide (in effect therefore, if the file is NOT shared, it amounts to the same thing.)

But what happens if you have another app needing to reference or update data in the first one? The II will have its own global Dict file, and usig your scenario of the clueless programmer, could define an existing field incorrectly.  So my point about Dicts wedded to files absolutely applies, regardless of where they actually are defined.

Obviously, dict fields should be unique...that's why the original Nelson-Pick model had A items and S as synonyms, secondary items not meant to define the data.

Chandru

[Peter McMurray]

HI Chandru

The File Definition is held by File Name and referenced from the master application.

In our OIL application we actually separate the Creditors and General ledger from the master Debtors, Stock and Pricing but they are able to cross-reference each other.

We actually have the General and Creditors in Separate Accounts as the timing of month end, year end will typically be different. Not essential just convenient as the staff are preferably different.

We pay particular attention to separation of duties as we feel both on our training as chartered accountants and direct experience that it is management duty to limit areas of not only error but also defalcation.

One of the beauties of COMMON and now NAMED COMMON is that cross reference is simple. In the U2 UCS-2and JBase UTF-8 implementation this is available between the PMV and Python.

I believe that the same applies with MVON# UTF-16 however I have not yet checked that, the same goes for the QM solution.

On Friday, June 15, 2018 at 7:24:37 AM UTC+10, Peter McMurray wrote:

Rocket has added Python to U2 and D3 come November. Why?

Millenials are now the buyers, users, decision makers in our business. The goal posts have moved and if we do not move then there is a danger of the baby going out with the bath water..

They are looking for Full Stack developers and or people who fit into one of the three major levels.

I said not too long ago that all we needed was FlashBasic and a simple link to the web. Not anymore.

If a person does not know where Python, Flask, Numpy, Pandas fit with the likes of Vue.JS, TypeScript and MySQl and Pick then they are not in the race. Certainly there will be a small market for looking after old sites just as there is a market for maintaining classic cars. If that is one's choice then fine.

[Bob Markowitz]

The many technologies that have been added to Pick by the database vendors allow for the data to be manipulated in more ways than Dick and Don could have imagined.  Where the inheritors of the Pick system have failed is not in the back-end storing and manipulation of the data but in the way the data is presented to the user.  This discussion, as all Pick discussions really focuses on the future.  MultiValue applications with a myriad of features and functions are losing out to less functional but prettier Apps that offer mobile and desktop GUI solutions and that is an indisputable fact.

 

To quote Peter – “I am definitely working on the back end right now and paddling furiously to grasp the front...."

 

I think that Peter’s “grasp the front” is his desire to make his Pick application look and feel like 99% of the non-Pick desktop solutions and also have his app run on all mobile devices.  Solve that problem and that is how we save Pick.  Now as to how to create a new front-end and mobile...

 

On Thursday, June 14, 2018 at 4:24:37 PM UTC-5, Peter McMurray wrote:

Rocket has added Python to U2 and D3 come ...

[Andrew Cole]

Alright, so I had an idea last night regarding my dislike of the current licensing. I'm not sure if it's a good one or if it's even workable but might as well throw it out there. So I understand that the licensing/maintenance is what keeps the creators/maintainers of MVDBS platforms in business. So destroying that for something completely different isn't an intelligent move. But most here would probably agree that more devs need to be exposed to MVDBMS. 

Now, most new devs will be familiar with PHP, Java(JSP), .NET(ASP), Python, <insert your favorite language here> and won't really want to touch BASIC. The main MVDBMS platforms already have drivers/libs for the most popular languages out there (with the exception of PHP imo) offering those languages basic CRUD support. So with that in mind, someone  could offer a "lite" version that included those libs, was limited to a terminal user and a web/connection pool user, and was limited to only the data storage engine. I suppose that means cutting out the compiler for BASIC and the engine that runs PROCS. I'm not fully up on how the deep internals of these systems are wired and if that's even possible.

The target audience I have in mind are small web servers and test servers. Most new guys out there are web devs or at least familiar with the web. Giving that large community the opportunity to use MVDBMS could be great for the market or at least the longevity of the platform. Obviously I would like to see the lite version as free but maybe with a paid support option to help supplement the makers? By cutting out the application layer, you ensure that your current customers can't drop their standard version for the lite since they're already engrossed in the platform including the app layer. So you'd theoretically maintain your current customer base while hopefully expanding the market which could lead to more people purchasing standard servers as well as a small increase in revenue from lite support.

There's my latest thoughts. Maybe they'll inspire a better idea from someone!

[Martyn]

I'm afraid that I have to somewhat disagree.  Revelation Software have consistently invested in their GUI and Web development tools and have supported the major MultiValue backend databases for quite some time.  It think that OpenInsight is one of the few GUI and web options which 'don't' ancourge people to move to SQL or some other backend database.  with OI you simply connect your U2, D3, QM, SQL database, etc. and you use the majority of the tools as is.  It frustrates me to hear people saying that everyone has focused solely on the backend when some of us have invested heavily in the user interface development tools but the MV community refuses to embrace them.

We have some super applications in the field that are both hugely functional and pretty.  One of our clients in Wales is constantly winning awards at the moment.  Several others have gone on to be bought out by bigger competitors because the OpenInsight solution is fast, efficient, robust and good looking.  Yes, there are some dire looking solutions out there, but that comes down to the developer not being graphically minded or a good designer.  OpenInsight 10 is making the creation of pretty application so much easier.

M.

[Kevin Powick]

On Friday, 29 June 2018 02:45:29 UTC-4, Martyn wrote:

Revelation Software have consistently invested in their GUI and Web development tools and have supported the major MultiValue backend databases for quite some time. 

You would never know this by looking at the Revelation Software website.  The majority of the site reads like a never ending series of white papers. 

Get some professional help for the marketing/website.  It's the "shiny things" that first grab the attention of busy, potential customers.  Just look at the website of any major IT company for inspiration.  Even Rocket and Zumasys are doing a pretty good job with their sites.

--

Kevin Powick

[Bob Markowitz]

And do not forget BlueFinity!

[James A]

I agree with Martyn: I just looked around Revelation's website, and offhand could not find a single image of what a nice looking MV data entry screen might look like.

Just text on and on.. nice for developers interested in 'the details'; but 'a picture is worth 1000 words'?

We just had a professional design group help with the look/flow of our website; check it out: www.docmagic.com (yes the core sofware is UV..;)

- James

[Tony Gravagno]

You're describing OpenInsight, QM, and jBase, which (I believe) all have developer licenses.

You're describing Universe and Unidata, which do (or did) have a free developer license.

You're describing MVON Express, which is MV over SQL Server Express.

You're describing a "lite" version of D3 which got me stares of insanity when I proposed it at Pick Systems some 20+ years ago, and then maybe every 5 or so years since then to every deaf ear in authority at the time.

 

You're describing a common connectivity issue where one web user is still equivalent to one DBMS user, because these companies are terrified to do what you propose, which is to earn their revenue based on high volumes of brief connections, rather than low volumes of long-term connections. This is as simple as "we've always done it like this and we can't imagine how to do it otherwise". That said, there are pooling connections including MVSP for mvBase and D3, and UO for U2. These are supported by enterprise licensing - their answer to "how do we keep from losing money" (duh). mv.NET is a cross-platform, third-party option (disclosure I'm a reseller), and there are other similar offerings, with a built-in pooling mechanism to maximize the efficiency of individual licenses.

Without BASIC? Won't happen and not necessary. I suggest all MV platforms are accessible using common client tools, and BASIC is a great alternative to common and very frustrating platform-specific stored procedure languages.

So you're right on the money. Frustratingly.

Your personal solution might best be to check out QM and jBase, find your comfort spot, and I believe you will find most of the features that you describe ... and which many of us have been discussing for (ouch, um) since you were a toddler and before...

T

On Thursday, June 28, 2018 at 6:02:48 PM UTC-7, Andrew Cole wrote:

I understand that the licensing/maintenance is what keeps the creators/maintainers of MVDBS platforms in business. So destroying that for something completely different isn't an intelligent move. But most here would probably agree that more devs need to be exposed to MVDBMS. 

someone  could offer a "lite" version....

[Wols Lists]

On 30/06/18 08:21, Tony Gravagno wrote:
> You're describing OpenInsight, QM, and jBase, which (I believe) all have
> developer licenses.
> You're describing Universe and Unidata, which do (or did) have a free
> developer license.
> You're describing MVON Express, which is MV over SQL Server Express.
> You're describing a "lite" version of D3 which got me stares of insanity
> when I proposed it at Pick Systems some 20+ years ago, and then maybe
> every 5 or so years since then to every deaf ear in authority at the time.

What I would like is to see a "free for personal use" licence. The
trouble with these developer licences is that they typically expire
after one month.

Okay, I could probably buy a licence from QM at least very cheaply, but
as someone who's only really used INFORMATION and UV, what use have I
got for a FOUR-seat UV licence? That was the minimum last I knew (of
course, it may well have changed since, that was pre-IBM iirc).

But give developers a freebie to use at home, and it strengthens your
support base. And the revenue loss is negligible to non-existent because
they were never going to pay anyway. And if they get their friends to
use it you've suddenly got this "hey, I've found an 'easy to use'
database" marketing thing going on!

Cheers,
Wol

[Kevin Powick]

On Saturday, 30 June 2018 04:20:26 UTC-4, Wol wrote:

What I would like is to see a "free for personal use" licence.

QM has, or at least used to have, this.  It does not expire. The only limitation is number of users (one) and total amount of data you can store.

 

The
trouble with these developer licences is that they typically expire
after one month.

QM dev license is free and renewable on an annual basis.  I've been doing this for years.  I *think* mine is a 5 user dev system.

All you have to do is send an email request to QM/Zumasys.

--

Kevin Powick

[Andrew Cole]

I suppose I left something out of my previous response that's quite important and that's an easy way to download. Tony, of all the platforms you listed, how many can I go to right now and download without filling out a form or talking to Sales? As Wol pointed out most of the dev licenses seem to expire after a certain amount of time and for other platforms, it doesn't look like they advertise it. Kevin, I don't see that advertised on OpenQM's site so maybe it's not a thing anymore? Either way, I went to mySQL's site and was at the community download within 3 clicks, never mind that it's in all the major linux distro's package managers. It's sad, but most people my age seem to have the attention span of a gnat and are too lazy to contact Sales. I suppose this whole subsection of the thread is about removing barriers. Talking to Sales, while useful for certain things, is a barrier to entry. Not having a well laid out website to lead these users to a "community" version of your platform is a barrier to entry. As far as the thought about removing BASIC for the lite/community version, that was more a way to limit the ability of commercial licenses to switch over but limiting database size can accomplish the same thing and require less work from the devs. One thing that, imo, would be severely detrimental as far as attracting new users is limiting the access of the Java/.NET/etc connectors to commercial versions.

Tony - does MVSP do connection pooling natively in D3? I know it doesn't in mvBase. Also, I know the jBase does indeed have a....Web License? I don't remember what they call it as my sales rep and I touched on license types about a month ago last. But as far as I understand it, it's exactly what I describe above.

But give developers a freebie to use at home, and it strengthens your 
support base. And the revenue loss is negligible to non-existent because 
they were never going to pay anyway. And if they get their friends to 
use it you've suddenly got this "hey, I've found an 'easy to use' 
database" marketing thing going on!

The other thing is, the more users like you describe here you have for your platform, the more beta testers you have to help you iron out bugs. Devs are way more apt to test out the upcoming versions on their test/pet systems and as long as you maintain a good way for them to report bugs back, you'll get free beta testers! Without that, you do you own bug tests then release the full version, devs who have test systems (I wish I had this but that's a different conversation) will then test the new version on there before moving to production. If they find problems, now you're forced into writing and releasing a slew of patches and hoping people install them. I've seen this with mvBase, We install a new version and all of a sudden we're 12 patches behind.

[Wols Lists]

On 01/07/18 02:44, Andrew Cole wrote:
> As far as the thought about removing BASIC for the lite/community
> version, that was more a way to limit the ability of commercial licenses
> to switch over

For a dev wanting a personal/lite version, removing BASIC effectively
destroys any value in the product ... !

It's like deleting Transact-SQL from the lite version of SQL-Server...

Cheers,
Wol

[Kevin Powick]

On Saturday, 30 June 2018 21:44:57 UTC-4, Andrew Cole wrote:

 Kevin, I don't see that advertised on OpenQM's site so maybe it's not a thing anymore?

They don't make it easy, but you can still get the "personal" version, which is just a restricted operating mode of the commercial version.  Follow these steps.

1) Download the commercial version for the platform of choice from one of the following links

     http://www.openqm-zumasys.com/downloads/

     http://openqm.com/?T0=downloads&X=rur05b7d2t

2) Read about "Personal" activation here: http://openqm.com/?X=rur05b7d2t&t0=h&t1=personal

3) You can also check out the USB version on the "Downloads" page, which, IIRC, requires no activation.

--

Kevin Powick

[Martin Phillips]

The Personal version is a single user licence with some limitations to prevent its use in a production environment.

 

The downloadable USB demo version is simply the personal version licence together with a somewhat out of date AccuTerm demo application. The Windows version of QM can be installed on a USB memory stick with the licence tied to the stick rather than the specific computer.

 

A four user developer version is available free of charge to developers creating an application that will be sold into the general marketplace.

 

 

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200

--

[Steve Trimble]

as always -- I just love QM

thanks Martin for ALL you guys do!

Computerized Data Mgmt Inc
Steve Trimble
(501) 615-8674 office

(501) 772-3450 cell / text

cdm...@gmail.com

[Charlie Noah]

Andrew,

As a former Jbase developer (retired) and tinkerer, I would not give a second glance to an MV system which excluded Basic, regardless of price. I'd sooner eat biscuits without leavening.

Charlie

[Andrew Cole]

Wol and Charlie,

Remember the audience I'm talking about. I'm specifically talking about people under 35 who are already well established in Java/.NET/PHP/Python/etc. My comments (as far as I can remember xD ) were pertaining to attracting new users to the MV world. We sort of took a detour to established MV devs.

I'll be honest here, I find PICK/BASIC incredibly constraining and incredibly difficult to find resources on. A good portion of my job the past couple years has been writing Java API's for the main mvBase programmer. With that said, I'm INCREDIBLY impressed with what Zumasys is doing with jBASE. They're really opening up BASIC with jabbascript/objects as well as built in JSON support. For people under 35 with no MVDBMS experience, they don't want that BASIC straight jacket when they can do all they want with their current language. You have to remember what you're marketing to the "younger" audience. You're main product is the database technology and BASIC is honestly an extra to the younger crowd with no prior MV experience. Just look at MongoDB, arguably the most popular NoSQL db out there. You just get the DB and connectors. Now you can try and market BASIC as an extra you don't get somewhere else but, personally, I believe that approach will do more harm than good.

However, if the target audience for a "developer" license is the crowd who's already established in the industry and on MV products, then removing BASIC would be a terrible idea. Those established in the MV world rely on BASIC and the point of a small test system for current devs would require BASIC. So in this case, limiting DB size is the perfect limiting factor. 

Martin & Kevin - Well knowing that, I might have to play with QM just so I can gain familiarity with it. However, I would strongly suggest doing something to make it more clear that there are personal and dev licenses available! I can offer free hair cuts but if no one knows I'm offering them what's the point?

[Tony Gravagno]

Andrew - You're 100% on target with your observations and suggestions.

Pick / Raining Data / TigerLogic / RocketSoftware have never had a clue about how to market the MV assets to a non MV audience. They hire people who don't know what MV is as marketing managers. Every new team through the revolving door approaches MV marketing like it's a new problem, like it's something old that they need to market to people who want new. They concede to themselves that this is an impossible task and after some initial enthusiasm they fall back to approach marketing with no fervor whatsoever. Is it any wonder that this leads to no new industry recognition? When marketing people get paid a full-time salary, they're not motivated to go after anything but the lower hanging fruit. They will get paid no matter how ineffective their daily activity. To them, Marketing is a tweet, a webinar, a new PDF on the website, and the eNewsletter with nothing new to say. The company fails to attract new developers (surprise surprise) so they raise prices on existing sites and try to sell the existing base new products. The marketing team moves on to new opportunities, the door revolves, the process begins again.

This is not unique to that company. All of the MV providers had and have the same issues. Yes, that includes Northgate and ONgroup. Zumasys has fallen into the pattern. InterSystems stopped pushing their MV implementation for similar reasons. I honestly don't know about Revelation marketing, as they seem to be the most consistent (and quiet) company in this industry.

I think this all comes from a common, high level, hands-off management directive "you folks here will do marketing, and you there will do sales". They get the people in place and expect results, not recognizing that the same team will only do the same as the old team unless they have guidance to do otherwise. The team doesn't perform, they get replaced, everyone continues to get a paycheck, the world moves on. Except overall the industry continues to suffer, and THAT is why I rant on these things.

So that's the big picture. To some of your points:

- Yes, the existing developer channel is a great source of Beta feedback.

- Yes, free/limited licensing is the globally accepted approach to getting product in the hands of new developers who will then sell licenses to new consumers ... that message seems to elude all of these companies at different times and with different management teams.

- No, MVSP does not default to pooling but you can buy Enterprise Licensing which their solution to get you to pay even more money for licenses that you already have. (Note that you can pool MVSP connections yourself or use existing products for this ... everything is a tradeoff between your Time or your Money.)

- How do you get licenses for development or otherwise? The standard approach with all of these companies is to contact your Value-Add Reseller = Application Provider (not my preferred linkage of relationships). If you don't have a tier-1 provider, contact your DBMS company Sales rep directly. These days I think Rocket just has a Sales department and no more actual account reps. In other words, you need to petition a faceless entity for what you want, with all of your logic, about how it should be better or easier, being ignored as people continue to get paid without a need for rocking any boats.

Have a great day! :)

T

[Martyn]

So, as one of those do nothing sales and marketing types that will run a mile after a few months, I will no doubt wish that I had not replied to this post.  However, taking your points paragraph by paragraph - here goes.

 

Andrew - You're 100% on target with your observations and suggestions.

Firstly, I totally agree with Andrew’s comments and many of the subsequent comments on this thread.  This is one of the reasons that I have contributed to this thread from a non-technical point of view.  For transparency, I have also reached out to Andrew separately.

 

Pick / Raining Data / TigerLogic / RocketSoftware have never had a clue about how to market the MV assets to a non MV audience. They hire people who don't know what MV is as marketing managers. Every new team through the revolving door approaches MV marketing like it's a new problem, like it's something old that they need to market to people who want new. They concede to themselves that this is an impossible task and after some initial enthusiasm they fall back to approach marketing with no fervor whatsoever. Is it any wonder that this leads to no new industry recognition? When marketing people get paid a full-time salary, they're not motivated to go after anything but the lower hanging fruit. They will get paid no matter how ineffective their daily activity. To them, Marketing is a tweet, a webinar, a new PDF on the website, and the eNewsletter with nothing new to say. The company fails to attract new developers (surprise surprise) so they raise prices on existing sites and try to sell the existing base new products. The marketing team moves on to new opportunities, the door revolves, the process begins again.

I have always tried to evangelise the virtues of MultiValue outside of the MV marketplace and for that reason I don’t keep up with the other MV vendors and, for that reason, I’ll therefore decline to comment on anything other that OpenInsight and Revelation Software related content.

 

This is not unique to that company. All of the MV providers had and have the same issues. Yes, that includes Northgate and ONgroup. Zumasys has fallen into the pattern. InterSystems stopped pushing their MV implementation for similar reasons. I honestly don't know about Revelation marketing, as they seem to be the most consistent (and quiet) company in this industry.

Granted, Revelation Software have been quiet of late with regards to Marketing.  This is because we have been involved in a massive rewrite of the toolset.  Why, because when trying to break into other (non-MV) markets we were consistently told that the interface was not intuitive, not what the mainstream, were used to and that they’d stay with what they have.  From the MV market point of view, we were told that people wanted more data connectors, support for cloud bases and the ability to create nice (sexy) looking interfaces without too much effort.  Yes, I noticed the comment about the RevUS website being text heavy, but that website is mostly technical and it serves our market very well.  It is also outside of my remit and I’ll therefore leave RevUS to comment.  However, OpenInsight 10 is a massive leap forward in productivity gains for developers, you can do more with less code, etc. etc.

Marketing efforts will shortly begin in earnest again.  Some of this will be to the existing MV market place which I hope you will all see.  Much of what I will be doing will be outside of the MV marketplace.  This is the hard task for a number of reasons but it is the only way that we will grow the MV marketplace.  For the moment, I am personally working on OI10 tutorials and associated videos.  I host these on a personal YouTube channel in the hope that some non-MV people will find us.  YouTube is easily the second biggest search engine and arguably number 1 if you look at the younger demographic.  This is where I get most of my non-MV leads, despite the old 9.x video series having the old interface.

I also have plans to review my Why MBDBMS white paper and Why Revelation white paper.  Yes, these are .pdf docs that I put out there, but they are good marketing aids.  Revelation have also supported numerous user groups, attended non-MV exhibitions, run adverts on planes and in magazines, etc. etc.  We have also been talking here in the UK about getting in front of journalists and editors again, but in a more controlled manner this time because the journalists tend to have a real downer on MV because it’s seen as old technology and because we (MV vendors and VARs collectively) typically do not spend marketing dollars with them.

OI10 is still settling in, but I know that we will become noisy again very soon.  In fact, If I think back three or four years, I was asked why I’d gone quiet because (other than a lady a Zumasys) I was the noisiest person in the MV community reaching out to IT people in general.  This time I have plans to utilise LinkedIn and my primary lead generation tool.  Will you guys see what I’m doing, probably not because you will most likely not be on my radar and most likely not looking where I’m networking and pushing OI.

 

I think this all comes from a common, high level, hands-off management directive "you folks here will do marketing, and you there will do sales". They get the people in place and expect results, not recognizing that the same team will only do the same as the old team unless they have guidance to do otherwise. The team doesn't perform, they get replaced, everyone continues to get a paycheck, the world moves on. Except overall the industry continues to suffer, and THAT is why I rant on these things.

This management hands off approach is the same in lots of companies.  Management employ a sales and marketing team and leave them to do what they do.  It is something that frustrates me but it is why I’m still here at RevUK 20 years on.  My opposite half in the US is also a long serving member of our team.  We both believe in MV and OpenInsight specifically.  We are very well supported and I only have to ask for help in a sales cycle and the help is there.  I can’t talk for the other MV vendors, but Revelation does not have a reputation for bringing in a sales and marketing team and then shipping them out a few months later.  It is a very hard and specialised sale and consistency is key.

I can relate to your comment on sales and marketing teams not performing when viewed from the outside.  From the inside, I would have to agree and disagree.  We do keep pushing but it is hard – damn hard.

Some of my thoughts are:

1. We suffer from MV being seen as a legacy technology – not something that I agree with and I’m happy to tackle head on.
   
2. We suffer from many of our VARs not allowing us to share their successes and to talk about them – We are quite luck at Revelation, but I still can’t shout about some of our biggest projects.
   
3. We suffer from many of our VARs being developers, rather than businessmen and women.  They build a system and wait for it to sell, or wait for the Vendor to help sell it. 
   Thankfully, many of my VARs are larger companies with business people that are getting exposure and selling their solutions.  This is why many of our VARs gain maximum market share.  The downside for me, is that all too frequently they become too successful and sell out to their competition who decide to buy them out because they cannot compete with a strong robust solution, backed by an attentive Vendor and a strong VAR.
   
4. Traditional marketing is expensive and it no longer works, but I don’t see much marketing being undertaken on the modern platforms.
   
5. Trying to get VARs involved with events, marketing and other things is difficult.  I’m lucky at Rev that I have VARs that do support me, but I wonder about the other MV vendors. 
   
1. How many of you guys reading this have offered your support at events?
2. How many of you have taken marketing ideas and opportunities to your MV vendor?
3. How many of you are actively and consistently marketing your products and where?
6. My number one obstacle is Developer and management reluctance:
1. The cost of the development license (there I said it).  All non-MV developers that I talk to want the tools for free.  That said, how many of you VARs give away a lite or feature limited personal edition for free – this is something that I am genuinely interested in.
2. Business management still refer software purchases to the IT manger.  He wants to run a big team and he and his team want to use the latest technology that will look good on his and their CV’s.  MV does not typically fit this personal need.  We are seen as a dead technology with no CV benefit and the IT Manager does not want a smaller team or to be able to deliver things too quickly.  Until the Financial Managers take control, this money waste will continue.
3. Developers like to use what the know and that they are used to.  We therefore need to get in front of future developers before they begin using other things.  This is a tough nut to crack but one that I am working on.
4. I am constantly amazed at how many young people in the Americas, Europe and Australia are just not interested in building business application.  They all seem to want to build games.  This has opened the gateway for India and the developing economies to fill that gap and they ‘all’ only offer MS, Java, Python and the flavour of the month technologies.  I find it extremely hard to get them to even talk about MV and OI.
   We recently had some developers over from India and we were specifically told that they were not interested in learning OI (despite being sent over my management) because it did nothing for their CV and they would not be around long enough to care.

I could continue but I won’t you get the picture and it is one that I’m sure that you are all too familiar with.

 

MY QUESTION TO YOU ALL – Rather than the MV VAR community look to the MV vendors for marketing all of the time, why don’t you get together with your Vendors and talk about ways that we can all work together to promote our MV applications and the underlying tools.  As I have said, I’m pretty lucky at Revelation with my VAR channel, but when I talk to a other MV developers (VARs) in general, they decline to get involved with their Vendors for fear of their lead generation and sales discussions turning to the underlying technology, something that they all too often don’t want to discuss and (to be fair) probably don’t need to because it opens up a can of worms.

 

So that's the big picture. To some of your points:

 

- Yes, the existing developer channel is a great source of Beta feedback.

Our OpenInsight community is wonderful when it comes to beta testing and I’d like to extend a thank you on here to all of the OI WORKS developers who recently alpha and beta tested OI10.

 

- Yes, free/limited licensing is the globally accepted approach to getting product in the hands of new developers who will then sell licenses to new consumers ... that message seems to elude all of these companies at different times and with different management teams.

Despite being on the sales and marketing team at Revelation, I have to personally agree with your comment.  Unfortunately, the MV management in general don’t tend to agree.  That said, at Revelation we have a very low cost of entry for developers, with the OI4MV developer license beginning at just £55.00 plus £11.00 p.a. per developer.  This is reduced to £15.80 per developer for large teams of 150 or more.  However, this is for the tools only and it does not include upgrades, support, etc.

 

- No, MVSP does not default to pooling but you can buy Enterprise Licensing which their solution to get you to pay even more money for licenses that you already have. (Note that you can pool MVSP connections yourself or use existing products for this ... everything is a tradeoff between your Time or your Money.)

 

- How do you get licenses for development or otherwise? The standard approach with all of these companies is to contact your Value-Add Reseller = Application Provider (not my preferred linkage of relationships). If you don't have a tier-1 provider, contact your DBMS company Sales rep directly. These days I think Rocket just has a Sales department and no more actual account reps. In other words, you need to petition a faceless entity for what you want, with all of your logic, about how it should be better or easier, being ignored as people continue to get paid without a need for rocking any boats.

Whilst Revelation Software provide 30 day evaluations, yes there is a form to complete but no gatekeepers, no sales hurdle, no nagging target chaser, just easy access to the entire development suite.  These evaluations can sometimes be extended on a case by case basis, where there is ongoing dialogue between Revelation and the developer, and where a mutually beneficial commercial reason is evident.  That said, developers usually know whether OI is right for them within the first week or so and they either drop it or purchase the OI WORKS license that includes supports, upgrades and a whole lot more.

 

At Revelation we are very personal.  In fact, Bob in the USA and myself are more account managers than hard sales and marketing people.  One of the reasons that I have been with Revelation for so long, is my access to senior decision makers, senior developers and the company owners.  I have a direct escalation route and the owner and senior developer of RevUK (Andrew McAuley) is always available to me to support my sales meetings and he often accompanies me on subsequent meetings where a qualified sale is underway and where more technical people will be attending.

 

Hard selling is no longer an acceptable method and, with GDPR, traditional marketing is becoming more and more difficult.  We ALL need to contribute if we want to take MV to the wider developer and user communities.  Leaving it all to the few MV vendors that we now have is never going to fly.  Just consider how many MV Vendors there are and then how many MV VARs,  independent MV developers, contractors and support people there are.  Collectively we ‘should’ all have a loud voice.  Leave it to the few MV vendors and that loud voice will surely become a whisper, despite how hard we try.

 

To finish, I have one final question for the VARs and MV developers taking the time to read this far too long post.  Other than magically landing new clients, what things would you like to see us doing from a sales and marketing point of view.

[Martyn]

Now you can all flame me to death :(

[Will Johnson]

The most astonishing point made in this discussion is that there are still people using mvBase.

[timbered]

Not to beat an already established horse, but...

In 2016, I sent an email to Rocket Software, asking about a developer/demo version of U2. After 8 rounds of emails back and forth, explaining what I was looking for, they finally send an email asking that I call a sales rep and chat for 5 or 10 minutes to explain to them what I wanted.

I gave up.

I remember this clearly not least of which because I still have the emails. I couldn't imagine having to do this for a product I knew nothing about (i.e. new users wanting to try MV...)

[timbered]

And for those that haven't seen it:

https://groups.google.com/forum/#!searchin/mvdbms/redwood%7Csort:date/mvdbms/k0GwsybgRdo/WcwU1tleBgAJ

That is a CLASSIC example of the state of the MV marketplace. There's just so many things wrong with that situation, I don't know where to start...

Where are the sales reps for them? Where is the customer support? Where are the demos of what they can do with their current system?

Why are we, as developers for X number of years, the only ones that know about MV? Everyone exclaims about the amount on knowledge on this forum. That's because we've all been around for decades, we already know what MV is, and are glad to use it. On existing systems, out of necessity.

Name one site that has recently decided to implement a large new system in MV because was shown to be a superior data model. Show me the press releases for a Fortune 500 company touting a new product / function / subsidiary that is designing new for an MV back-end...

I know of none. Only enhancements or maintenance of existing functions. As an MV champion, it's depressing.

[Ryengoth]

The MV data model is not superior to any other data model IMHO. It's just different.

--

[Jan Van Schalkwyk]

Strange?

I have been using Universe Personal Edition for many years now.

No emails back and forward.

Just a simple download from the Rocket website

What am I missing?

[geneb]

On Thu, 5 Jul 2018, Ryengoth wrote:

> The MV data model is not superior to any other data model IMHO. It's just
> different.
>

Heretic! Burn him!

:)

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

[Ryengoth]

I think metric is superior to imperial measurement so maybe I am a heretic. I'm not a witch though so don't get the duck and scales out.

[Charlie Noah]

Glen has been in the MV world a long time, and I believe he should know better. Of course, he's entitled to his opinion, but I am very surprised and disappointed.

Charlie

[Martyn]

Different and Superior are two interesting words to use and in some respects both ‘could’ be used.  To put some positivity into this thread, I often refer to MV as post-relational or NoSQL, depending who I’m talking to.  Usually post-relational because it is a lesser used phrase that gets peoples attention and it makes us sound a little more modern when talking to the uninitiated.

 

Anyway, I’m occasionally contacted by our VARs customers (our mutual end users) where the IT manager wants to know more about OpenInsight and this MultiValue data model.  Their enquiry is not necessarily from a technology point of view, but more because our VAR's systems have proven to be ultra-robust, highly scalable and they simply deliver on the changing business needs in a timely manner and year on year.  When I ask why this should be considered unusual, they talk about some of their other (mostly SQL and Java based) systems that are internally developed and third party COTS products.  The constant issues that I’m told about are scalability and  that they are often forced to upgrade hardware to cater for new versions, database admin is high with regular server reboots and very often they have to re-engineer modules to meet changing business needs. 

 

OpenInsight systems simply seem to run on whatever Windows supported kit they have, the systems are very scalable (one OI client scaled from a handful of users to the server’s capacity with NO measurable degradation in performance) and the software simply evolves with the business year on year with no major rewrites.

 

Yes, I think that you can say that we are different and with regards to the above points, we could also be considered superior.  Of course, the other systems are superior in other areas.  The superiority is therefore very much dependant on the end user and developers and what they need and are doing.

 

For me – it’s MV every single time.

[Martyn]

That is a CLASSIC example of the state of the MV marketplace. There's just so many things wrong with that situation, I don't know where to start...

Unfortunately this is becoming more and more commonplace ☹.

 

Where are the sales reps for them? Where is the customer support? Where are the demos of what they can do with their current system?

Perhaps the system was written by a third party that has since retired or an internal team that has long since moved on.  Either way, they see a loss of technical resource as a very real point of failure and the business is exposed too much. 

Had this been an OI based system and had the issues been brought to my attention, I’d have visited or contacted the end user and discussed ways that we could help to underwrite the system.  I’ve had several VARs retire and cash cow their businesses.  In such instances (and where they no longer wish to support their customer base) I try to step in to help keep the end user in place, upgrade them to supported versions of OI and in some cases we have taken over the solution to further develop and maintain it for the user base, all with the original author’s permission of course, or in some form of partnership with the original author

 

It is all about caring for your community, which includes your client’s clients.

 

Why are we, as developers for X number of years, the only ones that know about MV? Everyone exclaims about the amount on knowledge on this forum. That's because we've all been around for decades, we already know what MV is, and are glad to use it. On existing systems, out of necessity.

Because not enough people are talking about MV outside of these forums.  There are a couple of us Vendors talking about MV and marketing it but we tend to market our own flavour which dilutes the message from an MV developers point of view.  Plus there are too few of us with limited marketing budgets and limited reach.  We need the help of the VARs and developers to help to spread the word.  I feel that the developer community are very vocal on the MV forums but I see very little elsewhere.  If this is not true, please let me know where people are posting and I’ll gladly join in pushing MV to the masses.

 

Name one site that has recently decided to implement a large new system in MV because was shown to be a superior data model. Show me the press releases for a Fortune 500 company touting a new product / function / subsidiary that is designing new for an MV back-end...

You will not find any large companies talking about their use of MV, it is just not in their interests and they often don’t want to share something that is likely providing them with a competitive advantage.  For example, a few years back we had a major European bank (one of the biggest) using OI for a Self-Invested Pensions system (they still use OI but under a different name because the business was sold off).  The UK government made some legislative time critical changes and our client was the only SIP supplier to meet those tight deadlines.  This was a massive story with huge potential for Revelation and OI.  Were we allowed to use the story – of course not, the usual NDA was invoked and we were silenced. 

I have plenty of user cases like this.  One recent one is a national homeland security system that was produced for a very low six figure sum.  It’s still used but the person in charge of the project looked at other comparative systems and they were tens times (or more) more expensive and with less functionality and not specifically written for the department’s needs.

One of my favourite stories is a web based project.  I personally saw an opportunity for one of our VARs and pushed them for a time whilst the need grew.  We then released O4W and I needed to learn it.  I like to learn on real projects, so I wrote a very basic online Employee Self Service system – payslips, holiday request and management authorisation, etc.  It was written over a weekend and the VAR was so impressed they flew me over to their offices for a companywide demo and discussion.  The VAR then took what I’d built, commercialised it, hardened it and added some additional features that were beyond my very basic skills – I’m a salesman not a developer..  That system is now used by users of two of the biggest internet companies on a daily basis and we are looking to bring a third major internet company on board soon.  Again, I cannot name companies and the words here are about as close as I’m allowed to go without crossing the line.

I heard about a great story from another MV vendor who had a warehouse fully bar coded and driven by an MV system.  It was helping the end user to save untold amounts of money by optimising stock rotation and avoiding perishable goods from going out of date.  The system tracked both crates and forklifts throughout the massive warehouses.  Again, I suspect that the VAR is not allowed to talk openly about the end user.  Another way back when was speeding tickets issued by an MV system, we had something like a 3^rd or more people in the UK paid on an OI system, the stories that we cannot talk about go on and on.  Admittedly, they are fewer and fewer these days, but we vendors are reliant on VARs for these stories and the community is reliant on the Vendors brining in new VARs, and therein lies the rub.

A continued source of frustration for me is the lack of ability to scream and shout about large successes like these.  Until there is a change of mind, things will never change.

 

 

 

I know of none. Only enhancements or maintenance of existing functions. As an MV champion, it's depressing.

Agreed – the MV world depresses me on a daily basis.  I’m fortunate to have a good OI customer base with some strong VARS.  However, from a wider point of view, I wake up full of enthusiasm to find new clients and usually end the day deflated and frustrated.

[Andrew Cole]

This is a pretty good point. It reminded me that I haven't seen one of those "Our Customers" sections on anyone's website. I double checked; Rocket, Zumasys, OpenQM, MVON, and Revelation do not have those sections on their websites. I've attached screen shots of MongoDB and mySQL's home pages and both have it front and center. As trivial and petty as that can seem, for new devs looking at the tech it may help solidify that real companies actually use this tech. 

So, who does everyone think is MVDBMS' main target audience to market to? SQL users? MongoDB/other NoSQL users? Doing a google search on NoSQL doesn't pull up ANY MV companies and that's been a pretty hot keyword for a few years now.

[Martyn]

We have to be pretty careful using people's logos but I have some of our users case studies up front and centre on www.revsoft.co.uk.  Accessed from the Users menu item on every page - http://www.revsoft.co.uk/who-uses-openinsight.html.

Granted it is text heavy but RevUS have a similar list from their User Stories menu item which is again on every page (left hand menu) and they also have a Developers Network page which helps to promote our customers that offer products and services.  The ISV catalogue.

[Andrew Cole]

Right, I only looked at the home pages for all the vendors and if you're doing the logo thing it's normally front and center. I agree it would be a pain to obtain permission to use customer logos (if they'll let you use them at all) but from a marketing standpoint it may be worth the hassle? Confession: I only looked at your US site Martyn :)

[Wols Lists]

On 05/07/2018 20:53, Ryengoth wrote:

The MV data model is not superior to any other data model IMHO. It's just different.

You know my feelings about Relational ... that is broken in just so many ways it's not true ... starting with the fact that the 12 rules are self-contradictory and un-implementable ....

The MV data model is superior because it separates DATA from METADATA. It doesn't involve bashing square pegs into round holes. Etc etc. It DEscribes data, it does not PREscribe what data it considers is or isn't acceptable ...

And - from a mathematical standpoint - the generic model always trumps the specific. MV's multi-dimensional model can be shown to be a mathematical superset of Relational's 2-D model, therefore MV just HAS to be superior. And that's the maths saying that, not me.

Cheers,
Wol

[Kevin Powick]

On Friday, July 6, 2018 at 8:38:01 AM UTC-4, Wol wrote:

 

 

The MV data model is superior because it separates DATA from METADATA. It doesn't involve bashing square pegs into round holes. Etc etc. It DEscribes data, it does not PREscribe what data it considers is or isn't acceptable ...

That's one of MV's biggest weaknesses, actually.  Since the data model itself cannot prescribe (enforce) what data is acceptable, data integrity falls upon the application programmer. Both TAX.RATE = 7.5 and TAX.RATE = "Hello Kitty" are valid in an MV system if the application code allows it.   

Sure, the above example is contrived, but in any MV system of even moderate size, the amount of information a developer *must* know when writing their application is a cognitive burden.

Considering again "TAX.RATE", what is the acceptable range of values?  All the developer can do is look at the dictionary, hope that it's up-to-date, and maybe compare it to data that may already be in the file.  However, in a RDBMS, the data type and range of acceptable values can (should) be implemented in the data model itself.

Also, having the data integrity enforced in the model reduces the likelihood of corruption via data updates from any/all sources (e.g. program, editor, external DB connectors, etc.).

Having said this, good design and abstracted update routines can help to mitigate integrity problems in MV systems, but such approaches are not as common as they should be.  Also, nothing prevents a "rogue programmer" from screwing the whole thing up because they can write directly to the database for which no (enforced) data model exists.

The only mechanism in MV available to enforce the data model at the file level is a Trigger.  Not only are these rarely used, especially to enforce data integrity, they impose a not insignificant performance penalty on data update operations.

--

Kevin Powick

[S Yeomans]

But, and this is kind of a rhetorical question, why are companies loath to say "I'm using MV"? Non of them have any problem saying "I'm using MS SQL, Linux, SAP, etc etc)

It's the stigma that already exists, stemming from ignorance on the part of companies and/or the marketplace that either MV doesn't exist or that it's green screen only, or whatever.

Believe me, I understand the power of buzzwords and marketing (witness: mainframes -> client / server -> cloud & SaaS...I mean, how is that progress? It's not. It's marketing.)

Anyway, Martyn: It's too bad there's only one of you. There are multiple marketing areas that MV lags: Perception, Marketability, Visibility, and assurance that a company going with MV is moving forward, not back.

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

-- 
‹(•¿•)›

[Donald Montaine]

The loss of a open source version of QM was the harbinger of the eventual death of the MV world.  It may be too late, but a true open source MV database is absolutely necessary if the MV world is to have any hope of growing.  All the trial versions, personal versions, etc. are simply insults when the SQL and no-SQL worlds offer a ton of 'no cost to play' offerings that encourage hackers to become interested in a technology.

[geneb]

It wasn't "lost". It's still out there. So is the fork of it,
ScarletDME.

[Wols Lists]

On 06/07/18 22:42, Kevin Powick wrote:
>
> On Friday, July 6, 2018 at 8:38:01 AM UTC-4, Wol wrote:
>
>
>
> The MV data model is superior because it separates DATA from
> METADATA. It doesn't involve bashing square pegs into round holes.
> Etc etc. It DEscribes data, it does not PREscribe what data it
> considers is or isn't acceptable ...
>
>
> That's one of MV's biggest weaknesses, actually. Since the data model
> itself cannot prescribe (enforce) what data is acceptable, data
> integrity falls upon the application programmer. Both TAX.RATE = 7.5 and
> TAX.RATE = "Hello Kitty" are valid in an MV system if the application
> code allows it.

Firstly, what's wrong with strictly separating data and metadata? The
fact that Relational forces you to muddle the two is a serious problem.

Then we extend the model :-) Yup, I agree with you the lack of strict
data typing is a big weakness, but enforced strong typing is an equally
big pain. I'd love to add strong typing as an OPTION.

>
> Sure, the above example is contrived, but in any MV system of even
> moderate size, the amount of information a developer *must* know when
> writing their application is a cognitive burden.
>
> Considering again "TAX.RATE", what is the acceptable range of values?
> All the developer can do is look at the dictionary, hope that it's
> up-to-date, and maybe compare it to data that may already be in the
> file. However, in a RDBMS, the data type and range of acceptable values
> can (should) be implemented in the data model itself.
>
> Also, having the data integrity enforced in the model reduces the
> likelihood of corruption via data updates from any/all sources (e.g.
> program, editor, external DB connectors, etc.).
>
> Having said this, good design and abstracted update routines can help to
> mitigate integrity problems in MV systems, but such approaches are not
> as common as they should be. Also, nothing prevents a "rogue
> programmer" from screwing the whole thing up because they can write
> directly to the database for which no (enforced) data model exists.
>
> The only mechanism in MV available to enforce the data model at the file
> level is a Trigger. Not only are these rarely used, especially to
> enforce data integrity, they impose a not insignificant performance
> penalty on data update operations.
>

And strong data integrity requirements don't impose a performance
penalty on relational systems? Thing is, they optimise to reduce the
burden, so why can't we?

Yes rouge programmers in MV can get round a lot of constraints, but I'd
like to have strongly typed variables in BASIC, and strongly typed
fields in FILEs. I don't see why the database can't have FILEs which are
declared strongly typed, which enforce only one D-type per field (with
synonyms if required), and which allow said D-type to define valid
values. Yes I can think of plenty of ways a determined programmer could
try to bypass such stuff, multiple dictionaries for example, but
properly enforced if a programmer does try to "get round the system",
they're going to come a cropper as they break something else elsewhere.

Cheers,
Wol

[Kevin Powick]

On Sunday, 8 July 2018 13:07:14 UTC-4, Wol wrote:

Firstly, what's wrong with strictly separating data and metadata?

Nothing.  It's a technical detail for the vendor to implement.

 

The fact that Relational forces you to muddle the two is a serious problem.

What is this "serious problem" and how it might affect an application developer?

Then we extend the model :-) Yup, I agree with you the lack of strict
data typing is a big weakness, but enforced strong typing is an equally
big pain.

Contradictory statements.  Please explain how a database that enforces integrity at the model level is undesirable.

 

> The only mechanism in MV available to enforce the data model at the file
> level is a Trigger.  Not only are these rarely used, especially to
> enforce data integrity, they impose a not insignificant performance
> penalty on data update operations.

And strong data integrity requirements don't impose a performance
penalty on relational systems?

My statement wasn't a performance comparison to relational, just that using triggers in MV impose a penalty.  They might also in a RDBMS.

 

Thing is, they optimise to reduce the
burden, so why can't we?

Maybe the vendors can, but the first step is a mechanism for model level integrity. 

 

I'd like to have strongly typed variables in BASIC, and strongly typed
fields in FILEs. I don't see why the database can't have FILEs which are
declared strongly typed, which enforce only one D-type per field (with
synonyms if required), and which allow said D-type to define valid
values.

I fully agree, but this seems opposite of your initial claims which inspired my response.

When it comes to strong typing in BASIC, one feature that would ease the tedium of variable declaration is inferred typing.  e.g. X = "Hello" would automatically set the type of X to String, and not let it be changed by something like X = 21.  I would also like to see block level variable scoping by default. i.e. Variables inside of subroutines, loops, etc. have local scope.  Global variables could (optionally) be declared.

 --

Kevin Powick

[Cleber Vieira Baptista]

MV is depleted, no open source, no less technical group, no code examples, no large and strong community, with old programmers retiring and unwilling to deliver some knowledge with open codes. MV will wither and die.

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--

Cleber Vieira Baptista

+55

 61 8441-1663 Oi

 

[grant...@prosol.co.za]

Hi All,

Perhaps Typescript is an Avenue we should be looking at. JavaScript has some uncanny resemblance to to MV BASIC. It is untyped and manages objects in a similar way to our BASIC. Perhaps our compilers should more clever when evaluating what we are attempting achieve by checking our source code at compile time.

I am not in any way saying we should ditch BASIC but highlighting the fact that MV vendors should be adopting industry standard compiling and linting processes to our environment. A bit off the wall but would love to hear the forums views.

Cheers

[Peter McMurray]

Fascinating one and all. Great to see discussion.

Marketing has always been a disaster. I still shudder at the thought of the crap rap trip. Did anyone visit RMIT who used Pick as a teaching tool because they could achieve more in a semester than they could in three semesters with relational. No! one of the major Pick suppliers banned their people from attending the RMIT Pick get together. Probably as they did not want people knowing who used it.

Why are we now shouting Python - a tool designed by a Russian programmer to simplify coding thirty years ago - because it is taught in schools. Where is the free schools Pick edition?

I made enquiries about OpenInsight and understood that it was going to cost me over $AU2000 to get in. I was contacted by a chap who works from home in New Zealand as their rep.

Perhaps there is a breakdown there. Anyway 30 days is too short to evaluate such a massively different product albeit I agree with the modern interface idea.

Pick Multi Value is a great tool but for too long people have used it in a sloppy manner. We recognised the power and designed File and screen formats forty years ago. Yes it requires discipline but the average programmer lacks that drive. That is why I abandoned C as a tool that I loved - it is rather like giving a learner driver a formula one car.

It is possible to have sound Pick design that fits however the system designer must control CRUD. That is easy to do and enforce. Nowadays our approach is called single page application and the file design is called class.all controlled  by write once use many subroutines. The Python interface allows the classes to be used by front end programmers safely. Where are the working designs for that or for that matter the D3 Windows interfaces. It is no use saying to a Basic programmer "Oh! a .Net programmer would understand", actual example. That is no use because the .Net person doe not know Pick and training costs money.

[Ryengoth]

Much of what you describe is inherent in Progress. One of the reasons I say MV is not superior is because Progress ABL fills many of the real world faults when trying to use MV to actually build a business process. In my opinion Progress is superior to MV in most facets of building and deploying maintainable business logic.

--

[Donald Montaine]

10 yr old open source code is 'lost'.  Actually, it's worse than never having an open source version at all.  It's like a big sign saying "Don't enter here, no one cares".  If any vendor really cared about developing and expanding the MV world they would buy QM from Ladybridge, release and maintain it as open source and use it as the "entry level drug" into the MV world.  It would be the cheapest and most effective marketing program that could be devised.  But instead they all sit around milking the old cow until it dies and try to steal the remaining customers from each other.

[geneb]

On Sun, 8 Jul 2018, Donald Montaine wrote:

> 10 yr old open source code is 'lost'. Actually, it's worse than never
> having an open source version at all. It's like a big sign saying "Don't
> enter here, no one cares". If any vendor really cared about developing and
> expanding the MV world they would buy QM from Ladybridge, release and
> maintain it as open source and use it as the "entry level drug" into the MV
> world. It would be the cheapest and most effective marketing program that
> could be devised. But instead they all sit around milking the old cow
> until it dies and try to steal the remaining customers from each other.
>

I eagerly await the news of your purchase of Ladybridge.

Keep in mind it would be vastly cheaper for you to start contributing to
the existing open source projects. But that wouldn't help your narrative
at all, now would it?

[Wols Lists]

On 08/07/18 21:31, Kevin Powick wrote:
>
> On Sunday, 8 July 2018 13:07:14 UTC-4, Wol wrote:
>
>
> Firstly, what's wrong with strictly separating data and metadata?
>
>
> Nothing. It's a technical detail for the vendor to implement.
>
>
> The fact that Relational forces you to muddle the two is a serious
> problem.
>
>
> What is this "serious problem" and how it might affect an application
> developer?
>

Firstly, let me define what I mean by data and metadata. Data is what
you get from the user, metadata is what you infer from that data.

So the very act of converting to 1st Normal involves converting huge
chunks of metadata into explicit data. For example, if you have a list,
you need to create a field to sort by - the contents of the field are
meaningless, what matters is the collate order.

So I know you said that a Pick application developer has to remember
what type fields are supposed to be, but this problem with relational I
would say is of equal severity. In fact, I would say it's worse, because
another consequence of normalisation means that you are forced to break
Relational's own rule of "no storing duplicate data", simply in order to
convert stuff to 1NF (of course, relational fans don't see it that way).

>
> Then we extend the model :-) Yup, I agree with you the lack of strict
> data typing is a big weakness, but enforced strong typing is an equally
> big pain.
>
>
> Contradictory statements. Please explain how a database that enforces
> integrity at the model level is undesirable.
>

Implementation detail, but how many Relational databases can actually
correctly enforce a type of "Number"? Bear in mind this includes "Not a
Number" and "Infinity". How many databases can enforce a type of "Age"
bearing in mind this can include "dead", "not known", and "not applicable".

The point is, I can imagine that there are many situations where you do
not want to enforce integrity (as well as many where you do!)

And as an ex FORTRAN programmer who had a habit of both declaring all my
variables using implicit typing, and telling the compiler "treat
implicit declarations as an error", I think inferred typing is a mistake ...

As for my apparent initial claims, I want *optional* strong typing. So
the sequence

X = "hello"; X = 21

would be fine. But the sequence

NUMBER X = 21; X = "hello"

would fail.

However I would probably permit things like

NUMBER X = "21"

and just let it create a "coercion of string to number" warning.

The point is, I want existing stuff to work with the current
loose/non-existent typing, but I want to be able to declare and enforce
typing when it makes sense - which is most but not all of the time.

Cheers,
Wol

[Will Johnson]

To address a few points made here.

The ERP we use here was written in-house.

We have four full-time Pick programmers, the youngest of which (me!) is 55

So we have no sales rep of the kind that works at a third-party company.

Any vendor who bids, would have to replace the entire system, including the functionality.

[Bob Markowitz]

My four cents (hey Dick T, I doubled you).  Let’s get back to Peter’s post in this “Where to Now” conversation.  The discussion Peter started is centered on all things server with a slight turn to the left (or right) mentioning the web.  All of the pieces discussed are and I paraphrase, why the Pick system is better than the rest (or not); what the Pick system can do (or can’t); the wonderful new tools that have been added (or not), for example Python.  

 

We all agree that we have lost the marketing battle.  For those young Pick developers not aware of history – it all goes back to not having a single organization owning the Pick system (see Microsoft, Oracle, Progress) but I digress.

 

I also seem to be the only one that is seeing the elephant in the room.  I tried to change the direction of the conversation in an earlier post to this group but no one picked up on it.  It is probably because I work for the only organization that can make any system including Pick (Oracle, SQL Server, Apple) have an adaptive, Modern User Interface (GUI is now so passé’) that runs on the web, desktop and mobile devices.

 

No one (I may have missed it) is discussing what customers want to buy, what legacy system end user organizations want to see on their computer screens and that both groups probably want everything to run native on mobile devices!!!    

 

Want to know “Where to Now” and save Pick from dying?  Present the user with what they want and give the Pick developer the option to use the business logic and database strengths of Pick from the legacy app; let the developer add the new stuff coming from their database vendor with the caveat that it is from their vendor and may not work with other Pick implementations. Write a NEW PICK APP that runs on everything that presents a MUI.  For the most part, today, Pick applications almost certainly have more features and functions than their competition BUT unless it is pretty and runs native on a desktop and mobile device the Pick app will not win the developer (VAR) new business.  Without new business…

 

Commercial time, investigate Evoke from BlueFinity!

On Thursday, June 14, 2018 at 4:24:37 PM UTC-5, Peter McMurray wrote:

Rocket has added Python to U2 and D3 come November. Why?

Millenials are now the buyers, users, decision makers in our business. The goal posts have moved and if we do not move then there is a danger of the baby going out with the bath water..

They are looking for Full Stack developers and or people who fit into one of the three major levels.

I said not too long ago that all we needed was FlashBasic and a simple link to the web. Not anymore...

[Donald Montaine]

Open source projects within a closed source community do very little to encourage new / younger people to become interested in the product.  They may help existing users, but the cost of entry when compared to fully open source solutions is very high.  Seat licensing makes it even worse.  I do my non-MV work using a product that costs me $1100 per year.  However, there are no distribution costs at all.  That $1000 would buy what, 1 installation of three or four users for U2 or D3, and one installation of 8 users of QM?  And then to give the user a 'modern' interface, I have to add additional licensing costs on top of that.  If I am any kind of small start up, I am not going to add that kind of cost to what I am making. 

I am not an open source developer.  I make my income off of non-MV closed source development. However, since I was an MV programmer for most of 30 years, I still play around with MV as a hobby.   But I realize that for most of what is being marketed today, the MV pricing model does not compete against the products that are being used now by the newer generation of developers.  If I was a young developer, why would I take on the burden of convincing my prospective customers to pay thousands of dollars to implement my solution before I make a dime when I can use open source products to develop my solutions and then pay very reasonable commercial licensing fees for dual licensed software when my solution becomes marketable.

Or, that young developer could do what I do, pay a yearly licensing fee for a tool that has a built in database that can be accessed either with SQL or with procedural programming, or I could use the free connectors to MySQL, MariaDB and PostgreSQL with no need for the hassle of customer licensing.

I never said I wanted to buy a software company.  I just said that MV needs a functional, no cost of entry option,  that can help produce real solutions if it is to gain mind space with young developers.  I used QM as an example of a way to do that as it is the simplest MV product to manage.  A entry level version would be enough to at least allow young developers the opportunity to get hooked on the MV data model.  Enterprise level features could be priced accordingly.  

I don't expect that to happen, just believe it would help move MV beyond an aging bunch of users ( of which was one).

[geneb]

On Mon, 9 Jul 2018, Donald Montaine wrote:

> Open source projects within a closed source community do very little to
> encourage new / younger people to become interested in the product. They

This is effectively correct. However, instead of contributing towards a
solution, you offer nothing but excuses and criticism.

You're the epitome of what's wrong with the MV ecosystem - when someone
asks you for something, your instant response is "pay me" and not "what do
you need help with?".

Being a "closed source" developer isn't a thing - you're just a developer
that choses to not participate in open source projects (although that
doesn't appear to slow you down in your criticism of them). I've been a
"closed source" developer for over 30 years, and I've contributed
thousands of hours of work to open source projects because it's a fun
thing to do. Sure, I could be like you and carry a "Pay me or GTFO" sign
all the time and I'd probably be considerably better off financially, but
I'd be lesser person because of it.

One thing I've noticed about the multi-value industry over the years is
that the motto seems to be "Money Uber Alles". If there's no money to be
made, then there's no effort to be expended.

The only good thing in this avarice-laden industry is Ladybridge. Not only
did they open source their product, but the commercial version is
reasonably priced. I'm not a fan of per-seat pricing with anything, but
at least they don't rob you like Rocket does.

There's nothing wrong with not wanting to contribute to open source
projects. If that's not your thing, so be it. However, if you're not
contributing, it makes you uniquely unqualified to criticize and all
you're doing is booing from the cheap seats.

[Will Johnson]

Cleber above stated that there are no code examples.  However there are plenty of code examples right here

http://pickwiki.com/index.php/BasicSource

[Donald Montaine]

You have absolutely no reason to be an ass.  I have not been criticizing open source projects, if you had actually bothered to read what I have said. 

My statement was to the effect that MV is suffering because it is not dealing with the marketplace as it is now.  Open source projects, from MySQL to MongoDB are driving most of the new development in the world.

I started out by saying that the lack of a current, maintained open source MV database (ie: OpenQM) was the beginning of the end for the MV community because it has nothing to compete with the "no cost of entry" databases currently available.

Again: I was not criticizing open source - nowhere did I say open source was bad.  In fact, I said that the lack of entry level open source core (as in the actual databases) was an fatal underlying problem for MV.

Please read before you criticize.

[Dick Thiot]

***WARNING*** This is a lengthy post.  Proceed at your own peril...  It is not the first lengthy post in this thread though!

I'm not quite sure where to begin my comments on this discussion.  

First Gene, I have to agree with Donald.  It seems to me that Donald is providing his opinions.  Are his comments invalid because he doesn't contribute to the open source project?  

Second, Bob M, that was pretty close to pure promotion of your product since as you say it is the only product to do what you say that it does.  You likely have a great product in Evoke but like my comments below regarding the database, it isn't necessarily the best choice for every project.  You are after all a salesman so I expect you to promote your product like it is the be all and end all.  I have this personality flaw that I can sell a product to everyone.  If may not be the customer's best option.  We have so much technology available to us today and we should leverage our own skills and develop skills that allow us to accomplish the expectations that we need to meet.

With that lead in, my real comments are relative to the MV database.  I am not sure why we think that MultiValue is the best database in the market.  There are many choices and someone's chosen database is based on a multitude of factors.  MultiValue has a place but it is not the be all and end all.  It has benefits and if those benefits are important in your project then it can be a viable choice.  I think that our attitude that MV somehow is superior to all other databases is part of the problem that we have.  MultiValue doesn't somehow make us superior even though we seem to have that attitude.

The beauty of MultiValue is that it allows developers to easily develop applications without some of the restrictions that require more time in other environments.  That however, is a two-edged sword.  Without those restrictions a developer or even an end-user can do things with the data that they maybe shouldn't for a multitude of reasons.  It can also make it difficult integrating with outside processes and entities that expect data conformity.  Expecting the developers to implement data conformity is in many cases unrealistic and fraught with peril.

Another benefit to MultiValue besides flexibility is that it runs using very little system resources and does not require a large support staff to maintain it.  However, those same features also make it less desirable for some sites that want more control, security, etc.  

Please keep in mind that these comments are generalizations and if they don't apply to you individually please don't take offense.  If they do apply to you don't take offense either.  Just recognize that then give it some thought rather than flaming me.  This group tends to be very hard on anyone who doesn't conform to the beliefs that MV is the best database every created and anyone is foolish to use something else.  That kind of makes us a cult, doesn't it?

--

[geneb]

On Wed, 11 Jul 2018, Dick Thiot wrote:

>
> First Gene, I have to agree with Donald. It seems to me that Donald is
> providing his opinions. Are his comments invalid because he doesn't
> contribute to the open source project?
>

I grow weary of the incessant criticism. There's far too many people
willing to be part of the problem instead of the solution.

I've never taken hooting from the cheap seats very well, and probably
never will. From my standpoint, if you haven't done a thing, you're not
qualified to criticize it.