From: mitton@dave.lkg.dec.com (Dave Mitton)
Subject: Re: Programming under Pathworks for DOS
Reply-To: mitton@dave.lkg.dec.com (Dave Mitton)
Organization: Digital Equipment Corporation, Littleton MA
Date: Wed, 23 Dec 1992 18:29:36 GMT


In article <1992Dec22.215942.1@kosmos.wcc.govt.nz>, gaspard_r@kosmos.wcc.govt.nz writes:
From: gaspard_r@kosmos.wcc.govt.nz
Newsgroups: vmsnet.networks.desktop.pathworks
Subject: Programming under Pathworks for DOS
Date: 22 Dec 92 21:59:42 NZST

>Programming under Pathworks for DOS ...
>
>   1.	Is it possible to perform asynchronous network receives and transmits
>	under Pathworks for DOS, over a task-to-task logical link?  
>	In other words, can a program initiate a network receive or transmit
>	operation, and continue processing before the operation has completed
>	and the data received by this end or the other end of the logical link?
>
>   2.	Is it possible to have concurrent receive and transmit operations in
>	progress at the same time, over the one task-to-task logical link?
>
>	For standard DOS I/O operations like disk file I/O, it is not possible
>	to have two concurrent I/O operations because DOS itself is not
>	reentrant.  But does this restriction apply to Pathworks?
>
>The answer to both the above questions under VMS is "YES" -- but what about
>under Pathworks for DOS?
>
>We want to implement a full-duplex task-to-task logical link between a 
>program running under Pathworks for DOS and a program running under VMS.
>Each program effectively has three threads of execution: (a) a network
>transmitting thread, (b) a network receiving thread, and (c) an internal
>data processing thread.  Under VMS alone we can use the asynchronous $QIO 
>system service (rather than the synchronous $QIOW) to perform the network
>receives and transmits, and event flags to indicate completion.  If we used 
>synchronous receive and transmit operations then the two programs could 
>deadlock if (for example) both chose to transmit at the same time.
>                                   
>What features does Pathworks for DOS provide to implement the same
>functionality?

	All of this is possible and is done in several PATHWORKs applications
(eg: FAL, DTR & DTR)

	I suggest that you obtain a copy of the DECnet-DOS Progammer's
Reference Manual (PRM).  Under PW V4.0 it is now a seperate orderable
item, as most PATHWORKs owners don't do programming.

	Two levels of interfacing are documented.
1) C sockets: this is a BSD 4.2 style interface for doing DECnet task-to-task.
Like sockets it's not fully asynchronous nor supports multiple threads, 
but you can do Non-Blocking.

2) Assembly control blocks (NIOCB): this is everything that DNP supports.
If you wish to stay in C, you could hack on the socket library code to
make it multithreaded.
	
	NIOCB's support "Asychronous" calls that are internally queued
and processed when possible.   You can poll your command block for completion
or specify a completion callback (just like NETBIOS).  Your callback
can set event flags to coordinate your threads.  It just better be quick
about it, as it is running as a subroutine of DECnet at the time.

	I used to teach a DECUS Seminar on DECnet-DOS programming
but it lost attendence over time and I don't do that anymore.

	Dave Mitton
	Mr. DECnet-DOS V1-V3
	Networks and Communications
(included) to make something easier to