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
