Tag Archives: ISUG

Did you write an article for ISUG’s Technical Journal and either haven’t been paid or refused payment?

International Sybase User Group

For those of you that don’t know, I have written several articles for the ISUG Technical Journal.  I’ve been paid for one and refused payment on the others.  Are there other authors that haven’t been paid for one reason or another?

This is not meant as a dig at ISUG but simply determining if I’m the only one or if there are others.

Share Button

Sybase’s PowerBuilder v12 is powerful, .NET based, and wonderful! Why you shouldn’t use it

The following is MY perception of Sybase’s PowerBuilder:

Years ago PowerBuilder was king.  No one could touch it.  It was relatively inexpensive.  Microsoft’s Visual Basic matured and the Pascal based Borland’s Delphi was released.  Then it fell and fall it did.

Sybase

Sybase

As it was falling from the throne Sybase purchased Powersoft, makers of PowerBuilder.  As the the market share continued to shrink, PowerBuilder developers had more difficulty in finding new projects.  Most new development was written in Visual Basic or Java.

Years went by with marketing of PowerBuilder little more than the occasional road show, TechWave presentations and the ISUG Technical Journal ads catered towards existing customers.  Little to no effort was put forth by Sybase to gain new PowerBuilder customers.

During this week’s Sybase TechWave, PowerBuilder version 12 was released.  It has all the whistles and kitchen sinks you could ask for.   An amazing tool for development!  Too bad no one outside of the die hard PowerBuilder programmers will use it.

Blasphemy!  Heretic!

Consider this:

Sybase owns PowerBuilder.  It owns the PowerBuilder software, PowerBuilder language, PowerScript, the PowerBuilder vm, and everything PowerBuilder.

No problem right?

What will happen to PowerBuilder when Sybase is bought out by another company?  Products with tiny market share like PowerBuilder would likely be killed or in a state of limbo for several years.  Anyone remember what happened when IBM bought Informix?

Do you really want to bet your career and business on a software development tool that is locked to a single smallish vendor?

Maybe, perhaps, if Sybase were to release the PowerBuilder 4GL language and PowerScript to the world like Microsoft did with the C# and Visual Basic languages and Sun with Java…   Perhaps if Sybase would allow 3rd parties to develop tools based around the PowerBuilder language royalty free…

Sybase:  PLEASE FREE THE POWERBUILDER 4GL LANGUAGE!

I mean, really, what benefit could Sybase have to cripple the PowerBuilder developers?

Share Button

Retraction and an apology for my article in the January/February 2009 issue of the ISUG Technical Journal

The article I submitted (migration to Oracle from Sybase and surviving in the workplace) was so very different as to the article that was published.  My piece was too controversial for ISUG to release (Sybase to Oracle) so it was changed, not be me and not by the editor.  It became a weird Unix to Windows rant.  Yup, I agreed to the revised article but was trying to calm a screaming toddler and pamper a pregnant lady… not excuses just explaining where my brain was when I agreed to it.  ugh what a mess.

Ultimately, the publication of the article was my fault.  So please, just ignore my article in the Jan/Feb 2009 issue of the ISUG Technical Journal.

Share Button

Peter Thawley: Creating a RAM disk for Sybase’s ASE DBMS

International Sybase User Group

International Sybase User Group

Over on ISUG‘s SIG-ASE mailing list, Peter Thawley wrote up the following reply that I think everyone using Sybase ASE and is thinking of using a RAM disk should be aware of.  When I asked Peter if I could repost his message on my blog he agreed :)

Creating a RAM Disk

Peter Thawley

Peter Thawley

Joe and Shane are spot-on about a task context switching off the engine on an i/o to a RAM-disk based device … and yes Joe, there is nothing you can do about this right now. Normally, one would think of this as a good thing … and it is for that specific user since they get to consume more cpu/engine time thereby getting better response time for their request.

Now, to throw a wrench into this! In these cases where some or all of the database is cached, one does have to be aware of the potential for other user tasks to experience some amount of starvation. Image a bunch of tasks, each consuming a full time slice (100ms by default) before yielding. For systems doing pure OLTP (short) transactions with users getting on an engine and getting off reasonably quickly … little risk of a problem. For mixed workload applications with some OLTP and some DSS/reporting, the potential for starvation is quite real and nearly guaranteed for environments with fully cached DBs. I’ve seen some trading systems in tier 1 investment banks brought to their knees by an innocent IT person deciding to buy a lot of memory to cache the entire DB only to wonder why performance started going to hell. [Of course, it was Sybase’s fault … ( – ; )]

In these cases, be thinking about execution classes/engine groups to segregate OLTP and DSS users onto their own disjoint set of engines using dynamic listeners to keep execution engines and network engines aligned within the same engine groups. You may also want to consider reducing “clock tick length” to keep a timeslice period lower than 100ms … I’ve seen some sites successfully using 50ms and even less … there seems to be little downside since most systems do the async disk io and net io checks a lot more frequently than 100 ms due to the “io polling process count” param.

Just trying to present a balanced view here …. This is going to be important for more people to consider as in-memory database techniques and/or features / products become more prevalent.

Peter
_____________________________________

Peter Thawley
Senior Director / Architect
CTO Group, WMO
Sybase, Inc.

Share Button

Big things afoot at Sybase, Inc.

Sybase

It’s coming…

48 hours from now something big is coming!

Share Button