Re: Moving from AP/DOS to openQM
- From: "Frank Winans" <fwinans@xxxxxxxxxxxxx>
- Date: Thu, 6 Aug 2009 09:31:17 -0500
"Tony Gravagno" wrote
This is the reason I asked "why QM?" It seems many people are willingSome other considerations;
to spend time to learn a completely new environment, rather than spend
the money to use one with which they're already familiar. All other
valid and invalid considerations aside, I think that's the wrong
reason to choose a platform.
ap/pro users probably are used to doing control-s/control-q to 'pause'
the screen during long unpaged reports/program runs, and this feature
doesn't seem to work on the telnet.exe client provided with windows,
or with accuterm on a telnet connection to d3/nt; I used the telnet client
provided with cygwin and it hardly works, you skid to a 'stop' about
six pages later. This may be adjustable, but nobody wants to pay for
the research to see what's wrong, they just hang some serial terminals
on the new box instead... And telnet has a pretty massive 'baud rate'
anyway, you'd have to be inhumanly fast on the draw to stop most
rapidly-printing programs/reports.
Expect to have problems with the standard trap dcd feature when
you're doing ssh into a campus to an ssh userid fooguy that in turn does
telnet localhost in their /home/fooguy/.profile {or whatever the filename is..}
And you might want to review your security against intruders if you've largely
been leaving your campus isolated from ssh logins until now; this is a whole
other thread, and off topic for this group anyway. Anyway,
d3/nt dev-list t will show what pick ports are tied up with telnet
sessions, if you see an entry there on say pick ports 3 and 4 that you don't
see in LU then do reset-user 3 (x
reset-user 4 (x
and also if using the cygwin ssh server {sshd service in other words} go change
{under vi in a bash window} /etc/sshd-config line about keepalive-interval from the
default 0 to be 120 instead. The sshd server will send a packet to the user
out in the field every two minutes, and if three such don't get autoreplied will nuke
the connection at the server end. Helps some, but still not the full cure...
And set your putty or accuterm or whatever to also do 'keepalives' -- in this case
the term means sending empty packets up to the server every so often so all the
links in the chain of routers etc between client and server know to not drop the
connection as stale and abandoned. And train your end-users to do a d3 EXIT
verb at tcl instead of just OFF then closing the telecomm program window!! They'll
still be doing that same bad disconnect involuntarily if their modem drops due to line
static, by the way, so don't be too harsh with them about it.
I'm not a big fan of D3's restore-accounts when handling file-save
tapes from other companies like old mentor boxes, or even their own
older products like ap/pro or ap/proplus. If I had to do just a _little_
bit more of this over the years I'd make a stab at writing my own;
instead I omit problem accounts/files or do wholesale tdumps.
You'll want to recompile your programs when migrating from older platforms like
d3/proplus -- be aware some new reserved keywords have been added to basic,
so that's why it hates some of your alpabetic program labels.
.
- Follow-Ups:
- Re: Moving from AP/DOS to openQM
- From: Tony Gravagno
- Re: Moving from AP/DOS to openQM
- References:
- Moving from AP/DOS to openQM
- From: Larry Lovering
- Re: Moving from AP/DOS to openQM
- From: Tony Gravagno
- Re: Moving from AP/DOS to openQM
- From: Larry Lovering
- Re: Moving from AP/DOS to openQM
- From: Martin Phillips
- Re: Moving from AP/DOS to openQM
- From: Tony Gravagno
- Moving from AP/DOS to openQM
- Prev by Date: Re: Moving from AP/DOS to openQM
- Next by Date: Re: Moving from AP/DOS to openQM
- Previous by thread: Re: Moving from AP/DOS to openQM
- Next by thread: Re: Moving from AP/DOS to openQM
- Index(es):
Relevant Pages
|