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
