Willing Experts Idea
Posted 18 February 2004 - 05:37 PM
One area of in which I think that this forum could be made better is to have a "Willing Experts" area.
The basic issue is this. The forum is very good for when you have a specific issue or question to post to the list. Usually within a few days someone who has an answer will post one. However, when you are in a quagmire where you don't necessarily appreciate the full depth of what you are dealing with, then this list becomes less of a resource.
For example, I lately experienced 2 separate issues for which this forum was not very helpful. The first was in setting up the ssh client to run against RedHat Linux. Not appreciating all that is entailed with ssh, a ProIV client issue set me back days in figuring out what was going on. (As a courtesy, I did post what happened and maybe someone will find it in a search one day.) A different issue was trying to diagnose misbehavior of SQL Server record locking with ProIV.
It would excellent to be able to see what areas people on this forum are willing to help others out with. An example of this might be:
Setting up Bus and Tasks - or -
If we could search the database of users to see who is a willing expert, then we could contact them directly. The way that I would see it working would be this: A list of areas is compiled. Each user can specify their self-rated proficiency in each, the amount of time they would freely offer to give assistance to someone and their hourly rate for any additional time.
For instance, I may rate myself as follows:
Area Rank Free Time Consulting Rate
Setting Up RedHat Linux / PostgreSQL 3.5 of 5 30 minutes $125 / hour
Tuning PostgreSQL 3 of 5 30 minutes $125 / hour
ProIV 5.5 Native 4.5 of 5
I would especially see this as useful for really nasty client situations where turnaround time is critical and I may not mind paying someone else to solve my problems. Also, this would be useful for finding someone who could offer support for a new area of technology that we are not using (like VIP, Bus & Task, etc.)
Of course, there may be an issue in figuring out how to limit the expert areas so that they are manageable.
Posted 23 February 2004 - 03:55 AM
I can help in these areas:
1- setup of linux for pro4
2- key/ serialization recovery on linux. and backup server.
[for instance if a server for pro4 crashes, and you need to make a new one, it is simple to setup pro4 to use the old serialization files. If you are using linux and would like info on howto do this contact me. In exchange you could take the time to writeup a howto and post it to this forum.]
[ anyone running pro4 + linux should have a standby server ready, and use rsync to keep it current. I backup our production server to an onsite and offsite server atleast 1x per hour].
3- ssh / putty
i use pro4 Version : 4.6000 Revision : 2.1.3 .
Posted 24 February 2004 - 05:59 PM
Thanks for your info. Your backup methodology sounds very interesting. Where can I find more info on rsynch as it does not appear to be a standard RedHat 9.0 utility?
Areas where I am willing to help others:
ProIV with SQL databases - especially PostgreSQL
A really powerful utility that validates your actual SQL database versus your logical ProIV database and spotaneously generates the requisite SQL for Oracle, SQL Server or PostgreSQL. (I did give a copy of this utility to ProIV already)
Converting to ProISAM to any of the above
Anything ProIV Native
Unix level scripting, interfaces, etc
Dos Batch level scripting
(I was going to say DOS batch scripting - if you're ever really stuck. However, I realized the redundency... you wouldn't resort to DOS unless you were stuck!)
Reporting out of ProIV
Making irreverent and / or sarcastic remarks
Posted 09 March 2004 - 06:20 PM
I was not ignoring your question. It is just that the answer in very lengthy!
Our company supports dozens of clients on Unix and Windows running against Oracle, ProISAM, PostgreSQL, and SQL Server on two applications. There is one master source code library for each application. During installation of prx files, our routines will change the file declarations appropriately.
Our clients can upgrade at will. We used to cut one definitely release a year and then spend months getting clients installed. Of course, the problem with this is that regardless of how much you test, you always have issues come up when clients upgrade. Within several weeks, our definitive upgrade for the year would be replaced by the definitive upgrade for the year, version 2.
Depending on what issues were found, we sometimes had to immediately upgrade everyone who was on version 1 to version 2. This methodology for upgrading clients did not work for us.
Instead, we invested time into developing an upgrade on demand strategy. The way this works is that when a client is due for an upgrade, a new distribution of the software is cut from our production region. (Our production region is where changes are placed after they have cleared QA.) So, clients literary get a version based on what the current date is.
One of our staff members monitors what version clients are running. When clients get older than 6 months, we schedule an upgrade. So, almost all of our clients are within 6 months of current development.
This strategy has worked much better for us. The amount of time spent on upgrading clients and doing extensive version testing has dropped considerably. However, this approach presented some major technological challenges.
Specifically: Since clients are upgrading on command, there is no way to script for what files, tables, table expansions, etc. that they need when they upgrade. Our solution, which we are very happy to share, is GU_EMPTY. For the sake of space, and thread continuity, I'll create a new thread: GU_EMPTY, an upgrade solution
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users