| Author |
%BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP |
johncookson
Member
Posts: 26
Location: Canada
Joined: 04.12.08 |
| Posted on May 06 2010 02:27 |
|
|
I have just completed my first install of FreeAXP (Beta 271) on a new Core i3 laptop. The laptop is running Win 7 Home premium 64 bit. This is the first emulator installation I have performed on this machine.
Up until now, I have been using PersonalAlpha from Stromasys and have installed PersonalAlpha on several Windows computers under XP, Vista 32 and Win7 32 bit versions.
Not wishing to perform a fresh OpenVMS installation and configuration from scratch for my FreeAXP evaluation, I had used a copy of my existing PersonalAlpha 4gb disk container file (dka0.vdisk). The FreeAXP installation was problem free and I was subsequently able to boot OpenVMS using this container file. I was able to login using the console and used TCPIP$CONFIG.COM to recognise EWA0 as the NIC device which allowed me to telnet into the system from another Windows computer on my home network. So far so good.....
Everything looked normal to me until I ran an application for the first time. This application is just a menu program written in HP Basic and uses a couple of indexed RMS files. Under OpenVMS using PersonalAlpha, the application launches normally, just as it does on a real VAX, ALPHA or I64 box. However, using FreeAXP the application fails and displays an I/O channel open failure error message sequence which I have pasted below.
Any comments on what might cause this error would be appreciated. It appears there may be some other configuration changes needed when using a PersonalAlpha container file under FreeAXP.
$ RUN DKA0:[JCSPROGS]MAMENU
%BAS-F-IO_CHANOT, I/O channel not open
-BAS-I-ON_CHAFIL, on channel 51 for file at user PC 00000000
-BAS-I-FROGSBMOD, In GOSUB in module MAMENU
-BAS-I-FROMOD, In module MAMENU
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
LIBRTL 0 0000000000071E5C FFFFFFFF8089FE5C
DEC$BASRTL 0 00000000000105DC 000000007C16A5DC
----- above condition handler called with exception 001A804C:
%BAS-F-IO_CHANOT, I/O channel not open
-BAS-I-ON_CHAFIL, on channel 51 for file at user PC 00000000
----- end of exception message
0 FFFFFFFF800A70CC FFFFFFFF800A70CC
DEC$BASRTL 0 0000000000073964 000000007C1CD964
DEC$BASRTL 0 000000000007422C 000000007C1CE22C
MAMENU MAMENU$MAIN MAMENU$MAIN 1921 00000000000113C8 00000000000313C8
0 FFFFFFFF80375CE4 FFFFFFFF80375CE4
%TRACE-I-END, end of TRACE stack dump
$ |
|
|
| Author |
RE: %BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
| Posted on May 06 2010 03:36 |
|
|
|
What version of VMS are you using? |
|
|
| Author |
RE: %BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP |
VolkerHalle
Member
Posts: 104
Location: Germany
Joined: 02.04.10 |
| Posted on May 06 2010 04:48 |
|
|
John,
the meaning of the %BAS-F-IO_CHANOT error message is pretty straightforward:
The program attempted to perform an I/O operation before OPENing the channel. OPEN the channel before attempting an I/O operation to it.
Please consider to run your program with the debugger and make sure, that you've actually and successfully opened the channel. There may be ''environmental' conditions (missing logical name or logical name pointing to the wrong device name), that may prevent the OPEN from succeeding and not return an error message.
Please note that the BAS-I-ON_CHAFIL message does NOT report a file name. This may be another indication, that the OPEN really did not happen or did not work.
If you believe, the OPEN fails due to a possible problem in the FreeAXP emulator, please consider to provide a small reproducer, so that further troubleshooting outside the context of your application becomes easier.
Volker. |
 |
| Author |
RE: Working on the problem |
johncookson
Member
Posts: 26
Location: Canada
Joined: 04.12.08 |
| Posted on May 06 2010 08:46 |
|
|
Bruce - Just to confirm that I am using OpenVMS version 8.3
Volker - Thanks for the comments and suggestions. I certainly intend to get around to your suggestions.
before returning to this forum, I had checked out a few things which are of interest in chasing down this issue. These strategies had no impact on resolving the I/O problem. However, here is what I have done so far :-
I performed a second installation of FreeAXP Beta 271 on another laptop that I own. This laptop is a Samsung model using an Intel Core i5 cpu and running Win 7 32 bit (The laptop I used previously was an MSI brand using an Intel Core i3 cpu running Win 7 64 bit). Another difference is that the second installation was performed on a computer which already has the PersonalAlpha emulator installed on it. I did not uninstall PersonalAlpha from this second laptop and neither did I make any configuration changes or adjustments related to the PersonalAlpha installation (and such changes may be needed to ensure proper operation of FreeAXP). Once again, I used a copy of the existing PersonalAlpha container file to boot OpenVMS with FreeAXP on the laptop. In this case, I did not immediately make the NIC name change and ran my application using the boot console window. The application crashed reporting the I/O error in exactly the same way as happened on the first (Samsung) laptop. I then made the NIC change to match the adaptor name needed by FreeAXP. Strangely enough, having made the NIC related change, my attempts to Telnet into the laptop running FreeAXP resulted in an OpenVMS bugcheck crash of the Operating system followed by an automatic OpenVMS reboot sequence. Currently I am not worried about this "remote telnet attempt" related OpenVMS crash as this does not happen with my first installation where I don't have a resident PersonalAlpha installation and may simply be a result of my not having made needed configuration related changes required to run FreeAXP on the same machine where I already have PersonalAlpha installed. I should however mention that after shutting down the FreeAXP emulator, I am able to subsequently boot and login to OpenVMS with personalAlpha (using the original unmodified container file of course).
I will repost after further investigations centred around the application crashing incident.
Edited by johncookson on May 06 2010 09:15 |
|
|
| Author |
RE: %BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
| Posted on May 07 2010 03:38 |
|
|
If you see the Telnet/bugcheck issue again, we would like to see the crash dump generated by the problem.
There are no issues we are aware of having FreeAXP and PersonalAlpha co-exist on the same system. As you are already aware, the only configuration change required is to accommodate the difference in network devices.
I assume you are using the same disk device names (DKA0, DKA100, etc.) in both configurations, so we should be able to eliminate a device difference as a possible issue.
If you can share the code, we will test it here. |
|
|
| Author |
RE: Telnet bugcheck |
johncookson
Member
Posts: 26
Location: Canada
Joined: 04.12.08 |
| Posted on May 07 2010 08:16 |
|
|
Hello Bruce
The Telnet/bugcheck issue is 100% reproduceable on the Samsung Laptop that I own. I do not experience this problem accessing the other MSI Laptop on which FreeAXP is installed. I am using the same desktop computer and telnet client (with no setting or IP address changes) to connect with each of the laptops (Not at the same time of course). I'm guessing this problem could be related to the laptop NIC or its driver.
Yes, I should be able send you the crash dump. My wife has this laptop with her at the moment but I should be able to get around to this early next week when she returns home.
I am indeed using the device names DKA0 and DKA100. These are the same in all the configurations I use, including for PersonalAlpha.
There is no application related code involved in the Telnet/bugcheck issue as the problem occurs when I am simply attempting to login to OpenVMS from a Windows desktop PC on the same wired network. My Telnet client is called Anziowin.
Did you receive my earlier private email message regarding the I/O error problem ?
Unfortunately I use "Microsoft Hotmail" which can be inconsistently quirky under Firefox. I noticed the message I had sent to you was also sitting in the Hotmail "Drafts" folder. On occasions when this has happened before following sending an outgoing message, I have found that the message did actually reach the intended recipient whilst also finding its way into the drafts folder. Just wanted to confirm what happened on this occasion.
JohnC |
|
|
| Author |
RE: I/O channel error - File Open operation |
johncookson
Member
Posts: 26
Location: Canada
Joined: 04.12.08 |
| Posted on May 07 2010 13:00 |
|
|
Hi Volker
This is to confirm that I have already validated what happens when I rename the file to prevent my application from being able to open it.
The application displays an error message indicating that the open attempt had failed and then exits in an orderly fashion. This is of course how it is designed to work.
I will attempt to perform a SET PROC/DUMP analysis in the hope I can make some sense of the end result and let you know what I find when I get a chance. |
|
|
| Author |
RE: Process Dump Analysis |
johncookson
Member
Posts: 26
Location: Canada
Joined: 04.12.08 |
| Posted on May 07 2010 13:47 |
|
|
Volker
Here is the result of the post crash dump analysis.
$ ANALYZE/PROCESS_DUMP MAMENU.DMP
OpenVMS Alpha Debug64 Version V8.3-009
%DEBUG-W-IMAGENF, target image MAMENU not found on host system
%BAS-F-IO_CHANOT, I/O channel not open
-BAS-I-ON_CHAFIL, on channel 51 for file È[
-BAS-I-FROGSBMOD, In GOSUB in module
-BAS-I-FROMOD, In module
break on unhandled exception preceding SHARE$LIBRTL_CODE0+466524
DBG>
This doesn't tell us anything we didn't already know
beyond adding further confirmation that the data file upon
which the FIELD operation was subsequently performed
did not open successfully. This stands in sharp contrast to the
fact that my application indicates file open success by
passing the error trap which surrounds the relevant open
statement. In addition, there exists no justification for an
open failure to occur given that the subject data file is
both present and correctly positioned for a positive outcome.
Something strange is afoot here..... |
|
|
| Author |
RE: %BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
| Posted on May 07 2010 14:51 |
|
|
|
John: Private message received and responded to. |
|
|
| Author |
RE: re: TELNET bugcheck |
VolkerHalle
Member
Posts: 104
Location: Germany
Joined: 02.04.10 |
| Posted on May 07 2010 21:03 |
|
|
John,
please consider to look for CLUE files from those bugchecks. They should be found in CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS.
$ TYPE CLUE$HISTORY will also show the crash history, one line per crash. I would assume, that all those crashes show the same footprint (i.e. bugcheck name, module and offset). If so, please send me a copy of one of those CLUE files, before trying to provide the dumpfile itself (you'll find my mail address in my profile).
I do have a database of OpenVMS crash footprints and some experience of interpreting CLUE files, so I might be able to tell you, what's causing these problems or what the next step for analysis should be.
Volker. |
|
|
| Author |
RE: %BAS-F-IO_CHANOT |
VolkerHalle
Member
Posts: 104
Location: Germany
Joined: 02.04.10 |
| Posted on May 07 2010 21:27 |
|
|
John,
thanks for creating a process dump. This dumpfile can now be further analzyed with the debugger or SDA. It shows the static situation at the time of the program crash. And it can be easily distributed for expert analysis. Depending on the actual source code and where certain variables or status information is stored, further checks could be done. But this requires the source code and maybe even the /MACHINE_CODE listing...
You can now look at the process dump with SDA as well and look at the open channels:
$ ANAL/CRASH MAMENU.DMP
SDA> SHOW PROC/CHAN
This should show all open channels and files. Is that application file shown ? If not, then you can be sure, that the file is NOT opened !
As a next step, try $ SET WATCH FILE/CLASS=MAJOR (needs CMKRNL privilege) and then run your program. This traces XQP IOs (file system), so an OPEN statement in your program should produce some trace output. Does it ? Turn off XQP tracing with SET WATCH FILE/CLASS=NOMAJOR.
The most effective way to debug this problem is by using the debugger. Compile with /DEB/NOOPT and link with /DEBUG, then run your program. On the DBG> prompt, first just type GO and see, if the problem still exists.
Then start another debug session and set a breakpoint BEFORE the code, which is supposed to OPEN the file. Step through the code, consider to use DBG> SET BREAK/EXCEPTION, so that any exception will automatically enter the debugger and allow you to examine the context.
The most important step would be to confirm, that the file has successfully been opened. Once you've stepped past the OPEN statement, you can check with SHOW DEV/FILES or SDA, whether the file is actually open. It may be open, but the channel number may have been corrupted, causing further access to that file from your program to fail. Many things are possible and it is important to systematically find and diagnose them.
Could you also please provide some excerpt from the code, which opens the file and the code, which incurs the problem ?
Volker. |
|
|
| Author |
RE: %BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
| Posted on May 21 2010 05:49 |
|
|
|
We've tracked this to what appears to be a floating point conversion or arithmetic bug in the emulator. We are working on it. Thanks to John for providing the code and data needed to track down the problem. |
|
|
| Author |
RE: %BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
| Posted on June 03 2010 13:27 |
|
|
We have just posted FreeAXP 283. It corrects the floating point bug discovered in this thread. Visit the FreeAXP page for download, documentation, and forum links:
www.FreeAXP.com |
|
|
