2008/01/05

Weird Things

Multiple Inheritance

Forté does not support multiple inheritance ... well

looks like the class qqlo_CNM inherits from 3 classes Object, qqlo_PartitionStateMonitor & qqsp_TaskStateMonitor




Struct Union & Enum

structures, unions & enums are not declarable from the IDE, need to create a pex or cex file ... but








to achieve that

then ignore the error messages once and cancel subsequently. close the project and reopen to see the Struc Enum or Union.

OK you can't really use them ... if you find how let me know.






Puzzling statements in iPlanet UDS Help

I quote:

The class statement creates a custom class.

Syntax

class class_name [is mapped] inherits [from] superclass
[implements interface, [interface]...]
[ [has public | has private] component_definitions]...
[ has property [property]...
[ has file filename;]
end [class];

property is one of:
shared=(allow={on|off}[,override={on|off}]
[,default={on|off}]);
transactional=(allow={on|off}[,override={on|off}]
[,default={on|off}]);
monitored=(allow={on|off}[,override={on|off}]
[,default={on|off}]);

distributed=(allow={on|off}[,override={on|off}]
[,default={on|off}]);
restricted=(TRUE|FALSE);
extended=(name=value[,name=value]...)

you may have noticed that many screen dumps were made on Mac OS and any application on Mac OS has to be scriptable ... ftexec was no exception and this was the syntax to use in AppleScript to create a class.

2008/01/04

Forte 4GL (UDS) basics - code containers

Forté uses a proprietary format to store and manage code.

the format brings powerful features as code control, versioning & consistency, the drawback being it's not a set of text files. but since Forté is writing to and reading from those files as well as exporting/importing to/from text files using the IDE, there is some hope that it's possible to write our own specific 'FortéPad'.

btree & other code containers
in the latest Forté versions the container is a file with a .btd extension, along is a .btx file that contains an index for faster access and a .rop that is used in case the .btd file becomes corrupt.

interpreted applications and development repositories both reside in .btd files.

the .btd known as BTreeRepository was not always the norm. Forté used other formats like
CtreeRepository
GemstoneRepository
ObjectivityRepository
SQLRepository revealing that Forté Software Inc may have tried to use SQL Stores as development container.

Forte 4GL (UDS) basics - main binaries

nodemgr:
flags
-fns IPv4:port starts
name service

-e envName
environment manager

-fnd nodeName
node manager

ftexec:
interprets anyApp.btd files

rpstart rpstop rpserver:
to start development repositories.

personal: never use the automated install on Windows and get used to starting environment, repositories & application using batch files. this avoids env var contention and keeps the environment clean. this was supposed to help but it does not if you run several different versions of Forté or connect to different environments ... and as a developer it prevents sysadmin shuting down your forté executor bringing to a halt your IDE ... I confess I did it many times.

viva -fi, -fm, -fns, -fnd, -e, -n ...

export FORTE_ROOT=/forte

start the envmgr: nodemgr -e envName -fns mySvrIP:myPort

start the repository: rpserver -n myRepLogicalName -fr bt:/pathtobtdfile/myRep -fns mySvrIP:myPort

start the IDE: ftexec -fi bt:$FORTE_ROOT/userapp/forte/cl0/forte -fr myRepLogicalName -fw myWKS -fns mySvrIP:myPort

Forte 4GL (UDS) basics - agents

one of the unmatched strength of Forté: System Agents.

a system agent manages an object in a deployed application, that is, at run time it is possible to execute some commands and inspect some instruments on the managed object.

usually those commands have to do with monitoring and tuning an application but they may interfere with the business logic e.g. the possibility to bump up the queue a batch file to be processed asap even though there is no dedicated interface to do so.

these agents are visible using the provided tools eConsole or escript or any in-house tool.

the console






the partition agent & sub agents




the available instruments and values.





and that's another issue when migrating.

Forte 4GL (UDS) basics - runtime

to run an application across different heterogeneous sets of servers and clients Forté makes use of two alternatives available, it uses the platform specific C/C++ compiler and a virtual machine.

virtual machine
Forté relies on a “layer” to level off the differences among platforms: ftexec (+ libraries) this is the Forté virtual machine that runs anything (compiled or interpreted) developed with the Forté IDE.

compiled vs. interpreted
interpreted: ftexec takes a .btd file as input
compiled: the produced executable is linked with ftexec.o

the way Forté manages to mix interpreted & compiled code is utterly clever, in the IDE most of the plans are 3GL objects made available to 4GL code, but some of the plans (AppModel, HTTPSupp, IIOP, LDAP, OLE, XMLSvr & XSLT) are 4GL TOOL interpreted projects.

the IDE itself is an interpreted bit of code (that has some interesting implications ... later) that can be executed with the following command:

ftexec -fi bt:$FORTE_ROOT/userapp/forte/cl0/forte -fr myRep -fw myWKS -fns myEnvNode:port

Forte 4GL (UDS) basics - transaction

one very nice feature of Forté is the integrated transaction monitor. when a transaction fails it takes a little bit of work to figure out what are the objects to roll back, that requires a snapshot of these object prior starting the transaction process.

with Forté IDE, mark the objects taking part to the transaction as "transactional" set the transaction boudaries and do the job, if anything causes the transaction to abort the objects are rolled back. the end.

a nice behaviour that may be tricky to achieve when porting the code to a different platform.

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.

2008/01/03

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.

2008/01/02

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.