PM35776: A sticky project emits a faulty error on the foreground log.

APAR status

• Closed as program error.

Error description

• st execute failed: [Microsoft][SQL Native Client][SQL
  Server]String or  binary data would be truncated. (SQL-22001)
  
  [Microsoft][SQL Native Client][SQL Server]The statement has been
  terminated. (SQL-01000)(DBD: st_execute/SQLExecute err=-1) at
  /PerlApp/BuildForge/DB/Handle.pm line 308, ?$sock? line 67.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Symptom:
  A sticky project emits a faulty error on the foreground log.
  
  The error is somewhat different for different DBs, but has
  the same root cause and same line numbers. On MySQL it
  appears as:
  5/5/2011 11:20:37 AM: Event: 7864: CRRBF1384I: Services
  queued event 'job.started' [WAITING].
  Use of uninitialized value in hash element at
  C:/bf_src/rtc/2011A_engine/engine/BuildForge/Log.pm line
  260.
  Use of uninitialized value in string eq at
  C:/bf_src/rtc/2011A_engine/engine/BuildForge/Log.pm line
  281.
  Use of uninitialized value in string eq at
  C:/bf_src/rtc/2011A_engine/engine/BuildForge/Log.pm line
  281.
  DBD::mysql::st execute failed: Column 'bf_msgkey' cannot be
  null at
  C:/bf_src/rtc/2011A_engine/engine/BuildForge/DB/Handle.pm
  line 312.
  5/5/2011 11:20:38 AM: Step: 7476: CRRBF1595I: Job [BUILD_82]
  Step [echo COPY 1] starting command part 1 of 2.
  5/5/2011 11:20:39 AM: Step: 7476: CRRBF1597I: Job [BUILD_82]
  Step [echo COPY 1] completed command part 1 of 2 [P].
  5/5/2011 11:20:40 AM: Step: 7476: CRRBF1595I: Job [BUILD_82]
  Step [echo COPY 1] starting command part 2 of 2.
  5/5/2011 11:20:38 AM Database: 7864: CRRBFEEEEE:
  DBD::mysql::st execute failed: Column 'bf_msgkey' cannot be
  null at
  C:/bf_src/rtc/2011A_engine/engine/BuildForge/DB/Handle.pm
  line 312.
  
  5/5/2011 11:20:40 AM Database: 7864: CRRBF0551I: StackTrace
  from Process id [7864] called from [
     BuildForge::Log::DB(./BuildForge/Log/DB.pm:55)
     BuildForge::Log(./BuildForge/Log.pm:239)
     BuildForge::Artifact(./BuildForge/Artifact.pm:82)
  
  BuildForge::Artifact::Selector(./BuildForge/Artifact/Selecto
  r.pm:219)
  
  BuildForge::Artifact::Project(./BuildForge/Artifact/Project.
  pm:669)
  
  BuildForge::Artifact::Build(./BuildForge/Artifact/Build.pm:2
  97)
     main(.bfproject.pl:52)
  ]
  5/5/2011 11:20:40 AM Database: 7864: CRRBF0556I: Trying to
  call [execute] on a non-existant database handle
  Use of uninitialized value in hash element at
  C:/bf_src/rtc/2011A_engine/engine/BuildForge/Dictionary/Choo
  ser.pm line 75.
  Use of uninitialized value in hash element at
  C:/bf_src/rtc/2011A_engine/engine/BuildForge/Dictionary/Choo
  ser.pm line 77.
  Use of uninitialized value in hash element at
  C:/bf_src/rtc/2011A_engine/engine/BuildForge/Dictionary/Choo
  ser.pm line 78.
  5/5/2011 11:20:40 AM: ARRAY(0x45a5d30): 7864: CRRBFEEEEE: %s
  5/5/2011 11:20:41 AM: Build: 7864: CRRBF0468I: Build
  [BUILD_83] started.
  
  It always happens right after the job.started message. Note:
  This does not occur for non-sticky projects.
  
  Cause:
  The cause is two part, and both conditions must be true:
  -The user running the build does not have access to the
  server auth for the server picked to be the sticky server
  -The project is a sticky project
  
  The sticky server is assigned at the beginning of a project
  run prior to step scope. The message being emitted is
  because this is supposed to be a step log message. Since we
  do not yet have step scope for the build the error is
  emitted a change was made to check for step scope. If it
  doesn't exist then a message is instead placed into the log
  file, or foreground on Windows.
  

Problem conclusion

• There is a permission entitled Execute Inaccessible Server
  Auths which today has no value. Currently if a user can
  access a server then it is assumed they can access the
  server auth as well for a build. As a result there is no
  permission checking done against a server auth. It was
  decided to leave the functionality as it stands as
  correcting the issue would potentially break a large number
  of builds without purpose. Since the user has access to the
  project, step and server assuming access to the server auth
  is allowed for the purposes of running a build. Please note
  the lack of enforcement on this permission does not allow a
  user to edit a server auth for which they have no access -
  just run them if they happen to be associated with a server
  definition they _do_ have access to.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  BUILD FORGE EE

• Fixed component ID

  5724S2701

Applicable component levels

• R712 PSN

     UP