Tcl NetConfig write library

Clovertech Forums Cloverleaf Tcl NetConfig write library

  • Creator
    Topic
  • #122362
    Jeff Dawson
    Participant

      I’ve used $HCIROOT/tcl/lib/cloverleaf/nci.tlib to easily parse NetConfig scripts using different functions after netcfgLoad then netcfgGetConnList and netcfgGetProcList.  I came across an older clovertech thread where Rob Abbott stated these are behind the scenes scripts but Infor added them to documentation starting with CIS 6.2.61.  I’ve searched through CIS 2022’s online help and found no mention of this library or its functions. They are great ways to retrieve various NetConfig data but I’ve not found any functions that allow you to write back to the NetConfig, like a NetCfgsave or NetCfgWrite function.

      These types of scripts are never ran during regular business hours incase an analyst may be making changes in a site’s NetConfig.  Primary purpose is to make global identified NetConfig changes accurately and not have to rely on our team to manually go through 100 cloverleaf sites, 100’s of threads, and possibly typo or miss a setting.  Example enabling an Outbound SMAT file for large set of threads.  In past scripts I’ve had to parse the NetConfig line by line to find start/end blocks to update what is needed per a specific thread type.  These scripts backup the original NetConfig and write the updated NetConfig out to a new file that’s named differently, NetConfig.updated.datetimestamp that can be diff’d from command line or use a file compare utility before ever committing the change.

      I’ve got a question out to Infor but I was really hoping some type of library possibly exists or its something that goes on the list to develop when time permits.  Just to re-state this isn’t a script that would be used for day to day work rather large engine changes, like updating internal thread communication client/server threads from mllp2 to mllp having the server threads using hcitps_simpleack.

      # Set site environment and load NetConfig
      set env(HCISITE) $siteName
      if {[catch {netcfgLoad $netconfigFile} err]} {
          puts “Skipping site $siteName: $err”
          continue
      }
      set threadList [lsort [netcfgGetConnList]]
      foreach thread $threadList {
            set data [netcfgGetConnData $thread]
      keylget data PROTOCOL.TYPE protocol
      keylget data PROTOCOL.HOST host
      keylget data PROTOCOL.PORT port
      keylget data PROTOCOL.PDLTYPE pdlType
      keylget data PROTOCOL.MLP_MODE mlpMode
      }
    Viewing 5 reply threads
    • Author
      Replies
      • #122363
        Jason Russell
        Participant

          Documentation is under Services User > Reference Guide > Engine NetConfig interface extension or you can search for NCI. I’ve been working on a listing script since it only parses partial data, with searching functionality so I can narrow down to specific threads within a site. It’s a bit more tailored to us specifically, but it is useful. However, the netconfig script doesn’t get super granular. I was actually writing my own script at one point that did what this does in a similar fashion when I stumbled across this.

          I’ll drop my script, but there’s some stuff specific to how we operate and how our environment was set up that wouldn’t be applicable to others. Let me grab the file and upload it.

        • #122364
          Jason Russell
          Participant

            This is definitely a work in progress; it functions as it sits (for us at least). I didn’t use the keylget pairs at the time, not sure if I will or not considering how oddly some of the setup is. This distinguishes from TCP/IP, File based (ftp, fileset local, etc). I’m working on adding a switch that adds a ‘connected’ column where it will parse netstat data to show if a thread is connected.

            A lot of the script relies on our naming schemes to function properly, and I haven’t pushed some of script into procs yet. As I said, work in progress.

            Attachments:
            You must be logged in to view attached files.
          • #122366
            Jim Kosloskey
            Participant

              Basically in more current releases, the NCI is intended for Integration Engineers to query (query only) instead of tclib stuff.

              I have started constructing a Tcl proc to exploit NCI hopefully to its current capability. Certain data retrieval requires understanding the lists, list of lists, list of keyed lists, and lists inside keyed lists. As I discover those, I am producing a result of my findings which I hope to make available to the group.

              I am concerned the reliance on still understanding the underlying structure may present an opportunity for Cloverleaf to change that structure, so the engine still works but direct retrieval (after the NCI call) nay break.

              email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

            • #122374
              Jeff Dawson
              Participant

                Thanks Jason for the location where that library is called out in the online help, I made the mistake to search by the actual function name, where it looks like NCI pointed me in the right direction.  Slims pickings regarding the info in the document and even the correct usage if someone new wanted to try and get this working.  Its another item we always bring up with our Infor Site Customer Rep, can Infor invest in providing documentation that is update to date and accurate?  Love the Clovertech community and ideas/questions presented here but the price tag that comes along with Cloverleaf the expectation would be better.  This confirms there’s no write utility and will continue with what I currently do.

              • #122375
                Jason Russell
                Participant

                  To be fair, their documentation matches TCL’s documentation which is not very good either. A good technical writer would help tremendously.

                • #122376
                  Jim Kosloskey
                  Participant

                    FWIW attached are my notes guiding me drilling down into the Xlate Info from NCI. Very crude notes at this point but might be useful. Eventually, my intent is to produce some more polished level of documentation as well as a hopefully useful proc for extracting NetConfig Info.

                    As you will see (and this is indicated in CL Help) the NCI only takes you so far and then you need to understand the structure of the various lists and keyed lists. There is no documentation for those and I would not expect to ever see documentation distributed. That would make reverse engineering by competitors less painful.

                    The caution I see is what if we code to those structures and in a future release the structure is altered. How will we be protected or won’t we? Another Challenge for INFOR.

                    Attachments:
                    You must be logged in to view attached files.

                    email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

                Viewing 5 reply threads
                • You must be logged in to reply to this topic.