Basic Framework of JCL

/name JOB parameters...
//name EXEC parameters...
//name DD parameters...

Each of this JCL Statements have a label – a symbolic name assigned to them. Its like naming kids. Well, there could be so many boys in your area, but how do distinguish them? Of course, by their names.

In the same way, a JCL may contain a bunch of DD Statements, one for Input file, one for the output file, one for the error file. How do you tell them apart, by naming them. As a good practice, we always give names to all our JCL Statements. Names kinda help you to refer back to these statements in the future. You want to point out a particular JCL Statement to your friend, just spell out its name.

But, notice carefully, each label(name) is preceded with two slashes //. The two slashes are a JCL Statement’s signature. They indicate that the statement is a JCL Statement(one of JOB, EXEC, DD). Every JCL Statement wear the two slashes //. A naked statement without // won’t be treated as a JCL Statement.

Now, every JOB, EXEC and DD Statement has got these whole lot of parameters. What you’ll be learning throughout these tutorials is mostly the parameters. Parameters add stuff and meaning to the JCL Statement. 

Now, let me give you a booster, that’s going to help you organise the way you think about this JCL.

- JCL is made up of mainly JOB, EXEC and DD.
- JOB is easy to learn and use.
- EXEC is easy and fun to use.
- DD Statements take three forms
   1. DD Statements to read a file.(easy)
   2. DD Statements to write to the logs.(easy)
   3. DD Statements to create a new file(hard!); you’d have to learn parameters such as DISP, UNIT, DCB, SPACE and several others to code this.

Have a good look at this chart :


Improve your jQuery - 25 excellent tips

jQuery is awesome. I've been using it for about a year now and although I was impressed to begin with I'm liking it more and more the longer I use it and the more I find out about it's inner workings.

I'm no jQuery expert. I don't claim to be, so if there are mistakes in this article then feel free to correct me or make suggestions for improvements.

I'd call myself an "intermediate" jQuery user and I thought some others out there could benefit from all the little tips, tricks and techniques I've learned over the past year. The article also ended up being a lot longer than I thought it was going to be so I'll start with a table of contents so you can skip to the bits you're interested in.
Table of Contents

    *   1.  Load the framework from Google Code
    *   2.  Use a cheat sheet
    *   3.  Combine all your scripts and minify them
    *   4.  Use Firebug's excellent console logging facilities
    *   5.  Keep selection operations to a minimum by caching
    *   6.  Keep DOM manipulation to a minimum
    *   7.  Wrap everything in a single element when doing any kind of DOM insertion
    *   8.  Use IDs instead of classes wherever possible
    *   9.  Give your selectors a context
    * 10.  Use chaining properly
    * 11.  Learn to use animate properly
    * 12.  Learn about event delegation
    * 13.  Use classes to store state
    * 14.  Even better, use jQuery's internal data() method to store state
    * 15.  Write your own selectors
    * 16.  Streamline your HTML and modify it once the page has loaded
    * 17.  Lazy load content for speed and SEO benefits
    * 18.  Use jQuery's utility functions
    * 19.  Use noconflict to rename the jquery object when using other frameworks
    * 20.  How to tell when images have loaded
    * 21.  Always use the latest version
    * 22.  How to check if an element exists
    * 23.  Add a JS class to your HTML attribute
    * 24.  Return 'false' to prevent default behaviour
    * 25.  Shorthand for the ready event

ASP.NET AJAX mistakes

It’s important to remember that a partial postback is just that: A postback.
The UpdatePanel’s way of abstracting AJAX functionality behind standard WebForm methodology provides us with flexibility and familiarity. However, this also means that using an UpdatePanel requires careful attention to the ASP.NET Page Life Cycle.
In this post, I’d like to point out a few of the problems I’ve seen developers running into and what you can keep in mind to avoid them:
  • Page events still fire during partial postbacks.
  • UpdatePanel events fire, even when not updating.
  • Control event handlers fire after Load events.

Page events still fire during partial postbacks

One of the most common things that new ASP.NET AJAX developers overlook is that all of the Page’s life cycle events (Page_Load, Page_PreRender, etc) do execute during every partial postback. During a partial postback, the Page’s control tree is fully reinstantiated and every single control runs through its life cycle events. If that’s not taken into account, it’s very easy to run into mysterious difficulties.
Page.IsPostBack is true during partial postbacks, making it easy to avoid this pitfall. However, it’s a problem that surfaces at least daily on the ASP.NET forums, so it bears mentioning.
Additionally, ScriptManager.IsInAsyncPostBack is true during partial postbacks only. This property can be used to further distinguish what type of request is being processed.

UpdatePanel events fire on each and every request

Using the UpdatePanel’s life cycle events (Init, Load, PreRender, and Unload) can be a great way to partition your code and enables you to use __doPostBack() to trigger the UpdatePanel from JavaScript. However, it is crucial to understand that these events will execute on every page load, postback, and partial postback.
Even if you’re using UpdatePanels with conditional UpdateModes and some of those UpdatePanels aren’t being visibly updated in a given partial postback, all of them will be recreated on the server and execute any life cycle event handlers you’ve wired up for them.
Typically, this means that should wrap your code in an !IsPostBack or !IsInAsyncPostBack conditional if you don’t want it to execute on every request. However, one slightly more tricky situation is when you want to execute code only if a particular UpdatePanel is targeted for a refresh. To accomplish that, you can check the __EVENTTARGET:
protected void UpdatePanel1_PreRender(object sender, EventArgs e)
  // This code will only be executed if the partial postback
  //  was raised by a __doPostBack('UpdatePanel1', '')
  if (Request["__EVENTTARGET"] == UpdatePanel1.ClientID)
    // Insert magic here.

Control events are raised after Load events

One of my readers recently ran into what is probably the second most common page life cycle problem I’ve seen.
Basically, he had an UpdatePanel and Button interacting with each other to create a simple poll. The UpdatePanel’s Load event rendered poll results from a database table, while Button_Click let users submit their poll votes to the database.
Can you see the problem?
If you read the subheading above, it’s probably obvious. Button_Click was running after UpdatePanel_Load, giving his users the impression that their votes were not being counted since the display didn’t change when they voted.
The fix? Instead of rendering the poll in UpdatePanel_Load, he needed to render it in the PreRender event instead, because UpdatePanel_PreRender fires after Button_Click.
It sounds simple when spelled out, but it’s a mistake we’ve probably all made at one time or another. The extra layer of complexity that AJAX brings to the table only makes it easier to accidentally forget about subtle page life cycle issues.

Oracle vs. Sybase: 10 reasons to use Sybase on Linux

Sybase products are generally perceived within the database administrator (DBA) community as very reliable and easy to maintain, particularly compared to Oracle. Any move from Sybase to another DBMS (database management system) has got to be justified in terms of the current level of dissatisfaction with Sybase and the level of desire to use the other. I cannot recall anywhere where this is valid.
  1. The latest Sybase flagship product, ASE 15, has filled much of the perceived functionality gap between ASE and other databases.
  2. Linux is an ideal and cost-effective platform for development teams and many companies. With the availability of heterogeneous dump and load of Sybase databases across different operating systems, Sybase -- by virtue of its modularity and ease of use -- is an ideal DBMS for Linux. This needs to be contrasted with Oracle which is, pound for pound, a far heavier beast and resource-hungry.
  3. Sybase has a well-established and skilled workforce, offering infrastructure and development teams who are fully familiar with database architectures and Sybase products.
  4. Applications developed using Sybase have been running for a while and providing adequate service.
Continue Reading on

By Mich Talebzedah

How to pass value from main report to sub report?

Here's a detailed example:

1. In main report create a formula, name it, edit it with the formula editor as follows:
shared numbervar NAME := {table1.field1} + {table1.field2}
Save formula.note that you should replace the name and type of variable and a formula with ones of your own

2. Now create a formula in your subreport, name it, edit it with the formula editor as follows:
Shared numbervar NAME;
Save formula.

3. Use formula created in step 2 in your report.

This way you will have a {table1.field1} + {table1.field2} result from main report transferred to your subreport.