KXH105@PSUVM.BITNET ("Ken Hornstein 862-7007", 814) (09/10/90)
Sorry about that ... was looking in the wrong place. Turns out that NETSTAT was causing the problem, not IUCV. Please forgive me. --- If I had my life to live over again, I'd make the same mistakes sooner. Ken Hornstein kxh105@psuvm.psu.edu Phone: 814/862-7007
OPRJ38@TREARN.BITNET (OR) (09/10/90)
HI KEN,
MY VMCF PROGRAM MAY NOT RUN UNDER YOUR SYSTEM. BECAUSE
OUR SYSTEM IS VM/SP HPO REL 5, AND YOUR IS VM/XA REL 21.
WELL, THIS IS A NORMAL RESULT..
-OR-peter@dbaccess.com (Peter A. Castro) (09/11/90)
in article <9009090912.AA17846@ucbvax.Berkeley.EDU>, KXH105@PSUVM.BITNET ("Ken Hornstein 862-7007", 814) says: > > Is it possible to have both an IUCV routine and a VMCF routine active at the > same time? My VMCF interrupt handler works fine, but when the IUCV handler > tries to do anything, evil things happen. Is there something special I should > do in my VMCF routine to allow for IUCV interrupts, or am I wasting my time? As I recall, IUCV is the improved version of VMCF, where VMCF has all the SVC functions for Inter-Machine communication, but needs direct coding by the programmer. IUCV, on the other hand, has support for Cross- Machine support, being able to send/receive messages between connected machines. I also remember that both use the same Virtual Machine message operations and tend to conflict with each other, because each requires different interrupt parameters which the Virtual Machine uses to invoke the interrupt routine. I might suggest that you switch to IUCV, being it is more used by 370 applications for message communication, and in addition, can receive/send messages to other machines. > > --- > If at first you don't succeed - so much for skydiving. > > Ken Hornstein kxh105@psuvm.psu.edu Phone: 814/862-7007 -- Peter A. Castro INTERNET: peter@dbaccess.com // //| c/o DB/Access Inc. UUCP: {uunet,mips}!troi!peter // //|| 2900 Gordon Avenue, Suite 101 FAX: (408) 735-0328 \\ // //-||- Santa Clara, CA 95051 TEL: (408) 735-7545 \// // ||
eric@sunic.sunet.se (Eric Thomas SUNET) (09/16/90)
I don't really know why I bother, but anyway: In article <118@tardis.dbaccess.com> peter@dbaccess.com (Peter A. Castro) writes: > As I recall, IUCV is the improved version of VMCF, where VMCF has > all the SVC functions for Inter-Machine communication, but needs direct > coding by the programmer. IUCV, on the other hand, has support for Cross- > Machine support, being able to send/receive messages between connected > machines. I also remember that both use the same Virtual Machine message > operations and tend to conflict with each other, because each requires > different interrupt parameters which the Virtual Machine uses to invoke > the interrupt routine. I might suggest that you switch to IUCV, being it > is more used by 370 applications for message communication, and in > addition, can receive/send messages to other machines. IUCV is not a superset of VMCF, in particular it does not allow communication between 2 arbitrary virtual machines without directory authorization. Neither VMCF nor IUCV uses SVC, although you may of course build a VMCF or IUCV library which the application programs would invoke via some SVC. Being an uneducated nerd I have no idea what "indirect coding" is so I cannot comment on that. IUCV support for cross-machine communication comes with PVM release 4 and is not documented. I guess IBM wants you to use APPC/VM and TSAF for that purpose, or of course SNA. My lack of education shows again in my inability to understand the meaning of "Virtual Machine message operation", and I'm afraid I am yet to see a virtual machine setting up parameters to invoke their interrupt routines. Anyway the original poster's problem is that both IUCV and VMCF generate external interrupts which, obviously, have to be trapped in some way by the application program. You can do that with HNDIUCV or HNDEXT, or you can do PSW stealing, and you may or may not code your routine to pass unrecognized external interrupts back to the routine that was in the external new PSW before you altered it. Code that is written properly often dies or ignores unexpected interrupts, which would explain the problem. There is nothing preventing the use of both VMCF and IUCV in the same virtual machine. Eric
eric@sunic.UUCP (Eric Thomas SUNET) (09/16/90)
I don't really know why I bother, but anyway: In article <118@tardis.dbaccess.com> peter@dbaccess.com (Peter A. Castro) writes: > As I recall, IUCV is the improved version of VMCF, where VMCF has > all the SVC functions for Inter-Machine communication, but needs direct > coding by the programmer. IUCV, on the other hand, has support for Cross- > Machine support, being able to send/receive messages between connected > machines. I also remember that both use the same Virtual Machine message > operations and tend to conflict with each other, because each requires > different interrupt parameters which the Virtual Machine uses to invoke > the interrupt routine. I might suggest that you switch to IUCV, being it > is more used by 370 applications for message communication, and in > addition, can receive/send messages to other machines. IUCV is not a superset of VMCF, in particular it does not allow communication between 2 arbitrary virtual machines without directory authorization. Neither VMCF nor IUCV uses SVC, although you may of course build a VMCF or IUCV library which the application programs would invoke via some SVC. Being an uneducated nerd I have no idea what "indirect coding" is so I cannot comment on that. IUCV support for cross-machine communication comes with PVM release 4 and is not documented. I guess IBM wants you to use APPC/VM and TSAF for that purpose, or of course SNA. My lack of education shows again in my inability to understand the meaning of "Virtual Machine message operation", and I'm afraid I am yet to see a virtual machine setting up parameters to invoke their interrupt routines. Anyway the original poster's problem is that both IUCV and VMCF generate external interrupts which, obviously, have to be trapped in some way by the application program. You can do that with HNDIUCV or HNDEXT, or you can do PSW stealing, and you may or may not code your routine to pass unrecognized external interrupts back to the routine that was in the external new PSW before you altered it. Code that is written properly often dies or ignores unexpected interrupts, which would explain the problem. There is nothing preventing the use of both VMCF and IUCV in the same virtual machine. Eric