Re: Gather service

[White, G. <gr...@sl...>]

Hi Marty, I'm afraid I'm puzzled about your answer, on a couple of fronts. 

First, you said
> multiValue was also moved and renamed dbGroup.

and you commented:
> 

>> 2. I'd like to start using it soon, to make middleware that makes monitoring
>> 100s of magnets and klystrons efficient, for fast modelling.
> 
> multiValue could have been used for this puropose.
> If dbGroup has same functionality then it should be the basis.

Now, the application I need must gather data from many IOC, for instance it
would get magnet data from all IOCs controlling magnets. Surely then it
would not reside inside an IOC, it would reside in a host server, or even
in a client on a host - or when we had them, a pvIOC? A gather service 
running in a pvIOC (not IOC) would have been suitable, except that pvIOC is now 
defunct.  

> 
> This can NOT be done by pvManager.
> Even if some pvManager functionality is ported to C++ and made to run on 
> a V3 IOC it would need to implement  multiValue type functionality .

But there is no requirement for the gathering to run on an IOC. To get, for
instance, the (EM) field value of all quadrupoles say, you need something
that specifically runs at a higher level than an IOC.  

So, I think my question is, can gatherV3Data (or multValue) be extracted from pvIOC and
made standalone? or put in pvDatabase?

Cheers
Greg

On May 24, 2014, at 7:05 AM, Marty Kraimer <mrk...@co...> wrote:

> On 05/23/2014 07:59 PM, White, Greg wrote:
>> Hi Marty,
>> 
>> What's the status of the Gather Service?
> 
> masar implements gatherV3Data.
> It has the definition:
> 
> Gather an array of V3 scalar double or string values. The complete set 
> of data is presented as an NTTable. The NTTable has the optional fields 
> alarm and timeStamp. The class definition is:
> class GatherV3Data {
> public:
>     GatherV3Data(String channelNames[],int numberChannels);
>     bool connect(double timeOut);
>     void disconnect();
>     bool get();
>     bool put();
>     String getMessage();
>     PVStructure::shared_pointer getNTTable();
>     PVIntArray *getIntArrray();
>     PVDoubleArray *getDoubleValue();
>     PVStringArray *getStringValue();
>     PVLongArray *getSecondsPastEpoch();
>     PVIntArray *getNanoSeconds();
>     PVIntArray *getTimeStampTag();
>     PVIntArray *getAlarmSeverity();
>     PVIntArray *getAlarmStatus();
>     PVStringArray *getAlarmMessage();
>     PVIntArray *getDBRType();
>     PVBooleanArray *getIsConnected();
>     PVStringArray  *getChannelName();
> };
> 
> 
> See  the Masar documentation for details.
> 
> pvIOCCPP implemented multiValue which as I recall implemented a somewhat 
> more general version  of what gatherV3Data does.
> pvIOCCPP is now extinct.
> Project pvaSrv was created by Ralph.
> The pva ChannelProvider for accessing iocCore records was moved from 
> pvIOCCPP and renamed from V3Channel to  dbPv.
> multiValue was also moved and renamed dbGroup.
> 
> 
> I do not know the current status of dbGroup.
> Perhaps Ralph can give the current status?
> 
> 
> 
> 
>> 
>> You mentioned on Tuesday that with the development of dbGrp, you
>> weren't sure Gather was needed any longer. But they're really different
>> aren't they? dbGrp would be used to package record fields from a single IOC,
> 
> multiValue could get data from any provider (as I recall on each 
> individual value not on the entire set)
> If the provider is pvaSrv then it is getting data directly from the 
> ioccore records.
> NOTE: I Think this is just what You want.
> 
> Again I do not know the status of dbGroup.
> 
> 
>> gather is about getting data from many IOCs, and cacheing it to decouple
>> the client from the IOC.
>> I ask about Gather's status for a couple of reasons:
>> 
>> 1. Is it a starting point for a gateway?
> 
> Not clear to me that it is a good starting point.
> A gateway for pva should fully support pvData.
> gather only supports limited normative types.
> 
>> 
>> 2. I'd like to start using it soon, to make middleware that makes monitoring
>> 100s of magnets and klystrons efficient, for fast modelling.
> 
> multiValue could have been used for this puropose.
> If dbGroup has same functionality then it should be the basis.
> 
> Again I do not know the status of dbGroup.
> 
> 
>> 
>> 3. To clarify what are the differential decision criteria for
>> pvManager as opposed to Gather? When would one use one and not the other?
> 
> It sounds like the killer application is to collect data from a a set of 
> ioccore reords via a single channel instead of a channel for each record.
> multiValue (now dbGroup) can be used for this purpose.
> 
> This can NOT be done by pvManager.
> Even if some pvManager functionality is ported to C++ and made to run on 
> a V3 IOC it would need to implement  multiValue type functionality .
> 
> 
> Marty
>> Cheers
>> Greg
>> 
>> 
>> 
>