I have a customer PC that when printing from ATE or even preview in APEX will display an error that it cannot locate the file in the local directory...
c:\user\documents\apex\...
I can access this dir from notepad w/o issue. There are some older print files in this dir from about 2 weeks ago but for some reason it seems that it cannot write there. If i try to transfer a test file there manually from linux it seems to work.
I don't want to establish another transfer directory yet, so in the meantime where i can look in the way of a trace to tell me what the reason for the failure is? And would this be a server or pc based trace?
TIA
Re: ATE: failure to write to local dir
[Re: Frank]
#3339517 Sep 2010:30 PM
Are you getting an error message box? Does it have an error code in it?
The problem is almost certainly on the PC side, whatever it is. You might be able to get some clues by opening the debug message window and activating the following traces: FOPENS, ATE, LP, GDIPRT, XDEBUG. Then print a file to the PC. You'll want to turn off the XDEBUG trace shortly thereafter because it otherwise outputs too much stuff. The trace lines that seem relevant are ...
Code
7 15:10:46 <TELNET:45e4> TAB(-10,85);5,PRINT,3.4(135)
8 15:10:46 <TELNET:45e4> TAB(-10,54);Þtskaap.prx,,0,,262144,1,2296,1
15 15:10:46 <TELNET:45e4> AUX ON rcvd, w.wtc = 0
16 15:10:46 <TELNET:45e4> Aux print: switches=0x4(4), ptrfile=tskaap.prx, ptrname=, mime=0, copies=1, pfileize=2296
18 15:10:46 <TELNET:45e4> Aux print: using printer from config: <Prompt>
19 15:10:46 <TELNET:45e4> fopen(C:\Users\joaqu\OneDrive\Documents\APEX\tskaap-5.prx,w) returns 0x1188520
Line 7 shows the program launch on the server (PRINT.LIT in my case) Line 8 is the AG_SPOOLCFG Lines 15-18 are the start of the aux printing Line 19 is the opening of the file to capture the text (which I think is the one that's failing, although I'm not 100% sure.)
Note that the combination of the FOPENS and XDEBUG trace will cause the fopen() function to output an additional trace on failure.
Also, note that c:\user\documents\apex\ isn't exactly the expected directory; maybe that was just a typo but I would expect it to be more like c:\users\<username>\Documents\APEX. (You can see from my traces above that in my case ithe Documents directory got relocated under OneDrive. Which I don't recommend.)
Re: ATE: failure to write to local dir
[Re: Frank]
#3339617 Sep 2011:28 PM
I see the cache error but cant locate a new sysmsg.usa on the soslib site to decode... perhaps you could shoot me a new one or link one up here please...
Re: ATE: failure to write to local dir
[Re: Frank]
#3340018 Sep 2004:51 PM
does indicate failure (the return value should not be 0), but unfortunately it doesn't give us any additional details beyond the rather misleading message "cannot find the file". We're creating the file, so it is hardly surprising that it isn't "found". We can guess that it can't find the directory, but one would expect it to give a different error then. And, since you can write to the file with an explicit file transfer, or Notepad, it hardly seems likely that the directory has become inaccessible. So I have to admit I'm baffled.
I'm guessing that if you tried your manual transfer using ZTXFER with the /ATE switch, you'll get the same problem? (The /ATE switch tells it to use the terminal channel, just like it does for printing, rather than FTP.)
All of that would suggest that the file open library routine used by ATE, fopen(fspec,mode) is susceptible to some odd condition causing it to fail, whereas the file open library routine used by Notepad (there are several possibilities, but I'm guessing CreateFile(), is not, fopen() is the standard platform-independent function used for opening a stream, whereas CreateFile() is Windows-only. It has a lot of extra parameters relating to security factors, which may explain why it is working when the other isn't, but unfortunately it uses a different type of handle, making it difficult to swap one for the other without affecting all of the routines that read/write to sequential files. And none of that explains why it works in 99.9999% of the ATE workstations that we know of, and was working at this one as well up until a few days ago?
At this point I would be tempted to just recreate the directory (rename the old one and create a new one), making sure it offers full read/write privileges to all the relevant users. If that doesn't work, Plan B would be to define the APEX environment variable to point to some other directory that we know works, perhaps underneath the main ATE directory?
While stewing over that, here's a quick fix to the "cache error" issue caused by missing a couple of messages. You can just use VUE and yank these into your existing SYSMSG.USA. (I'll see about updating the UPDCUR system later.)
Code
004,001,Cut
004,002,Copy
004,003,Paste
004,004,Select All
004,005,Clear Selection
004,006,Clear Messages
004,007,Properties
004,008,Dump Font Cache
004,009,Print Screen
004,010,Set Debug Mode
004,011,Paste Special
004,012,Copy Cell
004,013,Dump Control Table
004,014,Close
Re: ATE: failure to write to local dir
[Re: Frank]
#3340118 Sep 2005:09 PM
Hmmm, actually i did remove the directory the other day and create it manually. However i didn't test with /ATE switch when i performed the file transfer...
Let me give that a go...
Re: ATE: failure to write to local dir
[Re: Frank]
#3340218 Sep 2005:27 PM
You know that I don't know nothing about ATE but, could it be the case of that operation being executed by a system user w/o permissions over that folder? Have you checked in the folder's Properties which users can do what? If you created it manually, it could have been indexed to your user, that opens the Notepad and does other user driven operations, but ATE don't. Just shooting
Last edited by Jorge Tavares - UmZero; 18 Sep 2005:29 PM.
Jorge Tavares
UmZero - SoftwareHouse Brasil/Portugal
Re: ATE: failure to write to local dir
[Re: Frank]
#3340318 Sep 2006:16 PM
The detail that doesn't quite fit is that ATE (effectively equivalent to A-Shell/Windows client) runs in the same user space as Notepad would. But, as I noted above, Notepad is no doubt using the more sophisticated Windows CreateFile() function, potentially with different security flags than the default ones used by fopen().
But that makes me think of another thing you could try: Use the File > Open Local Session and from the new dot prompt, try:
Code
.VUE C:\Users\Arelis\Documents\APEX\qui001-1.prt
It should prompt you to create the file, then let you edit it. Type in something, save and exit, and then repeat the command to see if it actually saved it.
VUE should be using pretty much the same kind of file i/o as ATE printing, so it should have the same kind of issues. Which might not tell us anything new, other than eliminating any question about it being something peculiar to ATE, since the local session is pretty much plain vanilla A-Shell/Windows.
Re: ATE: failure to write to local dir
[Re: Frank]
#3340518 Sep 2007:29 PM
Then i tried a straight ztxfer w/o the ATE swtich and got this:
FTPDLX error code = 30024 (Error occurred trying to write to local file.)
I can however send to another directory... so perhaps some issue in the users folder. I snapped the permission of this directory but again it looks fine to me... but im not a windows engineer
Last edited by Frank; 18 Sep 2007:40 PM.
Re: ATE: failure to write to local dir
[Re: Frank]
#3340618 Sep 2007:44 PM
PS: Sorry Cap crossed posts.. .didnt have a chance to try your VUE test... that might help narrow it down as well... i will most likely now have to wait til Monday to persue further but at least you can take a gander at the above.
Re: ATE: failure to write to local dir
[Re: Frank]
#3340718 Sep 2008:46 PM
The fact that the regular ZTXFER (SFTP) also fails suggests the issue is more than just related to the fopen() library call used by ATE. (The SFTP client would have probably used CreateFile()).
Are you sure that the logged in user is Arelis?
Try entering %documents% in the Start>Search bar to verify that it takes you to the same directory.
Re: ATE: failure to write to local dir
[Re: Frank]
#3340818 Sep 2008:48 PM
To avoid any doubts, add the users "all" with "full control" and, also, check the "Sharing" tab and confirm if there are any rules with chances to block any traffic (you don't necessarily need to share that specific folder, I believe it's under upper level precendences). That's an "working folder" so, I believe it's not under very restrictif rules, although the reports go there but no one knows about that :-) Good luck
Jorge Tavares
UmZero - SoftwareHouse Brasil/Portugal
Re: ATE: failure to write to local dir
[Re: Frank]
#3342021 Sep 2008:40 PM
Ok - its a bit late for April Fools and too early for Halloween but there is something unholy happening on this station...
First as prescribed i made sure the %documents% directory was correct and it was.
Then i tried the VUE test, and it "seemed" to build a file in the APEX directory.. however windows had no history of it. So then i simplified the test and tried
.vue c:\fmc\jack.tst. I created a small file, and even re-vued it. However same problem, Windows has no history of this file on the local PC.. i even did a full PC search. (see attached as proof).
So as i poked around the file explorer i noticed that this station was at one time running our ashell for windows application (there are remnants of these files in other areas). They have since moved to our cloud options and running ATE. I verified that indeed the icon was running ATE and connecting to the linux server and not the older windows connection, but i have to wonder if perhaps there are some old registry entries that are confusing ATE environment variables.. but even still, how do you reconcile the simple VUE test.. i mean either the file is there or its not! Ashell sees it and i can't find it on the windows side...
At this point i might need an excorcist! Seriously tho now i am completely lost in the ashell corn maze here... Jack we can perhaps establish a connection if you think it would help to poke around.. or let me know what next steps make sense.
TIA
Re: ATE: failure to write to local dir
[Re: Frank]
#3342121 Sep 2009:41 PM
I feel like the new subtitle of this thread should be "When is the C: drive not the C: drive?" ...
Looking at your image, the only explanation I could come up with is that the VUE session is running in the Linux space on the server, while the Explorer window of course has to be the Windows client. Just to confirm that can vue c:\fmc\test.lst successfully under Linux, I did so, and now have this in my directory list on Linux ...
So I have to ask: Are you SURE you launched the VUE session from a Local PC session (File > Open Local Session) ? (Note that the title bar of the window mentions "Cloud", making it look like a regular ATE connection to the server.)
An easy way to confirm this would be to use the PWD command at the dot prompt prior to the VUE test.
Unfortunately I think we're in the mode of debugging the debugging, but it would probably help relieve the vertigo to find some firm directory ground to stand on.
One other question: are the client PC's running ATE locally? Or are they connecting to some Windows server in the cloud and running ATE from there to your Linux machine? If the latter, maybe there is some legitimate room for confusion as to which C drive we're talking about.
Re: ATE: failure to write to local dir
[Re: Frank]
#3342422 Sep 2004:20 PM
ATE > Cloud Linux server. No RDP or other connectivity. Yes i was on the correct station. And i did a PWD and verified i was in the right church and right pew.
The original problem is with APEX not having access to the local /apex dir on the C drive. I was under the impression from your "vue" test that we could access this area, NOT the linux server. So i don't know what this test brings to the party.
How do i get vue to open a file on the LOCAL C drive of the PC? Or even write a simple test program to do so? I tried to open #1,"c:\fmc\test.dat",output and it creates a file on linux server not PC. Since linux use / and windows \ i thought ashell was smart enuf to detect where to place the file...
Re: ATE: failure to write to local dir
[Re: Frank]
#3342722 Sep 2006:51 PM
The only way to get VUE to open a file on the LOCAL C drive is to launch VUE from a LOCAL session on the PC, rather than from the ATE connection to the server. To do that, use File > Open Local Session (to create a new A-Shell/Windows session running locally on the PC), and then execute the VUE command from that dot prompt. That window will look suspiciously like the ATE window, so you may want to use the PWD command to verify that you really are operating within the PC environment, but it's also the case that while you have the local session open, the ATE window will be suspended.
It would be a nice trick for VUE.LIT running under A-Shell/Linux to recognize that the file you want to open looks like a PC filespec, and to then somehow redirect the operation back to the PC for execution, but that's a pretty tall order. Typically, if you want to be able to operate from system X on files that are resident on system Y, you have to do some kind of network mount of system Y's directory to make it visible to system X.
The point of the vue test was to convince ourselves that there wasn't some kind of vendetta against A-Shell preventing it from writing to the PC directory. We already know that Notepad can write to it, but we can't figure out why A-Shell can't write to it. I think it's because there's some confusion in the filespecs, or the context in which the filespecs are being evaluated, but I can't quite see just what the issue is. If we could at least establish that there is no problem with A-Shell/Windows running locally on the PC opening up a file on that directory, then we could eliminate the suspicion that the issue was related to privileges, and instead focus on the suspicion that it's just some kind of confusion of which system is which, i.e. which C drive we're talking about.
Re: ATE: failure to write to local dir
[Re: Frank]
#3343022 Sep 2007:07 PM
Ok i think we are peeling the layers of the onion.
Trying to Vue from ashell (ATE>Open local session) indeed there is some permission problem (see image)
So i tried parent folder of /documents and still no joy.
I was however able to access c:\users\arelis\jack.txt with no issue... so we have narrowed the problem to the documents folder. I checked permissions they seemed open.. also checked security to see if it had any restriction on ashell and didn't see any.. but i am not a windows expert by any measure.
So thoughts on what to look at next? Pass it back to their IT? Their pat answer is well i can see it in notepad so all is fine!
Re: ATE: failure to write to local dir
[Re: Frank]
#3343623 Sep 2004:39 PM
That's a tough one. It does sort of appear that the system may be imposing different security rules on different executables. And that's certainly possible. My suspicion would be on some kind of extra-Windows security layer (like a third-party anti-virus). But in that case, you would absolutely need the help of whoever set it up and controls it. You might be able to get some insight to that by just going into the Windows Security panel to see what virus protection is present.
If it comes down to the old "works in Notepad so it must be a bug in your program" tactic, I guess the comeback would be "works in my application in every other directory, why not this one?".
And a some point you may ask yourself why fight this when you can work around it by creating a new APEX directory. Once you define the APEX environment variable on that PC, the reconfiguration will be a non-issue for your application, which doesn't really need to know or care where the APEX directory is. Or, if you prefer to handle it entirely from your application, you can use AG_SETENV to just define the APEX environment variable on the PC to point to any existing known directory.
Re: ATE: failure to write to local dir
[Re: Frank]
#3343723 Sep 2004:47 PM
I agree... when its 4th and forever, punting seems to be the logical option. I really wanted to see this thru however since its not the first time and probably won't be the last. I think ill punt this back to them for any resolution and if not, as you suggest just change the apex location.
Can you remind me how to do this? I don't want to add anything to the application since i really want this to be a single station solution.
Is this something i can just add to the miame.ini on this station's pc environment?
Re: ATE: failure to write to local dir
[Re: Frank]
#3343923 Sep 2005:35 PM
Just enter "Envir" in the system search bar, select Edit System Environment, then click on Environment Variables, and define a System variable APEX that equates to a directory you know exists and is writable. (You may want to just create an APEX directory under the ATE directory.) Under Windows 10, i think the effect is immediate (although it may be necessary to re-launch the ATE connection - I'm not sure about that.)
You can test it from the A-Shell/Linux dot prompt with the AGCMD ...
Code
.AGCMD GETENV APEX
Note that in the usual case, APEX is not defined as an environment variable. When you define it, ATE then uses that definition instead of the internal definition of \Documents\APEX.
