Using MV program name extenion

[Peter Gonzalez]

Hello group!

For a couple of decades I have been tossing the idea of using program name extension. You could just click or right click on the program and your associated program will execute. It may not be a major MV community enhancement now but at least we will be prepared for future developments and be with the IT mainstream.  I'm not familiar with Jbase but I think they may have something already.

Thoughts? Suggestions? and of course positive criticism are welcomed.

 

Python has                 xxxxx.py

Batch programs   has  xxxxx.bat

DOS Subroutines has  xxxxx.dll

MV program would be     xxxxx.mv (or something that our community agrees to)

-Peter G

[John Stokka]

You want to at a minimum expand to include other possible extensions for MV.

perhaps...

.mvb - mvbasic

.mvp - mvproc

.mvd - mvdictitem

John

--
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 on the web visit https://groups.google.com/d/msgid/mvdbms/6b217401-9b50-48f0-b487-ad6874b5b604%40googlegroups.com.

[Marcus Rhodes]

I think it's a great idea, but it doesn't need to be built into any flavor; we can easily do it ourselves.  I've long appended .pbc (Pick Basic Code) to my programnames so that my file-browser automatically opens them in my preferred editor, whether Pluma, nano, or WED.  But I also use my own pre-compiler to copy these to names without the .pbc suffix before compiling/cataloging.

[Peter Gonzalez]

John, I like the idea that you expanded on the idea. .mvp could be associated to PROC or PARAGRAPH depending on the MV flavor.

Any ideas on the datafile?   Maybe xxxxx.mvdb for CUSTOMER.mvdb?   

.mvb - mvbasic

.mvp - mvproc or mvparagraph

.mvd - mvdictitem

-Peter G

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/E0mxfufnMxk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mvdbms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/CANhQ6Yi%2BfrmN0GOO%2BGA3tn6TTEX2Mhh_6mgMi04F_mYObHsBPw%40mail.gmail.com.

[Peter Gonzalez]

Markus,

Thank you for the feed back. I'm glad that someone is already doing this. Do you have any issues with a program name like  AWF.EDI.850.UPLOAD.pbc?  Do the additional periods create any unwanted results? 

-Peter G

--
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/E0mxfufnMxk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mvdbms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/99c9e5be-2d66-46b2-aa9d-d0ab8b61ebf7%40googlegroups.com.

[Marcus Rhodes]

I've never had any trouble with it at all.  (with the exception of other programmers freaking out, feeling threatened, having allergic reactions to new things, etc.  So, I only do this at home on my own systems, or when I'm the only coding/style authority I need to answer to, as is the case with my current client.)

That said, I'm an advocate of the underscore name-delimiter.  The only . in any of my own program names is the one that delineates the filename extension, and I never use dashes.  Period.  Maybe I'll start using dashes when all the flavors start allowing them in the code.  (E.g.: SUBROUTINE MY-ROUTINE-NAME( BLAH, BLAH, BLAH ))

But that's just me.

On Friday, November 22, 2019 at 2:28:04 PM UTC-5, Peter Gonzalez wrote:

Markus,

Thank you for the feed back. I'm glad that someone is already doing this. Do you have any issues with a program name like  AWF.EDI.850.UPLOAD.pbc?  Do the additional periods create any unwanted results? 

-Peter G

On Fri, Nov 22, 2019 at 12:51 PM Marcus Rhodes <marcus.aur...@gmail.com> wrote:

I think it's a great idea, but it doesn't need to be built into any flavor; we can easily do it ourselves.  I've long appended .pbc (Pick Basic Code) to my programnames so that my file-browser automatically opens them in my preferred editor, whether Pluma, nano, or WED.  But I also use my own pre-compiler to copy these to names without the .pbc suffix before compiling/cataloging.

On Friday, November 22, 2019 at 1:09:03 PM UTC-5, Peter Gonzalez wrote:

Hello group!

For a couple of decades I have been tossing the idea of using program name extension. You could just click or right click on the program and your associated program will execute. It may not be a major MV community enhancement now but at least we will be prepared for future developments and be with the IT mainstream.  I'm not familiar with Jbase but I think they may have something already.

Thoughts? Suggestions? and of course positive criticism are welcomed.

 

Python has                 xxxxx.py

Batch programs   has  xxxxx.bat

DOS Subroutines has  xxxxx.dll

MV program would be     xxxxx.mv (or something that our community agrees to)

-Peter G

--
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: mvd...@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/E0mxfufnMxk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mvd...@googlegroups.com.

[Kevin Powick]

On Friday, 22 November 2019 15:59:33 UTC-5, Marcus Rhodes wrote:

I've never had any trouble with it at all.  (with the exception of other programmers freaking out, feeling threatened, having allergic reactions to new things, etc.  So, I only do this at home on my own systems, or when I'm the only coding/style authority I need to answer to, as is the case with my current client.)

That said, I'm an advocate of the underscore name-delimiter.  The only . in any of my own program names is the one that delineates the filename extension, and I never use dashes.  Period.  Maybe I'll start using dashes when all the flavors start allowing them in the code.  (E.g.: SUBROUTINE MY-ROUTINE-NAME( BLAH, BLAH, BLAH ))

But that's just me

This is interesting because it illustrates some of the different "coding standards" that different developers and shops use.

Personally, I never use underscores for anything.  For me, they present readability issues and require an extra keystroke (shift).  In MV systems, I like my filenames hyphenated (my-file), and my code files dot (.) delimited.

--

Kevin Powick

[Kevin Powick]

One of the larger systems I work on has a legacy codebase standard that we have to follow.  In this case, programs are suffixed with .pgm and subroutines are .sub.  Unfortunately, .pgm isn't recognized as a file containing text/code by some services like GitHub and Bitbucket, resulting in failed file previews on those websites.  I'm just glad that configuring my editor to deal with these file extensions is not a problem.

--

Kevin Powick

[Peter Gonzalez]

Kevin, is there a national or international organization that assigns file extensions? It would be sad for us to create a standard and then find out that it will cause unexpected results like spam or malicious file.

-Peter G

--
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/E0mxfufnMxk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mvdbms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/3ca2fb78-54b2-4c6e-9ba3-6856115a5d3c%40googlegroups.com.

[Peter Gonzalez]

Markus,

Using the "." period is much quicker than "_" underscore which requires the pressing of the "Shift" key.  I'm with you on following whatever my 9 to 5 employer mandates for standards but with my personal system I'm starting to think of how to standardize the program names.

-Peter G

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/E0mxfufnMxk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mvdbms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/192a382a-866e-4b8d-9246-f66f376352ae%40googlegroups.com.

[Gerd Förthmann]

One or two keys to press doesn't really matter because what is the point of an extension when MV programs can only run if you are logged on in a MV environment?
In the end you can call your programs whatever you like and dots are perfectly fine in MV program names.
At the software house I used to work for we used SR. as a prefix for all subroutines for instance.
And since most MV programmers usually put programs in specific files like BP they know that all items in there are supposed to be programs or code snippets.
So adding .mvb or whatever to every program name is just so many extra keys to press and wasted disc-space to boot.

When I started in MV it was common to give users access to the MV command prompt (tcl) and let them type in program names.
Menus where just procs to disguise this.
Furthermore program names had to be short so users could remember them.
Now that was dangerous when a user would type in the wrong program name and start the end-of-month process P694 instead starting end-of-day P691.
The company made good money fixing the data afterwards and rolling it back, though.
Nowadays we often have GUI menus and we go to considerable length to prevent users to ever get anywhere near tcl or having to type or select program names from a list.

So what is the benefit in using extensions on MV program names?

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 on the web visit https://groups.google.com/d/msgid/mvdbms/CAGa%2Bwv%3DQfdkf-m6p%2BAkri4UtiKMYLtX_c22sDUXxQWM5J71d%3DQ%40mail.gmail.com.

[Wol]

On 22/11/2019 19:27, Peter Gonzalez wrote:
> Markus,
> Thank you for the feed back. I'm glad that someone is already doing
> this. Do you have any issues with a program name like
> AWF.EDI.850.UPLOAD.pbc?  Do the additional periods create any unwanted
> results?
>

Glad that someone is doing this? It's old-hat. Don't forget Pr1me went
bust in ?91?, and they were doing it back then. Program file names ended
in .IBAS by default, and compiled code ended in .IRUN. Then if you asked
for it you had files like .XREF, and I think there were a couple more...

Cheers,
Wol

>
> -Peter G
>
> On Fri, Nov 22, 2019 at 12:51 PM Marcus Rhodes
> <marcus.aure...@gmail.com

> <mailto:marcus.aure...@gmail.com>> wrote:
>
> I think it's a great idea, but it doesn't need to be built into any
> flavor; we can easily do it ourselves.  I've long appended .pbc
> (Pick Basic Code) to my programnames so that my file-browser
> automatically opens them in my preferred editor, whether Pluma,
> nano, or WED.  But I also use my own pre-compiler to copy these to
> names without the .pbc suffix before compiling/cataloging.
>
> On Friday, November 22, 2019 at 1:09:03 PM UTC-5, Peter Gonzalez wrote:
>
> Hello group!
> For a couple of decades I have been tossing the idea of using
> program name extension. You could just click or right click on
> the program and your associated program will execute. It may not
> be a major MV community enhancement now but at least we will be
> prepared for future developments and be with the IT mainstream.
> I'm not familiar with Jbase but I think they may have something
> already.
>
> Thoughts? Suggestions? and of course positive criticism are
> welcomed.
>
> Python has                 xxxxx.py
> Batch programs   has  xxxxx.bat
> DOS Subroutines has  xxxxx.dll
>

> MV program would be xxxxx.mv <http://xxxxx.mv> (or something

[izzizman]

I agree with Gerd here, why are we spending time even discussing this, who  cares about extensions ! Other issues/questions have already been raised that have more importance.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/2618b7b2-96ea-0709-49c3-4378ea5d7024%40gmx.net.

[Marcus Rhodes]

Well I, for one, see it as one of those little-yet-big things holding Pick back.  The more we expose Pick to the rest of the world, the better, and that includes the file-system and development tools.  My arrangement allows me to treat my code like any other, to find and open my programs with next to no typing, to search and sort them with better tools, because I can use the same point-n-shoot file-browser that I use for everything else on my PC, which means that I really don't care about avoiding the shift key.

In fact, I find it pretty painful that we haven't had something like WED, syntax highlighting and all, on Pick itself, or PC-like file browsers, and spreadsheets, even if they are text-mode.  I find it ludicrous that everyone still works in 80x24, and yellow-on-blue, and almost everyone still uses all upper-case.  I find it downright criminal that so much of the code I encounter was written with so little understanding of structured methods, event-driven design, or n-tier architecture, things that are de rigueur everywhere else.  I mean, I'm as big a critic of OO as the next guy, but, come on ... Goto?  Numeric labels?  No task-list?  No event loop?

We'll soon be entering the 3rd decade of the 21st century, but adopting the same filename practices everyone else uses is too trivial for us?

Thanks for sharing.

On Friday, November 22, 2019 at 8:00:04 PM UTC-5, Izzi Zman wrote:

I agree with Gerd here, why are we spending time even discussing this, who  cares about extensions ! Other issues/questions have already been raised that have more importance.

On 11/22/2019 7:10 PM, Gerd Förthmann wrote:

One or two keys to press doesn't really matter because what is the point of an extension when MV programs can only run if you are logged on in a MV environment?
In the end you can call your programs whatever you like and dots are perfectly fine in MV program names.
At the software house I used to work for we used SR. as a prefix for all subroutines for instance.
And since most MV programmers usually put programs in specific files like BP they know that all items in there are supposed to be programs or code snippets.
So adding .mvb or whatever to every program name is just so many extra keys to press and wasted disc-space to boot.

When I started in MV it was common to give users access to the MV command prompt (tcl) and let them type in program names.
Menus where just procs to disguise this.
Furthermore program names had to be short so users could remember them.
Now that was dangerous when a user would type in the wrong program name and start the end-of-month process P694 instead starting end-of-day P691.
The company made good money fixing the data afterwards and rolling it back, though.
Nowadays we often have GUI menus and we go to considerable length to prevent users to ever get anywhere near tcl or having to type or select program names from a list.

So what is the benefit in using extensions on MV program names?

Am 22.11.2019 um 23:52 schrieb Peter Gonzalez:

Markus,

Using the "." period is much quicker than "_" underscore which requires the pressing of the "Shift" key.  I'm with you on following whatever my 9 to 5 employer mandates for standards but with my personal system I'm starting to think of how to standardize the program names.

-Peter G

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/192a382a-866e-4b8d-9246-f66f376352ae%40googlegroups.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: mvd...@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 mvd...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/CAGa%2Bwv%3DQfdkf-m6p%2BAkri4UtiKMYLtX_c22sDUXxQWM5J71d%3DQ%40mail.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: mvd...@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 mvd...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/2618b7b2-96ea-0709-49c3-4378ea5d7024%40gmx.net.

[Kevin Powick]

On Friday, 22 November 2019 20:00:04 UTC-5, Izzi Zman wrote:

I agree with Gerd here, why are we spending time even discussing this, who  cares about extensions !

The people that care about extensions are working with MV code using development tools, utilities, and services outside of MV environments.  So, while items names really don't matter much within MV, they can matter a lot outside of MV.

--

Kevin Powick 

[Kevin Powick]

On Friday, 22 November 2019 19:10:23 UTC-5, Gerd Förthmann wrote:

And since most MV programmers usually put programs in specific files like BP they know that all items in there are supposed to be programs or code snippets.

Except that many MV developers host such BP files outside of the MV environment, allowing them to take advantage of a wide range of developer tools, utilities, and services.  I haven't written code within a MV environment for a very, very long time.

--

Kevin Powick

[Kevin Powick]

On Friday, 22 November 2019 17:46:04 UTC-5, Peter Gonzalez wrote:

Kevin, is there a national or international organization that assigns file extensions? It would be sad for us to create a standard and then find out that it will cause unexpected results like spam or malicious file.

Peter,

I don't think there is anything like a governing body or ISO standard, but one site that seems to have a pretty extensive catalogue of known file extensions is: https://www.file-extensions.org/

FYI, I checked a few of the extensions proposed in this thread and found they were already used.

.mv - IRIX command compressed movie: https://www.file-extensions.org/mv-file-extension

.mvb - A Microsoft multimedia format: https://www.file-extensions.org/mvb-file-extension

.mvp - mvpStats dataset file: https://www.file-extensions.org/mvp-file-extension

--

Kevin Powick

[Gerd Förthmann]

Hi Markus,

I know there are still a lot of MV programmers out there who think green-screen applications and using ED or even vi to write programs are the best things since sliced bread and refuse to use full-screen editors or GUI. I have worked with a lot of them over the years and it isn't fun. Especially when your boss is one of them and tells you that you're not allowed to use anything else. I even worked with a guy who claimed he didn't need Basic since he could write all his programs in proc.
But like the dinosaurs they will die out eventually.
I have also worked with young programmers using the currently most fashionable languages and tools who couldn't write a single line of code because all they were doing is spending hours or days on the internet trying to find code snippets in forums that they then pasted together spending even more time afterwards trying to make it work because they didn't even understand the code they had produced.

I don't see what that has to do with enforcing using extensions on program or even data file names, though.
When I was still working as a consultant or analyst/programmer I usually opened my favourite editor once I started working and kept it running until I logged off.
And those editors (WED was one of them) I used over the years could open files without typing anything.
But if you open MV program files only once in a blue moon and therefore find it more convenient to use explorer instead opening the editor first, you can always right-click and choose Open with and select the editor you want.
It doesn't make sense to me as a professional MV developer, though.

Well, if you feel so strongly about extensions, all MV platforms I know allow you to use whatever 'extension' you fancy.
And if you're the IT director or manager in charge of software development you can enforce such a rule in your company as a standard.
I personally don't need extensions and cannot see why I should need them any time in the future.
But should I ever be hired by that company I wouldn't have a problem naming new files that way.
The freedom not having to use extensions sure as hell is not holding Pick back. There are enough other issues that do that just fine.
Those dinosaurs are one of them.

But that's just the beauty of Pick.
You don't have to do things like the mainstream but if you want you can do it even if it doesn't make sense.

Like when I worked for a government department in the UK where some high-paid 'analysts' had decreed nobody was allowed to use multi-values on a Unidata system because that wasn't approved by the church of Codd (aka the mainstream at the time).
It sort of 'worked' but it was very awkward and a total waste of time as far as I am concerned.

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 on the web visit https://groups.google.com/d/msgid/mvdbms/a7852d60-fb87-482d-8cbd-fc0240848328%40googlegroups.com.

[Dawn Wolthuis]

It appears that .mvb as used by Microsoft is obsolete, and I have seen that extension used in MV before. I like it for MV BASIC better than just .mv, for example. I saw programs in a non-MV non-VB BASIC shop and they were .bas. Various flavors of languages can all use the same extension, but I do think Data BASIC is distinct enough (would dynarrays be a key example or are there better ones for differentiating it from other BASIC languages?) to go with .mvb rather than .bas.  --Dawn

Dawn M. Wolthuis President, Tincat Group, Inc. 616-901-6293 | dw...@tincat-group.com Take and give some delight today

--

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 on the web visit https://groups.google.com/d/msgid/mvdbms/2c2d73c3-2256-401d-9057-e22200e13063%40googlegroups.com.

[Kevin Powick]

On Saturday, 23 November 2019 10:55:44 UTC-5, Dawn Wolthuis wrote:

It appears that .mvb as used by Microsoft is obsolete, and I have seen that extension used in MV before.

Yeah, even if it is still in use by MS, it's probably not common.  I wouldn't hesitate to use it on my own system.  

--

Kevin Powick

[Patrick Payne]

I would throw out that jBASE uses .b as an optional extension.  Keep in mind this can cause issues elsewhere unless your compiler/pre-processor removes the extension when compiling which jBASE does for he .b extension.  This is proving to be an issue with the MVBASIC VSCode Extension and we are reviewing alternative ways to determine the language (such as looking at the contents of the file).

I did some of the same research when doing my first git projects and found that .b was already taken and is associated with a bad word =(

.b = brainf**k   - I originally thought somebody was messing with me but if you look in github it is a registered language.  Other searches on the internet show that it should be basic.

[Kevin Powick]

On Saturday, 23 November 2019 19:31:18 UTC-5, Patrick Payne wrote:

I would throw out that jBASE uses .b as an optional extension......  This is proving to be an issue with the MVBASIC VSCode Extension and we are reviewing alternative ways to determine the language (such as looking at the contents of the file).

One easy way around this is to modify the User settings in VS Code and add "file.associations" for your language of choice (mvbasic).  On one of my systems, all MVBasic (code) files are always found within a "BP" folder, so I set up a file associate for that relationship as follows.

"files.associations": {"**/BP/*": "mvbasic"}

This particular association keys off the folder name, so the actual file names (and extensions) do not matter. i.e. If they're in a BP folder, mvbasic is the language used.  I suspect that most MV developers could do something similar. 

--

Kevin Powick

[Peter Gonzalez]

Izzi,

If we don't spend time at least talking about it we will always be outside of the IT mainstream. Having standards makes everything much easier and more productive. Yes, it's a minimal thought but heading in the productive direction.

-Peter G

[Peter Gonzalez]

Gerd,

You are talking about typing the program name every time you need to do something. I'm suggesting associating the program name to an extension so we and future programmers could just click on the program and have some kind of action. One example is Intelligent Code Completion, see the wikipedia.   

https://en.wikipedia.org/wiki/Intelligent_code_completion

We gotta start thinking outside the box or else Pick will still be the database/program language running on Pick O/S.

-Peter G 

[Peter Gonzalez]

Kevin,

Exactly!

[frosty]

This is what I did; works great.

[Peter Gonzalez]

Kevin,

Than you for the VS Code update.

-Peter G

[David A. Green]

I do the same as others on this list by appending a .ubc (UniBasic Code) when I transfer to my PC.  Then I have to remove it when moving it back.

 

David A. Green

(480) 201-7953

DAG Consulting

 

From: mvd...@googlegroups.com On Behalf Of Peter Gonzalez
Sent: Friday, November 22, 2019 11:09 AM
To: Pick and MultiValue Databases <mvd...@googlegroups.com>
Subject: [mvdbms] Using MV program name extenion

 

Hello group!

For a couple of decades I have been tossing the idea of using program name extension. You could just click or right click on the program and your associated program will execute. It may not be a major MV community enhancement now but at least we will be prepared for future developments and be with the IT mainstream.  I'm not familiar with Jbase but I think they may have something already.

 

Thoughts? Suggestions? and of course positive criticism are welcomed.

 

Python has                 xxxxx.py

Batch programs   has  xxxxx.bat

DOS Subroutines has  xxxxx.dll

 

MV program would be     xxxxx.mv (or something that our community agrees to)

 

 

-Peter G

 

--

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 on the web visit https://groups.google.com/d/msgid/mvdbms/6b217401-9b50-48f0-b487-ad6874b5b604%40googlegroups.com.

[Tony Gravagno]

Random notes, some in response to others...

I posted a note in the QM forum a couple weeks ago. (Really surprised there was Zero response.)  I've been writing scripts using BASIC as just another alternative to bat/cmd, vbs, js/node, php, shell:

01 crt "HELLO WORLD"

save as hello.qms

> hello

HELLO WORLD

Click the hello.qms file from Windows Explorer and it executes.

The effect is that with file associations, just like .bat, .php, and .vbs, we don't need to write the code in MV and then call into it. The code-as-OS-script is a first-class citizen right from the OS CLI.

I'm just now starting to do this in Linux too.

I started calling it QMScript but that's too limiting, as are some other suggestions in this thread. I would call it MVScript, but that stomps on a product by Brian Leach. For ease of use within this industry I think usage above can easily be referred to as QMScript, D3Script, UVScript, etc.

The limitation of 8.3 style filenames is a relic of DOS, no longer required. We don't need to limit to program-name.mvb, we can use name.mvqmb, name.mvd3b, name.mvuvb, etc. For Proc, perhaps .mvd3p, etc. Python for MV is fine as .py (and there are a bunch of other .pyX extensions).

 

For MV items at the OS level, I recommend branding the flavor of MV BASIC so that those (few?) of us with multiple MV platforms can set associations for the proper platform to execute the code, and for tools like Visual Studio Code to open the right language handler.

I'm itching on the idea of adding an extension to dict items in the OS, as a pre/post processor is required to import/export these items from MV, otherwise we can't use them elegantly in queries. That said, a similar process could be used to set/reset the item name of programs. In other words, export your dict item "NAME" as "NAME.mvd" and import it back as "NAME" without the extension.

The same applies to code - export as .mvd3b and then strip the extension on import. This kind of juggle might or might not be used when saving OS files into a Git repo. Those of us who use code directly from the OS need to make some decisions on a case by case basis about whether the OS file has an extension or not.

Like I said ... random.

T

[Tony Gravagno]

Typo: "That said, a similar process could be used to set/reset the item name of programs"

I meant "That said, a process could be used to set/reset the item name" ... and I separated out the next paragraph to intend the same process for programs.

[Peter Gonzalez]

Tony,

Thank you for your feedback and for thinking outside the box or should I say outside the MV environment. 

Having the extension reflect the MV flavor as xxxxxx.mvqmb, xxxxxx.mvd3b, etc sounds pretty good. You know that accomplishing a standard like this will only come from consultants that deal with various flavors.

-Peter G

--

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/E0mxfufnMxk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mvdbms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/0c01e18a-1ae0-4b05-8a04-237457fd25d7%40googlegroups.com.

[Tony Gravagno]

On Tuesday, November 26, 2019 at 12:58:58 PM UTC-8, Peter Gonzalez wrote:

Having the extension reflect the MV flavor as xxxxxx.mvqmb, xxxxxx.mvd3b, etc sounds pretty good. You know that accomplishing a standard like this will only come from consultants that deal with various flavors.

Thanks Peter. People who do not deal with various flavors could easily argue that 5-character extensions are too much. I would prefer to have the built-in versatility, rather than the industry settling on 3 characters like MVB and the rest of us kind of suffering with that.

These concepts are not absolute, there can be compromises and accomodations...

- If I see a MVB extension and I know it was written by someone writing in D3-flavor, I can get my D3 import/export utility to process those files regardless of the extension.

- Similarly, we can easily get multiple extensions to be processed by one processor. For example, set an association for both .mvb and .mvqmb to be handled by a single program. This is a matter of choice which can be changed later.

- VSCode already has a feature where we can set a .config file to tell the environment which language processor to use for the current folder.

There are many ways for anticipated handling of these files to recognize a generic extension, and process it as a specific code type. But my arguments against starting with the generic extensions would include:

- Why start with a known limitation when it's not necessary? Are we really that concerned about 5 characters versus 3?

- Those who only use one platform need only be concerned about the extensions that they use. By definition they should never see other extensions, so why should they be against those of us who want them?

- Why force custom tooling to accommodate generic extensions when specific extensions tell us and the tools exactly what we have before us?

- If you receive a .mvb file, you need some other metadata to tell you which platform it runs on. Not so with a file that's already labeled with a .mvuvb extension. (For anyone who's thinking Flavours in U2 or QM, it's up to you to make the case for .mvuvpb, .mvuvib, mvqmpb, etc...)

- If a vendor publishes two BASIC programs, for different platforms, with short extensions both will need to have the same filename - or more specifically, perhaps different filenames with the same extension. This is exactly what we see when we install AccuTerm host programs. Or they'll need to put code for different platforms in different folders or packages - that will probably happen anyway and that's what I've done for years. But with 5 character extensions the vendor can publish name.mvqmb and name.mvd3b, there is no confusion, and this naming convention can help with installation programs.

The bottom line is that more specific extensions provide benefits, and more general extensions yield to known problems. If we're going in this direction, let's not start a new protocol with arbitrary limitations, knowing it already has problems.

T

[Kevin Powick]

On Wednesday, November 27, 2019 at 2:57:21 PM UTC-5, Tony Gravagno wrote:

 

The bottom line is that more specific extensions provide benefits, and more general extensions yield to known problems. If we're going in this direction, let's not start a new protocol with arbitrary limitations, knowing it already has problems.

I don't think anyone suggested a fixed-length of 3.  There were just some examples given following that old tradition.  I think everyone is familiar with longer, descriptive extensions like those seen in MS Excel for example.  XLS, XLSX, XLSM, etc.

While this concept is interesting, It's unlikely, IMO, that the MV community will actually agree upon a standard, and adopt it.

--

Kevin Powick

[David A. Green]

It looks like we are closer to agreeing on extensions than we thought.

Here is my proposal:

 

Filename dot “mv” mv_flavor mv_item

Example: READ.CUSTOM.DICT.mvudbc  would be a Multivalue UniData Basic Code

 

Mv_flavors:

• ud
• uv
• d3
• qm
• etc.

 

Mv_Items:

• bc           Basic Code
• pa           Paragraph
• pq           Proc
• db           Database
• etc.

 

David A. Green

(480) 201-7953

DAG Consulting

 

From: mvd...@googlegroups.com On Behalf Of Kevin Powick
Sent: Wednesday, November 27, 2019 11:19 PM
To: Pick and MultiValue Databases <mvd...@googlegroups.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 on the web visit https://groups.google.com/d/msgid/mvdbms/1c914ca1-94cf-455c-b972-70f05ea232f3%40googlegroups.com.

[frosty]

On Thursday, November 28, 2019 at 7:12:10 AM UTC-7, David Green wrote:

It looks like we are closer to agreeing on extensions than we thought.

Here is my proposal:

[snip]

bc           Basic Code

[snip]

Change 'bc' to 'bp' and you'll have my vote.

[Peter Gonzalez]

Thank you all for the suggestions, advice and some criticism.....   I have taken your ideas and build my own sample of file extensions with various mv flavors. Datafiles can either be expressed as a "t"=table or "db"=database as VENDOR.mvqmt or VENDOR.mvqmdb. Which one would be more descriptive when a programmer types DIR in windows or ls in Linux?   I added an extension for Python since it is a native programing language in Universe.

Again, the idea to to be able to right click and associate a mv file with an application. What the application is will be determined by the database vendor, software company or in-house programmer. Yes, I know it's more typing.

-Peter G

Windows

-------------

 Volume in drive H is Data2

 Volume Serial Number is 3456-2344

 Directory of H:\

Customer.mvuvt              12/05/2019 11:56 PM   Universe Table
Vendor.mvuvt                12/05/2019 11:56 PM   Universe Table
D_CUSTOMER.mvuvt            12/05/2019 11:56 PM   Universe Dict Table

D_VENDOR.mvuvt              12/05/2019 11:56 PM   Universe Dict Table

X_CUSTOMER.mvuvt            12/05/2019 11:56 PM   Universe Index Table

X_VENDOR.mvuvt              12/05/2019 11:56 PM   Universe Index Table

CUSTOMER.mvuvdb             12/05/2019 11:56 PM   Universe Data File

VENDOR.mvuvdb               12/05/2019 11:56 PM   Universe Data File

D_CUSTOMER.mvuvdb           12/05/2019 11:56 PM   Universe Dict File

D_VENDOR.mvuvdb                          12/05/2019 11:56 PM   Universe Dict File

X_VENDOR.mvuvdb             12/05/2019 11:56 PM   Universe Index File

X_VENDOR.mvuvdb             12/05/2019 11:56 PM   Universe Index File     
CustomerBilltoMaint.mvuv    12/05/2019 11:56 PM   Universe Application

CustomerShiptoMaint.mvuv    12/05/2019 11:56 PM   Universe Application

VendorBilltoMaint.mvuv      12/05/2019 11:56 PM   Universe Application

VendorShiptoMaint.mvuv      12/05/2019 11:56 PM   Universe Application

CustomerBilltoMaint.mvpy    12/05/2019 11:56 PM   Universe Python Application

CustomerShiptoMaint.mvpy    12/05/2019 11:56 PM   Universe Python Application

VendorBilltoMaint.mvpy      12/05/2019 11:56 PM   Universe Python Application

VendorShiptoMaint.mvpy      12/05/2019 11:56 PM   Universe Python Application 

********************** OpenQM ************************************************************
CUSTOMER.mvqmt      t=table (DATA table)
VENDOR.mvqmt        t=table (DATA table)
D_CUSTOMER.mvqmt    t=table (DICT table)
D_VENDOR.mvqmt      t=table (DICT table)
X_CUSTOMER.mvqmt    t=table (index table)
X_VENDOR.mvqmt      t=table (index table)
        *** OR ***
CUSTOMER.mvqmdb      db=database (DATA database)
VENDOR.mvqmdb        db=database (DATA database)
D_CUSTOMER.mvqmdb    db=database (DICT database)
D_VENDOR.mvqmdb      db=database (DICT database)
X_VENDOR.mvqmdb      db=database (index database)
X_VENDOR.mvqmdb      db=database (index database)

CustomerBilltoMaint.mvqm    (PICK program)
CustomerShiptoMaint.mvqm    (PICK program)
VendorBilltoMaint.mvqm      (PICK program)
VendorShiptoMaint.mvqm      (PICK program)


********************** Universe ************************************************************
Customer.mvuvt       t=table (DATA table)
Vendor.mvuvt        t=tabel (DATA table)
D_CUSTOMER.mvuvt    t=table (DICT table)
D_VENDOR.mvuvt      t=table (DICT table)
X_CUSTOMER.mvuvt    t=table (index table)
X_VENDOR.mvuvt      t=table (index table)
        *** OR ***
CUSTOMER.mvuvdb      db=database (DATA database)
VENDOR.mvuvdb        db=database (DATA database)
D_CUSTOMER.mvuvdb    db=database (DICT database)
D_VENDOR.mvuvdb      db=database (DICT database)
X_VENDOR.mvuvdb      db=database (index database)
X_VENDOR.mvuvdb      db=database (index database)

CustomerBilltoMaint.mvuv    (PICK program)
CustomerShiptoMaint.mvuv    (PICK program)
VendorBilltoMaint.mvuv      (PICK program)
VendorShiptoMaint.mvuv      (PICK program)

CustomerBilltoMaint.mvpy    (Python script using mv logic)
CustomerShiptoMaint.mvpy    (Python script using mv logic)
VendorBilltoMaint.mvpy      (Python script using mv logic)
VendorShiptoMaint.mvpy      (Python script using mv logic)

[Dawn Wolthuis]

My vote would be for c = collection or d = documents or data, if not f = file.

Document databases (New NoSQL DBMS) have a variety of names but new graduates understand documents (records) are in collections (files).

t for table is typical first normal form relational language, skip that

db for Database is the name of an entire schema (account) in SQL Server, for example.

Not that I have an opinion on this (hah) but c or d would work from my perspective, f as a 3rd choice.

I understand choosing two letters for MV and then another two for the DBMS, however, there really are just a few with significant installed bases still marketed today. I think you could call them j, q, u, n, d, r, o where the only one hard to remember would be n for UniData. UniData will move into UniVerse, I think, so easy enough as that could go away. 

mvqc or mvqd for a file collection in QM seems reasonable to me.

—Dawn

Sent from my iPad

--
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 on the web visit https://groups.google.com/d/msgid/mvdbms/81a4b793-252e-4cc8-bbfe-98b5960da9c5%40googlegroups.com.

[Tony Gravagno]

There is little chance of getting MVDBMS providers to standardize their database table extensions. They have already established their OS file extensions which are unique, and they have no motivation to change. We can and do accept that they don't follow a standard convention. I don't see a reason to press that one. I'd pull that concept from the table and focus on what we can influence, in a realm that is not already established by the MVDBMS companies themselves.

Peter, I think you're doing something really good here. Thanks.

T

On Thursday, December 5, 2019 at 10:13:10 AM UTC-8, Peter Gonzalez wrote:

...Datafiles can either be expressed as a "t"=table or "db"=database as VENDOR.mvqmt or VENDOR.mvqmdb.