Forte 4GL (UDS) basics - distribution

to make a application run on several different servers, Forté uses a specific object called Service Object.

basically a standard class (DummyMgr) is marked as distributed.
then a service object (by convention named DummyMgrSO) based on DummyMgr is defined in the Workshop. behind the scenes Forté creates a proxy that exports all attributes and methods of DummyMgr thus making them remotely available to clients.

the application is partitioned, the first time Forté defines a default partitioning that can be amended, and installed in a given environment on a given server.

dummy application, Client on node P4 & Server partition on node S5





the application is registered with the environment manager, once started the DummyMgrSO is registered with the name service so any client with a TCP/IP connectivity to the environment can get a reference to the DummyMgrSO and call methods or set/get values or variables on it. (accessing attributes may be arguable it is possible).

Forte 4GL (UDS) basics - workshop

Forté 4GL is an IDE, it all happens in one place. the Design, the Development, the Versioning, the Deployment & the Monitoring.

a development team has a Forté environment and a shared development Repository, each member has a Workspace in this repository that they access using the Forté Workshop.

from the Workshop (usually called Studio outside Forté Software Inc.) the team member can create, check in, check out classes, synchronise his Workspace with others',

define a logical partitioning of the application and deploy the logical parts to remote servers.





the only thing that needs another tool is the monitoring.

this is done through an environment console called eConsole and used to load application definition, install the application fragments on the relevant servers, start or stop them, view the logs or modify runtime parameters.

the used language is called TOOL for Transaction Object Oriented Language.



there is weakness though, there aren't any modelling tools per say, and getting a clear picture of the class tree and class relation diagram is not easy. plus every project, class, method ... opens in a new window, standard behaviour under Mac OS 9 but can be annoying to MS users.

Forte 4GL (UDS) basics

a short overview of Forté features.

Forte Software Inc. from Forte 4GL to UDS

Forté founded 02/1991, the staff chained to their desks for more than three years before shipping the product 08/1994, became profitable the next year and things went pear shape from 04/1997. To cut a loss story short, 08/1999 merger with Sun complete, Forté is an iPlanet product with a Sun logo, 2002 the iPlanet Sun|Netscape alliance is over and Forté is Sun ONE Unified Development Server (UDS) with an iPlanet logo ... trivial


PRODUCTS

Forté 4GL or Forté TOOL (ADE)

The very core of the Forté's offer. Define, Version, Distribute, Build, Deploy & Monitor all in one place. Specific language: Transactional Object Oriented Language (TOOL). DevStudio provided. Multi platform (Windows, MacOS, Tru64, Alpha Open VMS, HP9000 HP-UX, OS/390, RISC/6000 AIX, Sequent Dynix/ptx, Sun SPARC SunOS,) & multi DB (DB2, Informix, Ingres, SQL Server, Oracle, Sybase & ODBC)

Applications can be distributed across a heterogeneous array of clients and servers, run in interpreted (Forté VM) or C++ compiled, integrated with external systems using Java, C, C++, XML, OLE ...


Forté Express (04/1996)

A RAD tool to generate business model and matching DB layout & access.


Forté WebEnterprise (12/1997)

A deployment add on to Web enable Forté 4GL application by generating the necessary plumbing and GUIs to be served through MS IIS (ISAPI) or NES (NSAPI or ForteCGI).


Forté Conductor (9/1997)

A GUI based workflow design environment with the ability to analyse the work in progress.

Forte 4GL UDS Sun ONE Unified Development Server

Forte 4GL UDS Sun Unified Development Server
a series of articles about Forté 4GL (UDS) undocumented features and what can be done of them.

digging existing Forté code

what can be done of all that?

first stop ... 

using the previous thingies you may now be able to have a look at what is in $FORTE_ROOT/userapp/forte/cl0/forte.btd

a set of instruction is available here

an export of the Forté distributed apps is there

once imported have look at the plan named ‘ide’

enjoy browsing the Forté 4GL Workshop into the Forté 4GL Workshop ... mind boggling what the lads at Forté inc. managed to do. init?

 

internals of distributed apps

when an Object (eg mySO based on DistObj) is made remotely available Forté creates behind the scenes a class DistObjproxy that inherits from qqlo_Proxy and DistObj, it aplies to ANCHORED objects too.

there is only one class DistObjproxy created no matter how many SOs are based on that class, the multiple instanciation happens at runtime (the DistObjproxy is a class, the SO is an Object instanced using ImmobileInstanceAlloc as opposed to InstanceAlloc called on the ClassType when the ‘= new()’ statement is executed)

at runtime a method call on a SO translate into
GETGLOBALVAR 0
PUSHOBJECT 0 Rank of the SO in the list (looks like it's equal to SO_id - 1)
METHOD 3, 2


everything about GUIs and IRblock applies to distributed applications like forte.btd
but there are a couple of things that are not available directly in the runtime repository (at least I don’t know where)

when an application is distributed Forté creates 2 files suffixed .ace & .adf

the .ace file contains a serialised qqem_DistributionCatalogEntry used when econsole / escript lists the available, loadable distributions

the .adf is a qqem_StandardApp and contains the layout of SOs and their attributes (visibility, dialog duration)

so reading the .ace file makes you aware of the distributed layout.

internal Code storage __ qqrt_IRBlock

qqrt_IRBlock : how to get access to its attributes.

qqrt_IRBlock shows many attributes defined as pointers the good old $TOOCOMPLEX type.
unfortunately Forté as a 4GL does not allow you to set the pointee of a pointer, so just set pointer to the qqrt_IRBlock you want to inspect and load it in a BinaryData ... read at the requested offset something like

to get the list of pointer attributes

ptrIRB : pointer to char;
ptrIRB = (pointer to char)((pointer)(my_qqrtIRBlock));
myMemStream : MemoryStream;
myMemStream = new();
myMemStream.Open(SP_AM_READ_WRITE, TRUE);
myMemStream.UseData(ptrIRB, ClassType(qqrt_IRBlock).Size);


an Object is a pointer but the MemoryStream to be set requires a pointer to char ... so be it!


extracting the value of lets say qqrt_IRBlock. DoubleArray


linkedArray : BinaryData = new();
if my_qqrtIRBlock.DoubleCount > 0 then
voidBinaryData : BinaryData = new();
myMemStream.OffSet = 0x48;
myMemStream.ReadBinary(voidBinaryData, 4);
linkedArray.SetValue((pointer)(*(pointer to pointer)(voidBinaryData.Value)), my_qqrtIRBlock.DoubleCount * 8);
end;
BinaryData.Value is a pointer but we need to be able to read what is pointed as a pointer hence the silly recast (pointer to pointer) and the de-referencing and again the recast as (pointer)

migrating Forté 4GL TOOL source code

source code

... the easy not part ...

a method’s original source code is available in a ‘meta’ instance of internal Forté class called qqc4_Method

always better than parsing the Workspace export, it is possible to traverse the user’s plans in the workspace and generating txt files for every class traversed.

and the source in the watches

but still tedious since the source code has to be parsed by hand.

there might be a way out of this, a qqc4_Method when parsed & “compiled” using ‘Shift + Ctrl + C’ gives birth to a qqrt_IRBlock that can be seen in the log window when the flag trc:c4:3-5:10 is turned on and ‘Shift+Ctrl+C’ pressed on a compilable entity.

it spews
a bunch of object types & IDs
a bunch of Vars, Strings
a stream of assembly like commands

how to work out IDs? IDs are (a, b) ‘a’ being the plan ID and ‘b’ the class ID in that plan
see MS Access DB ForteIDs
this table also contains the Method, Attribute ... IDs for a given class.

the header can be read with that table here

the IR instructions are listed here next to the “mnemonic” code is the instruction name and the list of parameters. going down there is a mention made of a future ‘R4’ ... this day may never come.

at that point there is a way to generate a bunch of instructions based on that.

scanning Forté 4GL UDS GUIs

... the easy part ...

the Forté GUIs are not compiled at all, even in a C++ produced Forté applications the GUIs are still displayed through the VM interpreter. as a token you may have noticed the way Forté exports GUIs in a .wex, .pex or .cex file a blob of Hex, the produced C++ bears the same value in an binary array var.

now as the GUIs code is not compiled it is preserved in a way that makes things easy to crawl through all the items that constitute a _Window object.

as per the screen copy supra, opening the workspace and crawling the plans, classes ...

with the following snippet

aVoidObj now references an Array that contains the class definition of the example window

having a look at the local variables

the tree like structure describes all the items that the window is made of.

it is now only a matter of carefully matching the Forté ‘FieldWidget’ or ‘MenuWidget’ to the ones available to the target platform. all the attributes as bound objects, size, placement, visibility, behaviour and more are available through the Widget (or child classes) attributes and methods.

time consuming but not rocket science.