uniobjects documentation

[philippe GRACIA]

Hello !

we are trying to modernize our D3 applications and we are looking for a simple way to communicate with our database. we tried uopy, but performances are not we expected... so we are looking for implementing our own api calls to d3netsvc ( unirpc? ).

is there somewhere a documentation on this interface ?

thanks by advance !

[Pedro Santos]

Hi Philippe,

What version of D3 are you using? Remember you can update your D3 to use U2PY instead of UOPY.

I used Python Flask / IIS to create a RESTful API to call a subroutine in D3.

Also, you can use MVConnect for D3 at any version of D3 to create APIs, which is an excellent tool!

Thanks,

Pedro.

[Mike Whalen]

My company started conversion from D3 to jBase in 2022 before Rocket bought jBase. Process took about 2 years. Conversion contract stated jBase would be able to do the same functions and/or functionality that our Version of D3 had. Most of this was accomplished and was the main reason conversion took so long.

jBase/Rocket added significant functionality to jBase before conversation was attempted to make jBase work like D3 for about 95% of the functionality. Rocket should have most of these changes in the current version of jBase but suggest you contact Rocket for specifics.

Interfacing with the web server and other none Pick functions was considerably less time consuming and much faster. Reference "Houston's Inc" conversion if you want to. I retired in 2023 and my boss who negotiated the contract specifications retired last month.

--
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
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mvdbms/5772320c-1062-4562-b561-5a402afe626an%40googlegroups.com.

[Nivethan T]

UniRPC is for UniVerse.

There are two things you can do make performance more palatable when using uopy.

For uopy, it will help if you simply keep the connection option and have a heartbeat going. The startup cost of a session is pretty expensive.

The next thing would be to simply write subroutines to get the data in a format you want rather than to try and build it in python, this one is cheaty though as the whole point of using python was to use python. 

[Jim Idle]

This is the way to go, but I’m biased ;)

Your conversion took jBASE a long way to D3 compatibility. It isn’t easy to do as D3 was full of all sorts of quirks and unfathomable “design”. A new conversion should be relatively simple. Then you get a rest server for free and it can handle many more connections and transactions than any of the Uni add-ons. And you get JSON compatible objects in basic, and tons of other stuff not even possible in systems like Universe and D3. They are closed systems. 

jIM

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/CAMYBFiz0NkMXc4zSLw9Goqi5zZkj5SJURctBh%2BMSApuwd5i%3D%3Dw%40mail.gmail.com.

[bdeck...@gmail.com]

Rocket has developed a d3 compatibility extension for JBASE that addresses a lot of the differences making it a much lighter lift than before.   As your rocket rep for info about it.

Sent from my iPhone

On Jul 12, 2025, at 5:57 AM, 'Jim Idle' via Pick and MultiValue Databases <mvd...@googlegroups.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/mvdbms/CAGPPfg8d%3Duf6Pq63n3gAi5EysU3U7Sk4x7AEekpytQa%3DPCw7Jw%40mail.gmail.com.

[Christopher Jeune]

Are people now actively abandoning the Rocket D3 Old Dick Pick System Platform?

What is driving the exodus?   I used to Love Pick Basic, the TCL-Stack and Access Query Language and Proc Scripting capabilities!

--

[Nivethan T]

Rocket is seemingly more invested in Universe, UniData and jbase. D3 is in the list but a lot of the new development isn't being ported to the D3 platform.

For example, UniVerse is going to get the jbase JSON syntax whereas there's no plan to bring that to D3. 

UniVerse also has support to import a D3 account, where you do an ACCOUNT.SAVE on D3 and a D3RESTORE in UniVerse. It has some hiccups but it's not that painful.

[bdeck...@gmail.com]

“UniVerse also has support to import a D3 account, where you do an ACCOUNT.SAVE on D3 and a D3RESTORE in UniVerse. It has some hiccups but it's not that painful.”

 

Moving data is straight forward between any of the platforms.  The effort usually comes from other factors like:

1. Application specific coding practices (e.g., dependency on case insensitivity for example.  See: https://docs.rocketsoftware.com/bundle/jbase_lib_61/page/cut1666031250612.html)
2. D3 specific behavioral quirks
3. Use of D3-specific commands and interfaces like the % functions
4. Dictionary behavioral differences especially in cases like executed queries within BASIC

 

“Generic” code that was developed pre-D3 and that has not taken advantage of D3 specifics should be easier to migrate to any platform.

 

“What is driving the exodus?”

I have not seen an exodus.  A lot of D3 customers are completely content.  It’s usually those looking to modernize, especially those coming into the legacy apps with background in other stacks, that begin looking for ways to package and admin the apps more like the other stacks with which they are familiar.  jBASE is somewhat unique in this regard since it transpiles BASIC to native bins/libs, and allows BASIC to be extended via conventional #INLINE directives, provides a user-extensible data abstraction layer see: https://docs.rocketsoftware.com/bundle/jbase_lib_61/page/lej1666031300471.html), etc.   Also as mentioned, some of jBASE’s advanced language functionality, such as Dynamic object variable type (see https://docs.rocketsoftware.com/bundle/jbase_lib_61/page/enq1706514830731.html) is migrating to other Rocket platforms such as Universe. 

 

“I used to Love Pick Basic, the TCL-Stack and Access Query Language and Proc Scripting capabilities!”

And that is the essence of the conundrum.  The ‘new’ platform needs to support all the things that apps depend on, and that users love, while also allowing for modern design and coding practices that new developers demand.  A quick glance through the configuration switches in jBASE (see config_EMULATE https://docs.rocketsoftware.com/bundle/jbase_lib_61/page/jsn1721281281658.html) shows that a ton of work has gone into making jBASE adapt to the behavior of the other platforms (note: the link may not contain a complete listing of all recent emulation switches but provides a good idea of work that has gone into jBASE to enhance compatibility with other platforms such as D3).  There are even some switches in there to force jBASE to mimic known bugs in other platforms!  And, it’s more than simply declaring that you want to be “D3 Compatible” or “Universe Compatible”, it gets pretty nitty because the behavior of these platforms can also be configured (examples: Universe flavors and uv.config) so there really isn’t just one “Universe” or “D3” emulation.

 

Making sure that jBASE is configured to map to your configuration is key to a light lift.  Rocket pro services uses a tool that runs on the source platform to test and document the actual behavior of the source system, then produces a recommended config file from it.  The key is to get that configuration right from the start, so that when the data and programs are moved and compiled, you avoid the ‘what the heck?’ discovery time that can slow down the migration.  This is where Rocket has put a lot of effort over the last few years.  The idea is that for those looking to move, the migration should be the lightest lift possible while affording the greatest benefit to the customer’s modernization goals.  Having done a lot of migrations back in the day, from what I can see, while these enhancements are new, they seem to hold great promise in greatly reducing the lift effort we experienced in years past.)

 

The bottom line is that by reducing the lift and providing a modern packaging of a customer’s apps and data along with other administrative, architectural, and modernization capabilities, the thought is that Rocket is paving a forward path for the things that customers truly value; apps and data.

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/0f7c7181-0e21-4fc6-9227-884ab762ebd3n%40googlegroups.com.

[keit...@gmail.com]

We are not abandoning D3 !  It works well and does the job just fine when combined with AccuTerm.

 

Many in our industry want change for change’s sake… bleeding edge stuff that geeks love and customers could care less about.

 

I cannot tell you how much money we have saved and made by staying away from the flavor ( fashion ) of the week and relying on proven methodologies to deliver reliable functioning applications at reasonable prices.

 

As much as we would love a native GUI for D3, it would likely be cost prohibitive to retrofit our large application even if it existed.

 

 

Keith Grill

President

DBMS Inc.

318-635-0757 ext. 302 – office

318-631-7883 - direct

318-572-3196 – cell

Ke...@dbmsinc.com

www.dbmsinc.com

 

 

 

 

From: mvd...@googlegroups.com <mvd...@googlegroups.com> On Behalf Of Nivethan T
Sent: Saturday, July 12, 2025 4:40 PM
To: Pick and MultiValue Databases <mvd...@googlegroups.com>
Subject: Re: [mvdbms] uniobjects documentation

 

Rocket is seemingly more invested in Universe, UniData and jbase. D3 is in the list but a lot of the new development isn't being ported to the D3 platform.

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/0f7c7181-0e21-4fc6-9227-884ab762ebd3n%40googlegroups.com.

[Steven Martin Trimble]

my clients don't even know D3 vs QM vs mvBASE, etc.

when they call, they reference their AccuTerm programs.

makes a lot of sense, that's the Windows program that logs them in, input data, output data.

sometimes the output is html, csv, txt formatted files.

some of them have even progressed as far as emailing pdf attachments.

all of my clients seem perfectly happy NOT knowing the underlying OS and/or database. they are quite satisfied with functionality over presentation.

CDMI

Steven Trimble

(501) 772-3450 cell/text

cdm...@gmail.com

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/0d3401dbf50b%24fabd0aa0%24f0371fe0%24%40gmail.com.

[keit...@gmail.com]

Steven,

 

Ours neither, and the newer of the bunch also will refer to Accuterm rather than our product.

We have integrated Print Wizard to allow them to email invoices, statements and reports.

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/CAJDLGm5ixPGfKEqh-yNTNNq%2BGacnCHyjU0GGqywtnY%2Bvvm17rg%40mail.gmail.com.

[Joe Goldthwaite]

Our site also refers to our Universe system as "The AccuTerm System".  As the guy who created AccuTerm it always makes me smile. You guys spent all that time developing your applications but I got to name them. Lol.

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/0dd201dbf517%24ae8c3a00%240ba4ae00%24%40gmail.com.

[philippe GRACIA]

hello pedro and thanks for your answer. We already use UOPY and MvConnect, but performance are not we expected. we also use 2Upy dirctly from basic apps to extend functiunalities like mail reading ( imap).

but now, we are looking for a simple way to do basics IO with the database ( read, write, delete, select) from an external app with good perfs...

we also tried to setup Linkar tools without success for the moment ...

[Pedro Santos]

mmm, it sounds like "high-cost" queries.

Just for comment, obviously, I don't know many details. Another solution, I think, if you feel the performance is not adequate, is to move data to a different DBMS, make your queries there, and keep sync your data. 

With this solution your data is not online, but you will improve the performance. 

I think MVConnect or using UOPY with Python Flask application should be suitable for your external application for read, write, and delete, for select maybe the performance not.

You can contact me, I'm happy to help: icma...@gmail.com

Thank you,

Pedro.

--

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
---

You received this message because you are subscribed to a topic in the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mvdbms/8Nb6arWpGTA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mvdbms+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mvdbms/707fe9d6-fb54-4959-9d25-79a271659010n%40googlegroups.com.

[Nivethan T]

> but now, we are looking for a simple way to do basics IO with the database ( read, write, delete, select) from an external app with good perfs...

The answer is to use BASIC as much as you might not like it.

We only got good performance by having external apps call specific subroutines.

[Steven Martin Trimble]

The simplest, fastest, and secure way (if you're wanting to use HTML) is to acquire:

Coyote from EasyCo. Been using this since 1996 and never been hacked.

It is 'an account restore' and resides on the multivalue platform like any other account.

It includes a 'listen' daemon and is particular to the underlying OS (like Windows vs Linux).

I am a huge fan of 'LAQP' - Linux, Apache, QM, and PHP.

I let Apache handle 'all' static pages and images and let Coyote handle ALL dynamically created presentations.

In Coyote, you program in BASIC and HTML. Very cool stuff.

Have fun and good luck,

CDMI

Steven Trimble

(501) 772-3450 cell/text

cdm...@gmail.com

You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mvdbms/CANLBRnUN2N%3DyEWkFjj781Q8Pfu-fbqVX_Ys6vLSf%3DYYfi7aU0g%40mail.gmail.com.

[Jim Idle]

Universe has some basic ways of getting things into the system using a hacky C interface but does have anything for integration except non-scaling services in BASIC. 

Sure, you can smash things together and get something working but now you have some fragile stuff to maintain. 

--

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
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/707fe9d6-fb54-4959-9d25-79a271659010n%40googlegroups.com.

[MAV]

If you can do without D3, the answer is simple: OpenQM + QM command WEBSVC + QM Collections (JSON objects). With this, you can easily implement a JSON-RPC API and use it in a ReactJS-developed front-end.

Marcos Alonso Vega

INGESCO Sistemas Informáticos

[Wol]

On 15/07/2025 17:48, Pedro Santos wrote:
> mmm, it sounds like "high-cost" queries.
> Just for comment, obviously, I don't know many details. Another
> solution, I think, if you feel the performance is not adequate, is to
> move data to a different DBMS, make your queries there, and keep
> sync your data.
> With this solution your data is not online, but you will improve the
> performance.

How much effort have you put in to optimising those queries? Remember
searching is slow. Searching Is Slow. SEARCHING IS SLOW!

Relational databases have an optimiser. MV databases assume the analyst
is going to put that effort in up front, so the optimiser becomes a
waste of time.

How many indices do your tables have? EVERY regular query should have
most of its criteria satisfied by an index, not a search. Our system,
which I'm planning to write, has pretty much everything driven by
Delivery Date. That will need a load of optimisation, but also seeing as
it starts at -5:00, and finishes at maybe 27, 28:00, it's going to cost
me a lot of thought, but it'll be well worth it. What stuff do you have
where an index will pay dividends? Remember, you probably spend 90% of
your time reading files, not writing them. An index is not expensive in
the grand scheme of things.

I do miss the old I_... files from INFORMATION. They would have been
great to tack a dictionary of i-descriptors onto, but c'est la vie. You
can always fake that with triggers...

And of course, programming stuff in BASIC ...

The other thing is, drive everything you can through i-descriptors.
Store foreign keys in all your files. Look on Pickwiki (or download
ScarletDME) and find my GETINDEX routine. That enables you to pull an
index from a foreign FILE into your working FILE so you can use it in
i-descriptors. EVERYTHING should be coded so that it's as much "drill
down" as possible. You never want a query to scan a FILE unless either
(a) the FILE is small, or (b) it's unavoidable.

Cheers,
Wol

[Steven Martin Trimble]

yes that is a fact sir Marcos 😃

very cool stuff

CDMI

Steven Trimble

(501) 772-3450 cell/text

cdm...@gmail.com

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/5f3bd335-62ca-424b-a02f-fd95910071d3n%40googlegroups.com.

[Optimus01010101]

To bad that Rocket doesn't seem very interested in QM, even though it seems to be the best option. Martin and his team did incredible work on QM. It is a shame to see the state of it now.

[Steven Martin Trimble]

my sentiments exactly!

CDMI

Steven Trimble

(501) 772-3450 cell/text

cdm...@gmail.com

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/9cbcfabe-7f09-48c3-8f47-497141826898n%40googlegroups.com.

[Jim Idle]

In no way does QM match up to jBASE in h these kinds of things. That’s not to denigrate QM but the integration, modeling, data conversions etc are greatly superior in jBASE

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/5f3bd335-62ca-424b-a02f-fd95910071d3n%40googlegroups.com.