PVA link can't be "nested"

[mdavidsaver]

A PVA link in a "calc" link fails with DBLINK* corrupt on being unable to locate the associated record field in order to determine a native field type for the lset.

https://github.com/epics-base/pva2pva/blob/3b9990e3650fca2673eebfb83645193ac0e5297d/pdbApp/pvalink_lset.cpp#L28-L32

record(ai, "MTEST-JSON:A1") {
    field(VAL, 1)
    field(PINI, 1)
}

record(ai, "MTEST-JSON:inp_json_calc") {
    field(INP,
        {
            "calc": {
                "expr": "A|B|C",
                "args": [
                    {
                        "const": 0
                    },
                    0,
                    {
                        "pva": {
                            "pv": "MTEST-JSON:A1",
                            "proc": "CP"
                        }
                    }
                ]
            }
        }
    )
}

fyi. https://bugs.launchpad.net/epics-base/+bug/2031563

[mdavidsaver]

This logic is failing as the calc link type has its own link "fields". It is not immediately clear to me how a native field type could be inferred.

At present, the only use for this type is to identify DBF_INLINK.

https://github.com/epics-base/pva2pva/blob/3b9990e3650fca2673eebfb83645193ac0e5297d/pdbApp/pvalink_channel.cpp#L387-L395

@anjohnson I would appreciate your thoughts on this situation.

[anjohnson]

Could the pvalink not wait to decide whether to enable monitors through the PVA channel until the first call to either pvaGetValue() or pvaPutValue()? If it waits it will also discover what data type and how many elements the caller is looking for (e.g. has the user pointed an ai or subroutine input link at a large array so they only want the value of the first element).

Oh, and just because the ultimate record link field (INP above) is an input, that doesn't mean that the pvalink will always be used as an input, it might be configured for the calc link's out field — I think that's allowed, so it can't really know until it gets called.