The following information has been logged:
$message"; } // if } // SendNotification ?>
The following are select "discussions" between me and IBM about support with their software. Note that this is very expensive software and very expensive support that is paid yearly by my clients for the purposes of resolving, not kicking down the road, problems. The following is paraphrased from memory and are not guaranteed to be 100% accurate, however one can sure think that they might be able to form an opinion about very expensive, closed source :
On 2/22/2013 9:43 AM, Rational Client Support wrote:
Hi Andrew,
So if you follow the links.. and links in the OSLC manual..
http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=3Dtable;up=3D#Query_CapabilitiesWill lead you to
http://open-services.net/bin/view/Main/OslcCoreSpecification#Query_Capabilities
which leads you to
http://open-services.net/bin/view/Main/OSLCCoreSpecQueryI believe if you look at the "syntax" section on the last link that shows you what is in OSLC. It looks like some of the ones you listed might be codeable using the syntax listed.
Since there are no "or" listed in there, he said that you can use De Morgan's lay to get to an "or"
http://en.wikipedia.org/wiki/De_Morgan%27s_laws
I'm not looking to take a formal class in boolean algebra. AFAICT De Morgan's law requires a not operator which OSLC doesn't support from what I can tell. Otherwise I'd have a solution for IS_NOT_NULL
The IN operator, for example is no substitute for the OR operator in that IN applies only to the subject field (AKA the left hand side) and cannot serve to join two s together as in "if first_name eq 'Andrew' and last_name eq 'DeFaria'). Even SQL does that and it's how old?
I also fail to see why this matters. Users are used to regular boolean expressions as are common in just about every programming language. Even if cra= zy negation and a degree in math could get you an OR operation running this= is insufficient! Users of this should be able to to easily expression common boolean expressions and anything short of that is unacceptable.
The querying capabilities of REST needs to at least match those= of the native API or exceed it.
Hi Andrew,
I spoke with one of our OSLC folks on the CQ and he said that you have= to use SPARQL notations for your queries and OSLC only supports a subset of comparison operators.
He is going to check and verify what is and isn't supported.
Everything less than the operators specified in the Clearquest API manual for the native cqperl incomplete or missing functionality. We are looking for functionally complete software. If it's not complete then this PMR should remain open to represent the missing functionality if nothing else.
What OSLC can do however is to execute an existing CQ query by name or a CQ FTS search string.
We are not looking to do this. We are looking for functionality complete software. Please the missing functionality.
I will get back with you on what he finds in regards to which operators that OSLC supports and the formatting for them.
Anything less than all of the operators listed for the native API is unacceptable.
On 2/26/2013 6:31 AM, Rational Client Support wrote:
Hi Andrew,
While I agree that it is that you cannot execute the same query operators using OSLC that you can in regular CQ, the OSLC guidelines are not set by CQ. It is an open source committee that standardizes the input and output for CM tools so that you can interact with other tools without building coding infrastructure. The options that are are set by the OSLC CM workgroup.
You are free to take a look at the OSLC page and see if you can join this workgroup or offer suggestions to them etc.
Why don't you (i.e. IBM) join the group and offer these very suggestions? Surely I'll carry a lot less weight than IBM. You could approach it simply by saying "We find our customers want the full complement of boolean logical operators unavailable in all OSLC specs to date and that have been in vogue for decades now"... Well, maybe not as colorfully stated, but the point is the spec isn't even functionally complete and it's approaching 3.0! V 1.0 (http://open-services.net/bin/view/Main/CmQuerySyntaxV1) supports only the and operator, has no mention of LIKE or NULL, thereby rendering certain boolean operationsimpossible! (AKA broken).
V 2.0 (http://open-services.net/bin/view/Main/OSLCCoreSpecQuery?sortcol=table;table=up#oslc_where) does not remedy either of these situations. The sole boolean_op is still AND and null is not mentioned at all.
Now I've synthesized the IS NULL op by abusing the IN operator as in "IN ['']" however I'm not sure if that condition is true for both true null values and empty space values. But there is no way to do IS NOT NULL, which was one of the queries I requested assistance with in this PRM. And REST Interface, how do you formulate the query "<field> is not null" describes my attempts to get IS NOT NULL working. Judging by the number of views (1204) it seems clear to me that while I may be the lone spokesman here, a lot of people are interested in this.
The ClearQuest has given you the work arounds for this which would be to have OSLC execute a CQ Query which has the operators that you are looking for rather than having OSLC do the query itself.
This work around is not workable. I do not know beforehand what queries may be made by people calling my subroutine. So unless there's an for me to programmatically create CQ Queries on the fly and be able to execute and subsequently delete them there is no work around that works currently.
Here is the link to the OSLC website which has their meeting dates listed.
http://open-services.net/workgroups/Regards,
JamiI'll follow up by Thursday, February 28, 2013, should I not hear from you sooner with an update.
----------------------------------------------------
Thank you for using IBM.
-----------------------------------------------------
Jami Mitchell
Technical Support Engineer
Rational software
IBM Software Group
Hi Andrew,
I am sorry you feel with the options currently in OSLC.
Where did you get the idea I was ? I don't necessarily feel , I feel the implementation is incomplete as it stands and 2 major revisions have come out without a solution to this at all. I feel this should be reported and the software fixed to be functionality complete. I'd do this before 1.0. In my mind these are all cold, facts with little to no emotion associated with them.
What I really do feel about is well paid IBM Support neglecting to address clear bugs or limitations with their software with "call your sales rep" answers. I recall a time when such obvious bugs were simply addressed for what they are - errors that need correction.
The emotion here is irrelevant so I'd appreciate if we drop that aspect.
ClearQuest is working as and I've provided you with the options that are .
So you are admitting that Clearquest was to not support "is not null", the not operator, the or operator, the like operator,= etc.? That's amazing.
If so then it an enhancement to get the REST implementation to even par with the CQ API. I, however, will always it a bug by my definition.
If you wish IBM to press for more operators in the OSLC framework,then I would suggest speaking with your IBM sales rep and/or the IBM product so you can express your concerns.
I don't have an IBM sales rep - my client does I suspect. I don't know who that is. By all means, have them call me (858)-521-5691.
Regards,
JamiI'll follow up by Thursday, February 28, 2013, should I not hear from you sooner with an update.
----------------------------------------------------
Thank you for using IBM.
-----------------------------------------------------
Jami Mitchell
Technical Support Engineer
Rational software
IBM Software GroupWe value your feedback -- customers are my top priority. If at any time you would like to provide feedback about the quality of service, please contact my manager, Ralph Bosco, ralph_bosco@us.ibm.com
Find answers on the IBM Support Portal: http://www.ibm.com/support/
Get social with Rational Client Support at: http://www.ibm.com/support/docview.wss?uid=swg21410649&rcss=epsall
On 2/26/2013 12:57 PM, Rational Client Support wrote:
Hi Andrew,
As I stated before OSLC doesn't belong to CQ, it is an open-source life cycle that we have coded to allow interaction with ClearQuest. We (IBM) do not govern what options are in it.
Yes but you surely have influence - much more than I as an individual do. Why not simply "Do the Right Thing(tm)" and push for proper completeness? Or perhaps IBM could have chosen and better implemented back end to hang their hat on. Or gosh, IBM could write their own!
You know I'd be (but not necessarily happy) if you simply said "You're right. We've submitted a bug upstream. We can't say when or if it will be fixed" but you seem unwilling to even do that. I can't understand why. If you did then at least you have done what you could from my viewpoint and I couldn't complain.
If you cannot accomplish your goals with OSLC then you will have to use the API or the clearquest client .
My goal is to provide a library to clients who cannot use the API natively. In my case these are Linux clients who cannot install Clearquest to talk to the database because the database uses Visual Basic code.
I have been trying to attack this problem from two different angles and have been having problems with both approaches. IBM has just be passing off these problems as not their problem.
The first approach is using the REST so that clients on said Linux systems can talk to Clearquest through my library. However the following submitted PMRs impede this:
So with the REST approach I cannot perform certain queries and run the risk of corrupting data.
Another approach I have is to use a client/server model where the server would run on Windows, thus avoiding the problem of having Visual Basic action hook code and the clients can be Linux or Windows clients. Those clients would not need Clearquest installed locally. The server should fork to service clients so that it does not block having other clients waiting for the first client to finish. However I cannot a client/server module that uses multiprocesses because cqperl does not handle passing the open socket to the child:
which describes how one cannot pass an open socket across a fork/exec. See also:http://community.activestate.com/node/9501.
Due to these failures in software delivered in IBM's Clearquest product I cannot move forward. When I report these as bugs I am told that they are not bugs and to go talk to other organizations or talk to my sales rep.
This is not support or at least certainly not worth the support dollars that my client pays.
I don't think you want professionals who have been working in this field for decades to go from client to client saying to not purchase your products because the support often seemingly dismissive. Granted I understand that you lean on other's code but when a bug is reported I think it's pretty much incumbent upon you to diligently report the problem upstream and assist on getting the upstream bug fixed. That's what I would do.. no, strike that! That's what I do do - especially if somebody is paying for the support. However the way support seems to be lately I am becoming more and more convinced that perhaps my professional opinion should shift more towards other products.