I have several .fexes which have DOS commands in them - most are the COPY command to combine 2 files into a third file (like COPY file1 + file2 = file3). I also have some .fexes which have -DOS ftp.....

All of these have worked for months/years (as recently as July 23). Yesterday we noticed DOS commands stopped working. We don't get an error, we just don't get the DOS command to do what it used to do. No changes have been made to these .fexes since July 23.

I searched the IBI website and found something about permissions on the server, but our IT guy says nothing's changed there since July 23.

I'm wondering if anyone has any ideas.

We use WF 7.64 on a Windows NT box.

This message has been edited. Last edited by: Kerry,

I must admit that I haven't used -DOS for a long time - I use CMD or SYSTEM if I need the return code (e.g. -SET &DOSRet = SYSTEM(24, 'E:\scripts\Test_Mail.vbs', 'D4')

T

try -WINNT

Thanks for the suggestions. I tried all 3 - CMD, SYSTEM and WINNT - a couple different ways to COPY or TYPE a file but nothing works (anymore).

I either don't get any error, or I get an error (I tried with and without a hyphen as a prefix. Since you used parenthesis with SYSTEM, I did with and without parenthesis.

Any other ideas as to how to COPY or FTP a file when DOS (or CMD, SYSTEM or WINNT) stopped? And/or why DOS worked fine last week, but not anymore?

I'm sure there are hundreds out there who will echo the same reply. Things don't just "stop" working for no reason. When someone says that nothing has changed this actually means

Nothing SIGNIFICANT TO THEM has changed.
Nothing was changed ON PURPOSE.
Nothing THEY THINK YOU NEED TO KNOW ABOUT has changed.

Sometimes without understanding how everything interacts, changes happen that affect other process that were not considered.

For example, a system user id has a password that is set to expire every six months. The password expires, but no one ever logs in with that id (it is used by the system only) so none of that account's processes/privileges are functioning any longer. (this could explain your issue). Maybe a DNS entry changed on the network, some kind of firewall is interfering, etc., etc.

I wouldn't worry so much about how to change things to make them work. Find out what REALLY DID change and get that fixed.

Darin,

I agree with you 100%. I only know my focexecs haven't changed. And, unfortunately, I have to rely on our Network guys about any changes to the environment in which our focexecs run. Getting information from them usually isn't very easy.

you don't use a - in front of your command, right?
CMD STATE D:\IBI\APPS\AS400\TESTEDA.FTM
try a STATE command on some file in on your box
and see what your -&RETCODE is

i use this syntax on an NT box as we speak.

I had been using -DOS when these were working (until yesterday).

While testing today, I included and excluded the dash.

When I just tried STATE (which I've never used before), I did CMD, -CMD, DOS, and -DOS. For -CMD I got a focus error (I think similar to what I got earlier today while testing). For the other 3 I just tried, I didn't get any error or any kind of output.

I don't know if you have access or not, but you might try checking the system event log to see if errors are popping up.

There is also a setting for the WF server that can disable the ability to execute system operating commands. Don't know why that would have suddenly changed, either, but worth a look.

no dashes.
why they were working before is a mystery.
but no dashes.
for
CMD STATE filename
did you check the value in &RETCODE ?
It should return a 0 if the file exists
and a -1 if the file does not exist.
(and in unix the state command spits out an error message if the file doesn't exist.. i can't remember if it spits in windows or not...but the fact that you didn't see an error may be a good sign).
..
CMD STATE filename
-RUN
-TYPE RETURN CODE FOR MY STATE IS &RETCODE
and then try some
CMD COPY filea fileb
and see if windows spits back the copy confirm.

Darin,

I haven't asked about event logs yet, but I'll try that. But previously when asking our network guys about that, it's been unproductive.

IBI suggested verifying the server started with an ID which can execute DOS commands. Our network guy said it was. But if you're asking something different, do you know where that switch is (to disable operating commands)?

susannah,

I tried a couple variations of the following:

CMD STATE F:\system\ibi\apps\Interfaces\TEST.FEX
-RUN
-TYPE RETURN CODE FOR MY STATE IS &RETCODE
CMD COPY F:\system\ibi\apps\Interfaces\TEST.FEX F:\system\ibi\apps\Interfaces\TEST9.FEX
-EXIT

Basically, I get a return code of 0 (which is more positive than any other result today), but the file doesn't get copied.

There is a setting in WF that can deny access to the OS, SET OPSYSCMD=OFF, perhaps this is set on ?

You should get a message stating that system commands are disabled.

Waz,

IBI suggested that. I looked, and that setting isn't in WF. Thanks for the suggestion though.

Mark,

If the system commands route seems to be barred from you by sources unknown and you can't them to admit or undo what they've done then try the APP method of copying files -

APP COPYF appname1 filename1 filetype1 appname2 filename2 filetype2
where:

• appname1 - Is the application that contains the component to be copied.
  
• filename1 - Is the component to be copied.
  
• filetype1 - Is the file type of the component to be copied.
  
• appname2 - Is application to which the named component is being copied.
  
• filename2 - Is the component in the second application, after the copy process.
  
• filetype2 - Is the component type in the second application, after the copy process.

How you are going to circumvent the CMD FTP is going to take some thinking and imaginative coding.

T

Did your try using the bang (!)? For example:
!DIR

If you get a directory listing, then you could try:
!copy ...

Tony,

As a test, I tried copying a .fex, where:

appname1 and 2 are the same - Interfaces (the name of the folder/application where the file is and will be copied)

filename1 = test9
filename2 = test8

I wasn't sure about filetype other than I assume it's the filename extension, or in this case FEX; I tried with and without a period (.FEX or FEX)

for example: APP COPYF Interfaces TEST9 FEX Interfaces TEST8 FEX

I also used all uppercase for Interfaces

Every time I got a (FOC224) SYNTAX ERROR


Danny,

I tried a couple commands with ! and they give me what DOS gives me - EDA no data



I don't know if I tried this earlier in my testing, but recently, TYPE and REN (without DOS) does work - whatever clue that tells me. Of course, I've tried other commands with DOS, but they don't work.

folkey,

I look help files dev studio I find filetype be FOCEXEC (capitals) all line be captials then work OK.

I hope help

Kofi

quote:

EDA no data

This true but it work. see folder, file there OK.

Kofi

Kofi,

I just tried APP COPYF Interfaces TEST9 FOCEXEC Interfaces TEST8 FOCEXEC

and it worked! That's good. I'll do more testing, but what I need is something similar to COPY file1+file2=file3. Plus, using the DOS command, these 3 files have an extension of .txt. I'll have to see what Dev Studio calls these types of files.

Mark,

There are many file types (~60) that you can copy using APP COPYF. If you have Dev Studio then, as Kofi suggests, the help files are quite useful. Failing that use the search link above right to search the tech documentation library.

For Text files the filetype keyword is TXT.

As for your COPY file1+file2 etc. then I would ask how these files get created? If they are outputs from fexes then use the FILEDEF (APPEND syntax to add subsequent outputs.

T

Tony,

A little while ago I tried TXT and it worked with COPYF. I looked in help and saw a whole lot (I guess ~60 like you say).

For the files I want to append, I create them from the same .FEX where I want to append them.

I looked in help hoping there was a similar APP command which I could use to append the files, but didn't find one.

I didn't think about FILEDEF APPEND - never heard of or used that. I'll look into that one.

I want to thank everyone for all your suggestions.

After IBI recently asked me about whether a specific pw changed, and to recycle the server, I passed the questions/suggestions on to our network person. He did a thing or two. Still no DOS. Then he asked me to try again. Now I'm back to getting DOS working from within WebFocus.

I asked our network guy what he did. He hasn't replied, so I guess it's top secret.

quote:

a system user id has a password that is set to expire every six months. The password expires, but no one ever logs in with that id (it is used by the system only) so none of that account's processes/privileges are functioning any longer

Sometimes it just takes a VERY SPECIFIC question. At least now you know who to call when it happens again...

I was able to get some info from out network guys. First, to be clear, they recycled some services, not the server. That was one item IBI suggested yesterday.

Basically, the problem deals with some new antivirus software - Trend Micro - that we have.

Apparently, Trend Micro thinks the DOS commands in WF are acting maliciously and prevents them from working. When we stop the service - I'm not sure which, but it's something to do with Trend Micro - DOS works fine. Trend Micro is also causing another nonIBI problem where it doesn't let us open up Internet Explorer by clicking on a link which is supposed to open IE from within a SQL (I believe) application with a MS Access front end. Stopping a Trend Micro service makes that problem go away also.

Our network guys are saying sometimes these services restart - I'm not sure if it's everyday or when certain things occur – and they have to stop the service(s) for these things to work. But they're working with Trend Micro to see if Trend Micro will not assume DOS within WF is malicious.

Thanks again for all your suggestions.

They should be able to disable the services which will prevent them from ever starting. If it's uninstalled, it's likely that the service will be re-established, but if you leave it there and disable it in the services console. that should fix it for good.

Glad you got it figured out.