Rocket Software Homepage
Forum Home Forum Home > AccuTerm Knowledge Base (read only) > Advanced Features
  New Posts New Posts RSS Feed - Support for D3 Paths
  FAQ FAQ  Forum Search   Register Register  Login Login

The AccuTerm forum has moved. Go to community.rocketsoftware.com to register for the new Rocket forum.

Forum LockedSupport for D3 Paths

 Post Reply Post Reply
Author
Message
TonyG View Drop Down
Beta Tester
Beta Tester


Joined: February 04 2004
Location: United States
Status: Offline
Points: 127
Post Options Post Options   Thanks (0) Thanks(0)   Quote TonyG Quote  Post ReplyReply Direct Link To This Post Topic: Support for D3 Paths
    Posted: June 23 2017 at 9:35am
I'd really like to see AccuTerm+wED support D3 Path AND OSFI syntax:
account,file, item
host:account,file, item
drive:path\dir file=itemname


Thanks.



Tony Gravagno Nebula Research & Development
TG@ Nebula-RnD . com
http://Nebula-RnD.com/blog
http://Twitter.com/TonyGravagno
http://groups.google.com/group/mvdbms
https://www.linkedin.com/groups/64935
Back to Top
TonyG View Drop Down
Beta Tester
Beta Tester


Joined: February 04 2004
Location: United States
Status: Offline
Points: 127
Post Options Post Options   Thanks (1) Thanks(1)   Quote TonyG Quote  Post ReplyReply Direct Link To This Post Posted: June 23 2017 at 3:35pm
Having spent more time with this, I have a solution for WED for a full path. I don't know if I'll have time to look into any other path-related issues for a while.

There is a bug in the WED EXE (not the host code) which cuts-off the comma trailing a full path. So when you use this command:
WED ACCT,FILE, ITEM

The client application gets that comma but then it keeps coming back to the server with requests for:
ACCT,FILE << note no trailing comma

To patch this until WED is fixed: in FTBP FTSVRSUB, add this before the ERR=0 line:

* TG Start: added to support D3 pathing and WED bug which crops-off last comma from FNAME
IF INDEX(IO.FNAME,',',1) THEN
    OPEN IO.FNAME TO FTMP ELSE ; * If this is a local dict,data name, ignore it
        OPEN IO.FNAME:',' TO FTMP THEN ; * Verify that this is a valid full path
        * This is a full path in D3, looks like WED cut off comma
            IO.FNAME = IO.FNAME:','
        END
    END
END
* TG End


The chance of that opening an unintended file is extremely slim.

A way to avoid this problem without a code change is to create a QS-pointer to the file:

01 QS
02 ACCT,FILE,


A final way to avoid the problem is simply to login to the account that contains the file.

Personally I prefer to change the code so that I don't need to do any housekeeping to avoid this issue. I code where I need to be and I don't want the tools to tell me I need to do otherwise. YMMV

HTH
Tony Gravagno Nebula Research & Development
TG@ Nebula-RnD . com
http://Nebula-RnD.com/blog
http://Twitter.com/TonyGravagno
http://groups.google.com/group/mvdbms
https://www.linkedin.com/groups/64935
Back to Top
TonyG View Drop Down
Beta Tester
Beta Tester


Joined: February 04 2004
Location: United States
Status: Offline
Points: 127
Post Options Post Options   Thanks (1) Thanks(1)   Quote TonyG Quote  Post ReplyReply Direct Link To This Post Posted: June 23 2017 at 3:49pm
Regarding the use of WED with D3 OSFI to OS/network resources:

WED C:/FOO BAR
WED /TMP BLAH


There is another very esoteric issue which may cause that to fail.
There is a verb, SET-REMOTE-CLOSE, which forces a close on OSFI files immediately after opening. This is useful to clean-up system resources and may be required for some extensive uses of OSFI.

The FTSVRSUB program caches file descriptors (handles=pointers) to avoid the performance penalty of re-opening files. I do this a lot myself. However, if a pointer to an OSFI resource is cached, the pointer is forced-closed with that verb or another mechanism, and then the pointer is re-used, it results in a file open failure. The verb is useful but this is an unfortunate side effect.

One solution here would be to temporarily turn off that option for your port using "SET-REMOTE-CLOSE (F". That's fine for a developer that's using limited resources. But for the rare site that's doing something else with the AccuTerm client/server feature, that's not a good option. (And if anyone is actually doing any of this, I'd like to buy you dinner.)

Another less effective way to avoid the file-open issue is to modify FTSVRSUB in the OPEN.FILE sub. Replace the "IF Var<200" block with this:
* TG Start: Don't save/re-use OSFI pointers
IS.NOT.OSFI = 1
IF INDEX(IO.FNAME,":",1) THEN IS.NOT.OSFI = 0
IF INDEX(IO.FNAME,"/",1) THEN IS.NOT.OSFI = 0
IF INDEX(IO.FNAME,"\",1) THEN IS.NOT.OSFI = 0
IF Var < 200 AND IS.NOT.OSFI THEN
    OPEN.FILES(1)<-1> = IO.FNAME
    OPEN.FILES(Var+1) = FLV
END
* TG End


That will help if you open C:/TEMP or C:\TEMP or just \TEMP or /TEMP.

Now that I think about it, the solutions provided here might address OSFI-related issues with FT, FTD, FTPICK, etc too, because I think they all use these same mechanisms.

If anyone implements and tests these changes for local/remote server exchanges, I'd be grateful for feedback.

And I'd be even more grateful to Zumasys if these solutions get incorporated into the product.

Thanks!
Tony Gravagno Nebula Research & Development
TG@ Nebula-RnD . com
http://Nebula-RnD.com/blog
http://Twitter.com/TonyGravagno
http://groups.google.com/group/mvdbms
https://www.linkedin.com/groups/64935
Back to Top
iharper View Drop Down
Newbie
Newbie


Joined: October 13 2015
Status: Offline
Points: 12
Post Options Post Options   Thanks (0) Thanks(0)   Quote iharper Quote  Post ReplyReply Direct Link To This Post Posted: July 14 2017 at 1:57pm
I'm glad you pointed this out. I've been annoyed that wED can't open using account,file, item references. We've got Q pointers setup for most BP files so it's not something that I run into on a daily basis.
Back to Top
SeanC View Drop Down
Newbie
Newbie


Joined: July 06 2021
Status: Offline
Points: 8
Post Options Post Options   Thanks (0) Thanks(0)   Quote SeanC Quote  Post ReplyReply Direct Link To This Post Posted: October 28 2021 at 2:32pm
I'm late to this parade. I've run into that problem as well.
Back to Top
PSchellenbach View Drop Down
Admin Group
Admin Group

Moderator

Joined: December 15 2003
Location: United States
Status: Offline
Points: 2150
Post Options Post Options   Thanks (0) Thanks(0)   Quote PSchellenbach Quote  Post ReplyReply Direct Link To This Post Posted: October 28 2021 at 3:01pm
The problem with unusual file name syntax is deeper that you think. Pick file names are converted into a URL-style path in the Windows programs (WED, GED, etc.), and the 4-level hierarchy is expected all the way until its sent back to FTSERVER to handle the action. Something like mvdb://server\account\dictname\filename\itemid. So when you use WED FNAME ITEMID it get converted to a path like mvdb:\\*\*\MD\FNAME\ITEMID. If the trailing comma were to be supported, then when this path is displayed in the browser tree for opening or saving, you would expect to see the foreign account in the tree, and be able to browse files in that account. FTSERVER does not support access to more than the current account, mainly for security reasons.

The VSCode connector is a bit different as VSCode itself implements the file browser. In this case, the connector implements a simple File System REST API and converts file paths into normal MV file names. Again commas for foreign accounts would be problematic. Here's a link https://github.com/mvextensions/mvbasic/blob/main/doc/MV%20REST%20File%20System%20API.md to the API documentation.

A "WED Pre-processor" or "VSCODE Pre-Processor" would probably be the most reliable solution, where a temporary Q pointer was created for the foreign file, then deleted afterwards.

I wish I had a better solution,

oops - trailing comma above - whats that mean?

Thanks, Pete

Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.03
Copyright ©2001-2019 Web Wiz Ltd.