× 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.



Hello, all.
Speaking about not CL technique.
Does anybody use spawn() API to create a separate jobs?
Some years ago I tried to use it, but I didn't find the way to create job
in different subsystems.
Does anyone know if there is a way to run jobs in QBATCH subsystem?

� Thanks,� Alex Zhylich.
� 20.05.2016, 11:29, "Wilson, Jonathan" <piercing_male@xxxxxxxxxxx>:

On Wed, 2016-05-18 at 19:33 +0000, Denis Robitaille wrote:

�Hello,

�We have used this technique a lot over here. One of the problem with
it is that if the batch job fails and you forget to reset the data
area, your interactive program will never start until the user gets
tired and call the help desk and that the help desk figure out that
the data area is not up to date.

�I would proposed the following instead:

�Have the batch job put an exclusive lock on the data area at it's
beginning and release it at the end.

�Then the interactive jo tries to put a share lock on the data area
(ALCOBJ). You can put a wait delay on the ALCCMD of several hours if
you which. The interactive job will then wait until the lock is
release before continuing.

�Here are a few benefits of this approach:
�- if the batch job end abnormally, the lock is release. You don't
have to edit the data area
�- if the interactive program is already running when the batch
program start, the batch program will wait until it can get a lock or
times out (you can specify how long to wait before timing out)
�- no more goto
�- if the wait is too long, you can program an appropriate action
(like sending a message)

While I have used that approach in the past for specific things I guess
its usefulness would depend on the requirements of the OP's system. If
it needs to prevent jobs starting "until the job completes
_successfully_" then locking an object would fail as a cancelled or
aborted batch job would unlock the object and allow new interactive work
to start.

All that said... I personally would not put an interactive job into some
kind of wait loop, or even in a single long wait, and would instead
chuck a user readable message up the message queue ("batch job still
running, try again later...") or at the very least limit the loop to X
tries with a status message counting down.

�Hope this help

�Denis Robitaille
�Chef de service TI - Solution Entreprise
�Infrastructure et Opérations
�Cascades Centre des technologies,
�412 Marie Victorin
�Kingsey falls(Québec) Canada J0A 1B0
�T : 819 363 6130

�-----Message d'origine-----
�De : RPG400-L [mailto:[1]rpg400-l-bounces@xxxxxxxxxxxx] De la part
de Bob Cagle
�Envoyé : 18 mai 2016 14:46
�� : [2]RPG400-L@xxxxxxxxxxxx
�Objet : Technique critique?

�This is more of a CL programming question:

�Background: I have an interactive program that I need to have NOT
run while a specific batch job is running. Currently the batch job
updates a data area with a flag at the start of the job and then
clears it at the end. Interactive jobs can then check for this flag
before running.

�I have this code in my CL:

�CHECK:
�/* Check data area to see if job is running */ Rtvdtaara DataArea
rtnvar(&Check) If (&Check = '1') then( DO )

���/* wait 30 seconds and then try again */ Dlyjob dly(30)
���Goto CHECK
�ENDDO

�The GOTO is bothering me, so the question is - would you code this
different? This seems simple and straight-forward, but in your opinion
is there a better way?

�Thanks

�Bob Cagle
�IT Manager
�Lynk

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

�Please contact [7]support@xxxxxxxxxxxx for any subscription related
questions.

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

Please contact [12]support@xxxxxxxxxxxx for any subscription related
questions.

References

Visible links
1. mailto:rpg400-l-bounces@xxxxxxxxxxxx
2. mailto:RPG400-L@xxxxxxxxxxxx
3. mailto:RPG400-L@xxxxxxxxxxxx
4. http://lists.midrange.com/mailman/listinfo/rpg400-l
5. mailto:RPG400-L-request@xxxxxxxxxxxx
6. http://archive.midrange.com/rpg400-l
7. mailto:support@xxxxxxxxxxxx
8. mailto:RPG400-L@xxxxxxxxxxxx
9. http://lists.midrange.com/mailman/listinfo/rpg400-l
10. mailto:RPG400-L-request@xxxxxxxxxxxx
11. http://archive.midrange.com/rpg400-l
12. mailto:support@xxxxxxxxxxxx

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.