It might be the same kind of problem as described here:

problem: parameters in batch file

My guess is that one of the scripts contain something like

C:%1.ipf

and the DOSBox command interpreter is not smart enough to understand that.

I've looked at the scripts and haven't seen any 1%.ipf commands anywhere

I retested the issue the exact wording is can not open file c:.ipf
rather the can not run file c:.ipf - my bad i was winging it when i wrote it -

with the kman program running the first script runs two other scripts as follows in the programs scripting code

script 1:
perform vs
perform m1
bye

script 2:
e.serr =true
finish all
e.serr = false
release all
load "\\profiles\\vl\\vx\\vl" with "E"
load "\\profiles\\vl\\vx\\vlf" with "F"
noexit(true)
noabort(true)
clear
local x; local cen; local doexpire
e.supd = true
use "vdata\\vsite"
here = vsite.whoami
zdate = #date

!input zdate using "rr/rr/rr" with "rr/rr/rr"

cen = "0"
if tonum (substr(zdate,7,2)) < 90 then cen = "1"; endif
cdate = cen + substr(zdate,7,2)+substr(zdate,1,2)+substr(zdate,4,2)
printid = vsite.printnum
if printid = 1 then perform "\\profiles\\vl\\vx\\plzipf.plz"; endif
if printid = 2 then perform "\\profiles\\vl\\vx\\pdmipf.pd2"; endif
if printid = 3 then perform "\\profiles\\vl\\vx\\pdmipf.pd3"; endif
if printid = 4 then perform "\\profiles\\vl\\vx\\pdmipf.pd4"; endif
doexpire = false
if substr(vsite.expdtest,7,2) < substr(zdate,7,2) then doexpire = true; endif
if substr(vsite.expdtest,7,2) = substr(zdate,7,2) then
if substr(vsite.expdtest,1,2) < substr(zdate,1,2) then doexpire = true; endif
if substr(vsite.expdtest,1,2) = substr(zdate,1,2) then
if substr(vsite.expdtest,4,2) < substr(zdate,4,2) then doexpire = true; endif
endif
endif
vsite.expdtest = zdate
finish vsite
#errno = 0
e.serr = true
use "vdata\\li" with "vtemp\\li"
e.serr = false
if #errno ne 0 then
finish li
use "vdata\\li"
?;?;?"INDEXING"
index "vtemp\\li" for li by az lnum
endif
if doexpire = true then
change lstatus to "E" for (lstatus = "A" or lstatus = "O") and expdate < cdate and substr(expdate,1,1) ne ""
endif
use "vdata\\fp.itb"
use "vdata\\fn.itb"
use "vdata\\ag.itb"
clistn = ""
cntr = 0
return

script 3:
local FORM VLTOPF
AT 1, 02 PUT "(c) 1994 BRCSLC PROFILE SYSTEM"
AT 1, 1 TO 1, 77 PUT "FGBU"
AT 1, 70 PUT "Ver 3.11"
ENDFORM
local m1xx
local FORM MENU1F
AT 3, 33 PUT "MAIN MENU"
AT 3, 31 TO 3, 43 PUT "FWBR"
AT 4, 16 TO 20, 59 PUT "FOBU"
AT 5, 20 PUT "1 NEW PROFILE NUMBER"
AT 7, 20 PUT "2 ENTER/MODIFY/CHANGE PROFILE"
AT 9, 20 PUT "3 PRINT/DISPLAY PROFILE"
AT 11, 20 PUT "4 PRINT/DISPLAY LISTS OF PROFILES"
AT 13, 20 PUT "5 PROFILE COMPARISON REPORT"
AT 15, 20 PUT "6 SOLD FUNCTIONS"
AT 17, 20 PUT "7 MORE SELECTIONS"
AT 19, 20 PUT "8 EXIT"
ENDFORM
m1xx=1
while m1xx =1 do
clear
putform vltopf; tally vltopf
putform menu1f
selmax = 8; sel = 0; perform getsel
clear menu1f
test sel
case 1: perform newlist; cntr =cntr + 1; break
case 2: perform editlist; break
case 3: perform prtlist; break
case 4: perform psmenu; cntr = cntr + 1; break
case 5: perform cmpmenu; cntr = cntr + 1; break
case 6: perform soldmenu; cntr = cntr + 1; break
case 7: perform moremenu; cntr = cntr + 1; break
case 8: m1xx = 0; break
endtest
perform takebrk
endwhile
return

as you can see this is a lot of code and i would not expect a command prompt to understand, as it's a scripting language using the program kman v1.0a.
I have checked the files for any read only or other file properties that might prevent it from opening
looking at this again i think the issue might be that the command prompt is trying to run the scripts rather then let the program do it's work.

With this new information, I don't think it is the DOSBox command interpreter that is at fault.

This IPF-file that KnowledgeMan(?) is trying to open - could that be some temporary file that is created with information to be passed between different Kman scripts?

Maybe Kman tries to create the IPF with a filename that DOSBox does not accept? (DOSBox does not allow for the same range of characters in filenames as real MS-DOS do).

Or it could be something else. Someone had a problem with an application trying to open a zero-length file. And he got a special made patch for it?? Wonder if I can find that thread....

Edit: Ahh - here it is:
Need to write a small file on drive "Z:\"
I wonder if the patch has been committed, and if there is a version of DOSBox somewhere that contains the patch?

Edit2: Nope 🙁 Kippesoeps patch has not made it into the DOSBox source code yet.

thanks for the suggestion I'll see if that works.

here is some more details about the kman program.
.ipf file is the actual application script kman runs
.itb is the database table file can be encrypted unencrypted or encrypted with password
.icf i think is another script file that is encrypted and related to tables
.ovl is an encrypted core program file i think
.inc is a program script for loading select .ovl files

i tried loading a table in kman and I got the same "can not load file" error but for the .icf file

in win2k or xp the program will start in the comand prompt shell but will only load the main menu. Any selection of a action will result in a FCB error.

(as i recall there was a rpg/adventure game at one time built in kman - that someone was trying to rewrite for access, I'll see if i can find information on it)

How are you mounting it in DosBox?

I'm mounting a directory that is a copy of the hard drive we run the program on: a win98 computer. I have used this directory to create another computer to run the program in the past.

basically I mount the directory as a c drive...

as follows - mount c c:\brcslc_backup

...but now that you mention it, the scripts might be confusing dosbox of where to look, the mounted c drive or the real c drive, and therefore can not find the application files. I will try placing them in the root c directory and trying again.

edit: tested configuration by mounting c:\ as c:\ - lovely message saying this is a bad idea and a repeat of the can not open c:.icf error

What was the pathname of the original directory your brcslc application was located in?

the original program runs three programs kman the database and script program, word perfect 5.1 and lotus 123.

the folders for all three programs are in the root directory c:\

the actual kman program and our application is in a sub folder of c:\

the three folders are

c:\profiles\vl
c:\123
c:\wp51

the folder i'm mounting dosbox to right now is is c:\brcslc_backup\ which contains all the folders as subdirectory

Good - in that case mounting the virtual C-drive in DOSBox
mount c c:\brcslc_backup
it is the correct way to do it, because that will generate the correct paths as seen inside DOSBox.

And none of the filenames / directories have more than the standard 8.3 characters that DOS supports?

Since we don't know the nature of the problem it is hard to give advice on what to do. If you are - or know someone who is - an experienced programmer, maybe the best option for you is to build your own version of DOSBox with extra logging around the file and disk operations? Logging that will tell you (and us) exactly which files the Kman application is trying to open, and how DOSBox responds to those requests.

that would be great but sadly, I don't program. I also don't know any programers.

Guess I'll just have to put this on hold until I can get a programer to work on it

You can try to run FileMon ( http://www.microsoft.com/technet/sysinternals … on/Filemon.mspx ) and have it filter on the file operations done by DOSBox. It might show which file it can not file. Maybe...

ok i ran processmon rather then filemon as it supposedly has more info in it. I'm attaching the files, hope you can make heads or tails of it.

all i got from the files was dosbox can't fine some files because it's looking for a file with only the extension .ipf and not the name. there are also many files that cause buffer overflows.

there was a couple of files the program looked for that were missing but they are not needed to run the application or the program, our legacy systems don't have these files either. such as kmouse.exe the kman mouse driver.

hope this helps, if needed I'll run the filemon - but i think the info would be the same.

The only clue is at sequence no. 155606-155616:

155606 7:36:32.8938037 PM dosbox.exe 2816 CreateFile C:\brcslc_backup\PROFILES\VL SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened

155607 7:36:32.8938998 PM dosbox.exe 2816 QueryDirectory C:\brcslc_backup\PROFILES\VL\.IPF NO SUCH FILE Filter: .IPF

155608 7:36:32.8939889 PM dosbox.exe 2816 CloseFile C:\brcslc_backup\PROFILES\VL SUCCESS

155610 7:36:32.8941370 PM dosbox.exe 2816 CreateFile C:\brcslc_backup\PROFILES\VL\.IPF NAME NOT FOUND Desired Access: Generic Read/Write, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a

155612 7:36:32.8943395 PM dosbox.exe 2816 CreateFile C:\brcslc_backup\PROFILES\VL SUCCESS Desired Access: Read Attributes, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened

155613 7:36:32.8944317 PM dosbox.exe 2816 QueryDirectory C:\brcslc_backup\PROFILES\VL\.IPF NO SUCH FILE Filter: .IPF

155614 7:36:32.8945147 PM dosbox.exe 2816 CloseFile C:\brcslc_backup\PROFILES\VL SUCCESS

155616 7:36:32.8947066 PM dosbox.exe 2816 CreateFile C:\brcslc_backup\PROFILES\VL\.IPF NAME NOT FOUND Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a

Seems like 607 is a search for a file named C:\brcslc_backup\PROFILES\VL\.IPF. The file does not exists, and it goes on to create on in 610, but gets a "NAME NOT FOUND" back??

Makes me wonder if the name really should be just .IPF and not SOMETHING.IPF, and that that "SOMETHING" is disappearing somewhere due to a problem in DOSBox.

Are wildcards needed in MS-DOS? Would a "dir .ipf" return all files with extension of .ipf? I seem to remember DOS being able to do this whereas the NT command prompt does not.

/EDIT Well I guess that theory is shot to hell since DosBox can do dir.exe or dir.ipf just fine....

dosfreak you might be on to something.

i think the error is related to dosbox backtracing to the c:\ prompt when the kman program uses \\ in the scripting (which kman uses for real directories vs a single \ for script comands)

so instead of opening a script located in directory c:\profiles\vl\vdata\
dosbox looks for the file at c:\

the script in kman would be load \\vdata\\
or something like that
just a thought....not sure how to test that theory

edit: never mind the process log doesn't justify that theroy. I looked at the scripts again and i don't see where the script makes calls for a .ipf or a dir.ipf there is a line that says something like \\profiles\\vl\\vx\\vlf\\ and i'm not sure what that line is looking for. but i don't think it is anything related to the file not found issue.

i'll see if i can run filemon or processmon on our win98 legacy system so we have a comparison of running the program in dos vs dosbox