[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference help::decnet-osi_for_vms

Title:	DECnet/OSI for OpenVMS

Moderator:	TUXEDO::FONSECA

Created:	Thu Feb 21 1991
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3990
Total number of notes:	19027

3974.0. "DECnet phase IV to DECnet-Plus migration white-paper?" by RDGENG::WOOD_J ([email protected]) Tue May 27 1997 08:22

Does a technical note exist which explains the issues in migrating
an application from using DECnet phase-IV to using DECnet-Plus?

Specifically I have been asked by a software partner if their
application, which uses non-transparent DECnet task-to-task and
$QIO calls on OpenVMS VAX v5.5-2 to v7.0, should simply recompile
and run on OpenVMS Alpha v7.1 with DECnet Plus.

Thier application has client & server components. Should the 
OpenVMS Alpha v7.1 versions of their clients & servers be able to 
communicate with OpenVMS VAX DECnet Phase IV clients and servers,
and OpenVMS VAX DECnet-Plus clients 7 servers?


Re. their first question - I'm asking only about the network API
(-I can advise them about generic VAX & Alpha differences). My guess
is that the answer is Yes, although I note in the DECnet-Plus 
programming guide the recommendation to use $IPC rather than $QIO.

For the second question, again I guess the answer is Yes.


Thanks,
  John Wood
  Software Partner Engineering

T.R	Title	User	Personal Name	Date	Lines
3974.1		RMULAC::S_WATTUM	Scott Wattum - FTAM/VT/OSAK Engineering	`Tue May 27 1997 09:51`	6
	Unless the application used undocumented and unsupported QIO calls into DECnet (such as some of the special NETACP functions) the goal of DECnet-Plus was to provide a fully backward compatible interface. So in general, the answer would be yes, all they should need to do is re-compile and run. --Scott
3974.2		BACHUS::KNEUTS	Erwin Kneuts DTN 856-8726	`Tue May 27 1997 12:20`	7
	Previous entry (3973 hanging NSP ports in OSI 7.0) is an illustration of the fact that migration from phase IV to Decnet + is not as smooth as we would like. It is exactly what we did, recompiling an application using $QIO interface under 5.5-2 and decnet IV to 7.0 and decnet+. Still looking for some answers there, so any suggestions are welcome. Erwin
3974.3	Why did you recompile?	TWICK::PETTENGILL	mulp	`Thu May 29 1997 00:19`	20
	The applications should run as is. The compatibility is at the binary level. What has seemed to be a problem is that certain fields in the NCB that should have been null were filled in with something that DECnet-OSI considered garbage, but that DECnet-Classic ignored. If you look thru this conference you will find reports of such problems and it seems to me that all were reported as fixed in a future release. If you're having problems, its probably necessary to find the offending service call and make it conform to the documented interface. Another source of problems might be making a $QIO call and then not $WAITing for it to complete. Somethings that were simple and could be handled synchronously became complex and so they were really asynchronous and you really have to wait for them to complete before using the results. Again, it comes down to implementing to the documented service call. The reason to use the $IPC interface is that it offers more options and it was designed to be more efficient for the network services then QIO.
3974.4	And In One QIO case an IOSB is Mandatory, else System Crash.	EICSMS::CELLAM		`Mon Jun 02 1997 05:01`	9
	On the case of QIO's we have found a case where the Iosb field is no longer optional, you have to give a valid address, if not then the system crashes. I can't remember where DECosap engineering said this happened, it was definitely in OSI Transport and I thing it was when breaking a connection. This problem only started occuring with DECnet Plus 7.0 and is still there in 7.1. I'm not sure why the DECosap engineers didn't inform the DECnet Plus engineers. Chris