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
