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




On 05/11/2005, at 7:19 AM, Adrienne McConnon wrote:

Anyway - I can't believe I am asking for more advice for 1 call 1
condition program - but I obviously do not 'get' something.  I stream
the job that runs the program and it just sits in the job queue with a
status of 'SIGW' - which means it is waiting for a signal.  I am not
sure how to supply the signal.  I understood that the 'sleep' function
would proceed after the specified seconds passed, but that was not the
case.  I let the job sit in the queue for at least 20 minutes.  I feel
like I am missing something here.  Anyboyd have any ideas?

1) If the job is in SIGW status then it must be active so is no longer in the job queue. It only gets onto a job queue (*JOBQ object) as a result of the SBMJOB command. It only stays on the job queue until the subsystem to which the job queue is attached accepts it for work at which point it becomes active and is no longer on the job queue. If you're not using the SBMJOB command to start this program then you must be CALLing it from the command line (or similar interface) in which case it runs inside your current interactive job and never goes near a job queue. This stuff is described in the Work Management and you would do well to read it sometime.

2) SIGW is the normal state for a job in sleep. The sleep() function uses signals to interrupt it which is why it is documented in the Signals section of the Unix API information. Thus the job is waiting for the system to send a timeout signal when the time period you passed in to sleep has ended. If the job is in SIGW for more than 20 minutes then it is because you told it to wait for more than 20 minutes.
        o Make sure you are passing the value you think you are passing.
o Make sure the data type you use maps correctly to that expected by sleep, that is a BIN(4). o Make sure the sleep time is passed in the same manner (reference or value) expected by the function.

3) If you are using Jon's example code without verifying the sleep interface for yourself then the problem is that the default behaviour of COBOL is to pass by reference (like almost all OS/400 languages except C). However the sleep function is a C function and as such expects numeric parameters to be passed by value. The example code omits BY VALUE (tsk, tsk, Jon) thus it passes by reference which causes the sleep function to receive the first 4-bytes of the pointer AS IF IT WERE the sleep value. Pointers are 16 bytes and usually contain a large number e.g.,
         EVAL %addr(sleep-time)  
         %ADDR(SLEEP-TIME) = SPP:C1BD78661E013CD0
(Note this shows only the last 8 bytes of the pointer. To see the full pointer value you have to redefine the pointer as character data. In which case you would see the following:
         EVAL charptr:x
     80000000 00000000 C1BD7866 1E013CD0 
The first 4 bytes of this pointer is x'80000000' which when interpreted as a 4-byte binary value is 2147483648 so that's how long sleep will wait (approximately 68 years).

So specify BY VALUE on the input parameter for sleep.


Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------




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.