Of course there is going to be a need for monitoring/terminating ill behaving tasks.
Rob Rob Schramm Senior Systems Consultant Imperium Group On Wed, Dec 4, 2013 at 4:50 PM, Sam Siegel <[email protected]> wrote: > search google for examples of the msgxxx functions. Since they are > published standard functions, you should find lots of non z/OS code that > uses them. > > > On Wed, Dec 4, 2013 at 1:48 PM, Scott Ford <[email protected]> wrote: > > > Sam, > > > > Thx I am looking at the msgxxx C functions..the lack of examples in the C > > Doc is maddening at times > > > > Scott ford > > www.identityforge.com > > from my IPAD > > > > 'Infinite wisdom through infinite means' > > > > > > > On Dec 4, 2013, at 4:25 PM, Sam Siegel <[email protected]> wrote: > > > > > > look at the msgctl, msggegt, msgrcv, msgsnd and msgxrcv in the c/c++ > run > > > time documentation. sa22-7821. > > > > > > These queue functions can be wrapped in C programs. COBOL can call C. > > > I've not used them, but they look very useful. > > > > > > Since they are part of the C-runtime, they are include with the system > > even > > > if the c/c++ compiler is not licensed. > > > > > > Or you can google FIFO queue in "C" using google and get different > > > implementations. the main issue with getting code from google is the > > z/OS > > > difference in locking mechanisms. > > > > > > Or you can roll your own in ASM. > > > > > > > > >> On Wed, Dec 4, 2013 at 1:12 PM, Scott Ford <[email protected]> > > wrote: > > >> > > >> Sam, > > >> > > >> The answer is yes, but the ldap is java multi-threaded..I agree with a > > >> queue ..the question is that would the queue be in assembler I assume > > yes > > >> ... > > >> > > >> Scott ford > > >> www.identityforge.com > > >> from my IPAD > > >> > > >> 'Infinite wisdom through infinite means' > > >> > > >> > > >>> On Dec 4, 2013, at 2:15 PM, Sam Siegel <[email protected]> wrote: > > >>> > > >>> Scott - Do the security action messages and non-section action > messages > > >>> come into the process via the same tcp connection? The based on type > > of > > >>> processing (security vs.non-security) get processed by different > > >> sub-tasks? > > >>> > > >>> If the answer is yes, you may need 3 sub taks: > > >>> 1) tcp processing > > >>> 2) security processing > > >>> 3) non-security processing > > >>> > > >>> The task could be connected by queues. The tcp task would put a work > > >>> element on either the security or non-security queue based on > > processing > > >>> needs. > > >>> > > >>> the worker tasks would process the work and put the answer on a queue > > >> going > > >>> back to the tcp task. > > >>> > > >>> depending on how you configure the processing will determine the > number > > >> of > > >>> queues needed. For example: > > >>> 1 queue to security task from tcp task > > >>> 1 queue to non-security task from tcp task > > >>> 1 queue to tcp task to security task > > >>> 1 queue to tcp task to non-security task > > >>> With dedicated queues, you don't need to have "work" type > identifiers. > > >> The > > >>> queue defines the direction and purpose. > > >>> > > >>> If you use shared queues, then you need more info in the queue > message > > to > > >>> determine purpose ( sec vs. non-sec) and potentially direction. > > >>> > > >>> It may be easier (design, coding and testing) to use dedicated > queues. > > >>> > > >>> Sam > > >>> > > >>> > > >>> > > >>>> On Wed, Dec 4, 2013 at 10:53 AM, Scott Ford <[email protected] > > > > >> wrote: > > >>>> > > >>>> All: > > >>>> > > >>>> I have what seem to be a dumb question, but this is my first venture > > is > > >>>> real multi-tasking... > > >>>> > > >>>> We have a single thread Cobol STC that performs all the necessary > > >>>> functions we need to do, > > >>>> Two STCS perform Security Reconciliation and Provisioning just to > > >> provide > > >>>> everyone with a general idea . > > >>>> Our z/OS STCs talk via encrypted messages to a LDAP that resides on > > >>>> Windows or Linux or any *nix derivative. > > >>>> > > >>>> I am not 100% percent sure based on my reading we can multi-thread > > Cobol > > >>>> like we need to do . We can separate storage , i.e.; > > >>>> with Local-Storage, no issue. I need to have two threads running > > TCPIP. > > >> We > > >>>> currently use EZASOKET, which performs and works fine. I need one > > >> thread to > > >>>> issue various security commands via r_admin and the other thread > > >> performing > > >>>> other not security type calls to other programs. But can I do TCP > > calls > > >>>> from a second thread or do I have to issue a 'ATTACH' in assembler > and > > >> call > > >>>> the new Cobol code ? I am thinking about two separate listening > ports > > >>>> because our STC listens based on a parameter provided port. > > >>>> > > >>>> If I do the 'ATTACH' how would the Cobol program 'POST' back .. > > >>>> > > >>>> As always Best Regards, > > >>>> > > >>>> Scott J Ford > > >>>> Software Engineer > > >>>> http://www.identityforge.com/ > > >>>> > > >>>> > ---------------------------------------------------------------------- > > >>>> For IBM-MAIN subscribe / signoff / archive access instructions, > > >>>> send email to [email protected] with the message: INFO > > IBM-MAIN > > >>> > > >>> > ---------------------------------------------------------------------- > > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > > >>> send email to [email protected] with the message: INFO > IBM-MAIN > > >> > > >> ---------------------------------------------------------------------- > > >> For IBM-MAIN subscribe / signoff / archive access instructions, > > >> send email to [email protected] with the message: INFO > IBM-MAIN > > >> > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
