SD - Rev 0.9-1

[Nextjob]

Hello Group

Looking for beta testers for SD 0.9-1 (https://github.com/stringdatabase/sdb64/tree/dev)
Major changes:

Add back ACCOUNT.RESTORE and TAPE functions as install option.
- Modified for SD account structure, only allows restore to GROUP account.
- Admin must use MODIFY.ACCOUNT to grant additional users access to account.
- Very minimally tested.

Rework revision methodology.

Original release introduced two revision tracks, one for the VM another for the SD mods to commands,  ideas on user / accounts etc. The thought was that very few changes would be made to the VM and we would maintain compatibility with QM/ScarletDME at revision 2.6-6.
With some of the recent changes (addition of Sodium, Embedded Python and more importantly the dynamic file prefix change from ~ to %),  SD is no longer completely compatible with 2.6-6 version systems.  Roll back to single revision track and start at rev 0.9-1.
As a result, you MUST shutdown and restart the OS on delete and install of SD.
If you have user / group accounts saved from previous installs, a prompt for upgrading the accounts will occur at login.

What is next for SD
1) Complete first phase of documentation.
    - SD User Manual
2) Investigate adding additional python object handling.
3) Other?

Mark B

[Steven Martin Trimble]

if it's not too much trouble, I would like to see PROC reinstated.

lots of legacy code (at a minimum) uses PROCs as menus and as a way to EXECUTE a string of selects, etc as a batch scenario. I know ALL this can now be done within BASIC, but hey, if you don't have to reinvent the wheel.

thanks for all the extra effort on this.

if openQM goes away, the SD may just be the ticket forward.

CDMI

Steven Trimble

(501) 772-3450 cell/text

cdm...@gmail.com

--
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/fe437599-2c82-47c1-b8db-29d440d10fcbn%40googlegroups.com.

[Steven Davies-Morris]

I too would like to see Proc restored.  Having come from Reality and
Pick before discovering Information in the mid 80s, I have great
familiarity with Proc, and have (on tape) a boatload of legacy code that
contains Procs.  Years ago I helped write a tool that created BASIC from
Procs, to facilitate moving applications from Pick to Information,
Revelation and Unidata.  I should probably dig that up and make it
freely available to the SD toolset.  But in the meantime, porting any of
those legacy apps to SD without Proc, is far less likely to happen.

On 3/6/25 15:35, Steven Martin Trimble wrote:
> if it's not too much trouble, I would like to see PROC reinstated.
> lots of legacy code (at a minimum) uses PROCs as menus and as a way to
> EXECUTE a string of selects, etc as a batch scenario. I know ALL this
> can now be done within BASIC, but hey, if you don't have to
> reinvent the wheel.
> thanks for all the extra effort on this.
> if openQM goes away, the SD may just be the ticket forward.
>

> *CDMI*
> *Steven Trimble*
> /(501) 772-3450 cell/text/

> cdm...@gmail.com
>
>
> On Thu, Mar 6, 2025 at 4:43 PM Nextjob <nextj...@gmail.com> wrote:
>
> Hello Group
>
> Looking for beta testers for SD 0.9-1
> (https://github.com/stringdatabase/sdb64/tree/dev)
> Major changes:
>
> Add back ACCOUNT.RESTORE and TAPE functions as install option.

> -Modified for SD account structure, only allows restore to GROUP
> account.
> -Admin must use MODIFY.ACCOUNT to grant additional users access to
> account.
> -Very minimally tested.

>
> Rework revision methodology.
> Original release introduced two revision tracks, one for the VM
> another for the SD mods to commands,  ideas on user / accounts
> etc. The thought was that very few changes would be made to the VM
> and we would maintain compatibility with QM/ScarletDME at revision
> 2.6-6.
> With some of the recent changes (addition of Sodium, Embedded
> Python and more importantly the dynamic file prefix change from ~
> to %),  SD is no longer completely compatible with 2.6-6 version
> systems.  Roll back to single revision track and start at rev 0.9-1.
> As a result, you MUST shutdown and restart the OS on delete and
> install of SD.
> If you have user / group accounts saved from previous installs, a
> prompt for upgrading the accounts will occur at login.
>
> What is next for SD

> 1)Complete first phase of documentation.
>     - SD User Manual
> 2)Investigate adding additional python object handling.

> 3)Other?
>
> Mark B
> --
> 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

> <mailto:mvdbms%2Bunsu...@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/fe437599-2c82-47c1-b8db-29d440d10fcbn%40googlegroups.com

> <https://groups.google.com/d/msgid/mvdbms/fe437599-2c82-47c1-b8db-29d440d10fcbn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> 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/CAJDLGm6F_0Dym32OLH3_aAULsmA21gR5hfkhn0HDQcQpSdF8Hw%40mail.gmail.com
> <https://groups.google.com/d/msgid/mvdbms/CAJDLGm6F_0Dym32OLH3_aAULsmA21gR5hfkhn0HDQcQpSdF8Hw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
SDM a 21st century schizoid man in SoCal
Systems Theory website www.systemstheory.net
Through The Looking Glass radio show at www.deepnuggets.com
Email "The Cleaner System" at cleaner...@yahoo.com

[James A]

I disagree with restoring PROC: we got rid of all PROC long ago; it's trivial to replace it with EXECUTE and BASIC code; surely less trouble that adding an ancient kludge to SD. No only is it horribly structured, It just makes the system more 'cobol-like' to modern developers.

There's lots to be done to move things forward with JSON, Python, sql DB interfaces; etc etc; than wasting time supporting a funky language invented 50 years ago. 

If someone really wants to support their PROC library, they can write maybe a hundred or so lines of BASIC code to read and EXECUTE those files.

[MAV]

For me, the most interesting OpenQM feature to replicate is COLLECTION(). OpenQM's handling of JSON objects is very good compared to other multivalued products. Another interesting OpenQM command is WEBSVC.

Marcos Alonso Vega

INGESCO Sistemas Informáticos

[Wols Lists]

On 07/03/2025 05:08, James A wrote:
> I disagree with restoring PROC: we got rid of all PROC long ago; it's
> trivial to replace it with EXECUTE and BASIC code; surely less trouble
> that adding an ancient kludge to SD. No only is it horribly structured,
> It just makes the system more 'cobol-like' to modern developers.

So because you don't need it, other people should be denied it?

> There's lots to be done to move things forward with JSON, Python, sql
DB interfaces; etc etc; than wasting time supporting a funky language
invented 50 years ago.

New does not automatically mean better - there's lots of new stuff I
would dearly get rid of (and some new stuff is great!)

> If someone really wants to support their PROC library, they can write
maybe a hundred or so lines of BASIC code to read and EXECUTE those files.

Which should be a STANDARD thing, to save repeatedly re-inventing the wheel.

INFORMATION never (well, until the very last version) never had PROCS,
and as an INFORMATION clone, I expect PROCS was a bit of an afterthought
for OpenQM. It should most definitely be there, but yes, probably as a
bolt-on module, not a core part of the product. I don't know what
proportion of OpenQM/Scarlet/SD is written in BASIC, but the more the
better, and if PROCS (and much else) is just a BASIC source file to be
compiled as required, that's how it should be.

Cheers,
Wol

[Christopher Jeune]

I got some old Pseudo files will they work with this?

--

[Christopher Jeune]

I love Proc Libraries!

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/78b2b930-13bb-465b-83de-0086c97949a6%40systemstheory.net.

[Nextjob]

Not sure, maybe?

My testing was with a minimum 10 year old File Save from a D3 Linux system.  I believe the file save was written to a compressed file with a Pick0 tape statement something like:

 tape /tmp/pseudo       1000000  p  lx            # compressed pseudo tape

I know the file had to be decompressed before attempting to use it with account restore.

Output from the test attached as text file.

I did not investigate the "Illegal characters in record id" error.

YMMV

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/CACHAbR3R_nD4ZLvVM%2BfMuzJDNj%3DSEdFWmU0zWWJAsSi7kBYPkg%40mail.gmail.com.

[Nextjob]

PROC has been added back to my dev repo (https://github.com/mbullr/sdb64/tree/dev).

It will make its way into the stringdatabase repo in a few days.

My view: The more eyeballs on SD and the more use (testing) the better it is for the project.

As for future development. While I agree adding in additional functionality to match the current openQM version would be highly desirable, the reality is there needs to be a greater skill set at the terminal (its not me!). Digging into how variables and their associated Descriptor Structures works is no small task.  My view is the project is better served linking to other projects.  That is the thing ScarletDME/SD have in their favor, the projects can pretty much use any software package that is GPL  -compatible, embedding python for example.

[Steven Davies-Morris]

I don't mean to appear snarky, but "If someone really wants to support

their PROC library, they can write maybe a hundred or so lines of BASIC

code to read and EXECUTE those files" is what was removed.  The PROC
program. In doing so it left a hole triggering an error if a PARAGRAPH
executed that declares itself as a PROC (PQ).  Easy fix: put PROC back.
I agree that long term converting PQ items into BASIC is a good idea,
but pulling the plug .... not so much.  YMMV.

On 3/6/25 21:08, James A wrote:
> I disagree with restoring PROC: we got rid of all PROC long ago; it's
> trivial to replace it with EXECUTE and BASIC code; surely less trouble
> that adding an ancient kludge to SD. No only is it horribly
> structured, It just makes the system more 'cobol-like' to modern
> developers.
>
> There's lots to be done to move things forward with JSON, Python, sql
> DB interfaces; etc etc; than wasting time supporting a funky language
> invented 50 years ago.
>
> If someone really wants to support their PROC library, they can write
> maybe a hundred or so lines of BASIC code to read and EXECUTE those files.
>
> On Thursday, March 6, 2025 at 3:35:52 PM UTC-8 Steven Martin Trimble
> wrote:
>
> if it's not too much trouble, I would like to see PROC reinstated.
> lots of legacy code (at a minimum) uses PROCs as menus and as a
> way to EXECUTE a string of selects, etc as a batch scenario. I
> know ALL this can now be done within BASIC, but hey, if you don't
> have to reinvent the wheel.
> thanks for all the extra effort on this.
> if openQM goes away, the SD may just be the ticket forward.
>

> *CDMI*
> *Steven Trimble*
> /(501) 772-3450 <tel:(501)%20772-3450> cell/text/

> cdm...@gmail.com
>
>
> On Thu, Mar 6, 2025 at 4:43 PM Nextjob <nextj...@gmail.com> wrote:
>
> Hello Group
>
> Looking for beta testers for SD 0.9-1
> (https://github.com/stringdatabase/sdb64/tree/dev)
> Major changes:
>
> Add back ACCOUNT.RESTORE and TAPE functions as install option.

> -Modified for SD account structure, only allows restore to
> GROUP account.
> -Admin must use MODIFY.ACCOUNT to grant additional users
> access to account.
> -Very minimally tested.

>
> Rework revision methodology.
> Original release introduced two revision tracks, one for the
> VM another for the SD mods to commands,  ideas on user /
> accounts etc. The thought was that very few changes would be
> made to the VM and we would maintain compatibility with
> QM/ScarletDME at revision 2.6-6.
> With some of the recent changes (addition of Sodium, Embedded
> Python and more importantly the dynamic file prefix change
> from ~ to %),  SD is no longer completely compatible with
> 2.6-6 version systems.  Roll back to single revision track and
> start at rev 0.9-1.
> As a result, you MUST shutdown and restart the OS on delete
> and install of SD.
> If you have user / group accounts saved from previous
> installs, a prompt for upgrading the accounts will occur at
> login.
>
> What is next for SD

> 1)Complete first phase of documentation.
>     - SD User Manual
> 2)Investigate adding additional python object handling.

> 3)Other?
>
> Mark B
>
> --
> 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/fe437599-2c82-47c1-b8db-29d440d10fcbn%40googlegroups.com

> <https://groups.google.com/d/msgid/mvdbms/fe437599-2c82-47c1-b8db-29d440d10fcbn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> 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/601ba318-c824-4e67-b9d7-5f3271f80142n%40googlegroups.com
> <https://groups.google.com/d/msgid/mvdbms/601ba318-c824-4e67-b9d7-5f3271f80142n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jay LaBonte]

I would like to see PROC restored as well, primarily for compatibility with QM and older code. That said, couldn’t PROC be recreateded using BASIC?


Regards,
Jay LaBonte
President & CEO

P: 561-705-3688 |:: jlab...@paradigm-systems.us
2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481
www.paradigm-systems.us

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/78b2b930-13bb-465b-83de-0086c97949a6%40systemstheory.net.

[Jay LaBonte]

Count me in. I have previously completed the porting of Mercury Flash with Zumasys’ blessing and they made several enhancements for me so I could maintain a single code based between UniVerse, UniData and OpenQM. I would like to get Mercury working on SD and can easily provide a list of missing functionality of modifications Zumasys (Martin) made for this project.

 

My goal with Zumasys was to create a front end, web based console for managing OpenQM. Im happy to revive that project for SD.

 

Regards,

Jay LaBonte President & CEO

(: 561-705-3688 |*: jlab...@paradigm-systems.us

2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481 www.paradigm-systems.us

--

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/fe437599-2c82-47c1-b8db-29d440d10fcbn%40googlegroups.com.

[Wols Lists]

On 09/03/2025 18:07, 'Jay LaBonte' via Pick and MultiValue Databases wrote:
> Rework revision methodology.
>
> Original release introduced two revision tracks, one for the VM another
> for the SD mods to commands,  ideas on user / accounts etc. The thought
> was that very few changes would be made to the VM and we would maintain
> compatibility with QM/ScarletDME at revision 2.6-6.
> With some of the recent changes (addition of Sodium, Embedded Python and
> more importantly the dynamic file prefix change from ~ to %),  SD is no
> longer completely compatible with 2.6-6 version systems.  Roll back to
> single revision track and start at rev 0.9-1.
> As a result, you MUST shutdown and restart the OS on delete and install
> of SD.
> If you have user / group accounts saved from previous installs, a prompt
> for upgrading the accounts will occur at login.
>

Bear in mind that OpenQM and ScarletDME are not compatible at the binary
code level. As part of GPL'ing OpenQM a bunch of changes were made, and
changing all the op-codes was one of them ...

As for the dynamic file prefix thing, I think we should keep the change
to %. One of the things on my list waiting for a Round Tuit was to
update ScarletDME to prefer % - happily accepting ~ but all new creation
would be %. It just makes sense as far as I'm concerned.

(At least we don't have the PI/Open behaviour to contend with, their
"hidden" files all started with <space><backspace> ! Presumably to avoid
people tampering with them.)

The other thing to watch out for - INFORATION catalogued routines all
had names beginning with "*" and these got created as OS-level files.
Played absolute havoc with certain backup programs. Does SD / Scarlet
have any more quirks like that that anybody knows of?

Cheers,
Wol

[Nextjob]

PROC has been added back to the dev branch of SD
https://github.com/stringdatabase/sdb64/tree/dev

[Nextjob]

"Bear in mind that OpenQM and ScarletDME are not compatible at the binary
code level. As part of GPL'ing OpenQM a bunch of changes were made, and

changing all the op-codes was one of them"

This is not entirely true. I have taken a simple  "compiled object" created with Scarlet / SD, dropped it onto a 'newer" version of openQM and it worked.

You cannot however go the other way. 

--

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/db1abbe7-44d8-4072-b358-c076285063d2n%40googlegroups.com.

[Wols Lists]

On 09/03/2025 19:09, Nextjob wrote:
> "Bear in mind that OpenQM and ScarletDME are not compatible at the binary
> code level. As part of GPL'ing OpenQM a bunch of changes were made, and
> changing all the op-codes was one of them"
>
> This is not entirely true. I have taken a simple  "compiled object"
> created with Scarlet / SD, dropped it onto a 'newer" version of openQM
> and it worked.
> You cannot however go the other way.
>

Interesting ... I wonder if the binaries might have some sort of header.
If the (closed) OpenQM can recognise a GPL'd binary, it could easily use
a different op-code table.

Not that we are supposed to, but if we can create an OpenQM op-code
table, IFF Rocket pretty much drop OpenQM (which it sounds like they
might), doing something like that ourselves might not be a bad idea.

Cheers,
Wol

[Nextjob]

"Interesting ... I wonder if the binaries might have some sort of header. "

Yes, defined in gplsrc/header.h

--
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/99711b0f-9a52-46b4-96fe-88a31f17662c%40youngman.org.uk.

[Nivethan T]

I think a feature wishlist type thread may be a great idea especially with an actual application that is being attempted to run. 

I would like to cut my teeth on more stuff but I’ve built out the features I needed to write web apps in Pick and so my own fork has been at a standstill.

https://github.com/Krowemoh/ScarletDME

This is a zig fork but I’d be happy to contribute to the c side.

You should start a new thread to put some focus on this.

[Steven Martin Trimble]

that sounds very interesting

hope it comes to fruition

be well,

CDMI

Steven Trimble

(501) 772-3450 cell/text

cdm...@gmail.com

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/04a301db911e%2427942bf0%2476bc83d0%24%40paradigm-systems.us.

[Jay LaBonte]

I would be happy to create a discussion group on MultiValue.World for SD, when suggestions can be entered and discussed.

 

Let me know if the group would like to go that route, and I can create it.

 

Regards,

Jay LaBonte

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/8bcc6200-efca-4dcf-9af7-5a886d94ee95n%40googlegroups.com.

[Nivethan T]

The best thing would be to have it be part of the SD github page so that it's in front of the widest audience.

Possibly Nextjob can enable discussions on the SD page, otherwise an issue is fine.

[Nextjob]

My preference would be for any dedicated discussion group be hosted elsewhere (thanks for the offer Jay!), or just continue as threads on mvdbms (most visible to the  mv community?) .  While a discussion forum on the stringdatabase github site may make the most sense, I do not have the desire to be a forum moderator.  SD is a hobby, and the amount of time I choose to spend on SD varies based on life.  Sorry.   

[Aquilino Edwin]

Hello NextJob,

I really appreciate your work on SD (stringdatabase ). I know dedicating time to a project like this isn't easy; we all have priorities, and focusing in an application conceived over 60 years ago might not seem like the best use of our time. It is hard to let go of our Database because of our Pick programmers, they know this stuff inside out. The only thing is, I need to update our servers to make sure we are running secured OS's.  I recently came across jBase, but adopting to it  may cost our little company a lot of money. So, I was wondering if SD could integrate with MongoDB in a similar way to jBase. I found this "jBASE Tutorial - Introduction to MongoDB jEDI" in YouTube and editing files (arrays) via a browser is impressive, and I think the mongoclient approach can help me learn Pick thru SD and at the same time upgrade our Linux. Eventually we will hire devs to do the frontend via API, in the meantime we still need to support this legacy setup. So back to question, I am able to run jBase a 30day/two user license with mongoclient. I am also able to manage the containers using 'Portainer' utility. Is there a way duplicate the mongo/jBase setup? Thanks!

[Nextjob]

In theory you could use the embedded python interpreter to talk to MongoDB, in practice?

[D M]

For us, Donald M and Mark B, work on SD is a hobby, which we contribute to when we feel like it.  There has been some interest in the idea of SD becoming some sort of production alternative to other MV products.  While it is likely  that SD, even in it's current state, could be used in some cases as an alternative MV database to the commercial offerings, that has never been our focus, intent or interest.  It is a fun hobby, and for some limited applications what SD is now may be appropriate.  It can certainly be a free educational introduction to MV concepts.  However, if someone is interested in making it a full open source replacement for QM or other multi-value databases, they need to fork the repository and invest the time and effort to make that a reality.  We really are not interested in that level of investment.  

Donald M

Mark B