Rick Young

Has anyone attempted and succeeded using PuTTY instead of "DOS" (windows cmd) telnet.exe to connect to a Linux server?

 

Here's the why I'm trying...

 

If a Linux user has a French language ($LANG = fr_CA.utf-8) and/or there are French characters being displayed by a Linux script, these character are not readable via DOS telnet.

 

They're perfectly fine if I ssh or telnet using PuTTY.

 

The only way that I could get a PuTTY terminal window at all, was by adding the following in the General/Connection/Advanced Parameters/Parameters field: -load "[my saved session]" -P 23 -telnet

 

This gives me a login prompt in a PuTTY window; allows me to login fine and see correctly displayed French characters (whether my Linux user is set to fr_CA.utf-8 or en_CA.utf-8); but when I execute the script to run ProIV, and choose the GUICLR option - it displays (poorly) to the PuTTY window, instead of returning control to MFC client like the telnet window does.

 

Hope this makes sense(?)

 

Thanks in advance

Rick

Greetings all

 

I'm trying to make the MFC client (version 7.1.55.0-PR) connect using ssh.

 

I currently use it just fine with telnet on a "local" (via VPN) server, however I also need to connect to a different remote (across the 'net) Linux server which does not have telnet access.  Using telnet, it throws open a dos telnet window; I login, run the applicable bash script at the *nix command line, choose the appropriate terminal type, and everything is then thrown back to the MFC client.

 

Whilst VPN'd have used both the puTTY windows client and puTTY's plink dos command-line client to successfully connect via ssh to the remote server.  By the way, ProIV is not installed on this remote server.  I have to then ssh/telnet to a second server.  

 

The Northgate-provided p4sshlink.exe does not do anything if I attempt to use it dos command-line as if I were executing plink.exe.  (I assume that it has been specifically compiled to work with ProIV.)

 

I've also attempted to setup puTTY's ssh-tunneling (which I am not familiar with), as an alternate plan and was not successful.

 

I'd like it to work in the same manner that I'm used to using with the telnet option mentioned above.  Whether via direct ssh or tunnel, I don't care which.

 

Many thanks in advance

Rick

 

 

I've just reported a bug to ProIV - green screen only, it doesn't affect GUI.

Kernel: 6.2.59-PR, 64-Bit. Tested on HP-UX 11.23 PA-RISC 64-bit, and on Linux (uncertain of specific OS version).

If a user types in (or copy'n'pastes) input greater than the length of the input field, 021 Entry Is Too Long . . . Re-Enter, is displayed. Pressing Enter again, restores the prior value of the field.

eg. if you have an input field of length 3, and you type in ABCD then Enter, the problem arises.

In GUI and also in all prior kernel releases/versions that I'm familiar with - input greater than the field length is just ignored (or maybe it's truncated); either way, it is/was a non-issue for users.

-Rick

seeking opinion please - or even better, fact

Which "costs" more (processor and/or time-wise): calling a logical set of nested cycles/LU's, or calling a GU to perform the nested cycles/LU's? Approx .5mill calls will be made. Only "good" reason I currently have for wanting to use a GU, is so I don't accidentally screw myself with key/field values reading the same physical & logical filedef as in the main cycle/LU.

Thanks in advance
Rick

I have a GS, that I want to call BOTH as a) as if it were a 'regular' Screen called from a menu; AND as a true GS called from within another function.

The catch: when calling it directly from a menu (or executing from ProIV command line) - it looks like a "window" not a regular screen.

Is there some way to dynamically set whether it appears like a "regular screen" or a window, depending on how its called?

Thanks
Rick

kernel v6.2.35