Jump to content

Rick Young

Member Since 15 Jan 2003
Offline Last Active Apr 08 2017 08:40 PM

Topics I've Started

ProIV Developer vs ssh

30 March 2017 - 04:53 PM

Greetings all


I'm trying to make the MFC client (version 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




Entry Is too Long

27 July 2011 - 07:26 PM

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.


GU vs LU - cost?

31 March 2011 - 08:30 PM

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

Global Screen...sometimes

11 February 2011 - 07:51 PM

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?


kernel v6.2.35

HP-UX 11.23 RISC 64

01 February 2011 - 03:43 PM

Please don't anyone take any real time on this - just throwing it out there on the offchance someone has seen this happen and maybe has a good clue or knowledge as to "why". HP support has been contacted, although there has been no feedback/theory thus far.

Client's server has been up for some 320+ days running with no known issues (with one exception, not including the one I'm posting about). The exception was about 2-weeks ago, had a ProIV function coredump a few times filling up root volume.

Last Friday afternoon cronjobs stopped executing. Based on some basic logging from some of the jobs - the prior night overnight jobs all ran; the "hourly type" jobs last ran at 2pm; and an every minute job last ran at 2:02pm. There are a mixture of ProIV transparent login jobs as well as shell scripts; there are no other programs/applications being executed.

User reports first thing Monday morning started the hunt for why "their" expected automatic data updates had not occurred.

- ps -ef |grep cron - showed cron to be running
- /var/adm/syslog/syslog.log - did not show any errors in the Friday ~2pm timeframe, nor the prior 24-hours
- /var/adm/cron/log - simply shows cron jobs running and then no entries.
- dmesg - shows the last "nospace" errors only
I did not check every single job to see if any were actually still running processes - I probably checked about 1/3 of them. But that does of course mean, I cannot guarantee that there was not a "hung" job blocking the queue.
There have been no changes to the crontab, nor the cron job scripts nor the ProIV functions being called in 3 weeks.
The largest interval of any job, is "skip the weekend" - but there are always at least "half a dozen" jobs executed daily and multiple times per day.
Server time had not been changed recently.
So for over 300-days, the jobs have all run fine.

I then used crontab -e to verify that all jobs in the schedule were as expected. Upon quitting, ALL of the jobs then executed - and at ~9:30am on Monday morning last day of the month, the "overnight" kill users process did not rate highly on the popularity list.

Ongoing for the remainder of the day, overnight, and this morning - cronjobs have/are executed/executing normally.

Once again - please don't expend any real time on this - but any thoughts would be appreciated.