%BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP
- johncookson
- Topic Author
- Visitor
14 years 8 months ago #4871
by johncookson
%BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP was created by johncookson
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
$
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
$
Please Log in or Create an account to join the conversation.
- Bruce Claremont
- Topic Author
- Visitor
14 years 8 months ago #4872
by Bruce Claremont
Replied by Bruce Claremont on topic RE: %BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP
What version of VMS are you using?
Please Log in or Create an account to join the conversation.
- VolkerHalle
- Topic Author
- Visitor
14 years 8 months ago #4873
by VolkerHalle
Replied by VolkerHalle on topic RE: %BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP
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.
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.
Please Log in or Create an account to join the conversation.
- johncookson
- Topic Author
- Visitor
14 years 8 months ago #4874
by johncookson
Replied by johncookson on topic RE: Working on the problem
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.<hr>
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.<hr>
Please Log in or Create an account to join the conversation.
- Bruce Claremont
- Topic Author
- Visitor
14 years 8 months ago #4875
by Bruce Claremont
Replied by Bruce Claremont on topic RE: %BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP
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.
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.
Please Log in or Create an account to join the conversation.
- johncookson
- Topic Author
- Visitor
14 years 8 months ago #4876
by johncookson
Replied by johncookson on topic RE: Telnet bugcheck
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
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
Please Log in or Create an account to join the conversation.
Moderators: iamcamiel
Time to create page: 0.192 seconds