If the universe server is on windows XP (or windows 2000/nt or I think windows
server 2003) you can use services.msc to allow the universe telnet server
service access to the desktop (there's a checkbox in the log in tab). Of course
that's only useful if you're a desktop user on the server
If you're doing FTP, you probably want the -n option on the ftp (no prompt
for login) and then use the user ftp command.
We'll build a script for the ftp session and then call it as ftp -n
scriptname
Inside of scriptname you'll have something along the line of:
open host
user name password
cd
On Thu, 16 Feb 2012, Ed Clark wrote:
If the universe server is on windows XP (or windows 2000/nt or I think
windows server 2003) you can use services.msc to allow the universe
telnet server service access to the desktop (there's a checkbox in the
log in tab). Of course that's only useful
I suspect my issue was not this, more related to the server not letting my
process access the internet.
I also tried to run a perl program that was compiled to open an ftp
connection and download test data,
And that process hung as well. Which is what made me think the server popped
up a
Probably so from what you were describing... I was speaking to the expecting
input causing it not to close. The ftp client on the version of Windows and
'nix'es I've used immediately prompt for username and password at the open
command. The -n stops it from doing that, then you can use user
I believe I tried the -n and inputfile method first, and that kept hanging as
well, So I went with the PERL method; which didn't help either.
I logged into a PC using logmein over the internet, then from that PC I logged
into UV (on an NT server) using Wintergate and then once logged
In, I did
You can also use the -s option to have the FTP command read from a
script file. Personally I found it easier to use cURL for Windows when
doing any kind of file transfer from a Universe environment on Windows/DOS.
Robert Porter wrote:
If you're doing FTP, you probably want the -n option on
It was a 32 bit NT server. Also my perl program hung as well. I compiled it
with perl2exe, so I don't know if the perl module has the same issue.
It would connect, but it hung on the transfer, it was strange.
From: John Jenkins [mailto:u2g...@btopenworld.com]
Sent: Thursday, February 16, 2012
I wondered about that too and googled around. Simple answer: Services can have
access to a desktop, but it isn't the same as any user's desktop. Apparently
there are some things that a process can do that require a desktop that nobody
needs to see. SQL server uses this for task synchronization.
The goal of any tool is to make us, programmers, more productive. I've
used Accuterm back in 90's and even with all of the enhancements, it
requires a telnet session to work. Not the best way to show new
programmers that you have a telnet session open to compile a program.
The big question I
As you type compiler messages from the real compiler
This one sounds a bit odd to me.
So I have a dimensioned variable called Billing.Array
And on a new line I'm typing Billing.Array(5) = 100
And as I'm typing this it keeps telling me End of line unexpected on each
keystroke
or something
Wil, you're asking a question from the product website or doc. I
just wanted to make people aware of the offering here, in
response to a specific request. At this point I suggest anyone
with interest take questions to the vendor.
From: Wjhonson
As you type compiler messages from the real
From: Doug Averch
The goal of any tool is to make us, programmers, more
productive.
Wjhonson wrote:
There's no market for a tool that runs on a telnet system.
To Wil, I suggest in agreement with Doug that productivity is
unrelated to the connection mechanism. mvToolbox is indeed a
From: Ed Clark
Or you can have a listening program running on your
desktop, and the server can connect to it and tell it
to open desktop windows.
When people ask for a way to invoke PC applications from a
browser based on interaction with an MV app, that's exactly how I
do it. There can
On 16/02/12 23:09, Tony Gravagno wrote:
To Doug, you imply that GUI=productive which is as invalid as
telnet=unproductive. I also hoped that you would have restrained
your competitive instincts in just this one case. You don't need
to stomp on other products to promote your own. You'll note
A GUI is useful for
1. Web users who have no idea what criteria your system is using and have to be
helped for every single field (including Name)
2. Novice clerks, or those filling in for someone on vacation, temps, and so on.
3. PHBs what does this big red button do that says 'Don't press this
From: Wol
Tony Gravagno wrote:
To Doug, you imply that GUI=productive which is as invalid as
telnet=unproductive.
Actually, I think it's pretty much a given that
gui=UNproductive.
Well, in all fairness, I don't put that extreme postion on the
medium either. Maybe we can agree that a
Tony, my worry is about support in the future if you cannot keep your
website functional today. Never did I say that product was not as
advertised.
Telnet is archaic and was developed around late 1960's. So when you are
using SQL Server, or Oracle, or Informix do you use telnet to do anything
Whilst I understand where you are coming from Doug. I think we get too caught
up that telnet is negative. Microsoft had to bend to demand for a command
line system for Windows because the tech guys said it was too slow to do things
in Windows forms. When I talk to Oracle databases, SQL
19 matches
Mail list logo
