RANMAR is a good quality random number generator, but better (and slower) ones are known, eg CERNLIB's RANLUX (V115). RANMAR was chosen for it's speed and simplicity of use.
By default, SGV always starts with the same seed. Therefore, exactly the same events will be produced by two consecutive runs of SGV, if no run-conditions were changed. However, with the steering-card DSEED one can set the starting seed of the sequence. Any number form 1 to 900 000 000 will produce an unique sequence.
If the seed is set to 0, the starting seed will be calculated from
the wall-clock, changing every 10 ms. The cycle is 
, so
approximatively every 12 days, the same number comes up, but only
during 10 ms. We estimate that it is sufficiently unlikely that
two jobs would start with a separation of exactly 
ms, so
that this is acceptable. If not, set seeds guaranteed to be unique
by hand. Note that one should avoid to send a number of batch-jobs at
the same time: there is a risk that more than one would start in the
same 10 ms interval. Use the /AFTER qualifier of the VMS SUBMIT
command or similar constructs on UNIX, with different times for
different jobs (a few seconds of difference would do).
3.3
The event-generator random numbers are also initialised in the same way. However, this is so only if the event generator uses the Lund random-number generator (the function RLU). Clearly, JETSET and PYTHIA uses this routine, but also eg. SUSYGEN. The steering card to set the seed is GSEED. The sequences of the event-generator and the detector simulation are independent.
Note that it is not assured that setting DSEED to 0, and GSEED different from 0, will yield the same true generated events with different seen values if the run is repeated. Even though this settings means that the random-number sequence for the generated events is the same between runs, it is possible that the sequence gets out of synchronization due to a different detector response, ie. the same random numbers are generated, but they might be used differently.