Hey Cap -

I have tested this on older Ate flavors and it works but with my new ATE 7.0.1752.5 I am getting the following error when trying to ftp something to/from linux from ATE:


local ashlog:
04-Jan-24 16:35:51 [DESKTOP-38J0SAK:01-0]<TELNET:6> xcall_error(FTPDLX,3)
04-Jan-24 16:36:21 [DESKTOP-38J0SAK:01-0]<TELNET:6> Clearing intrap flag for error 12
04-Jan-24 16:36:21 [DESKTOP-38J0SAK:01-0]<TELNET:6> Trapped Basic Error #12 (Subroutine not found) at location counter &h45E4
04-Jan-24 16:36:21 [DESKTOP-38J0SAK:01-0]<TELNET:6> Call stack trace, from program TELNET :

Thanks.

If the subroutine is actually not found, that kind of suggests that the FTPDLX COM module hasn't been registered. But FTPDLX has been deprecated for years now, having been replaced by FTP2. So I strongly recommend just pivoting. The old ZTXFER.LIT defaulted to FTPDLX mode, forcing you to explicitly specify the /2 switch. But if you run UPDCUR from the SYS: account to get the latest ZTXFER 1.4(110), it now defaults to the newer mode.

So i tried the /2 before posting and got the same result. Is it possible that somewhere in 7.x it forces ftp2 automatically? Anyway, with that being said i do not have FTP2.SBR on our server... should I?

Assuming you have a reasonably current ZTXFER, /2 should only revert to FTPDLX if the ATE version is ancient. But neither FTP2 nor FTPDLX ever existed as SBR files (which don’t exist in A-Shell). The FTP2 xcall interface is internal, and the actual code is in ashnet. FTPDLX relies on and ALIAS which links it to a DLL.

Ok running ztxfer.lit (109).

Lets focus on why it doesnt work with 7.x ATE but does with 6.5

I’m keeping eye on this as interestingly my ztmftp also stopped last month , I thought it was all related to new office move and changing from vpn to Tailscale and bunch other things , Ive still not solved it and started temporary cheat use the /ATE switch ,I can’t check til tomorrow but wonder if was same time I update to ATE 7.0/Client.

After researching this a bit, I have to admit that I'm still not sure why it isn't working. I am sure that the problem is purely on the client side though. (Connecting from ATE 7.0 to a LInux server and using ZTXFER/1 generates the error, while connecting to the same server from ATE 6.5 does not.) The same goes for running it from A-Shell/Windows 6.5 or 7.0.

The error is "Error pinging COM subroutine", which indicates some kind of breakdown in the COM interface, which consists of the following parts:

• ALIAS=FTPDLX:FtpDLXcall.FTP in the MIAME.INI
• FTPDLXcall2.DLL and wodFTPDLX.DLL somewhere on disk, registered as COM objects using REGSVR32

I've double-checked both on my system, and I know the objects are successfully registered, because they work in 6.5. But even if I replace the 6.5 ashw32.exe in place, with the 7.0 version, it fails. So it's not related to an issue with the directory itself.

The fact that it's just now being discovered seems to imply that people have been taking our advice and migrating to the newer version (introduced in 2014).

I guess I'll need to get a longer shovel to dig deeper into it. But even if/when the mystery is solved, it isn't going to fix the reason why we switched in the first place, which is that the older routine is dependent on library modules that haven't been updated in a decade or more, and it no longer supports all the modern variations and security-related protocol refinements of SFTP, so you'll increasingly find that there are sites that will reject your attempts to connect. FTP2 also has a number of other advantages, such as the ability to call it natively from Linux, as well as list, delete and sync capabilities, plus it's much faster when doing multiple transfers (because you can leave the connection open). So aside from the thrill of solving the mystery, as a practical matter you should definitely convert. Fortunately, that's pretty easy since FTP2 is pretty much a superset of FTPDLX with nearly the same calling parameters. And for ZTXFER, it's even simpler - just get the current version or add /2.

Thanks. ZTXFER/2 works fine from my W10 box but i am getting this debug window on my W11 box. I am assuming some local issue here since W11 wants to lock you out of almost every conceivable option. I have never seen an OS take you so many layers away from what you are doing. They want you to treat the PC as an appliance rather than a tool. Any ideas what I can do to resolve this? TIA.

Interesting. I never noticed this issue either, but I can easily reproduce it. Apparently by default Windows 11 protects the c: drive root directory. Installers can bypass that by elevating, but FTP doesn't have that option. I haven't tried unprotecting mine yet (it's probably not a bad idea), but if you want to, it appears there are many internet articles explaining how to do it.

For our immediate purposes though, I suggest just changing the target to a known accessible directory, like c:\ate\cache.

Well i did try a dir called c:\test above but i just tried the edgemed\cache dir and still no joy

ps: I am confused by the error at the bottom "failed to delete path" ???

You may have run into one of the slight differences between FTP2 and FTPDLX. You didn't provide the syntax of the ZTXFER command line or XCALL, but after some investigation I realized that in FTP2 the localpath argument needs to contain the actual file.ext. (This is a consequence of the greater flexibility it offers in terms of wildcarding.) Based on the error, it sounds like it thinks the target c:\ate\cache is the full filespec and not the directory. I haven't been able to reproduce that with ZTXFER, for example...

..seems to work fine.

If you want to provide a command line or code example, I'll see whether it's practical to update FTP2 to handle it exactly like FTPDLX did. I'm considering changing the FTPDLX front end to just translate directly to FTP2 to eliminate the problem, but there may be a few details like this that need to be ironed out.

Interesting, initially this was the command:

.ztxfer/2 post.run c:\edgemed\cache

But to your point this works:

.ztxfer/2 post.run c:\edgemed\cache\post.run
'/hosting/edgemed/vm/miame/dsk0/010000/post.run' -> 'c:\edgemed\cache\post.run'

But this does not:
.ztxfer/2 post.run c:\edgemed\cache\*.*
'/hosting/edgemed/vm/miame/dsk0/010000/post.run' -> 'c:\edgemed\cache\*.*'
^C interrupt

So are you saying its been this way for 10 years? Or something in 7.x has changed the behaviour?

I don't think this behavior has changed in the FTP2 implementation in 10 years. But I agree that it seems like a shortcoming, maybe even a bug, or at least a missing feature, that it isn't copying the post.run filename from the source to the destination if the destination is just a directory. Oddly, it works fine for me here. whether or not the target directory exists. (If it doesn't exist, it creates the directory, provided its parent exists.) Do you get the same behavior if the target is c:\ate\cache? There may be some confusion as to whether c:\edgemed\cache is a directory or the name of the file you want to copy to, but I guess it can always figure that out (although in the general case it would require a remote DIR operation which would double the number of round trips needed and thus slow the operation down).

In the ZTXFER case when copying to the PC, the ATE side could (and probably should) make that determination. Or maybe it's sufficient to just assume that if the target spec does not contain a period and extension, then it must be a directory. That may have been what FTPDLX was doing.

Adding the *.* in your example doesn't help because these are SFTP (*) wildcards, not AMOS wildcards, and in the FTP world, I don't think the idea of *.* on the target side is valid like it was under AMOS. And in any case, ZTXFER is just a wrapper for various file transfer methods, so it's not immediately obvious how it's translating the command line into an XCALL FTP2, although opening the message window and activating the ATE and XCALL traces reveals ...

That at least confirms that ZTXFER is not adding the job1.log filename to the end of the c:\ate target. But it doesn't tell us much more than that.

I'll put it on the to-do list to review the ATE-side of the AG_FTP operation, comparing FTPDLX to FTP2 to see if we can add some caulking to seal up a rough edge in auto-converting FTPDLX to FTP2.

(*) I've been assuming here that the context is an ATE connection over SSH, so that ZTXFER would be using SFTP rather than FTP. It it's actually a TELNET connection, then the same ZTXFER command line is going to invoke legacy FTP rather than SFTP, and despite any appearances to the contrary, those are totally separate implementations with almost nothing in common.

Ok, sorry this has taken so long but I think I've finally cleaned up all the loose ends here, in 7.0.1753.2 :

1) FTP2 now manually defaults the file.ext from the hostfile parameter into the localpath parameter for GET operations, if necessary, to eliminate the weird situation where that doesn't get handled automatically by the underlying FTP or SFTP service. (We never did quite pin down why it was working in some environments and not others, but this should eliminate the main obstacle in just switching from FTPDLX to FTP2.)

2) FTPDLX now works again. I finally tracked down the issue, which is too arcane to describe here, and I'm not quite sure when it surfaced, but it did seem to be related to either the refactoring for 64 bit support, the migration from 6.5 to 7.0, and/or updates to the development tool set. So the old ZTXFER without the /2, or the new ZTXFER 1.4(110) with the /1, should now work between ATE and CentOS 7. However, as previously noted, everyone should still switch to FTP2, because under newer Linux installations, such as Ubuntu 22 LTS, you'll get another error (FTP error code = 30042 (Crypto algorithm could not be negotiated)) due to the failure of the FTPDLX underlying library to keep up with the evolving SFTP protocols.).

The update can be done through the Help > Check for Updates menu. Links to the Linux platforms will follow shortly.

Hey Cap i appreciate the follow thru thanks very much will give it a full test whenever all the updates are posted tomorrow.

Note that for the purposes of ZTXFER, you only need to update ATE. (Even though you launch it from the server side, the FTP2 or FTPDLX operation is actually driven from the client. And as far as FTPDLX goes, one of its other weaknesses is that it's only available under Windows, so it would apply to LInux versions anyway.) But if you're calling FTP2 directly from your application, then the Linux updates would be applicable...

CentOS7/RHEL7:
ash-7.0.1753.2-el7-upd.tz
ash-7.0.1753.2-el7-x86_64-upd.tz
CentOS Stream 8:
ash-7.0.1753.2-cs8-upd.tz
ash-7.0.1753.2-cs8-x86_64-upd.tz
CentOS9/RHEL9:
ash-7.0.1753.2-el9-upd.tz
ash-7.0.1753.2-el9-x86_64-upd.tz
Ubuntu 22 LTS:
ash-7.0.1753.2-u22-x86_64-upd.tz
Debian 12:
ash-7.0.1753.2-d12-x86_64-upd.tz

Also, you should run UPDCUR from the SYS: account in order to get the latest ZTXFER.LIT (and any others that you may be behind on.)

Hey Cap - following up on this today.

Getting this from UPDCUR - can you provide some assistance? Or just link me up to the latest ztxfer.lit here and will worry about UPDCUR later... TIA

.updcur
UPDCUR 1.0(105) - Update current directory from online repository
A-Shell Version 6.5.1728.3
Current dir: DSK0:[1,2]
Repo: http://www.microsabio.net/dist/65dev/dsk0/001002/
Retrieving 001002.dir
Status = -6
Online repository not available for this directory
Checking current files against repository...
0 files updated, 0 new files, 0 already current, 0 errors
.

OK - realized i was being obtuse, but leaving this for future generations I did a /? got the help info, re-ran this from SYS: and it worked and said only 1 file updated. (NOT SURE WHICH ONE! Is there a log or some way to find out what was actually updated? I realize it scrolls but no way to see/recall what those results are!).

Unfortunately NO JOY on the ZTXFER.LIT(110) as I am still lookiing at (109) here.

As noted by the UPDCUR/? message, only a few directories are supported. Currently those are:

• SYS: (DSK0:[1,4])
• BAS: (DSK0:[7,6])
• ASHINC: (DSK0:[907,16])

I'm not sure there's anything in the OPR: directory that would make sense to refresh from a common repository.

Please re-read the entire post above ^^^

Ok, I was initially focusing on the fact that you were trying to execute UPDCUR from 1,2 rather than 1,4. That's reason for the initial error messages. Looking at it again, I see that you were running it from A-Shell 6.5 rather than 7.0. For reasons that are hopefully acceptable to all, I don't see much benefit in updating the LITs for 6.5 when the preferred update route from 6.5 is to first go to 7.0. (In fact, there's no particular guarantee that LIT updates are backward compatible to earlier versions.) So the ZTXFER update you were looking for wasn't in the 6.5 repository. But, in this case I guess there is no harm in adding the ZTXFER update to the 6.5 001004 repository. (It's there now.)

As for getting a list of which files got updated, aside from activating the scroll back feature (which gives you 200 lines, more than enough to see every possible update in this program at least), it also creates a *.x0# backup copy of any modules replace. So for example, if DIR.LIT got updated, you'll see a DIR.L01 (or .L02, etc.) in your directory. That would be one way of checking which files got updated after the fact. Another would be to use DIR/LT/P, which will list the files most recently updated. I guess it would be nice to have some kind of report output from UPDCUR; maybe I'll add that to the wish list!

Gotit, thanks! (we are scheduling a 7.x ashell update for our inhouse servers soon...)

PS: after looking at all the files with JAN 10 on them there are well over 50 but the updcur summary said 1 update... maybe something to look at when you open the hood.

I'm confused. Did you see a see a screen full of "Upd" messages, followed by a summary saying only 1 file updated? Or did it all appear like just one file was updated, but you're confused why there are 50 files dated today? (I don't have answer for that, but it could be an unrelated cause, like copying or installing the files prior to UPDCUR.)

Just to review how it should work, you can force an update by copying one of the *.x01 files back to the original name and then running UPDCUR again. Here I'm doing it with ATSYNC.SBX ...

Well if i had a log i could tell you!!!!

It scrolled a bunch of files with .... OK. Not sure what OK means... OK the current version is current or OK it was Updated! Either way the summary said 1 file updated when clearly a ton were updated.

A better reply would be "UPDATED" or "CURRENT" or something similar....

PS: Either way unfortunately the new ZTXFER has caused FTP issue with our 6.5 ATE so in the meantime i will have to revert back... until such time we are all 7.x. Just a caveat emptor to anyone who is still following this thread... (forces /2 with full target dir)

PSS: ALSO on my 7.0.1752.5 boxes it is still requiring /2 as well as a full targer directory to work. Was there an ashell update as well? You just mentioned a server side update which didn't apply unless using FTP2.

All this also begs the question if it is now requiring a full target dir what happens when attempting a full wildcard transfer?!

I’m trying to keep up but currently lots of episodes behind here, if I catch up is it as entertaining and ends as good as Succession did?

Good luck! All for now...

I think you might have to binge read it REALLY fast to have any hope of excitement out of this particular series! But maybe some really loud music and a stiff drink would help.

For anyone who hasn't changed the channel yet, both the individual file lines and the summary both do actually make a distinction between new and updated files, with the two variations shown here ("Upd" vs. "New"):


vs.

Ok ill play... What does New: OK mean??!! vs Upd: OK! This is starting to sound like Trump's defense Atty!!

New means it was a new file that you didn't previously have. Upd means that there was an update to your existing file.
OK means that the operation (update or new) succeeded. The other main possibility would be some kind of error message.
Perhaps you'd prefer something more explicit?

What happens when there is NO update of any kind? Does it just not list it? I guess i envisioned the update going thru the update vault and tracing what happens after every file... if not now I know how the thing works...

The best way to see what happens if there are no files to update is to execute it a second time. But it sounds like you’re looking for a /VERBOSE switch that would lisr every file it was checking. Let me ponder…

Ok my fault for changing the primary topic here... its fine. would be nice if updcur had a log but its not mandatory.

Back to ZTXFER - the latest version still requires a target directory AND filename. I thought you were going to make it so that was not required. OR do i need a later version of ate?

Sorry, that was a modification added to ATE, not to ZTXFER. It seemed to make more sense to handle it there because ZTXFER is just one of many possibly applications using the AG_FTP interface to get ATE to initiate a file transfer. And besides, the original issue was tied to the Windows client, not to ZTXFER.

OK -

What version of ashell is required?

Also, unfortunately that doesnt explain why the new ztxfer.lit(111) stopped working for my 6.5 ATE installs... but by now i am inclined to just move onto the next fire.

If you use the Help > Check For Updates method, you'll have access to the necessary update, as well as the notes (with or without actually updating)...

As for ZTXFER 111 not working with ATE 6.5, I'm unable to see why that would be the case, nor have I been able to reproduce it here. ZTXFER updates aren't listed in the ATE release notes (because it is part A-Shell, not ATE), but the A-Shell 7.0 Release Notes do fairly describe the two recent updates 110 and 111. The only change there that would directly affect ATE was in 110, where the default transfer mode was switched from FTPDLX to FTP2. But you can force it to continue to use FTPDLX by adding the /1 switch.

Other than intellectual curiosity, it's not quite clear to me what you're trying to accomplish and/or avoid by examining every permutation of ZTXFER, ATE, and A-Shell version. It seemed like the original issue arose when you updated ATE from 6.5 to 7.0 (< 1753.2), which did in fact break FTPDLX and hence ZTXFER 109 (without the /2 switch). Updating to ZTXFER 110/111 fixed the FTPDLX issue by switching to the newer FTP2, but exposed a problem with the file.ext from the hostfile not being automatically added to a localpath directory in a GET operation. ATE 7.0.1753.2 fixed both of those issues, which should allow it to continue to work with any version of ZTXFER under any 6.5 or 7.0 version of A-Shell/Linux. So as far as I can tell, the issue was introduced by a 7.0 ATE update and then solved by a subsequent ATE update (which, however unfortunate, is neither unusual nor especially painful if detected during in-house testing). Although the situation was complicated by the interaction with the ZTXFER change of the default transfer mode, we could take it out of the picture (i.e. revert back to the prior 109 version), provided you're ok waiting for file transfers to stop working at some unexpected later date when a server updates its TLS package and starts demanding protocol support that FTPDLX can't satisfy.

Really not trying to exhaustively test this because I don't know about you but i am exhausted with the amt of time we have already spent on it. Your scenario is correct: 7.x NO WORK. Fix 7.x and 6.X didnt work. I have not updated the entire office to 7.x yet perhaps I should have.

Updated to 1753.3 and works as advertised. However i will tell you that the first time i got the debug message and second time it worked... not sure what is happening there but not going to waste more time on it.

As for 6.x i have reverted to the original ztxfer.lit(109) and those are working again. Going to close this thread for the time being.

This ending on a cliffhanger? Or is there a season 2 coming to tie it all up?

The studio didn't pick up the next season...

... unless, that is, we can figure out a way to work more sex and violence into the series. There has been talk of a cage match between the two stars, but the sex angle remains elusive.