Weaving WebSphere: The Data Perspective

[MCWebsite.Staff]

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
** This thread discusses the Content article: Weaving WebSphere: The Data Perspective **
0

[Guest.Visitor]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
Joe, the Quantum DB elipse plugin is a good one (Be sure to download the eclipse 2.0 version for use with WDSC). One handy feature is that is keeps a log of your previous SQL statements similar to STRSQL. I have set this up in a seperate perspective, so if I need to run a quick SQL statement, its just one mouse click away cheers Colin.W http://as400blog.blogspot.com

[joelcochran]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
I know mention of MicroSoft and .NET could get me castigated, but since IBM was good enough to release the .NET Managed Provider in iSeries Access V5R3, I've been working on a C# tool that I use for SQL work. It's faster and friendlier than OpsNav SQL, although nowhere near as powerful. I've been thinking about cleaning it up and offering it as an Open Source example of using the Managed Provider. I know it isn't a WebSphere thing, but it is right along the lines of using JDBC and Java to roll one's own tool...

[bharder@nlrha.ab.ca]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
I want to second the suggestion that the StrSQL command is great. It really is! This is one of the quickest ways of producing a report, if you know the table structures, that I know. There was a PTF a while back that patched the F9 command. It used to only support the most recent command, but with the PTF it supports the entire command stack, the way you want it to. A quick look for the PTF number didn't bring up the information I wanted; you'll probably have this PTF already anyway. Now, I find that this interface is impressively fast. However I never use it for updates. There is no auditing and this is not acceptable in our environment. I also have some trouble with more elaborate join syntax. The prompting is not especially helpful in figuring out syntax problems.

[J.Pluta]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
Thanks, Colin, I'll look into it ASAP. Further discussion with the Powers That Be at the WDSC labs affirms that the Data Perspective is basically pretty useless without the DB2 Application Development Client (whatever THAT is). Just one of the problems of not fitting the "lock 'em in and then nickel and dime 'em to death" policy of most software models these days (thanks for nothing, Microsoft). Joe

[J.Pluta]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
Are you sure "castigated" is the word you meant to use? Seriously, though, I have no problem with .NET per se. I only get a little riled up when I hear self-styled experts saying that ILE is "IBM's version of .NET", even though ILE pre-dates .NET by a number of years. Or when I hear that drag-n-drop GUI development with Visual Studio is so much more productive than programming in RPG. Well, duh. It's kind of like the difference between throwing pre-mixed cookie batter in the oven and baking them from scratch. Scratch takes longer, but you can do anything you want, while the pre-mixed stuff allow you to quickly make something that SOMEONE ELSE THINKS TASTES GOOD. If you can run your business on someone else's model, then canned software and/or code generators are the way to go. But our client base has consistently thrived on custom software pushing the envelope of what computers could do. You never had a code generator for MRP because it was never simple enough for a junior programmer to stuff into a macro. Ah, I'll stop here before I get my blood pressure all jacked up... Joe

[J.Pluta]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
I want to second the suggestion that the StrSQL command is great. It really is! This is one of the quickest ways of producing a report, if you know the table structures, that I know. And anybody who is mucking about with ODBC or JDBC or embedded SQL ought to know the table structures anwyay! You mentioned the F9 feature which allows you to go back through your command stack. As I said, I also like the ability to driect the output to printers or output files. Here's one you may not have tried yet: when you exit STRSQL with F3, there is an option to save the current session in a source file. This is great not only for saving sessions for use on another machine, but also for embedding in SQLRPG programs or even Java. Joe

[Guest.Visitor]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
You can run cwbundbs.exe to run the "Run SQL Script" portion of navigator without it's overhead, and you can save the work you've done in a .SQL file for later.

[TerryMcP63]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
Nice article Joe. Is "Native I/O" considered passe these days? I'd like to see something which compares Native I/O to SQL with some sort of metric(s) showing how SQL access has gotten better(?) in recent releases of OS/400. Also, comparing "raw" clients which roll DDM (RLIO, DRDA, LIPI) protocols may prove to be of interest to your readers. Kind regards, Terry McPharlin

[David Abramowitz]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
TerryMcP63 wrote: I'd like to see something which compares Native I/O to SQL with some sort of metric(s) showing how SQL access has gotten better(?) in recent releases of OS/400. Unless there have been developments that have changed the way I/O works, Native I/O farms out all I/O to a separate I/O processor freeing the CPU for other work. I do not believe that the QQQUERY API takes advantage of the separate processor (otherwise why would we still have the QQRYDEGREE system value). As all query functions including SQL call the QQQUERY API, it stands to reason that the basic architecture of Native I/O produces greater performance benefit. I do not know if this has been changed on the "I5" box. Dave

[Guest.Visitor]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
This is arguably getting a little off topic, but does anyone know of a way to prevent updating the DB via STRSQL, without preventing the ability to run selects? As Brian says, updating your production system via STRSQL is a bad idea, but in my shop they've prevented this by revoking authority to STRSQL. This stops you runnng queries, and having to resort to WRKQRY, which if you know the SQL you want to run can be far slower.

[J.Pluta]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
Some folks who have grown up with SQL as the only real database access they've ever used tend to look at native I/O with some disdain; they prefer the somewhat less restrictive capabilities of SQL. Why less restrictive? Because with native I/O, you have to actually create logical files rather than specifying them on the fly, and you don't have to worry about file level checks. What is interesting about that particular viewpoint is that neither of those points is valid in all or even most situations. I'll be addressing that a little bit in my next column. In the meantime, the IAAI Website has some Open Source benchmarks that you can download and run on your own particular box to see the difference. In general, SQL is slower than native I/O, sometimes a lot slower, on my machine (at V5R1). Except when performing mass updates, SQL significatnly underperformed compared to native I/O on database modification. I don't know about V5R3, I haven't gotten my new machine yet. Joe

[R.Daugherty]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
I saw a couple of things reading an issue of InformationWeek that prompted me to respond. One was a list of sites that just quit responding under heavy loads. In my opinion, it is due to the use of SQL. I think the speed difference discussed is just one aspect, and a minor one. If that's all it was, and the difference was even double, then IT would buy twice the hardware and think nothing of it. They already are and think nothing of it due to decreased hardware costs is what it looks like to me. However, I think as scaling goes up, the granularity of RPG I/O logic and record locks scales linearly, while SQL runs into contention issues. I don't have any numbers on that, but that's what I think is going on. But what prompted me to come here and post was this little tidbit, from The Transformer, an article in InformationWeek on IBM and its CEO Sam Palmisano, this: "Support for multiple operating systems is a key capability for some customers that are expanding globally. Packaging vendor Greif Inc. connects with some of its customers using an AIX-based Baan enterprise resource planning system from SSA Global Technologies; for others it uses a BPIX system running on IBM's i5 operating system." BPIX is apparently phonetic spelling from the reporter, or maybe not, who knows, it was BPCS when it ran on an AS/400, but (formerly the AS/400) does not follow i5 as it always did with iSeries. I guess reporters are totally confused by now or refuse to say (formerly the iSeries). Just change the names to protect the innocent and move on. Works for me if someone buys BPIX running on an i5. rd

[dacust]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
pricec asks: does anyone know of a way to prevent updating the DB via STRSQL, without preventing the ability to run selects?
Actually, I think you want to protect the data, not the STRSQL command. In our shop, the programs are owned by a profile that has rights to update/delete/etc, but the users do not, they only have "use" authority. Therefore, from the command line they can only see the data. STRSQL can only see the data as well, not change it. -dan

[TerryMcP63]

Weaving WebSphere: The Data Perspective

** This thread discusses the article: Weaving WebSphere: The Data Perspective **
Thanks for the pointer to the benchmarks, Joe. Also, I find David's comments about how native I/O utilizes secondary processors (Control Storage Processor?) very interesting. It's something that I know about in the back of my mind, but it's probably something that most people don't think about. In addition to having secondary processors for disk and communications I/O, the AS/400 has had an interesting "fabric switched" backplane architecture that I rarely read about in the trade press. An article which discusses these features and compares them to other architectures would be interesting and very enlightening. Keep 'em coming, Joe.