Basic Routine

rajeev_prabhuat · Post by **rajeev_prabhuat** » Mon Dec 27, 2004 12:52 am

Hi,

I have writing a routine to get the log summary to a text file and i am getting the data into the text file also, but when i get the data for a date range i am getting the data for the complete day and that is huge. I want the data for last run and for this i am sending the starttimestamp and endtimestamp (hardcoded), this works fine. Now i want to parameterise it and I want to set the datetime in the follwing format : "YYYY-MM-DD HH:MM:SS", and then use it to the Routine, i.e. how can i convert the incoming format to needed format in Basic, can anyone give me a solution for this.

Regards,
Rajeev Prabhu

ray.wurlod · Post by **ray.wurlod** » Mon Dec 27, 2004 1:25 am

You're trying to do too much!

There is a control record in the log (//JOB.STARTED.NO) that keeps track of the event number with which each of the past few runs started. Why not use the first item off this list?

Code: Select all

Read JobStartedList From Log.fvar, "//JOB.STARTED.NO"
Then
   LastStartEventNo = JobStartedList<1,1>
End

Search the Forum for //JOB.STARTED.NO, you will even find examples of code.

If you're passing arguments to the routine, the calling routine is totally responsible for their format. Remember that there are no data types internally in DataStage. So whatever calls your Routine has to provide timestamps in the correct format (which, incidentally, is the format prescribed by ISO 8601).

How you actually convert it (and, indeed, whether you even need to) is determined totally by what's delivered through its argument list to the routine.

rajeev_prabhuat · Post by **rajeev_prabhuat** » Mon Dec 27, 2004 3:47 am

Hi Ray,

Thank you, Ray it worked with out JOB.STARTED.NO itself, i tried it with the jobstarttimestamp and jobendtimestamp, it gives be only the last run status.

As you told that i am doing too much, but what to it is the client requirment and we have to provide it anyhow, so have to do it.

Now i have a query, i am writing the fatal and warning errors to two different text files. But i want to write it to only one file itself rather than two i.e. if fatal file is not null then populate the fatal error only, if fatal file is null then write what is in warning, and if warning is also null then write nothing. My query is how do i check for null in a text file's in Basic Routine. I want the command to do the same check.

Thanks & Regards,
Rajeev Prabhu

ray.wurlod wrote:You're trying to do too much!

There is a control record in the log (//JOB.STARTED.NO) that keeps track of the event number with which each of the past few runs started. Why not use the first item off this list?
Code: Select all
Read JobStartedList From Log.fvar, "//JOB.STARTED.NO"
Then
   LastStartEventNo = JobStartedList<1,1>
End
Search the Forum for //JOB.STARTED.NO, you will even find examples of code.

If you're passing arguments to the routine, the calling routine is totally responsible for their format. Remember that there are no data types internally in DataStage. So whatever calls your Routine has to provide timestamps in the correct format (which, incidentally, is the format prescribed by ISO 8601).

How you actually convert it (and, indeed, whether you even need to) is determined totally by what's delivered through its argument list to the routine.

ray.wurlod · Post by **ray.wurlod** » Mon Dec 27, 2004 11:18 pm

My query is how do i check for null in a text file?

The answer is that there is no such thing as a NULL in a text file. There are no data types in text files, only text. There is usually some convention agreed upon for representing NULL, such as "<NULL>", and you simply have to check for the occurrence of that.

When client requirements are stupid, the only honest thing to do is to tell them so, with explanations. If they continue to insist, it's their money.

T42 · Post by **T42** » Wed Dec 29, 2004 9:25 pm

Rule #1 that many... MANY people do not follow in software development:

Communicate with your customer.

Whether your customer are your own management team, or some clients, you must insist on ensuring that you and they are on the same page on the value of certain features.

It could be likely that someone there had a "brilliant" (read: dumb) idea on this feature. Ask them directly: What value will this add to your end result to have this feature? Is it something that you must have now, or something that can be waived in term of saving time and resources needed to test this?

The more we communicate, the less problems we will have.

rajeev_prabhuat · Post by **rajeev_prabhuat** » Wed Dec 29, 2004 9:39 pm

Hi Ray and T42,

Thanks you for your advice.

Regards,
Rajeev Prabhu

T42 wrote:Rule #1 that many... MANY people do not follow in software development:

Communicate with your customer.

Whether your customer are your own management team, or some clients, you must insist on ensuring that you and they are on the same page on the value of certain features.

It could be likely that someone there had a "brilliant" (read: dumb) idea on this feature. Ask them directly: What value will this add to your end result to have this feature? Is it something that you must have now, or something that can be waived in term of saving time and resources needed to test this?

The more we communicate, the less problems we will have.