Ok,

Here goes, we currently have 3 applications written in AREV, and we are talking big applications with some dict tables containing over 1500 fields… each application also has anywhere from 5-8 BP tables depending on what they are used for, we have a BP table for common programs/utilities used through out all 3 systems and the more module specific program tables…

My question is, we are planning to migrate to OI 16/32 and from my understanding there is no VOC file, so how do I bring over all the program in the 5-8 different tables??? is there a way to still call the program from each table or do I need to migrate all BP tables into one, I was trying to avoid this since some of the BP tables have over 1000 programs.

Please Help, any ideas around this???

Thanks

Jack

There is a SYSDICT which fulfills the role of VOC but there is no easy way of storing all of your routines in different tables and calling them from there. However this should really present no real problem in practice as the system editor makes location of individual routines relatively easy.

If it were a major issue then it could be coded around with work but it would not seem worth the expenditure of energy.

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks for the quick reponse…

so bottom line, I need to migrate all my BP tables… I was so hoping I did not need to do that… :(:(

Thanks

Jack

Jack ..

I'm sure you read Sprezz's response. All source code in OI has to be stored in a single table. Like you, I had specific BP tables. What I did was to name the programs BPFILENAME_ITEM_NAME. This made finding them easy. As you know, each entry has to begin with:

SUBROUTINE Your_Name(Parm) .. including Void, if necessary

or

FUNCTION Your_Name(Parms)

You can keep your original names so that internal calls in source code will stay the same. Effectively, all compiled code is auto-catalog'd in SYSOBJ using the name declared on the first line.

The function of SYSDICT is similar to the old DICT.VOC items. There's no similar capability to non-dict VOC items from AREV .. TCL pointers, etc. But, if you have a lot of commonality in your file dictionaries, SYSDICT is useful.

I found in AREV that anything over about 700-800 dict items became way too unstable to maintain. I got in the habit of coding a lot of dict symbolics as Functions and just having a caller in the DICT. This also made debugging of these items a whole lot easier too. Also made deploying upgrades easier since the call stayed the same .. just the BP code changed. This works well in OI as well.

Just a thought …

Don Miller

C3 Inc.

All source code in OI has to be stored in a single table.

Um…are you sure about this? I might not understand what you are saying but we support an application where source code is kept within diferent tables (i.e. other than SYSPROCS). However, of course, when we compile the code a copy is put into SYSPROCS and the object code is put into SYSOBJ.

The reason for this approach was because the code was being shared by an AREV application that attached the same source code tables.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don B.

I learn something new every day. I thought all source code had to be in SYSPROCS .. I tested your hypothesis and you're right. You can have separate source tables, but when compiled, the source migrates to SYSPROCS. All object code lives in SYSOBJ though or am I missing something there too?

Thanks ..

Don M.

Don M.,

Yes, all object code gets moved to SYSOBJ.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Umm… what about SYSPTRS - this table acts pretty much like the AREV VOC pointer. Of cause there is zilch documentation. - I used it at some stage, but now have forgotten how .

Richard Bright

BrightIdeas New Zealand

View this thread on the forum...