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 <scott_j_f...@yahoo.com> 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 <s...@pscsi.net> 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 <scott_j_f...@yahoo.com> > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
