[HECnet] DECnet/E programming manual / examples

There is also some information in the RSTS/E programming manual (http://www.bitsavers.org/pdf/dec/pdp11/rsts/V09/6_System_Programming/AA-EZ0…) about setting up message handling (generic local and also decnet/e) but as Paul has said, it is very low level and as far away from a transparent task= type setup as is possible to be. Keith From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Wilm Boerhout Sent: 16 December 2021 15:46 To: hecnet at Update.UU.SE Subject: RE: [HECnet] DECnet/E programming manual / examples Thanks Paul! I let you know if and when it works. Wilm From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of Paul Koning Sent: Thursday, December 16, 2021 4:43 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet/E programming manual / examples On Dec 16, 2021, at 8:03 AM, Wilm Boerhout <wboerhout at gmail.com<mailto:wboerhout at gmail.com>> wrote: Hi folks, I need to port a simple DECnet task-to-task program to RSTS/E V10.1, DECnet/E V4.1 Do any of you PDP-11 buffs have a DECnet/E programming manual. I know bitsavers doesn't. A small example in Fortran, Basic, Basic-Plus will also do. The functionality, expressed in VMS DCL, is as follows: $ open /read /write NETCHN REMOTE::?150=? $ write NETCHN ???f$trnlnm(SYS$NODE)?? $ read NETCHN time $ close NETCHN Thanks, Wilm The simplest way would be to use the "high level interface" library (DNEHLL), which is callable from BP2 and Fortran. There's also a simpler interface called the "concise Cobol interface" which I suspect is useable from other languages too. They are documented in the manual, but that brings us back to the previous question... :-( I looked through my sources for sample code that uses these, have not found any really short examples. The attached Fortran program uses the library, it offers access to each of the functions interactively. The thing to remember with RSTS is that, unlike most or all of the others, its DECnet data service is a segment service rather than a message service. In other words, the OS makes the application worry about breaking application messages into NSP segments, and the beginning-of-message and end-of-message flags are supplied by the application. It's possible to do bad things that won't bother other RSTS network programs but confused other operating systems, for example by sending messages without ever setting EOM. I've also seen some buggy programs that send the first segment without BOM, which probably won't break stuff but certainly is not correct. When dealing with short messages as in your example, you'd just set BOM and EOM both, and expect EOM in the incoming message. paul