Urgent

[lansa]

HI

I have a requirement where in a RPG should invoke a web service and should wait for 7 sec and do the next operation if the control doent come back.

We use Lansa for our webserice. Meaning I will have to give a 'call' to lansa program from RPG. then this RPG should continue(after 7 sec) without the control going to the lansa function.

I dont want to submit a job as this might take some time.

Is there a way to call another program from RPG in a seperate thread or something. Can I not call another program without passing the control to the called program.

I want all these to happen interactively,

Any idea would be highly appreciated.

Thanks in advance

[MichaelCatalani]

Re: Urgent

The first item is to find out how to se the timeout value in Lansa during their connect phase. I dont use Lansa so I would not be any help with that, but certainly it should be settable somehow, especially if a connection can not be made. This alone may solve your issue.

If you want to separate the calling program from the Lansa program, then you can do this by using dataq's. Each original program would have a unique data q associated with it, and would pass this data queue name and livrary and the web service request to a file.

The file would be set for frcratio of 1 so that any writes would immediately update the file. The file should contain a unique transaction id, the dataq name and library, plus any info needed for the request.

Set a trigger over this file. The trigger program should send a data queue request to another data queue that all of the Lansa calling programs are reading. This will signal a Lansa job that there is a request to process. This also allows you to determine how many of the Lansa calling jobs you want running at a time, and they will all read from the same Lansa data queue. The Lansa calling program will immediately delete the record from the request file, then cal the actual Lansa webservice process.

When the Lansa calling program completes, it will send data back to the data q provided in the file, including the transaction #.

The original calling program will submit the file entry, and then wait on its data q for 7 seconds. If an entry comes in, then it compares the transaction id to make sure it is the current one, and not one from an aborted process.

If more than 7 seconds lapses, then the original program will drop off of the dq read, delete its transaction # from the file if it exists, and continue. By deleting the transaction from the file, this will keep a Lansa job from starting the process on something that has already been aborted.

Another benfit from the above solution is that you can write a program that can display the file at any time so you can see how backed up the requests are getting. Or you can track the average response time from when a requests hits the file until a lansa job can service it. This will tell you if you need more Lansa calling programs started. These jobs should run in their own subsystem, and be set up as auto-start jobs.