[Yuzurihara, YamaT]

Lockloss guardian stopped due to the user code error on Saturday evening and lockloss information hadn't updated until this morning.
We found this issue caused by too long string was put by 'ezca' because many labels were tagged for one lockloss event.
So we added a treatment of the length of the string and reproduced lockloss list during the absence of Lockloss guardian.

-----
Memo:
String type of EPICS records can treat 40 characters (excluding '\0' as a terminating character). When we uses a string more than 40 characters via 'caput', behind of 41th characters are silently ignored. On the other hand a case of using 'ezca', such an operation is raised as a error.

I'm not sure how did the problematic lockloss occurred on Saturday evening yet. Anyway many labels were tagged to this lockloss event and total characters of labels became longer than 40 characters.

This issue is occurred only for the volatile EPICS record and json archive for the list on the Web is not affected. So we modified the guardian code as 'ezca' puts only the 1st 40-characters of labels to EPICS records. This means that we can see only a part of labels on MEDM screens when so many labels are tagged to one lockloss event. But such a case is very rare and it can be complemented with the list on the Web. In practice, this treatment seems to be enough. If this treatment becomes serious for daily commissioning works, we plan to add new string channels to record the behind of 41th characters of labels.