[OpenSTA-devel] [ opensta-Bugs-1468855 ] 'LOAD RESPONSE_INFO' fails if performed in a different scope

[SourceForge.net <no...@so...>]

Bugs item #1468855, was opened at 2006-04-11 14:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1468855&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Arrowwood (jarrowwx)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'LOAD RESPONSE_INFO' fails if performed in a different scope

Initial Comment:
This is similar to issues 433574 and 645735, and in
fact is explicitly mentioned in 433574, but is being
lost in the confusion because there are multiple bugs
being reported at once.  So, to try and help this issue
get some attention, here it is in a separate bug.

Regardless of whether you use PRIMARY GET URI or GET
URI or PRIMARY POST URI, the following applies:

If you perform the HTTP request in a subroutine, and
then try to LOAD Response_Info after the subroutine
finishes, or if you attempt to call a subroutine in
order to perform the LOAD, either way, it errors with
the familiar:

HTTPRESPONSE: No data available for connection id(1)
TScript::run: ERROR in TOF execution; resuming...

This appears to be an issue whether the connection ID
is a constant, an integer variable, or an expression. 
This is why I chose to raise a separate bug, since the
other two seem to be focused on the use of a variable
for the connection id.

The use of SYNCHRONIZE REQUESTS seems to be of no
value, whether performed in the calling subroutine, or
the called subroutine.

The wrapping of the call in an IF block also likewise
does not help.

It would seem to be a scope issue.  It seems like once
the scope of execution changes, the connection id is no
longer valid.

Here's hoping that helps narrow down the source of the
problem.  And if this could be fixed, it would enable
scripts to be much better organized and maintainable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1468855&group_id=10857