Print Page | Close Window

Support for D3 Paths

Printed From: Rocket Software
Category: AccuTerm Knowledge Base (read only)
Forum Name: Advanced Features
Forum Description: Private escape sequences, host integration using the AccuTerm Server and ObjectBridge
Printed Date: December 04 2022 at 3:45pm
Software Version: Web Wiz Forums 12.03 -

Topic: Support for D3 Paths
Posted By: TonyG
Subject: Support for D3 Paths
Date 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


Tony Gravagno Nebula Research & Development
TG@ Nebula-RnD . com

Posted By: TonyG
Date 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:

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
    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:','
* 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

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


Tony Gravagno Nebula Research & Development
TG@ Nebula-RnD . com

Posted By: TonyG
Date Posted: June 23 2017 at 3:49pm
Regarding the use of WED with D3 OSFI to OS/network resources:


There is another very esoteric issue which may cause that to fail.
There is a verb," rel="nofollow - 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
    OPEN.FILES(1)<-1> = IO.FNAME
    OPEN.FILES(Var+1) = FLV
* 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.


Tony Gravagno Nebula Research & Development
TG@ Nebula-RnD . com

Posted By: iharper
Date 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.

Posted By: SeanC
Date Posted: October 28 2021 at 2:32pm
I'm late to this parade. I've run into that problem as well.

Posted By: PSchellenbach
Date 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" rel="nofollow - 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

Print Page | Close Window

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