My problem is:
In case the table is locked the macro throws an error. Also that execution goes on and everything works I can’t accept Error messages in the log nor a job to end different than with an Error condition of zero.

I can’t figure out how to achieve this suppression of Errors – especially the ones written to the log.
I could save the error status at the beginning of the macro and re-set it at the very end of the macro – but what should I do with the log?

Any suggestions would be really welcome (it starts to drive me nuts)!

The way I test the macro is to open 2 SAS session. In the first one I open the table used for testing (sashelp.class), in the second session I call the macro as below (and then I go back to the first session and close the table).

So as already described: The macro works as such but I end up with Errors which shouldn't be there.
It's the LOCK statement causing the issues and I still haven't found a way to capture the error conditions.

Re: %trylock and Error condition

Exactly what SAS error are you getting in your log? Preferably share the SAS code in your SASLOG output, pasted as a post-reply with all code exposed, otherwise we are left guessing about the error you are concerned about.

Re: %trylock and Error condition: full message

The program works as I expect it to, which may be a bit odd. If the program times out waiting for a lock then it still executes the LOCK statement, which I don't think you want. If you want a different action just modify it to maybe, print a message and ENDSAS when it times out.

Re: %trylock and Error condition: full message

I want the macro to try and lock the table - and if not successful to wait a defined time and then try again to lock the table - until either the total time for trials runs out or a lock is successful.

My "only" problem is that if the lock is not successful a error message is written to the log and I haven't found a way to suppress this.

No error condition (code) is generated in 'my' UNIX environment so the issue is at least only on the level of 'ugly'.

To be more precise: &syscc is not affected and stays 0 but somewhere the error condition must be saved as in the end of the log the errors are mentioned.

What I'm looking for is to suppress the log error message caused by an unsuccessful lock statement and not to write it to the log. It would already be o.k. if I could suppress any log messages while the macro executes and not to mention any errors in the end of the log.

Interesting is also that if I use 'lock list; in a Win32 environment then the log tells me that no one is locking the DS (even though I have it open in a second EG session), but when I submit a 'lock ;' I'm getting the all to well known error message.

Re: %trylock and Error condition: full message

> Hi data _null_
>
> I want the macro to try and lock the table - and if
> not successful to wait a defined time and then try
> again to lock the table - until either the total time
> for trials runs out or a lock is successful.
>
> My "only" problem is that if the lock is not
> successful a error message is written to the log and
> I haven't found a way to suppress this.

The macro is designed to use OPEN to TEST if a LOCK can be obtained. If a lock can be obtain by sucessfully opening the data set or the loop times out the lock is attempted. This is a flaw in the code in my opinion. I think you should modify the code to NOT attempt the lock if the loop times out. You know you can't get a lock so why try. This will fix the ERROR problem. Then you can take action as needed because you can't get the LOCK within the time limit.

Re: %trylock and Error condition: full message

I don't think OPEN will work I think you will need FOPEN in Update mode.

My testing shows that if the data set is open in say EG then OPEN will not show that. However if you create a FILEREF that points to the data set and use
[pre]FOPEN(fileref,'U')[/pre]
the function will return "file in use" and you can determine if a LOCK would fail or not.

What I remember is that even after implementing all the good stuff data null suggested I still found cases during testing where the macro didn't behave as required. I ended up with running the jobs in sequence and "flagged" %trylock as an approach I'm no more trying to use in the future.