Nothing which was really helpful with our business until now, especially nothing inside U2

• I have tried to let chatGPT let create some UV-basic-Code but failed, - had to write it my own.
• I had a discussion what chatGPT knows about SBXA and System builder :-)

Mike,

I have been using ChatGPT+ and Co-Pilot with Visual Code. I have generated some UV BASIC code with ChatGPT+ after a bit of prompting. I think that ChatGPT does not fully understand the UV BASIC syntax. I have generated a UV BASIC program to calculate a loan payment. However I feel that just generating UV BASIC code is missing the point of using AI. It can also provide documentation about code as well as review code as a collaborator. 

I feel that it's inability to generate usable UV BASIC code on the first try puts AI in an unfavorable light. I have used it to assist me with writing Python and JavaScript code using Co-Pilot with excellent results. I have used ChatGPT to review documents I have written to give me suggestions to improve my writing. It is a new technology and as such has some learning curve. AI is akin to search engines like Google. Would any of us wish to live without Google? AI is a paradigm shift in technology. I liken it to the next search engine revolution. I will retire soon and intend on using AI to assist me with some coding projects I'm planning to work on. I believe it is the wisest use of $30/month.

Jon

Wish List - An AI-enabled conversion tool that takes UV-Basic and not just translates to U2 Python but automatically rebuilds to 'best practices' - which is in itself needs to evolve with AI-enabled low/no-code workflows.

this post has been shortened due to its length

I've left the MV industry for the most part and now do a lot of AI work. One of the reasons I left after over 35 years is that there is a lack of vision in this industry, from Rocket (all former DBMS providers) and from the developer sector. With no vision we lose end-users. As we lose end-users, there is an attrition of developers. This leads to Rocketing raising prices and looking for other ways to maintain acceptable revenue. That perpetuates the cycle and just reduces the size of the audience that justifies my continued investments in this industry. So while I could have geared up to provide AI services for this industry, as I did for EDI, web services, web development, desktop  GUI, telephony, app integrations, mobile, and other tech - I decided to hop off the MV train.

The question "What are you thinking or doing with AI around your MV app?" is a good one to ask, but inherent in this is the implication that MV apps are somehow different from the rest of the world. <...>

From the few responses here (yet another bad sign for this industry), we see (1) limited understanding of AI and the tooling, (2) nothing about integration or using AI integrally with MV, and (3) nothing about user requirements.

1) ChatGPT is a sample application that uses the underlying APIs to integrate with OpenAI LLMs. It's the gateway drug, the Hello World to get people used to the concepts - it's not the final product. ChatGPT is not AI, no more than your business application is "Pick". ChatGPT is a minimal front-end that provides only a glimpse into what is possible with the tooling. When asked "what are you doing with AI" and your response is "I'm using ChatGPT", then you're not actually using the technology.

The GPT Large Language Model used by ChatGPT, is just one of many such models. A LLM like GPT is (for the most part) a text database for the purposes of processing text. It is not an information database. It has information and has been fine-tuned for its public audience to link information in predictable ways. That information comes from public resources. There are extensive discussions, articles, Q&A sites, books, videos, and other resources available for mainstream tech like JavaScript, Linux, MySQL, React, WordPress, and web services. That's the source of information on those topics. For MV we have limited public resources - just a few blogs and articles, very few GitHub repositories with MV BASIC, and a small handful of public forums that have always had low traffic. So it's reasonable that a LLM can't forge the same sort of insightful links for the creation of BASIC code as it does for others. To address this, anyone can  create a Custom GPT (free and easy), providing text or PDF files that represent everything that you would want to ask about. Scan and prune the decades of forum insight. Get PDFs from Spectrum and old email newsletters with golden insight published by VARs in the 90's. Add all PDF product documentation from U2, D3, QM, mvBase, jBase, and others. Find GitHub repos, and resurrect PickWiki and similar sites. Make all of this data available to a LLM, and then it will be better able to understand and generate BASIC code, F-correlatives, I-Descriptors, SB subroutines, and TCL/ECL statements. Add to that the schema of your own applications in a common format like JSON, and it will be able to create application-specific commands.

2) Integrations: MV can be used integrally with any LLM. It can be interfaced with other APIs and participate in Q&A sessions for data, system management, and so many other purposes - just like every other database.

You can escape the confines of the primitive ChatGPT application by using any of many APIs that allow you to attach to any LLM, send requests, and receive responses. There is an evolving world of patterns for conversations, memory, and data access. You can use any available MV API to interface with your MV system (UO, Linkar, mv.NET) or you can directly use the Python integrations for these MV platforms. This will allow conversations from TCL, mobile apps that function like ChatGPT but produced by you and not related to such public services.  You can use the tech to watch for changes in data patterns or system resources. That is - rather than asking for code to do these things, use language to monitor your data so that you don't need to write code. With new vision I/O and speech I/O, think about how your business software can be used with new user interfaces. The world is talking about dumping Graphical User Interfaces now (clicks on textboxes and buttons) and interacting with machines with vision, motion, conversation. Add to this concepts like weather, location, traffic conditions, and other factors that factor into business flow. Most people here are still stuck with character-based screens, hesitant to jump on GUI (or mobile or B2B services or ...) and now the world is starting to think differently. Participate in this. Your MV system and all of your skills can be used here.

3) User requirements :

A better question would be "What are your users asking you about AI?" Forget MV. How many times have VARs said "I sell applications, not databases"? VARs actually sell solutions in the form of applications. MV app users are no different than any other in terms of their business requirements and expecations from their vendors. The issue this industry has always faced is that end-users don't perceive that their MV VARs can provide the kind of "value-add" that is required to support their modern needs. So without even asking for AI integrations or others, end-users have historically met behind doors, decided that migration was necessary, and notified their VARs that they would not be renewing their maintenance agreements.

So if your users are not asking you about AI, something is wrong. Everyone here needs to start asking end-users what dots they are connecting between their business and modern technology, and let them know that you will provide solutions if they continue to commit to the application. Don't think about "how do I connect AI to MV". Technology is irrelevant. That's never been the tough part and I've written about this many times over the decades. The tough part overall is ensuring that you have a firm plan to serve client needs, whatever they are. Identify costs and resources for attaining goals, establish ROI, and just do it. Or the hemmorage of end-users from this industry will simply continue.

Offer something to your users and see if they'll bite:
- If you get a lot of requests for custom reports, and you'd prefer to allow them to generate their own (if that's not your revenue model), you can use ChatGPT to allow users to ask questions about their data, pass requests to your system, and process the requests into AQL/English statements. Return the data in a common format and let the user decide how they want it rendered.
- Think about things like asking your customer file about current client sentiment, and try to link that to changes in products, pricing, marketing, or outside trends.
- Think about correlating business sales to general social media traffic or sentiment on specific topics : Might your client expect more or less sales when there is more news or buzz about a specific topic? Have they been caught short on inventory in those those times? Predictability can help to secure orders that might otherwise go to competitors - companies will pay for that.
- Think about defect tracking that links finished-product returns to changes in assembly components (source, cost, size, etc). We used to code for this. Now it's easier to log data and have the AI look for patterns.
- Consider linking shipment commitments with news, like trucker strikes, train derailment, weather, local holidays, or local traffic conditions. Again, we used to code for this - or we chose not to do so because it seemed too tough.
- What about automatic product documentation updates based on code repo commitments or customer support exchanges? Customer: "I have a problem with 'this'." Tech: "The answer is 'that'." Documentation: "Enhancement proposal, add 'that' info about 'this'."

Not realistic? This is exactly what companies are doing with AI now - and yes, you can do it too.

Or try just talking to users, like Mike did here. Ask them in groups or one-on-one (don't just do a cold survey, this should be a personal discussion) : What are You thinking about this in relation to your business? How can we help? That simple question might defer or prevent the closed discussions about migration.

<..>

I left this industry in part because questions like this, about the phenomenon of the milennium, tend to result in just a few responses as we've seen here, and all of those responses miss the fundamental marks. Rocket can't continue to look for inspiration from the MV-focused developer base and expect anything to change. Rocket needs to lead with information, vision, a can-do attitude, and significant drive to inspire the developer base to create new modern offerings to address contemporary business needs - for the existing client base and hopefully for new clients. Unless Rocket leads, the trend will continue. That's not supposition, malaise, apathy, or pessimism - it's easy to recognize, direct observation of this industry over a period of decades.

Developers, drive Rocket to do better.
Rocket, drive developers to do better.
End-users, drive all of your vendors - the cost and pain to replace them is higher than it is to keep them.

Mike, you can take that ball and run with it. I've tried getting others there to do so. No one seems interested. I'd love to see it happen.

Tony Gravagno
Owner
Nebula Research and Development
Mission Viejo CA US

Perhaps Rocket would consider developing a lightweight _ cloud-based _ MV database. 

I don't think Rocket listens anyway. If they did, they'd get SB+ updated. We do all our development and testing work using SB+ and then use it in the finished product. Then we use MVSToolkit to get it on the web. The MVSToolkit takes two ot three times as long as the process from initial design to completion in SB+ and obviously costs a lot more. If you want to keep us in the mv space, look after us and listen to us. I bet as usual, that this will be moderated out of the discussion because we don't like negative feedback.

"I completely agree with you. We also develop all business processes in SB+ and only use other UIs where absolutely necessary, as the development process in SB+ simply works much faster and better. I would like to have an SB+ toolkit similar to Flutter, preferably in Basic or as a paragraph process..."

Alex,

While I do not like hearing that you think Rocket does not listen, I appreciate the feedback. 

I understand your concern how long it takes you to build/enhance your MultiValue solution, in fact Developer Productivity is one of the spokes in the Modernization Wheel. 

Please start a new thread about your concerns around the speed of development in MVSToolkit, since in addition to Rocketeers who frequent the forum, there may be others who resolved these issues you are experiencing.

I would also suggest that you follow the MultiValue Tools forum, since it includes discussion around SBXA.

Note that SBXA is an evolved version SB+, offering more modern features and capabilities.

Unfortunately, still not listening. I have been using Pick/D3 for over 35 years and System Builder and SB+ for the same amount of time. In fact my  original SB+ licence was Number 6. In that time I have seen businesses move over to Universe/Unidata etc and they have ALWAYS complained about the move. I have also then seen some of those move out of the MV space completely. SBXA is a Universe product only, so is of absolutely no interest to us whatsoever. SB+ on the other hand still works with the latest D3 and works extremely well I might add. No doubt Rocket will one day purposely break that in an effort to force the move to Universe and at that time, we too will exit the MV space. It beggars belief that you have a product that is loved universally, (no pun intended), and you do everything possible to kill it. I think that you would be surprised at how many users would willingly pay for support if you updated SB+ for D3. Who knows, you may have to stop raising prices on the dwindling user pool.

------------------------------
Alex Polglaze

The Book-Keeping Network
Perth Western Australia
+61419 776 348
apolglaze@book-keepingnetwork.com.au
https://www.book-keepingnetwork.com.au/
------------------------------

Alex,

Thank you for the additional information, I incorrectly assumed from your first post, and others, that the issue was with  MVSToolkit, and a desire to improve the development environment.  That is why I suggested you start a new thread for that topic.

I hear you, I will look into what you presented, and if needed I will reach out to you directly to get some clarification some of your statements.

Feel free to contact me anytime. I love talking about SB+.

Hi Alex,

I'm certainly no apologist for Rocket but I do think the fundamental problem is you are potentially talking apples and pears. 

SB+ and the web are diametrically opposite: when System Builder first released SB+ they had the chance to embrace modern technology and come up with a model that separated the design from the runtime, which could then have been technology agnostic and moved with the times. Instead, they chose to keep with what they knew and produced a better SB6, but still with all the issues that created - constant navel gazing, completely stateful and as soon as you get beyond the screens and forms to the logic behind, all the complexity still based around the common block and injecting processes.

Don't get me wrong - that works fine for stateful and heritage applications: but it just doesn't translate to the stateless and asynchronous nature of the web - it can be emulated with a lot of effort, as SBXA offers on UniVerse, but that translates into complexity and therefore cost. It's also working against the model.

So whilst using a tool like MVS Toolkit is more expensive - the bottom line is that developing for web is always expensive. It's also a constantly moving target - whether you are using  Angular, vuejs, Blazor or another grown-up stack that changes every five minutes. These things are far (far) more complex than SB+ has to be and the maintenance overheads that come from keeping up with standards (real or de-facto) , security (real or imagined) , testing or responding to whatever latest lunacy from Google et al keeps it so.

We've all been spoilt with how easy and cheap it is to develop on MV platforms and it's probably just not cost effective for an organization like Rocket to absorb the costs of meeting those expectations for web development across all the platforms. It's no different outside the MV space: if you were developing on SQL Server you would still go through the same pain. You still have to design your web forms, write your TSQL (hopefully), do your validations, etc. etc.

As an aside, I have, in the past, helped migrate sites from D3 to UniVerse and they certainly haven't been unhappy with the move, once they have learned the differences and how much the platform has to offer. It's a learning curve, and perhaps it is more about education.

My position was not meant to say that SB+ should be all encompassing, but rather it should be upgraded to take advantage of the changes to hardware and the D3 itself. As it is fast and nimble, development is quite easy. Once a system is tested and working, then webifying it is another process. Yes it would be good if there was an SB+ equivalent that then took that code and translated it into a web application without having to virtually start from scratch again. Who knows, it could be called Web Builder+ (WB+), but that is for another day. We just assisted a client update and relicence their D3 legacy system from more than 20 years ago, because it keeps on working. That is my point, D3 and SB+ just keep on going, but they do need a bit of love and care.

Jumping in to add an upvote to Alex P.'s remarks. I love SB+. I think--and have always said--there is a place for rapidly developed and maintained screens and whole systems inside U2. I don't love the GUI interface but I have many clients who don't mind it a bit.  I still think our ability to quickly create great apps is a huge advantage.

There is such a cognitive dissonance for our less technical end users and executives that see a lifetime of success in the applications and how much many people really (still) love SB+ -- and some clanging in the background telling them they're supposed to think it's a bad thing. A few changes to the actual host-based development side of SB would go a long way, but we've been banging on about the lack of a "web interface" for so long that we've killed the enthusiasm. 

I always look for why. I can't find an easy answer in this case other than "resources" which is a story about a snake eating its own tail. So really, I'm just here to add "Like Alex said."  

Susan Joslyn

p.s. AI will be an information/database thing.  Cranking up UI screens for criteria and questions or to view answers would be another good use for SB+. How do I know? We were doing it in the 1980s.

I will also add my thougts about SB+ (sorry because this is not the main topic of this thread..)

The application Im working on (alpha) is a SB+ (SBXA) Application running in UV11 which I developed about 27 Years ago.
I stopped MV World for about 20 years and did .net Development during the most of these 20 years.
The Company I currently work for has bought alpha 25 years ago and called me because they are still growing and the main programmer is near at his pension.

All the last 25 years the development in alpha was continued.
Nevertheless alpha is still easy to maintain and to expand and it is really fun to work on it.
I have never seen a product which was so maintainable after such a long period of development in no other Dev-Environment.

The only Thing that we really miss is a good UI Framework to replace the Non-Gui Screens - Not because they are ugly but because there is not so much space.
The users support alpha by 100% there are no doubts..

------------------------------
Thomas Ludwig
System Builder Developer
Rocket Forum Shared Account
------------------------------

Hi Brian,

I take a position that's more of a middle ground, and I'll explain why in a moment; but I do see Alex's broad point. Unfortunately when I pressed Rocket senior people on the possibility of SB+ being made available in flavours other than U2, I was told SB+ post v5 is far too embedded in Universe tech to be re-engineered to d3. Dead end.

Part of that I think was due to the politics of VMark who at the time owned BOTH SB+ & UV if memory serves; so they had ZERO incentive to make dev available on a competing mv db. n fact, quite the opposite. It is only now that they are all under the one roof; that we wish things would improve. But they shan't in this respect.

However to bring me back to your point about the SB+ 'method' and web development 'method' I do see and take your point that Web development can and should be about separation of UI from db etc. I forget the jargon; but you know what I mean. But in my opinion it is not that simple. Allow me to explain.

One 'way' I viewed SB+ [which I also love btw] is it provided a great pre-built 'framework' within which things just worked. But far more than that simple concept, was it provided a mv-centric dev 'platform' that took care of matters that frankly d3/UV/jbase etc etc etc should perform natively. To mention a few:

• Creation of files
• Creation of dictionary items
• Creation of essential CRUD forms
• Creation of reports both Access and otherwise
• Validation methods
• Basic operations like file opens, closes, searches
• Security
• Full screen code editor
• The list goes on...

But the biggest of all is tracking of such changes and providing tools for creating a release of changes to update a target system. Thus for a developer it took all of that and wrapped it up nicely. The web 'paradigm' you speak of does nothing to deal with any of these issues, and thus a place exists for something... a tool which assists the developer but still allows for your paradigm.

Bear with me, I'm nearly there....!

However, as you state: that does not easily fit with a web-paradigm; which brings me to the next product which in many ways is the evolution of SB+ that should have happened but never did: designBais. [Full disclosure: I have no financial relationship with designbais. I am a customer, and a fan though].

DesignBais in many ways is not as powerful as SB+; but it takes ALL of the points I raised above and elegantly handles them browser-based interface, which means one can do all of the things mentioned above to the back-end; and create a 'proper' Web-based application if you wish where designbais will create the front-end UI as well. Quickly. Cheaply. Thus it 'takes over' from where SB+ v5 left off; but with a 'web paradigm'. You do not lose most of the really important concepts which SB+ 'took care of' so well.

However, it does not end there. In designbais one can have a system which:

• Creates pdf's
• Emails them
• Prints on any device the Browser can 'see'
• Zero footprint deployment
• Use CSS to customise the look and feel
• Is compatible across all mainstream versions of mv out-the-box and even SQL with an add-on thus 'future-proofing' the system
• ... so much more....

But the real kicker is that designbais not also produces responsive web pages but now can expose elements as an API. It can also consume API's.

Therefore one can have the best of both worlds, because as mv developers one still needs to be able to do all the mv back-end stuff which the native UI handles very, very poorly. I mean really, does anyone seriously expect to use update-processor and tcl-commands to setup a mv system? Code, compile? And what about security, look-ups, searches, validations and god-knows what-all? Write your own?

Therefore Brian, with all due respect I think there is a place for the correct tool. Call it SB+ if you like, but that specific instance has shot itself in the foot by being U2 specific plus I think it requires expensive and bloated middle-ware and clients. designbais is the rightful heir to that throne.

To do as you say in a web environment is 100% correct, and of course the UI could be built in 'whatever': Angular JS for instance and that is good thing. The point is: It is a tool. Nobody serious writes in native HTML, or PHP. What is 'missing' from your proposal is a similar 'tool' to benefit the back-end as the db does not handle any of that. The benefit of designbais is itis  such a tool, and further will create a Browser-based app for you which can be 'final' as a sole application or merely a stepping-stone to a system that has more fancy UI elements via suitable UI tools such as Angular.

Therefore I believe there is a need and a place for BOTH in the developer's toolkit; primarily because the mv system does NOT natively provide it. One ends up with the best of both worlds: The low-cost back end development which mv is famous for and arguably it's best feature PLUS the OPTION to allow for 'modern' UI/UX front end all using the same controlled code-base.

Who could want for more?

PS: I appreciate this is actually off-topic. I had no intention of hijacking this thread.

Best wishes,

------------------------------
David Knight
Managing Director
Matash Australia Pty Ltd
AU
------------------------------

Please David et al,

I did not say there wasn't a space for a tool to do these things, nor did I say anything disrespecting SB+ for what it does, or SBXA on UniVerse. 

Nor was I proposing that you should go and hand code everything front to back in Angular 12. Life is too short, it is hard work and expensive and you have to rewrite the front end every 12 months anyway because of breaking backward compatibility (grin). David, I know designBais and it clearly does a great job - and there are others. 

All I said, in response to a very specifically D3 question and comments about webifying it, was that the design of SB+ isn't such that you could easily and cheaply propagate its applications to the web, because of the way that it is heavily tied to (a) statefulness, (b) synchronicity and (c) its own self-inspecting architecture. All of which makes it potentially expensive - though obviously far from impossible - to square with the very different web paradigm. SBXA (or similar runtimes) have to fill in the gaps, and so there is probably a not insubstantial cost to maintaining that complexity. I don't work for Rocket, so I don't know, but I've done similar stuff to emulate other existing systems and it is painful.

And in those circumstances, with multiple platforms to support, it is not surprising that the focus would be on U2 rather than D3. I'm sure there are things that could make SB+ better on D3, but that wasn't the point I was making.

And Alex - you clearly love D3 and I'm not suggesting you change, but please know that UniVerse isn't bad. It's actually pretty good. Really ;)

Perhaps a new thread could be started for people to focus on AI rather than SB and GUI?

I approach the topic of AI like all others : We can easily make all technologies integrate with MV. The notion that MV is somehow unusual in its abilities limits developers and end-users creativity, and drives thinking toward other solutions. That's painful for everyone.

The OP here asks developers "What are you thinking or doing with AI around your MV app?".
Consider discussions based around these questions:

• Are you more inclined toward "I have no idea what AI really is" or "I get it, I'm just not sure what it means for my business"?
• Are you more inclined toward "how can this AI thing be related to MV" or "I know what I want to do, I just don't know how"?
• What are end-users asking about AI in relation to their MV apps?
• What do you see people doing with AI that you'd like to do with MV?
• Fundamentally, are you confident, or skeptical about the ability for MV to use AI? That is, do you doubt that MV is up to the task or are you perhaps just not sure what tasks might be useful?
• Do you have the impression that Rocket needs to do something to AI-enable MV before you can do anything?
• Similarly, are you looking to Rocket to help guide your adoption of AI for your MV apps? In what way?

Let's be open about concerns and challenges. There's so much more here to be explored.
Anyone interested enough to start some new threads?