Latch sets 
Author Message
 Latch sets

     To create a latch set, one must be authorized. So says the
Authorized
     Assembler Services Guide. One must either be in supervisor state or

     have PKM allowing key 0-7.

     But the manual 'Programming: Callable Services for High-Level
     Languages' says that C,COBOL,fortran,PL/I and REXX languages can
use
     this service by issuing CALL statements appropriate for the
language
     in question. If somebody is going to write something in one of
these
     languages to use latch sets,they are going to need authorization.
Authorized
     FORTRAN programs??? This seems ridiculous. Did I miss something?

     THNX. Pierre.



Fri, 06 Jul 2001 03:00:00 GMT  
 Latch sets

Quote:

>To create a latch set, one must be authorized. So says the Authorized
>Assembler Services Guide. One must either be in supervisor state or
>have PKM allowing key 0-7.

>But the manual 'Programming: Callable Services for High-Level
>Languages' says that C,COBOL,FORTRAN,PL/I and REXX languages can
>use this service by issuing CALL statements appropriate for the
>language in question. If somebody is going to write something in one of
>these languages to use latch sets,they are going to need authorization.
>Authorized FORTRAN programs??? This seems ridiculous. Did I miss
>something?

No. You pretty much grocked the stupidity of it. The authorized assembler
services book is correct. You have to be sup state or have a PKM allowing
auth keys.

Now as we all know (or should), NONE of the IBM language products supports
authorized execution. Well, ok PLX does and there is a brain damaged form of
LE runtime used by DB2 - but none of the street versions do. Anyway, I
raised this issue with the developer (Peter Relson) along with a few other
related issues. We had a long healthy disagreement.

That's NOT a criticism of Peter! He did a great job at getting something
working quickly for internal purposes. It was then made available
externally, without allowing him time to "finish it off" i.e. to add
usability features we might consider necessary. e.g. there is no way to
delete or change the shape of a latch set and MVS recovery is blissfully
unaware of latches - which tends to violate the principle of least
astonishment.

If your application runs unauthorized, then you can safely ignore the latch
manager. There's just no way you can use it. Don't even waste your time
trying.

If your application DOES run authorized, then you CAN use the latch manager,
but you have to be prepared to write a butt-load of extra code to manage
recovery issues. If you DON'T, then you will regret it very quickly.

I did take the time to write that additional code for a certain vendor's
internal use and it works very well, but I have to say I lost a few body
parts and a lot of {*filter*} doing it. Overall these services fall into the
"William Tell - Near Miss Award" category. Nice try, no cigar.

Chris.



Sat, 07 Jul 2001 03:00:00 GMT  
 Latch sets
I did more reading today and saw a C example ( I forgot in which book ) where
they MODESET to supervisor state before doing latch functions and then reset to
problem state afterwards. So, yup, silly-assed COBOL programs will have to issue
MODESETS to do this. Too bad, it's a good idea.

I also recognized, that latch sets once created last until the next IPL. So if
your application/address space craps out you'd better have solid recovery
because you could lock yourself out of the house.

What is needed is latch-type features which are branch entry (PCs) and which die
if the creator/owner die. This would be very handy.



Sat, 07 Jul 2001 03:00:00 GMT  
 Latch sets
: I did more reading today and saw a C example ( I forgot in which book ) where
: they MODESET to supervisor state before doing latch functions and then reset to
: problem state afterwards. So, yup, silly-assed COBOL programs will have to issue
: MODESETS to do this. Too bad, it's a good idea.

: I also recognized, that latch sets once created last until the next IPL. So if
: your application/address space craps out you'd better have solid recovery
: because you could lock yourself out of the house.

: What is needed is latch-type features which are branch entry (PCs) and which die
: if the creator/owner die. This would be very handy.

I was under the impression that latch sets are deleted when the job or
address space that creates them terminates.  Specifically, I refer to the
following documentation in "OS/390 MVS Auth Assembler Services Guide"
under "Creating a Latch Set (ISGLCRT Service)" in which it says:

<documentation>
  "Once you create a latch set, the latch set remains in place for the life
   of the job or address space.  You cannot delete a latch set."
</documentation>

--
| Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
| Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

| 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |        
| Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Sun, 08 Jul 2001 03:00:00 GMT  
 Latch sets

Quote:

>I did more reading today and saw a C example ( I forgot in which book )
where
>they MODESET to supervisor state before doing latch functions and then
reset to
>problem state afterwards. So, yup, silly-assed COBOL programs will have to
issue
>MODESETS to do this. Too bad, it's a good idea.

Yech! This is an appalling idea. The extra pathlength is possibly going to
eliminate the speed advantage of the latch anyway. The really bad news is
that the LE code is going to be massively astonished if it finds itself
running in supervisor state and this can easily open an integrity hole. All
of the LE control blocks, including the program's stack, are in key 8
storage. You know where that can lead....

Quote:
>I also recognized, that latch sets once created last until the next IPL. So
if
>your application/address space craps out you'd better have solid recovery
>because you could lock yourself out of the house.

The latch set only exists until the address space ends. Of course, if it
happens to be an initiator or STC, that could be a very long time. Its a
silly limitation and you're quite correct in saying that you can easily
"lock yourself out" - even GRS is at least aware of the untimely demise of a
task holding an ENQ. Not so with latches though! You hold them until you
explicitly release them, or the end of time, whichever comes first. ;o)

Quote:
>What is needed is latch-type features which are branch entry (PCs) and
which die
>if the creator/owner die. This would be very handy.

The goober-ware interface (with the umpty parameters and the boffo big work
area) is intended to provide the obtain/release service with everything it
needs, including a save area. That's to avoid needing to obtain storage, or
even issue PCs. The internal design performance criteria were (I am led to
believe) extremely stringent.

Obtain and Release are plan old branch entry services with standard linkage
(i.e. no state change). However, the latch manager control blocks are key
zero, so you really have to be running in a privileged state (not just APF
auth) to pull it off.

The create and purge services are PCs (IIRC) - but they have much less
stringent performance requirements as you might expect. Anyway, while the
books might show the code you describe, I would consider it a massively bad
idea to try to run things that way. There might be mitigating circumstances,
e.g. the address space is yours and yours alone (meaning key 8 storage would
possibly be ok), but in general its just a bad idea.

Chris



Sun, 08 Jul 2001 03:00:00 GMT  
 Latch sets
Sorry I didn't respond earlier. Busy. Where does one get information on
pathlenghs for stuff like PCs? How does this compare with an SVC in terms of
performance? How does one compare the performance of one versus the other? There
may also be pure branch entry type code. Being far from internal performance
knowledge, one sometimes has to make guesses. Any help on how to judge which is
best would be appreciated.

Also, I didn't say I would use latch sets. The recovery logic may get quite
twisted. And I hate that.

Pierre.



Tue, 10 Jul 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. How to program set(X) + set(a) = set(X)

2. How to program set(X) + set(a) = set(X)

3. "Latched" buttons

4. Latching leds on.....

5. Changing bitmap for a button with the 'latch when released'-reaction

6. Latch action with event structure

7. Latching a signal

8. D-Latch (VHDL to Verilog)

9. How to avoid this Latch

10. Intentionally wanted latches

11. latch setup & hold

12. Latch Inference

 

 
Powered by phpBB® Forum Software