jce

I am of the understanding that cobol does not have a wait or sleep....
I'm sure that there is some LE function I can call but what is the quickest
and most simple method of having a "WAIT".

I don't know assembler so cannot code to the STIMER macro.
I've seen some asm here:
http://www.mainframeweek.com/journal...+REXX+programs

but I don't use anything I cannot support.

Is there an LE function precisely for this - or some method of SIGNALling ?
Just a link would suffice - I have workarounds but nothing "elegant".

This is Batch and NOT CICS.
This is on IBM z/OS running Enterprise COBOL

Thanks

JCE

william m. klein

Do a dynamic (or static) CALL to

ILBOWAT0 (first is letter "O" - 2nd in number "0")

Pass it a half-word binary (if that doesn't work, pass it a full-word
binary, I can never remember which) with the number of seconds to WAIT.

The parameter must be BELOW the line (i.e. compile with DATA(24) or have an
intermediate program compiled with DATA(24))

This is an ANCIENT OS/VS COBOL routine that is still available in the LE
library - and works for any LE-enabled program.

--
Bill Klein
wmklein <at> ix.netcom.com

joe zitzelberger

Then STIMER is your best bet. I don't think LE has anything that will
help you.

It is rather simple to use, here is the simple example:

CSECT URPGMNM
INIT SAVE=(14,12) <---- whatever standard entry you need
LR R1,R1 <---- address your parameter list
L R1,0(R1) <---- assume a fullword passed as parm
STIMER WAIT,INTVL=(R1) <---- wait that number of ticks
EXIT RC=0 <---- return to caller
END URPGMNM

You will need to find out your shops init/exit standards and use their
macros, but otherwise that is it...

Your example went over the top. Checking out the Rexx environment
blocks, et al...

Just do the simple 5 line thing and call it via TSO CALL.

binyamin dissen

:>I am of the understanding that cobol does not have a wait or sleep....
:>I'm sure that there is some LE function I can call but what is the quickest
:>and most simple method of having a "WAIT".

You have been given several answers to your basic question.

My question is why do you have the need of the wait?

Is your COBOL program starting some asynchronous activity?

Might there be a better design? --
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

harley

| I am of the understanding that cobol does not have a wait or sleep....
| I'm sure that there is some LE function I can call but what is the
quickest
| and most simple method of having a "WAIT".
|
| I don't know assembler so cannot code to the STIMER macro.
| I've seen some asm here:
|
http://www.mainframeweek.com/journal...ion+for+REXX+p
rograms
|
| but I don't use anything I cannot support.
|

Do a scan of your source library, someone else may have already coded an
STIMER routine.
I found a bunch of them at the last place I was at.

Sometimes there really is a free lunch.

jce

I'm getting a DB2 contention deadly timeout. Right now we get a -911 and
the job goes down - the alternatives are to autorestart, just try again
repeatedly, or wait (or anything else you can think of).
Given that the time wait is usually about 2-3-4-5 minutes, I figured it
would be best if I could get the program to waste 4 minutes doing something
that isn't a tight loop.

I have to try and remember to include the "why" when I talk to this group
because the alternative solutions are almost always as good (if not better)
than the straight answer :-)

Thanks to ALL of you who posted so quickly...I am going to look at some of
these alternatives to see if I can do this.

JCE

hugh candlin

I would not put a production program to sleep.

If it never wakes up, programs which are dependent upon its completion
will be held up, and the Master Scheduler will remove you
from his Christmas Card List.

Other possible issues to research
http://www.quest-pipelines.com/pipel...ips00.htm#june

This is from the Sybase manual
If you receive DB2 SQL-911 errors, be sure that the LTMOBJECTS system table
does not share a tablespace with a primary table.

To correct DB2 SQL-911 errors
Use the same user ID and password that originally created the system tables
(usually LTMADMIN).
Shut down Replication Agent.
Save the data from the system tables using your site's normal backup
procedures.
Drop all three system tables.
Create all three system tables in a different tablespace or table blocks.
Restore the contents of the system tables saved in step 3.

jce

Ok - so now I feel like a complete moron. There exists some ASM that is no
longer used called MVSSLEEP. I tried passing it a COMP 9(08) value and lo
and behold it magically waits..

Thanks!
JCE

jce

************Under what condition would this happen?*************

The situation we have is predictable..we have multiple jobs executing
against the same tables doing mass delete/inserts. It is not the operative
position and we are looking, and have looked at other options but this is
the most straightforward (KIS).

The issue is annoying because each program is mass delete/inserting based on
a different key field but we are getting page level locking in spite of
this. We full reorg the table regularly which should limit this but this
has not worked.

The six serious solutions are:
1) Partition the table and thus separating the data which has other data
management implications when adding new data which means we have to actively
maintain

2) Set up OPC maintained negative dependencies - however this is consuming
with a every job to every jobdependency and means we have to actively
maintain(I've been told we cannot do an APPLID level negative dependency)

3) Capture the -911 and SLEEP and retry which is a one time works everywhere

4) Change the schedules to run the jobs as a special bi-monthly/on demand
run versus daily (the original requirement). This is not trivial - but
isn't what they wanted - but IS what I am want...this resolves this and many
other issues we have.

5) Auto-Restart the job if it goes down with - 911.

6) Quit. Move to the beach and retire (if only I was old enough).

The option (3) is the least impact - seemingly simple solution that requires
no future management of resources; however, your statement scares me a
little.

I would like to use this in other places too - similar to an MQSeries GET
WITH WAIT option. I don't want to execute a tight loop that churns CPU for 5-10 minutes.

I'm not on it now :-)

I'm gone for the rest of week but I will look on monday for responses !

JCE

riplin

Many MS-DOS programmers appeared to not even consider that there ever
could be 'another program' and would sit in timer loops or 'kbhit()'
loops and would maximise the CPU time wasted by the program.

On straight MS-DOS this was usually not a problem, if TSRs ran they
would do so on the interrupt timer and this would wrench the CPU from
the program.

Many ways existed of multi-tasking DOS programs, from DeskView to
Windows to Multiuser-DOS. On these the CPU _could_ be used by another
task, and timer loops and kbhit() loops simply degraded overall
performance while giving no benefit to the program doing them.

On MS-DOS there was no 'sleep', but there _was_ a way of despatching
the CPU time to the next task, using INTx2F AX=1680.

Many MS-DOS programmers moved on to Windows where they probably still
do the same thing.

Still, who cares ? Just tell the user to buy a processor upgrade.