Conference bulova::decw_jan-89_to_nov-90

    If you actually want to run DECwindows applications, the answer is
    no - you need a VAXstation (or a DECstation).  If you simply want to
    do some programming, and run the programs later on a workstation,
    then there's no problem.
    
    Perhaps your MicroVAX can be upgraded to a VAXstation.
    
    			Steve

...a VCB01 option and appropriate monitor, cable, bulkhead, and mouse, you
most certainly could load the DECwindows software and run. If you wish to run
DECwindows applications on another machine (displaying on your home node over 
the 2400 baud phone line), you will also need to set up a dynamic async decnet 
link on your system and that means talking  to network security for 
authorization. Sounds like you just need a bit more stuff...

							jr

    
    
    Sorry. My mistake, the processor is a VaxstationII  NOT a uVAX as
    was previously mentioned in 0. Please excuse the confusion .
    
    The big question now is how do I get the VAXstation to work using 
    the modem ? (the VAXstation has a mouse piece, 19'' screen monitor
    etc... )     Also PLEASE tell me EXACTLY how to make work.
    
    Thank you again
    
    Bob
            
    PS: (Once again, I apologized for the my mistake uVAXII Vs.
    VAXstation 2000.

Here is what I remember about getting async DECnet working.  BTW, you are
*NOT* going to like the performance when displaying a work-based DW app.
on your home ws at 2400 baud.  However, it is better than trying to debug
graphics with no graphics device.

You might discover that you would rather do the development right on the
workstation and then just copy the source files back and forth over DECnet.

Burns
=============================================

From:	DECWIN::FISHER       "VMS DECwindows Engineering, 381-1466"    7-JUN-1989 22:32:59.79
To:	xxxxxx
CC:	FISHER
Subj:	The magic of DECnet in your home...

First, you need to say to NCP:

DEFINE NODE <worknode> TRANSMIT PASSWORD <choose a password>

<Worknode> must be a router.  The password must match what your receive
password is set for in <worknode>'s data base.

Then in SYSTARTUP:

$set term tnnn/perm/speed=nnn/hangup/eightbit/modem !Eightbit is crucial
$ins == "$install/command"
$ins
create sys$library:dynswitch/prot/share/open/header !Prob. does not need open & header
$mc sysgen
connect noa0/noadapt


I think that is everything, though there may be another thing or 2 in ncp.
To get it started, say SET HOST/DTE Tnnn.  Do the regular thing with the
modem (just as if it were connected to a VT100) to get into
<worknode> directly (not through a LAT).  When you are on <worknode>, say
$SET TERM/SWITCH=DECNET/PROTOCOL=DDCMP (no privs are required)

You get back to the local DCL prompt, but you notice the modem has not hung
up.  It sometimes takes 20 or 30 seconds of talking back and forth, but eventually,
SHOW NET will show you that <worknode> is your router and SHOW KNOWN LINES
to NCP will show TX-0-0 (or whatever) as being up.

Burns

    Thanks Burns, I'll give a shot sometimes this week and let you know
    the results.
    
    Appreciated your help/support.
    
    Cheers,
    
    		Bob
    
    

If the machine that you're dialing into is on EasyNet, there are special
considerations for running DECnet over the line.  Contact your local site
EasyNet management for details on the policies involved.

--PSW

You also have to make special arangement to get a dedicated telephone line 
which connects directly to a backplane interconnected port. LAT lines will
not function (well) for async DECnet ports. You can make it work, but the 
probability of getting a spontaneous disconnect is greatly increased. The LAT
box has a set of timers that can beat against the timers DECnet is using and 
as a result, you can get into a situation where DECnet thinks the  link has 
timed out because LAT is off trying to deliver a packet over a busy ethernet.

James

    Thank you all for all your ideas/suggestions. the requested task
    seems to be an almost impossible/impractical{dream to pursue  any 
    further ???
    
    Several of our customers are looking forward to the possibilty of doing 
    that sort of task. Is there any plan(s) to remove that limitation in the
    near future ? 
    
    Well... Once again, a  BIG thank you  to all for your support.
    
    Ciao,
    
    		Bob
                                    

Which limitation were you referring to? Several were cited in various replies.

The performance issue is simply one of the bandwidth of the dial-up lines and
the volume of data required by the protocols. More efficient applications 
could improve things there (i.e. applications designed to pass less 
information across the connection by any of various design approaches - 
primary among which is to have specific application components running at
either end, rather than just using the local system as a phosphor server),
though at 2400 baud the best of these would look pretty sick, I believe.
Better lines and modems (9600 baud) should help there - I haven't tried
DECwindows across 9600 baud specifically, though.

There is another issue which you should be aware of. When I worked with
Async DECnet on a VAXstation II some years ago, DECnet would NOT permit
the use of the console terminal port (CSA0:). Use of any other terminal
interface (DZV, DZQ, DHV, DHQ...) works just fine. The issue was that
the DECnet code wouldn't let me define a circuit (either statically or 
dynamically) unless the port was a TTxx or TXxx device. Hopefully this
has changed, but it may be due to a hardware restriction on the console
port (such as no buffering).

With regards to the speed of the link, I have been using DECwindows over a 
9600 Baud synchronous dialup modem for some time and find that it is OK,
but not a speed demon. Even so, it's still better that the packet overhead
of doing edits over a SET HOST session!

Greg

I've set up asynch circuits over CSA0.

    What is NCP-speak for CSA0:?  CS-0-0?

    Yup. But you don't have to set it up that way yourself provided you're
    going the dynamic asynch route, since DYNSWITCH does it for you when
    the escape sequence comes barreling down from the host. (i.e. after
    you've done SET TERMINAL/PROTOCOL=DDCMP/SWITCH at the host, having
    logged in via the SET HOST/DTE CSA0: route.)

    The problem with CSA0: is that it doesn't have modem control lines, so
    you can't use VAXPAC or similar things to autodial over it. Instead,
    you SET HOST/DTE CSA0: and then talk to your modem (actually, typing at
    it is considerably more effective).

    I've leaving out lots of details, so don't treat this note as a
    tutorial - look in the docset for all the incantations (or in a
    previous reply).

    re .10

    I could be wrong (it's been a while, and I generally defer datalink
    details to others), but I don't think it's ever been true that
    DYNSWITCH *required* the port be TTxx or TXxx. I certainly don't recall
    it as an issue at any time. Sometimes one symptom masquerades as
    another.

    In any event, since I've used CSA0 for dynamic async, the point is moot
    now.

Hi Bob,

A few things also come to mind regarding the discussions in this note.

First, the <worknode> needs to have virtual terminals enabled (SYSGEN> connect 
VTA0/noadapter/driver=TTDRIVER) so that the process hangs around after the line 
disconnects during the DYNSWITCH sequence. The details are spelled out in 
chapter 5 of the Networking Mnaual beginning on page 5-11.

Second, the process for properly obtaining a nodenumber assignment from Easynet
management required me to read numerous policies regarding information security,
AND write a letter of intent, explaining the business need for having a home 
node. My manager had to sign it...   They don't make it easy (and the reasons
are obvious...) but it CAN be done.

Third, don't forget to enable access by <worknode> to <homenode> in the 
'customize - security' menu of the session manager...

DECwindows application performance over 2400 baud lines is very slow (on the 
order of 3-4 minutes to get the DECwindows MAIL window on the screen) and every
time those windows are occluded and then uncovered, the repaint (done by the 
client) takes quite a while too. But as was mentioned in an earlier note, it 
beats debugging graphics applications with no graphics device. I would tend to 
take the 'copy the sources and debug locally' approach, if it were me.

						Go for it, and Good luck!
							jr