|
Post by ghost128k on Mar 10, 2019 8:57:34 GMT 1
Hello I'm try to run a rmcobol app with a network share folder to store the files, but when the rmcobol app try to create a file, show a 30,01 error. it's means that can't create a file vdos run at w10 64 bits environment. it's anyway to solve the problem? Many thanks in advance.
|
|
|
Post by Jos on Mar 10, 2019 9:11:34 GMT 1
Most likely it’s caused by an invalid path, or insufficient access rights to create that file. Run vDos with the /log option (“…vDos.exe”/log), and look for a “CreateFile failed:” entry in the generated vDos.log file.
Jos
|
|
|
Post by juanmaria on Mar 11, 2019 9:13:56 GMT 1
I've got the same problem but, as I see it, the error is 30.@1 30 is a system error and @1 is the actual error reported by the underling system so it would be interesting knowing if @1 is some actual VDOS error code. Anyway, I'm gonna try the log option and will come back here with the results. Thank you.
|
|
|
Post by juanmaria on Mar 11, 2019 9:49:34 GMT 1
I've just run a few test, as I wrote before the actual error was 30.@1, that's the program output: "Se ha producido un ERROR código 30,@1 en archivo <CONTA.03> "
This is what I found on the log file:
43.72 Int 2F unhandled call B700 OpenFile failed: FIC\CT6\FIC999\CONTA.03(2) => \\OLINET-SERVER17\DiscoH\FIC\CT6\FIC999\CONTA.03 Int 2F unhandled call B700 OpenFile failed: COBOL\CT6\OBJ\H:\FIC\CT6\FIC999\CONTA.03(161) => \\OLINET-SERVER17\DiscoG\COBOL\CT6\OBJ\H:\FIC\CT6\FIC999\CONTA.03 Int 2F unhandled call B700 OpenFile failed: COBOL\CT6\OBJ\H:\FIC\CT6\FIC999\CONTA.03(161) => \\OLINET-SERVER17\DiscoG\COBOL\CT6\OBJ\H:\FIC\CT6\FIC999\CONTA.03 Int 2F unhandled call B700 44.86 Idle
This is my autoexec.txt mapping: USE F: \\OLINET-SERVER17\DiscoF\ USE G: \\OLINET-SERVER17\DiscoG\ USE H: \\OLINET-SERVER17\DiscoH\
This mapping: FIC\CT6\FIC999\CONTA.03(2) => \\OLINET-SERVER17\DiscoH\FIC\CT6\FIC999\CONTA.03 is correct, the path \\OLINET-SERVER17\DiscoH\FIC\CT6\FIC999\ does exist but the program fails when trying to create the new file CONTA.03
When files are already created it reads them with no problem.
Also, I've got a lot of "Int 2F unhandled call B700" in my log file.
I'll try to run a few more tests, any help would be welcomed.
Thank you.
|
|
|
Post by Jos on Mar 11, 2019 10:23:05 GMT 1
vDos mimics the DOS error codes. 01 - Invalid function number - is pretty vague. It could mean the program calls some DOS API function with an invalid or unsupported (by DOS 5.0) subfunction. But also the (sub)function not implemented in vDos. Mostly this condition isn’t logged since the program is considered to deal with that. Often it is then just probing DOS for functionality/extensions.
“Int 2F unhandled call B700” - APPEND - INSTALLATION CHECK - is logged. Normally an one-time-only call should be sufficient for a program to know some functionality isn’t present. APPEND won’t be installed out off the blue between multiple calls. APPEND is a rather obscure program, no idea what it could do for an end-user program, certainly not why the program would need to communicate with the resident (transparent functioning) APPEND program. Perhaps to ensure it isn’t fooled by APPEND?
OpenFile failed: FIC\CT6\FIC999\CONTA.03(2) just means CONTA.03 isn’t found. The two other OpenFile failed entries have “…H:..” in their paths. “:” can only the second character, after a drive letter, in all other situations it’s invalid. If CONTA.03 isn’t found, it should be created? There’s however no CreateFile failed entry, though the file creation could have failed due to a ‘normal’ DOS error.
Jos
|
|
|
Post by juanmaria on Mar 11, 2019 16:39:17 GMT 1
Hi again, now I know what the problem is, I misregarded it as an error when creating a new file but it's a mishandling of a file-not-found by RM-Cobol, before creating a new file Rm-Cobol looks for the file and that's the moment when the error raises.
I've got the same problem, simply, trying to open a non-existing file.
RM-Cobol should react to an attempt of opening an non-existing file with a code "35" that most programs capture and, then, create the new file. Under vDos it raises a system error (30) that most programs interpret as a fatal error and, such, as an abort condition.
From the log it seems like it tries a first time with the correct mapping: "failed: FIC\CT6\FIC999\CONTA.01(2) => \\OLINET-SERVER17\DiscoH\FIC\CT6\FIC999\CONTA.01" and two more times with an incorrect mapping: COBOL\CT6\OBJ\H:\FIC\CT6\FIC999\CONTA.01(161) => \\OLINET-SERVER17\DiscoG\COBOL\CT6\OBJ\H:\FIC\CT6\FIC999\CONTA.01" but this is as a result of a single COBOL instruction: OPEN INPUT CONTA
I don't know with method uses RM-Cobol to deal with file openings but it seems that it's not compatible with this environment.
Thank you.
|
|
|
Post by juanmaria on Mar 11, 2019 17:05:47 GMT 1
I forgot pasting the whole log sequence:
158.63 Int 2F unhandled call B700 OpenFile failed: FIC\CT6\FIC999\CONTA.02(2) => \\OLINET-SERVER17\DiscoH\FIC\CT6\FIC999\CONTA.02 Int 2F unhandled call B700 OpenFile failed: COBOL\CT6\OBJ\H:\FIC\CT6\FIC999\CONTA.02(161) => \\OLINET-SERVER17\DiscoG\COBOL\CT6\OBJ\H:\FIC\CT6\FIC999\CONTA.02 Int 2F unhandled call B700 OpenFile failed: COBOL\CT6\OBJ\H:\FIC\CT6\FIC999\CONTA.02(161) => \\OLINET-SERVER17\DiscoG\COBOL\CT6\OBJ\H:\FIC\CT6\FIC999\CONTA.02 Int 2F unhandled call B700 159.76 Idle
|
|
|
Post by Jos on Mar 11, 2019 20:26:44 GMT 1
Problem is that vDos gets Windows error codes, translates them to DOS errors, while RM-Cobol translates the latter to its own Cobol-like error codes.
Most Windows error codes related to file operations, are identical to the DOS error codes. Some differ, and some don’t have a corresponding DOS error code. Windows returns error code 161 (ERROR_BAD_PATHNAME) for the invalid paths (…H:…), no such error code defined in DOS. RM-Cobol will be ‘confused’ by that non-existing error code, parachuting to 30 (Permanent error - no other information is available). I tested what DOS error code NTVDM returns in such situation. That’s 03 (Path not found), so I’ll also let vDos return that.
Though still puzzling where that "COBOL\CT6\OBJ\H:\" comes from.
Jos
|
|
|
Post by juanmaria on Mar 12, 2019 8:13:47 GMT 1
>Though still puzzling where that "COBOL\CT6\OBJ\H:\" comes from.
Sure, I've thought that, maybe, when RM-Cobol doesn't find a file in the appropriate path, before giving up, it tries finding it appending its path to the program's path that is "COBOL\CT6\OBJ\", it would also explain the call to int 2f APPEND function.
Thank you. Juan María.
|
|
|
Post by juanmaria on Mar 13, 2019 10:02:41 GMT 1
Hi again,
I've just tested version 2016.06.01 and with this version RM-Cobol behaves properly when trying to open a non existent file, it also can create new files.
Thank you. Juan María.
|
|