Comments on: Time To Dump Query/400 http://itknowledgeexchange.techtarget.com/as400-tutorials/time-to-dump-query400/ Eric Witham's tips, tricks & techniques for system efficiency & problem resolution Tue, 07 May 2013 14:13:22 +0000 hourly 1 By: Getting Started With IBM i SQL - AS/400 & IBM i Tutorials http://itknowledgeexchange.techtarget.com/as400-tutorials/time-to-dump-query400/#comment-4 Getting Started With IBM i SQL - AS/400 & IBM i Tutorials Mon, 05 Nov 2012 21:13:30 +0000 http://itknowledgeexchange.techtarget.com/as400-tutorials/?p=5#comment-4 [...] & IBM i Tutorials « Time To Dump Query/400 Nov 5 2012   9:13PM [...]

]]> By: JohnAndersen http://itknowledgeexchange.techtarget.com/as400-tutorials/time-to-dump-query400/#comment-3 JohnAndersen Sun, 04 Nov 2012 19:28:41 +0000 http://itknowledgeexchange.techtarget.com/as400-tutorials/?p=5#comment-3 @TomLiotta

Thank you for your comment. And exactly spot on… QM addresses ALL of the security and job management shortcomings administrators have with Query/400, and then a few more.

As far as the licensed product goes I was referring to the STRQM interface :-)

-John Andersen

]]> By: TomLiotta http://itknowledgeexchange.techtarget.com/as400-tutorials/time-to-dump-query400/#comment-2 TomLiotta Sun, 04 Nov 2012 04:51:55 +0000 http://itknowledgeexchange.techtarget.com/as400-tutorials/?p=5#comment-2 I fully agree. I’ve recommended migrating off of Query/400 for almost 20 years since first encountering and learning QM.
 
And the real beauty is you probably already have Query Manager licensed…
 
It should be noted that licensing is part of the SQL Dev Kit and generally covers the user interface for QM rather than the ability to compile and run QM queries and report forms.
 
Essentially all AS/400s since V2 have had QM capability. Those that licensed the SQL Dev Kit also had the QM user interface as part of that license. The UI makes it easy to work with QM, but it’s not required. The QM UI is available wherever the STRSQL interactive SQL command is found.
 
For users, giving access to STRQM is preferable to STRSQL. Within QM, you can restrict users to using only SELECT for example. There are no similar restrictions available for STRSQL.
 
For users familiar with SQL, there should be few issues with not having STRSQL. The biggest drawback I see is that there is no session history. But previous queries can be saved, copied and modified. For users familiar with Query/400, the QM “Prompt” mode of query creation provides an interface that is very similar to Query/400; no SQL is needed in “Prompt” mode. Users should be able to adapt quickly, often with no help.
 
The ability to define queries separate from report formats takes a practice session or two, since Query/400 has no ability to work the two parts individually. After it is understood that a single query might be used with numerous different report definitions or that a single report definition can be used to present many different queries, users often develop extensive query/report libraries, interchanging components to meet a variety of needs.
 
I can understand sites not wanting to lose their investments in hundreds or thousands of old Query/400 query objects. But I haven’t seen any good reasons not to stop creating new ones and instead to switch to QM.
 
Tom

]]>