× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi, Michael:

Now that we know a little more of your requirements and what you are trying to do, we can suggest some alternatives.

1. create a never-ending (long-running) server job that waits on a
request data queue; you will start this job automatically, each day,
e.g. via the job scheduler or an auto-start job entry attached to
the appropriate subsystem -- obviously, must not be running in the
same single- threaded job queue where these other jobs are expected
to run, as it will "block" that job queue indefinitely
2. your program will "post" a "request" (that data structure you
mentioned) onto this request data queue, to be handled by the server job
3. your program continues to run merrilly along

Does that help?

You should be able to find plenty of examples of how to do this sort of thing "in the literature" (and on the web) -- search for "never ending program" and "data queue" and such.

Hope that helps,

Mark S. Waterbury

> On 5/24/2012 1:05 PM, Koester, Michael wrote:
Mark,
This new process is an extension to existing work.
The part that's in production currently runs in a single-thread job queue that is for jobs that don't take too long. The job provisions a service order to the telecom switch equipment. Now I need to further provision that same order to some other equipment that requires access via web services, and they take some time. It seems that since the first job has already collected some details about the service order that will be needed by the new job, I should utilize that and pass it to the long-running process, rather than have to go rediscover it all.

-- Michael

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Thursday, May 24, 2012 12:51 PM
To: RPG programming on the IBM i / System i
Subject: Re: Passing data structure to batch job

Hi, Michael:

Since the first job is already running in batch, why needlessly
complicate matters by spawning several additional batch jobs? That
introduces all sorts of additional problems. How will the first job know when the other jobs have completed? How will they get back any results? etc.

Just call these other program(s) directly from the first program. That way, you can easily pass whatever data structures are needed, etc., with no worries due to the vagaries of the command parsers and quoting and all that stuff that happens when you need to cross a job boundary (e.g.
via SBMJOB).

Hope that helps,

Mark S. Waterbury

> On 5/24/2012 8:39 AM, Koester, Michael wrote:
Never tried this before: I have a sqlrpgle program running in batch that needs to submit another program to batch and pass a data structure to that new job. The original job executes in just a few seconds, the new job executes calls to web services that take maybe 45 seconds each to return results, so I'm reluctant to burden the original job with that kind of wait. I normally use a call to QCMDEXC to launch (via sbmjob) such a job from RPG, but my question is more about passing a data structure ( like I'd do in a prototyped call ). Is a data queue required here? ...I have no experience with those.
(Extra points to a response that say's "it's easy") Thanks.

Michael Koester

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.