> Stefan, I don't think we're talking 'mis-use' - rather different subdetectors being commisisoned
> at different locations, on an uncorrelated schedule, using independent run control (RC) instances.
> At this point in time, we can't use a common RC instance.
> The collected data, however, are written back into a common storage, and we need to avoid two
> subdetectors using the same run number. As all RC instances can connect to the same database and request a
> run number from there, an external DB serving run numbers to multiple clients looks as a reasonable solution,
> which provides unique run numbers for everyone. Of course, the run number gets incremented (although on the DB
> server side), and of course different susbystems are assigned different subsystem types.
>
> So, in essense, it is about _where_ the run number is incremented - the RC vs the DB.
> If there were a good strategy to implement a DB-based solution that w/o violating
> first principles of Midas:), I'd be happy to contribute. It looks like a legitimate use case.
Ok, maybe attitude comes from the fact that I never used such a scheme in the last 30 years with midas.
If you go in this direction, there is an alternative to what Ben wrote: Use the sequencer to start a run.
The sequencer script can obtain a new run number from a central instance (e.g. by calling a shell script
like 'curl ...' to obtain the new run number, then put it into /Runinfo/Run number as Ben wrote. This has
the advantage that the run is _started_ already with the correct number, so the history system is fine.
The script can then wait for n events, then stop the run etc. A sequencer script will also be necessary if
you want to configure your electronics (see next answer...)
Stefan |