Accessing a C shared Library function in a server routine

aartlett · Post by **aartlett** » Fri Apr 23, 2004 8:06 pm

I have been given a C shared libary function to convert from loacl time to GMT. I have also been supplied a PX routine to access it, however more then 75% of my jobs are in Server as the volumes do not warant PX use (only up to a few thousand records).

Can someone please give me some insight on how to convert the PX routine to a server routine, or alternativly to use a function in a library in Server?

tanx in Advance

Andrew (a newbie to the forums).

ray.wurlod · Post by **ray.wurlod** » Sun Apr 25, 2004 3:51 pm

Calling C functions from server (= DataStage BASIC) is possible, but not for the faint hearted. It's done through a mechanism called the General Call Interface (GCI) and, among other things, requires that you statically link the function library into the DataStage executable. That is, you have to build a new "version" of DataStage containing the link to your library, and there are so-o-o many things you can get wrong. At the very least make sure you've got backups of everything before you go down this path.
Even with the amount of experience I have, I'd be tempted to reinvent the C functionality into a DataStage BASIC routine of some kind. The DataStage Engine is a very sensitive beast, and the load sequence during make has to be exact because of the amount of overloading that it does.
Unfortunately there are no conversion utilities from C to DataStage BASIC; you have to analyze the algorithms used and re-create these.

aartlett · Post by **aartlett** » Mon Apr 26, 2004 2:28 pm

Thanx Ray. I;m going to get the C shared library function wrutten as a standalone C program and call it from inside of a routine via a Unix call.,

ray.wurlod · Post by **ray.wurlod** » Mon Apr 26, 2004 11:09 pm

Why don't you do it in a proper (that is, DataStage BASIC) server routine? GMT is easy to do, provided your TZ environment variable is set (which a C routine would require in any case).
Is it a time in your data, or just the system time, that you need to convert?
Take a look in the SDK routines; there are already a couple there that deal with GMT, which may solve your problem. If not, post again and we'll see what we can do.

aartlett · Post by **aartlett** » Tue Apr 27, 2004 6:23 am

The problem with writing it in it in basic is that it has to deal with three times:
Australia/Victoria - including DST - > GMT, GMT+10 -> GMT and GMT+10 -> Australia/Victoria.

We have since hacked the SO version apart, created a C program and doing final testing. It is a trivial program. We'll call this from a routine calling a unix function. Not the most effiicent but it will work.

chulett · Post by **chulett** » Tue Apr 27, 2004 7:38 am

aartlett wrote:The problem with writing it in it in basic is that it has to deal with three times:
Australia/Victoria - including DST - > GMT, GMT+10 -> GMT and GMT+10 -> Australia/Victoria.

Out of curiousity, how is this a problem? In BASIC, it too is a trivial program and I personally think adding calls out to the OS for a C program is (IMHO, of course) a mistake. Keep it all in the tool unless you've got absolutely no other choice.

aartlett · Post by **aartlett** » Tue Apr 27, 2004 2:44 pm

Hey I'm not proud, if someone can show how to BASIC the TZ and day light savings problem, remembering in Australia the start and end times differ from year toyear and state to state, I'll use it. If three po0ple post it I won't even have to plgerise, that makes it research ;-)

ray.wurlod · Post by **ray.wurlod** » Tue Apr 27, 2004 6:00 pm

Are you asking about different servers in different time zones or one server managing different time zones? Obviously a single TZ environment variable doesn't solve the second case. How are you doing it in C? (Are you able to post the C code? Someone here will probably be happy to "translate" the C into DataStage BASIC, if only as an intellectual exercise).

aartlett · Post by **aartlett** » Wed Apr 28, 2004 4:20 am

It's a single Server handling multiple timezones to multiple timezones and GMT and some data with or without daylight savings even if that TZ should have DST ... real fun.

I don't have the C code on me, but it is calling the C cdae function and overriding the TZ as required to get a seconds since epoch and then reversing it to give the output date. I can't see how to do that in basic. If it was just GMT+-N TZ changes ... no problems, it's the DST switches in Australia that cause the problem and having to cater for the time the data was entered locally (Australia/Queensland differs from Australia/Victoria even though they are in the same TZ wrt GMT except for DST).

ray.wurlod · Post by **ray.wurlod** » Wed Apr 28, 2004 4:09 pm

Yes, that needs to be table driven in Australia. Remember how they changed even from those rules for the 2000 Olympics? But that's no big difficulty - you could used a hashed file or UV table, or even a text file; the volume of data is not huge.
Are any of your data dates (those that need conversion to/from GMT) in the future, or are they all in the present or earlier? Also, how do you identify the location - just State/Territory, or does this need to be deduced from some other item, such as postcode? For instance, there are three variants on the east coast; Queensland (no DST), New South Wales, ACT and Victoria (usually last Sunday in October to last Sunday in March) and Tasmania (usually first Sunday in October to last Sunday in March). How do we know which one to use?
We're getting there, slowly but surely!

ray.wurlod · Post by **ray.wurlod** » Thu Apr 29, 2004 3:37 am

I guess that raises the question whether you have to be able to do this only for current dates, or possibly also for historical dates (and, if so, how far back). Hmm...

It's also the case that the TZ environment variable has a different value/format depending on your UNIX. Here are two examples, the first from Solaris, the second from AIX.

$ echo $TZ
Australia/NSW

$ echo $TZ
EET-10EETDT,M10.5.0,M3.5.0

aartlett · Post by **aartlett** » Thu Apr 29, 2004 4:09 am

Ray,
Thanx for all your help. One of our enterprising developers wrots a DS Basic routine using the October/March mandate for Victoria. We'll see how the PTB's accept this. If this fails, we'll go to the C program that we have cobbled together.

We are on a Solaris box, so the Australia/Victoria is the option and we can use the alternate date call to tell it not to use day light savings.

ray.wurlod · Post by **ray.wurlod** » Thu Apr 29, 2004 4:05 pm

Thinks...

Daylight saving can be handled most easily using the Julian date (that is, the ordinal number of the day in the year). OCONV(date, "DJ") gets this.
In Australia, if this is less than the finish date (Julian form) or greater than the start date for daylight saving, then no adjustment need be made. Otherwise (currently) a one hour adjustment is made in appropriate regions. (Does TZ return Australia/NT for Northern Territory? Without that you have to have another way to identify the region!)

Does the code have to be sensitive to the fact that the actual changeover is at 02:00am? That is, are you using dates or timestamps?

Finally, what if "they" change the offset from one hour to two, or 90 minutes, as was proposed for Tasmania a couple of years back?

You'd need to incorporate this in the algorithm, so a Routine is the best way to go.

chulett · Post by **chulett** » Thu Apr 29, 2004 6:46 pm

Sheesh.

I take back the 'trivial' statement I made. I'm sure it can still be done and would be a better solution than the C program, but... sheesh. Didn't realize it was quite so complicated Down Under.

ray.wurlod · Post by **ray.wurlod** » Fri Apr 30, 2004 2:40 am

Some useful date routines for solving the Australian daylight saving question.

Code: Select all

FUNCTION LastSundayInOctober(Year)
$COPYRIGHT "Copyright (c) 2004, Ray Wurlod.  All rights reserved."
$* Calculates the date of 01-November in the year in question, then steps backward until a Sunday is encountered.

      EQUATE RoutineName To "LastSundayInOctober"
      Ans = @NULL
      If Unassigned(Year) Then GoTo MainExit
      If IsNull(Year) Then GoTo MainExit

      If Year Matches "1N0N" : @VM : "1N0N'BC'"
      Then

         TestDate = Iconv(Year : "-11-01", "DYMD")
         Loop
            TestDate -= 1
         While Mod(TestDate, 7) > 0
         Repeat

         Ans = TestDate

      End
      Else

         Call DSLogWarn("Non-integer year: " : Quote(Year), RoutineName)

      End

MainExit:
RETURN(Ans)

Code: Select all

FUNCTION LastSundayInMarch(Year)
$COPYRIGHT "Copyright (c) 2004, Ray Wurlod.  All rights reserved."
$* Calculates the date of 01-April in the year in question, then steps backward until a Sunday is encountered.

      EQUATE RoutineName To "LastSundayInMarch"
      Ans = @NULL
      If Unassigned(Year) Then GoTo MainExit
      If IsNull(Year) Then GoTo MainExit

      If Year Matches "1N0N" : @VM : "1N0N'BC'"
      Then

         TestDate = Iconv(Year : "-04-01", "DYMD")
         Loop
            TestDate -= 1
         While Mod(TestDate, 7) > 0
         Repeat

         Ans = TestDate

      End
      Else

         Call DSLogWarn("Non-integer year: " : Quote(Year), RoutineName)

      End

MainExit:
RETURN(Ans)

Code: Select all

FUNCTION FirstSundayInMarch(Year)
$COPYRIGHT "Copyright (c) 2004, Ray Wurlod.  All rights reserved."
$* Calculates the date of 01-March in the year in question, then steps forward until a Sunday is encountered.

      EQUATE RoutineName To "FirstSundayInMarch"
      Ans = @NULL
      If Unassigned(Year) Then GoTo MainExit
      If IsNull(Year) Then GoTo MainExit

      If Year Matches "1N0N" : @VM : "1N0N'BC'"
      Then

         TestDate = Iconv(Year : "-03-01", "DYMD")
         Loop
         While Mod(TestDate, 7) > 0
            TestDate += 1
         Repeat

         Ans = TestDate

      End
      Else

         Call DSLogWarn("Non-integer year: " : Quote(Year), RoutineName)

      End

MainExit:
RETURN(Ans)