Q-Pointer to Path?

[Jose Gabino Arocas]

Hi all,


I know the use of filepath directly:

    LIST PATH:c:/temp
or
    OPENPATH "C:\TEMP" TO FILE
or directly:
    OPEN "PATH:C:/TEMP" TO FILE

There is any posibility to create a q-pointer to a path?

I test:

 POINTER
 001 Q
 002 PATH:C:/TEMP

I test changing the "PATH..." in field3 or field 4 and doesn't work


Anyone knows if it's possible?

Jose Gabino

[CDMI - Steve T]

ED MD QTEMP

001 F

002 D:/TEMP

 

Steve Trimble (501) 615-8674

Computerized Data Mgmt Inc (CDMI)

---

From: Jose Gabino Arocas <alpha....@gmail.com>
To: ope...@googlegroups.com
Sent: Thursday, September 18, 2014 11:21 AM
Subject: Q-Pointer to Path?

--
You received this message because you are subscribed to the Google Groups "OpenQM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openqm+un...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openqm.
For more options, visit https://groups.google.com/d/optout.

[Martin Phillips]

Hi Jose,

 

As Steve suggests, the solution is to create an F-type VOC pointer. This can point to any directory in the system to make its content available as a QM file.

 

Probably just a typing error but, the directory delimiter character in Steve’s example should be \ instead of / for a Windows system.

 

 

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

[Jose Gabino Arocas]

Hi,

I know this "trick", but this is not a "pure" q-pointer, i mean if you run an "account.save" or something similar this external file is backed (yes, i know there is a field in the f-type record to exclude this). I'm going to make a "very-external" use to a remote folder "//machine/directory" that another Pick (D3) is writing registers in. I think that QM makes more "control" to f-type files than q-type files and i expect that this don't result in an issue to a remote file.

Thanks for your help

Jose Gabino

[Martin Phillips]

Hi Jose,

 

A Q-pointer points to an F-type VOC item in another QM account. Your situation does not appear to fit this.

 

If I am reading your requirement correctly, you want a pointer to a file that can be used in normal file operations but will not be included in a backup. I cannot see any way to do this other than a flag in the VOC record which we already have.

 

If you can see a different way in which we could support this, please let me know.

 

On the other hand, you could install QM on the D3 machine and use QMNet (via a Q-pointer) to access the remote data.

 

 

Martin

 

 

From: ope...@googlegroups.com [mailto:ope...@googlegroups.com] On Behalf Of Jose Gabino Arocas
Sent: 19 September 2014 09:44
To: ope...@googlegroups.com
Cc: cd...@swbell.net
Subject: Re: Q-Pointer to Path?

 

Hi,

[Jose Gabino Arocas]

Hi,

The "real" scenario is comunicate D3 and QM via several files. The idea in D3 is to make q-pointers to files "DOS:C:/XXXX/YYY" and use it like normal files; and this works (exception to dictionary, but no-problem with it). Then access it in QM via "PATH://D3machine//yyyy", and now this works. The need of a q-pointer is not to make changes in names of filse in programs. My only doubt is if a f-type file in relation to q-pointer file supposes an internal difference that will generate future problems.

Jose Gabino

[Martin Phillips]

Hi Jose,

 

This sounds as though D3 has a special form of Q-pointer that is equivalent to our F-pointer. It might be possible to implement something similar in QM though I would prefer to find a better solution.

 

Of course, the best way forwards would be to write a QM Virtual File System handler that would access the D3 file system directly. We cannot do this here because we do not have a D3 system. If you or any other QM use would like to try to write this, we will help in any way we can. We already have similar VFS handlers for UniVerse and Unidata.

[Jose Gabino Arocas]

Hi,

In the D3 there are OSFI (Operating Systems File Interface) files to access non-file entities as if they were standard D3 files. For example "DOS:" , "UNIX:" or "NT_BIN:" are for accessing files or directorys in the host O.S. The use is: "LIST DOS:C:/TEMP" and you can make a normal q-pointer to a normal D3 file or to an OSFI file, simply writing in filed2 the name of file: "DOS:C:/TEMP" and blank field1. If F-type in QM works well i'm satisfied. A direct access to D3 internal files would be great but i think this surpasses my tecnique and programming abilities.

Jose Gabino

[Tony Gravagno]

Jose, I'm very familiar with D3 OSFI and I exchange files between these environments all the time. I use Accuterm WED to write my code which is saved to a common OS location via OSFI, and then from QM TCL I just need to use the BASIC command to see if it compiles - it's the same source on both sides. (I also use XBASIC to pre-compile for platform-specific nuances. https://bitbucket.org/foss4mv/xbasic) Another benefit here is that the OS folder that has the code is easily committed to a SVN repository.

What I don't understand is why don't you feel the F-pointer is adequate? Can you explain that again?
You can also create a DIR file in QM which points to the common OS folder.
No VFS is necessary here, that would be overkill.

I think you're just wondering if reading and writing items like this is going to create any problems - if your data is going to be corrupted. I'd say no. However, in addition to @AM translation to CRLF in DOS and LF in *nix, D3 also translates between tabs and 4-spaces. This can be controlled with a custom item in the Devices file (rather than default "C", "D", "E", "DOS", "UNIX", etc.)  You should also see what happens with item IDs that have reserved OS characters, like *, ^, and ?. In other words, D3 and QM are compatible in the items that they read/write, but the OS restrictions are handled differently, and the convenient translations in D3 might need to be overridden.

BTW, "DOS:C:..." is redundant. The "C:" device defaults to "DOS:" so you can simply ED C:/temp MyID, or COPY D:/temp, and the item gets saved with CRLF rather than @AM.

HTH

[Jose Gabino Arocas]

Hi,

I didn't say that i don't feel the f-pointer is adequate (i'm not english and sometimes i don't explain the things well), i'm accostumed to q-pointers and i only ask Martin if F-type is adequate to this pointer to external files. He says yes and when i test it deeply i will feel satisfied. ;-)

Jose