Confining myself to the technical front...
I suggest you begin by determining the environment in which the application runs. "Mainframe" could mean a couple of different things, given the application's age it could be CICS or IMS. It's also possible the original authors wrote their own started task.
Depending on where the application runs, it will likely make use of APIs for that environment, CICS now uses an interface markedly different from its early days, I cannot speak for IMS. If the application is its own started task, then it may very well have its own internal API - I spend some seven years supporting such a beast, written in the same era.
Something else to consider, given the age of the application, is that the Assembler with which you wish to integrate C++ predates the existence of Language Environment (LE). As such, unless the Assembler has been updated to be LE-conforming, you will have some difficulty as C and C++ are LE-compliant and require their callers and callees to also conform.
Another point for consideration, if this application is running on a moribund mainframe, you may be looking at trying to integrate with an application that runs on unsupported hardware and software. This would be not unlike trying to integrate with an application written in 1989 that runs on DOS 4.01 on its original hardware.
Digging from http://www.befria.nu/elias/pi/binpi.html to get the binary value of pi (so that it was easier to convert into bytes rather than trying to use decimal digits) and then running it through ent I get the following for an analysis of the random distribution of the bytes:
Entropy = 7.954093 bits per byte.
Optimum compression would reduce the size of this 4096 byte file by 0
percent.
Chi square distribution for 4096 samples is 253.00, and randomly would
exceed this value 52.36 percent of the times.
Arithmetic mean value of data bytes is 126.6736 (127.5 = random).
Monte Carlo value for Pi is 3.120234604 (error 0.68 percent).
Serial
correlation coefficient is 0.028195 (totally uncorrelated = 0.0).
So yes, using pi for random data would give you fairly random data... realizing that it is well known random data.
From a comment above...
Depending on what you are doing, but I think you can use the decimals
of the square root of any prime number as a random number generator.
These should at least have evenly distributed digits. – Paxinum
So, I computed the square root of 2 in binary to undetake the same set of problems. Using Wolfram's Iteration I wrote a simple perl script
#!/usr/bin/perl
use strict;
use Math::BigInt;
my $u = Math::BigInt->new("2");
my $v = Math::BigInt->new("0");
my $i = 0;
while(1) {
my $unew;
my $vnew;
if($u->bcmp($v) != 1) { # $u <= $v
$unew = $u->bmul(4);
$vnew = $v->bmul(2);
} else {
$unew = ($u->bsub($v)->bsub(1))->bmul(4);
$vnew = ($v->badd(2))->bmul(2);
}
$v = $vnew;
$u = $unew;
#print $i," ",$v,"\n";
if($i++ > 10000) { last; }
}
open (BITS,"> bits.txt");
print BITS $v->as_bin();
close(BITS);
Running this for the first 10 matched A095804 so I was confident I had the sequence. The value vn as when written in binary with the binary point placed after the first digit gives an approximation of the square root of 2.
Using ent against this binary data produces:
Entropy = 7.840501 bits per byte.
Optimum compression would reduce the size
of this 1251 byte file by 1 percent.
Chi square distribution for 1251 samples is 277.84, and randomly
would exceed this value 15.58 percent of the times.
Arithmetic mean value of data bytes is 130.0616 (127.5 = random).
Monte Carlo value for Pi is 3.153846154 (error 0.39 percent).
Serial correlation coefficient is -0.045767 (totally uncorrelated = 0.0).
Best Answer
The usual reason for writing numbers, in code, in other than base 10, is because you're bit-twiddling.
To pick an example in C (because if C is good for anything, it's good for bit-twiddling), say some low-level format encodes a 2-bit and a 6-bit number in a byte:
xx yyyyyy
:produces
In such a circumstance, writing the constants in hex is less confusing than writing them in decimal, because one hex digit corresponds neatly to four bits (half a byte; one 'nibble'), and two to one byte: the number
0x3f
has all bits set in the low nibble, and two bits set in the high nibble.You could also write that second line in octal:
Here, each digit corresponds to a block of three bits. Some people find that easier to think with, though I think it's fairly rare these days.