6 replies to this topic

[jbach35]

Hello everyone!

My first post here. My apologies for the short novel.

To Cathy: I read your post (Best method for remote connections to PRO-IV), and Darrens reply. I am intrigued by the possibilities of creating our own interface. I didn't want to hijack your post, so here goes.

We currently (still) use v4.6 r2.0.0, but have recently been experimenting with 5.5 r4.1.1. All our servers run SCO Unix Open Server v 5.0.6, Tomcat 3.1, and Java 1.3.1.

This week we installed the WebClient3 on the unix host, ver 3.1.1.074.

WC3 installation went well. It connects, configures, and behaves (seemingly) properly, albeit a tad slow and at times, cumbersome.

I like the idea of using IE to display the client, but we're looking for something with a bit more "windows like" feel.

All of our functions were originally created for character terminals, and many of the screens are jammed full of fields, and to implement combo boxes and list boxes crowds the screens even more.

We will have to rewrite many of our screens to give it that windows "look" so why not write something that can use IE on the end users pc.

I'm wondering if an interface (Java servlet) could be written to interpret the pro-iv data, using pro iv commands to communicate with the servlet. Then the end user could connect to the unix host with IE. Tomcat would serve up the interface.

Another characteristic we'd like to include is the ability to access several screens/functions without having to close the current one the user is in. This would eliminate the end user firing off several client sessions to access multiple functions.

Darren, you mentioned Java, .Net, and Asp. Can you, or anyone, give me more info on getting this accomplished?

Unless there is an easier way?

Would it be easier to use a pro iv tool already in use?

Thanks in advance.

Jon

[Steve Houghton]

Hi Jon

Just to reply to one of your points

"All of our functions were originally created for character terminals, and many of the screens are jammed full of fields, and to implement combo boxes and list boxes crowds the screens even more."

You are not restricted to 25 rows by 80 columns in Pro-IV. I use 30 rows by 110 columns for most applications and 42 rows by 130 columns in another version of the same system. The screen space is there to be used - you are not restricted.

I would be interested to know if anybody is using more spaxce than 42 rows by 130 columns.

Regards

Steve Houghton

[jbach35]

Steve,

Thank you for that info.

I'll pass it along to our programmers. That should give us much needed realestate for data entry.

Jon

[DARREN]

I like the idea of using IE to display the client, but we're looking for something with a bit more "windows like" feel.

All of our functions were originally created for character terminals, and many of the screens are jammed full of fields, and to implement combo boxes and list boxes crowds the screens even more.

We will have to rewrite many of our screens to give it that windows "look" so why not write something that can use IE on the end users pc.

I'm wondering if an interface (Java servlet) could be written to interpret the pro-iv data, using pro iv commands to communicate with the servlet. Then the end user could connect to the unix host with IE. Tomcat would serve up the interface.

Another characteristic we'd like to include is the ability to access several screens/functions without having to close the current one the user is in. This would eliminate the end user firing off several client sessions to access multiple functions.

Darren, you mentioned Java, .Net, and Asp. Can you, or anyone, give me more info on getting this accomplished?

Unless there is an easier way?

Would it be easier to use a pro iv tool already in use?

Thanks in advance.

Jon

Jon

you raise several interesting topics

The first one is that of your current system design and how it was coded originally for character based rendition. As you have no doubt found out, these screens will render in the PROIV windows client and it does a pretty good job of it. It, however, is not a magic bullet in that your screens were coded x number of years ago to work in a certain fashion and that it what they still do. Code written 10 years ago will behave like code written 10 years ago. See some of my other responses to topics on what can be achieved today with PROIV i.e. the screen shots. In short - if you want your application to have a windows interface then you will have to change your screen functions to put the functionality in there. This is not as onerous as it sound and PROIV have a tool/service that will do it for you (I was one of the developers that created the tool when I worked for PROIV )

The second one is

"I'm wondering if an interface (Java servlet) could be written to interpret the pro-iv data, using pro iv commands to communicate with the servlet. Then the end user could connect to the unix host with IE. Tomcat would serve up the interface."

hmmmmm....I wonder why PROIV haven't thought of that....or may be they have.... :-

With regard to the ability to launch a seperate PROIV screen from an existing one, this can be achieved in 6.1....it's a done deal and the functionality is there.

The last point is api's into PROIV. These are (or were) bundled with the PROIV distribution with 'C', VB and ocx examples. You can also purchase the Java api's from PROIV as a "simple to implement" bundle and this is what we use for our web interface into PROIV. Also note that PROIV can be called as a web service in 6.1. I would talk to your PROIV account manager and I am sure he/she could set a demo up for you/give you more details.

hope that helps

[jbach35]

Thank you Darren.

Can you provide me with more technical insight as to how well the "service/tool" might respond to our functions?

I realize this may not be possible without reviewing our code, but short of that, can you enlighten me as to what we could reasonably expect?

I understand from tech support that we'd have to port from 4.6 to 5.5 r543, then 6.x.

We did convert one client (running Win SBS 2003) from 4.0 to 5.5 r518 by exporting all functions from 4.0, then imported them into 5.5. Be we experienced several errors when we tried to regen any functions on the system. Functions did operate normally as long as they weren't regenned there.

Would the service/tool help in any respect to this?

Lastly, is (was) the "simple to implement bundle" supported under 4.6 or 5.5?

Any thoughts/ideas would be greatly appreciated.

Jon.

[DARREN]

Thank you Darren.

Can you provide me with more technical insight as to how well the "service/tool" might respond to our functions?

I realize this may not be possible without reviewing our code, but short of that, can you enlighten me as to what we could reasonably expect?

I understand from tech support that we'd have to port from 4.6 to 5.5 r543, then 6.x.

We did convert one client (running Win SBS 2003) from 4.0 to 5.5 r518 by exporting all functions from 4.0, then imported them into 5.5. Be we experienced several errors when we tried to regen any functions on the system. Functions did operate normally as long as they weren't regenned there.

Would the service/tool help in any respect to this?

Lastly, is (was) the "simple to implement bundle" supported under 4.6 or 5.5?

Any thoughts/ideas would be greatly appreciated.

Jon.

Jon

Have a quick read of the following document (located on the PROIV web site)

http://www.proiv.com.....(A4 size).pdf

After reading you will note that PROIV (the company) can take some or all of your application screens and graphically enhance them The document also discusses the Security and Menu Driver, which I highly recommend, as it is the usually the entry point for users into an application and as such has to look the part as it were. Again, as one of the developers that worked on this, I can confirm that it is tight as a drum. So much so that when I moved to the company I currently work for one of the first recommendations I made was to purchase the menu driver. (see attachments). PROIV developed tools to auto migrate your existing security model (native,SuperLayer etc.) into the data model used by the menu driver.

As for what the service offers, I would again speak to your account manager, but I recall that three levels of service were offered just converting your screens to a full implementation of the menu driver and a basic e-commerce solution. I would hazard a guess that the service now requires you to have your source code in Developer (VIP) and not native, but that may be another thing you could discuss.

You mentioned that you experienced several errors when you attempted to migrate to 5.5 r518. The first thing to note is that the gen process did tighten up a lot between 4.6 and 5.5. As part of the migration of you source code to Developer (VIP) it performs a sanity check against the code and tells you what is wrong (illegal) with it e.g. return fields of file reads that are not part of the cycle etc. Without knowing what your errors were, I cannot expand any more on this.

You do get a lot of 'bang for your buck' with the graphical service, as your application can take on a whole new look very quickly. We pushed thousands of functions through the transformation service and the change, especially for less busy screens, was quite dramatic. We also saw all sorts of coding styles and adapted the service to accommodate them all (one of the most complex pieces of code I have ever written ) Again talk to PROIV and they will expand on all this - they are there to help.

The Java bundle is basically class libraries that allow for the simple call (from java/JavaScript code) to PROIV. I cannot think of a reason as to why it would not work with 4.6 - even though that version of the product has not been supported for a long time.



I would recommend that you migrate to the latest version of 5.5. and into VIP. This will give your code a shake down but is well worth it in the end. Then graphically enhance some/all of your application. How much you want to do is up to you and we concentrated on our high traffic screens first and in some cases re-configured them.

Attached Thumbnails

• 
• 

[jbach35]

Darren,

Once again you've been most helpful.

I've contacted Pro-IV in persuit of some of these services.

I have also downloaded the Windows Single Developer and begun to familiarize myself with it. I thought it would be version 6, but the kernel info says 5.5.

I am not "the" programmer here, but have a good working knowledge of several aspects of Pro-IV, and plan on doing more of the programming, or at least influencing our direction.

I also plan to download and 6.1.

Question: should I spend time on 5.5 if we eventually decide to migrate to 6.1? Does 5.5 behave/look similar to 6.1?

I guess I'm looking for the best advice on where to spend my time.

Jon