Problem with ENV in upoc

Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Problem with ENV in upoc

  • Creator
    Topic
  • #53414
    Gary Atkinson
    Participant

      Hi all-

      I have UPOC that runs on a schedule.  It calls ENV to set up the path to a directory.  For some odd reason sometimes the engine says it can’t find the variable  ðŸ˜ˆ Anyone else seen this and if so how did they fix it??

      here is the error:

      Code:


      proc    = ‘tpsCrispDSQuery’
             args    = ”
             result  = ‘can’t read “env(HCIROOT)”: no such variable’
             errorInfo: ‘
      can’t read “env(HCIROOT)”: no such variable
         while executing
      “set sqlitePath “$env(HCIROOT)/sqlite””

      The messages go to the error database.  I resend them and no error occurs  ðŸ˜•

    Viewing 10 reply threads
    • Author
      Replies
      • #77609
        Jim Rawls
        Participant

          Hi Gary,

          Did you declare env as global?  That’s the only time I’ve seen that error.

        • #77610
          Gary Atkinson
          Participant

            yes I declared env as global at top of proc.  It’s very strange it only happens here and there.  When I resend the messages they don’t error.  I tried declaring the path in start mode, but that does not work.

          • #77611
            David Barr
            Participant

              I assume that this is a regular UPOC interface running in an hciengine process and not calling any subprocesses. If so, this is a strange error. My only idea is that you might have a separate TPS proc in a different thread in the same process that is updating this environment variable.

              “env” is a special variable in that it is tied to the process environmental variables, and unlike other variables making a change to this can affect other threads even though they have separate interpreters.

            • #77612
              Gary Atkinson
              Participant

                Yes its a “regular” UPOC (if there is thing :)) in an hciengine process.  The process is only used for sqlite processing.  There is no other code changing env in the process.  It’s really weird becuase it only happens sometimes and when I replay the errored messages the error does not occur.  One thing I tried is to declare the variable path in start mode, but that does not work, which I would think it would.  I hate to have to hardcode in the hciroot path, becuase I will never remember when we upgrade  ðŸ˜†

              • #77613
                Elisha Gould
                Participant

                  Do you have any other global variables in the same function?

                  I’ve had issues if I have multiple global calls, global should be called with all variables on the same line.

                  ie

                  global env

                  global HciConnName

                  will not work as you want it to. The correct way to call global is:

                  global env HciConnName

                • #77614
                  Gary Atkinson
                  Participant

                    I did have HciConnName on a different, but even after moving to same line it didn’t help.  added using evn in start up didnt help either.  Here is code snippet of what I am doing:

                    Code:


                    [ – – – – – – LOG MESSAGE FROM:
                    [LOG NOTE: TEST/tpsCrispDSQuery Fri Dec 14 07:47:17 EST 2012] WARNING: Failed to set ‘sqlitePath’ in START mode


                    Code:


                    switch -exact — $mode {
                    start {

                    package require libtclsqlite3 1.0
                    set sqlitePath “$env(HCIROOT)/sqlite”
                    }

                    run {
                    if {![info exists sqlitePath]} {
                    WriteLog $module “WARNING: Failed to set ‘sqlitePath’ in START mode”
                    set sqlitePath “$env(HCIROOT)/sqlite”
                    }

                  • #77615
                    Charlie Bursell
                    Participant

                      Your problem is that the variable sqlitePath should also be declared as global if you use it like this.  It does not make any difference if you declare one or several variable on the same line.  You can use the global statement as many times as needed.

                      You can access a global varaible without declaring it as global as long as you remember to address it in the global namespace (::).  For example in the start part of your proc:

                              package require libtclsqlite3 1.0

                              set ::sqlitePath “$::env(HCIROOT)/sqlite”

                      And then in the run portion:

                              if {![info exists ::sqlitePath]} {

                                 WriteLog $module “WARNING: Failed to set ‘sqlitePath’ in START mode”

                                 set sqlitePath “$::env(HCIROOT)/sqlite”

                              }

                      No global declarations are reguired.  However, why use the env array at all?  Why not simply use one of the suppled globals, HciRoot?

                               $::HciRoot is the same as $::env(HCIROOT)

                    • #77616
                      Gary Atkinson
                      Participant

                        Thanks Charlie that worked!!

                      • #77617
                        Gary Atkinson
                        Participant

                          Charlie-

                          Question for ya.  By coding in this manner if sqlitePath is also used another thread in same process the value will be changed correct?  In my situation this ok, but in another situation this would be bad.  

                          I still wonder if this is not a bug inside CL  ðŸ˜›

                          Gary

                        • #77618
                          Charlie Bursell
                          Participant

                            Not in another thread.  Another thread would have a different Tcl interperter.  However you can bump heads with globals with another proc runnning in the same thread.  That is why I prefer to use namespaces

                          • #77619
                            Elisha Gould
                            Participant

                              If you are going to have this in multiple threads in the same process the way we get around this is to use the HciConnName global as part of the namespace name.

                              ie

                              namespace eval TclScriptName$HciConnName {

                                 variable sqlitePath PATH

                              }

                              To grab the data from a namespace, you need to declare HciConnName as a global, and access using:

                              set myPath [set TclScriptName${HciConnName}::sqlitePath]

                              To set the value:

                              set TclScriptName${HciConnName}::sqlitePath $myPath

                          Viewing 10 reply threads
                          • The forum ‘Cloverleaf’ is closed to new topics and replies.