mdstcl do/method initial call fails

[rzorger]

Affiliation
PPPL

Version(s) Affected
MDSplus version: 7.153.3

Release: stable_release-7-153-3

Platform(s)
Rocky Linux 9.7

Installation Method(s)
mdsplus.org repository

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:
I am seeing another fail on first attempt bug in mdstcl. I am testing the action nodes in our tree and the first attempt to 'do/method' in a mdstcl session always fails. Subsequent attempts work:
mdstcl
TCL> set tree rf
TCL> do/method \RF::FW_H908_02 init
%CAMERR, module SFW_H908_02, bad status = 0

Error executing device method
Error message was: %TDI-E-ABORT, Program requested abort
mdsdcl: --> failed on line 'do/method \RF::FW_H908_02 init'
TCL> do/method \RF::FW_H908_02 init
TCL> do/method \RF::FW_H908_02 init
TCL> do/method \RF::FW_H908_02 init
TCL> q
[root@skylark2 dispatcher]# mdstcl
TCL> set tree rf
TCL> do/method \RF::FW_H908_01 init
%CAMERR, module sfw_h908_01, bad status = 0

Error executing device method
Error message was: %TDI-E-ABORT, Program requested abort
mdsdcl: --> failed on line 'do/method \RF::FW_H908_01 init'
TCL> do/method \RF::FW_H908_01 init
TCL> do/method \RF::FW_H908_01 init
TCL> q

This is like issue #2977

Expected behavior
If this is a bug please fix and release a new stable version

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
I need this to troubleshoot our action nodes and get the shot cycle to work under Rocky 9

[mwinkel-dev]

Hi @rzorger -- I will use a Rocky 9.7 virtual machine later today to investigate this issue. Thanks also for mentioning that it is similar to the closed issue, #2977, as that is likely an important clue.

[mwinkel-dev]

Hi @rzorger -- I am assuming that failing action is associated with the H908 device provided by "MitDevices". If that assumption is incorrect (i.e., if it is instead a device driver that PPPL wrote), let us know.

[mwinkel-dev]

Hi @rzorger -- I now have a Rocky 9.7 (Blue Onyx) VM with MDSplus stable-7-153-3.

This issue will be investigated with two parallel tracks:

• As you suggested, we should make a new stable release.
• In the meantime, I will continue investigating this H908 problem to determine if it is different than Issue 2977.

[mwinkel-dev]

Hi @rzorger -- Does the failure occur with all action nodes? Or just the H908 related actions?

Based on your description, I am assuming the bug is with do /method regardless of which device and action node is invoked.

[mwinkel-dev]

Hi @rzorger,

The %CAMERR, module sfw_h908_01, bad status = 0 error message is probably being generated by the tdi/dev_support/DevCamChk.fun file. Check to see if the failing action node calls DevCamChk(). The comment in the *.fun file indicates that this involves a device that is in a CAMAC chassis.

Also find a non-CAMAC device in your trees and see if do /method your_device init works OK.

Let us know if the do /method problem occurs with all devices or just CAMAC related devices.

[mwinkel-dev]

Hi @rzorger,

Please examine your RF tree's FW_H908_02 device and the associated "init" action node. Post the contents of that action node to this issue.

[joshStillerman]

If the answer is either -

• all CAMAC
• just this module

See if you get the error with CCL talking to the module

[mwinkel-dev]

Hi @rzorger -- CCL probably means "CAMAC Command Language". Here is a link to a manual for the utility. It ships with MDSplus as mdsccl.

https://mdsplus.org/images/ccl.pdf

[mwinkel-dev]

Hi @rzorger -- The current conjecture is that the CamSingle.c and CamMulti.c files are not correctly handling mdsip connection IDs that are zero. (PR #2288 of 19-May-2021 allowed connection IDs to start with zero instead of 1.)

I can create an experimental build of MDSplus with a proposed fix for that issue. However, I do not have access to CAMAC devices to test the fix.

Note that if the above conjecture is correct, then do /method some_device init should only be failing on your various devices that are in CAMAC crates. The do /method should work fine on non-CAMAC devices.

We are also discussing plans for cutting a new stable release.

[rzorger]

All of the .fun files we use that I have found/examined so far are written by PPPL, and are not in the MitDevices folder.

I get the 'module XXXXXXXX, bad status = 0' message the first call on every node I have tested. I have not manually tested all of the action nodes. There are 143 of them and the scripts I have tried crash on this error.

As far as I can tell, all of the INIT and STORE action nodes we have are for CAMAC. If other types are in the trees I would need instructions how to find them.

It looks like all of the INIT and STORE fun files use DevCamChk().

If you want me to try a try an experimental build let me know where I can download it.

[mwinkel-dev]

Hi @rzorger -- Thanks for the information. I hope to have the experimental build available later today. When it is available, I will contact you and arrange to get it to you.

[mwinkel-dev]

Fixes were made to two libraries: libCamShr.so and libRemCamShr.so. Experimental builds of those libraries were tested and proven to fix the problem. Therefore, those fixes will now be submitted as a PR. After that PR is merged, a new "stable" release will be created.