Run VMS / OpenVMS PASCAL on x86 Linux

What do we mean by 100%. The only goal for continuous integration is 100% Transpile (translate, compile). At the beginning of the project there may be VMS PASCAL odd structures or statements that may not translate. Sector7 will modify and enhance VX/Pascal until 99.9999% of your code transpiler and where tested runs in exactly the same way as VMS PASCAL. Occasionally you may need to reorganize the VMS PASCAL in such a way that the code compiles and runs on on VMS / OpenVMS and also transpiler with VX. Pascal. Out of 3M LOC, you may expect to have to change < 100 LOC.

There is no compromise with the execution of the emitted C++. It will run identically to the same Pascal executable compiled on VMS / OpenVMS. We call this "Bug for Bug compatibility" - if there is a bug in your Pascal code it should still be there in the C++ code.

VX/PASCAL is part of the Sector7 continuous integration suite of migration software. This has a VERY specific and important meaning and is anything but a "throw away" industry phrase.

For any Sector7 product to be branded "Continuous Integration" it must be capable of translating 100% of the original VMS language or API set. the generated C++ must compile 100% and execute in the identical manner as the original language / API.

for example
# vxpascal -g *.pas

will translate all the .pas files in a directory to C++, and compile all of the .CXX to .OBJ (we keep the .OBJ extension for the linux .o files so that MMS files can be automatically translated to make files)

We do NOT try to reorganize code, (there are some options for inverting loops etc) our goal is to produce C++ code that looks almost identical to the PASCAL code and works 100% identically without the C++ code needing to be played around with.

The simple truth is that unless you have a translator (transpiler) that translates, compiles and links ready for running in a single step, it is unlikely that your project will ever get completed, and if it is, it will be in the multi year time-frame and the C++ code will always be playing "catch up with the Pascal which - will be moving on to service the needs of the business.

It is exactly like painting a bridge, if you don't finish quickly, you'll be back at the beginning doing it over again - great if you're the owner of the bridge painting service, kinda sucks if you're the bridge owner.

VX/PASCAL is fully integrated with VX/RT which will enable your VMS Pascal to execute on Linux/Windows exactly the same as it did on VMS / OpenVMS.

VX/PASCAL is the only translator that can guarantee this.

Take a simple example of "PRESENT"; this relies on the capability of the VMS stack which keeps a count of the number of items passed on the stack (which seems like a really really good idea )is there a 5th argument - simple to answer on VMS / OpenVMS [ if 5 > va_count then not(present)]. Unfortunately, linux & Linux does not keep a count of the number of arguments passed to a function so: if 5 > va_count results in the answer "blue bananas"or more likely "stack violation, core dump or 92333 (basically any random integer).

VX/PASCAL due to the 35 years of writing Microsoft, PDP11, VMS language translators was written to specifically handle problems like this.

We are aware of some organizations taking 3 years to convert 3M lines of VMS PASCAL to C++ - and not even getting it working. 3M lines of VS PASCAL should be converted to C++ in < 6 months and after the initial "break/fix" cycle, all 3 million lines of pascal should translate / compile / link and run with no human contact in 30 minutes.

The first stage (wh9ch can be omitted) is for all of your PASCAL code to be translated and compiled & linked on VMS / OpenVMS and each executable tested.

The process outlined above is still followed and and work on the translator is continued until all of your Pascal code transpiles to C++, links and runs in exactly the same way as Pascal on VMS / OpenVMS.

Once VX/PASCAL has been proven to translate and compile all of your Pascal source code, straight through without ANY HAND MODIFICATION then it is ready for continuous Integration.

This effectively means: Continue to develop in VMS PASCAL, Test; then move code to Linux; Translate; Compile; Link and Test on Linux (or on VMS in C++) the results will always be identical.

Zero code freeze, means that your C++ on VMS / OpenVMS or C++ on Linux will always be current with your latest VMS Pascal released product. As continuous Integration means that your current release is Transpiled (Translate/Compile) in C++ in minutes (100% at this time). No manual changes; therefore no code freeze.

32 Vs 64 Bit

VMS PASCAL is inherently a 32 bit product with 64 bit extensions. The natural place that VMS PASCAL and (obviously) its translated C++ wants to live in a 32 bit address space; The base INTEGER size being 32 bit and the "encouragement" to put POINTERS into INTEGER (32 bit) address spaces would lend itself to a natural 32 bit C++ translation.

VX/PASCAL has been enhanced to follow the places where pointers are put into 32 bit integer spaces and expand the integer to 64 bits. VX/Pascal will expand a 32 bit integer in a structure to 64 bit's and will notify you if the structure is being overlaid or used in such a way as to make the increased size a problem. It makes sense that one would not store the address of a data item in a structure that will be written to a file and then retrieved (as the address will change the exception being if the structure is in a PSECT.

VX/PASCAL represents the pinnacle of automated language translation. VX/PASCAL is actually the second version of a VMS PASCAL to C/C++ translator. in 2001 Sector7 migrated the data network control and provisioning system for "Australia" or at least the 90% of it maintained by telstra. C++ was not in common use, and the code generated was pure C.

Although it "worked" the generated code was by all definitions "ugly" and definitely not maintainable, however, as even V1 of VX/PASCAL was 99.99% automated the PASCAL could be translated and compiled without manual intervention.

V2 of VX/PASCAL brought together 30 years of translator technology experience. We realized that with some "clever" C++ the emitted C++ code could look almost identical to the PASCAL and thus maintenance in C++ would be simple, no real knowledge of C++ would be needed (but clearly would be a huge advantage) to maintain and debug the emitted code.

One of our clients, was graded by an external agency on the readability and maintainability of their code, in a truly amazing turn of events, our generated C++ scored better than the original VMS PASCAL. The emitted code is BEAUTIFUL, I'm not sure that if one is an expert in VMS PASCAL the emitted code can be truly be said to be "better" but, when one takes into account the diminishing PASCAL skills and the begin/end ";" semantics, the "{" and "}" is definitely a huge improvement.

Part of the beauty of the V2 VX/PASCAL is the string handling.

Take A := Me + "You" + Them;

if one looks at string handling needed for a plain C translation we are faced with a number of issues. the literal "You" cannot simply be passed to a generalized string handling function due to the VMS PASCAL variable length string descriptor (Class_VS). A function to convert "You" to a descriptor item capable of being handled by STR$CONCAT or STR$COPY (or the higher functions that call them) is required.

VxStrCpy(&A, VxStrCat(&Me, VxStrcat(VxStrTmp("You"), &Them)));

[VxStrCat clearly returns a temporary descriptor which has to be kept track of and deallocated at the exit of the routine].

Now this can be made a little prettier by using a "printf" like pre-formatter (or even a STR$CONCAT style function but with a null termination due to Linux stack differences).

VxStrCpy(&A, "sls", &Me, "You", &Them);

This is obviously an improvement, but, still not "Pretty", in addition, string concatenation in a function call still requires a VxStrCat function.

With C++ the entire "mess" gets to be cleaned up.

Pascal: A := Me + "You" + Them;
C++ : A = Me + "You" + Them;

This technique is applied throughout VX/Pascal for the "sweetest" translation to C++ that is possible.

VX/PASCAL supports all RMS operations from VMS PASCAL. When used on Linux/Windows with VX/RT and VX/RMS, you program will work in the identical manner. All RMS file organizations are supported INDEXED, RELATIVE, SEQUENTIAL and BLOCK, and all record formats are supported: FIXED and VARIABLE; and all access modes: KEYED, SEQUENTIAL, BY RFA.

On Linux/Windows Keyed files have slightly different I/O timings, we believe that our VX/RMS actually provides faster I/O where it is needed as opposed to VMS / OpenVMS. VMS / OpenVMS RMS does not balance its internal tree structure until a reorganize is performed. VX/RMS ALWAYS keeps the b+ tree balanced. As such, ADD's and DELETES's are slight;y slower, but READ/UPDATE significantly faster (as the tree is always accessible in N-1 access operations.

See VX/RMS

VX/Pascal has over 500 user configurable optons.

VMS API Function Classes

VMS Include and Inherit file naming

VMS Logical translation tables

VMS System Inhertance (STARLET .PEN's)

VMS Inheritance PreLoads

VMS Alignment and PSECT's

VMS Zero initializers

VMS "Truncate" emitted C++

VMS CDD Top

VMS POSIX error code abstraction

(yup - VMS and Linux have different numeric values for the same symbolic E_XXXXX error code - go figure)

PASCAL to C++ Variable naming conventions

PASCAL to C++ datatype's (INTEGER -> int_t)

PASCAL to C++ Array Naming and initialaztion

Pascal to C++ verb naming (Writeln etc)

PASCAL to C++ function naming (ABS etc)

PASCAL to C++ variable naming avoidance

PASCAL to C++ Function naming avoidance

Code Styling options (Line breaks)

Code formatitng opions (Braces, single / multi line etc)

Comment style handling

See Full List

System Service API's Prototypes

Templates and Item Lists

Datetime, String Logic