Home > Archive > Cobol > May 2006 > TSQ/TDQ purpose?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| arrbee 2006-05-03, 7:55 am |
| Hi, we have DFHCOMMAREA to move data between main program and
subprogram in a CICS-COBOL programming? Why do we use TSQs and TDQs?
I am reading CICS by Kageyama. I am learning CICS but don't know about
these concepts.
Please explain in detail.
Thanks in advance.
| |
|
| In article <1146657576.942544.49500@y43g2000cwc.googlegroups.com>,
arrbee <arrbee@gmail.com> wrote:
>Hi, we have DFHCOMMAREA to move data between main program and
>subprogram in a CICS-COBOL programming? Why do we use TSQs and TDQs?
>
>I am reading CICS by Kageyama. I am learning CICS but don't know about
>these concepts.
It may be a bit premature to deal with CICS before you are able to
demonstate competency in batch processing; consider the advice behind
'First you learn how to walk, *then* you learn how to run.'
DD
kk
| |
| sgbojo@gmail.com 2006-05-03, 6:55 pm |
|
arrbee wrote:
> Hi, we have DFHCOMMAREA to move data between main program and
> subprogram in a CICS-COBOL programming? Why do we use TSQs and TDQs?
>
> I am reading CICS by Kageyama. I am learning CICS but don't know about
> these concepts.
>
> Please explain in detail.
>
> Thanks in advance.
Here is a brief explanation:
http://www.felgall.com/cics9.htm
| |
| arrbee 2006-05-03, 9:55 pm |
| Thanks to sgbojo.
| |
| Arnold Trembley 2006-05-04, 3:55 am |
|
sgbojo@gmail.com wrote:
> arrbee wrote:
>
>
>
> Here is a brief explanation:
>
> http://www.felgall.com/cics9.htm
>
That's useful information, but it's only the beginning. I work with a
CICS application that uses Temp Storage queues extensively. We use
MAIN rather than AUX TS queues, because memory is faster than VSAM
file. A TS queue can be thought of as a Relative file, in the sense
that a named TS Queue has multiple records (items) identified by item
number. But you can also use a TS Queue as a storage area identified
by key, in the sense that each TS Queue has a unique 8-character name.
You can default to item(1) when reading or writing a named TS Queue.
For example, we have in-core memory tables for rapid lookup of
application data. The in-core table itself is an assembler program
consisting of DC (Define Constant) statements only, no executable
code. The table is loaded into memory during CICS PLTPI
initialization and marked RESIDENT, so the "table" can never be paged
out. Then we store the entry point address of the table in a named
Temp Storage Queue. Every program in the application can now read the
named TS Queue, obtain the entry point address, and map the in-core
table into the CICS COBOL program's linkage section. The in-core
table can be read (or updated) by any program. Some of these in-core
tables are multi-megabytes in size, and all of them now reside above
the line, once you get to COBOL II or higher.
Another use of TS Queues involves saving the results of a VSAM browse
(using item numbers of course) across executions of a
pseudo-conversational program with BMS MAP.
CICS itself uses Transient Data Queues for generating and printing
diagnostic messages from various CICS services. We have used TD
Queues to read a QSAM file at startup to obtain application
configuration parameters (control cards). This kind of thing also
requires a DCT (Destination Control Table) entry for the DDNAME of the
external QSAM file.
arrbee's original question was why use TSQ's and TDQ's, when he could
already use DFHCOMMAREA to pass data to the LINK'ed or XCTL'ed
program. But DFHCOMMAREA, TSQ's, and TDQ's are not the only option.
When you define your PCT (Transaction Entry) you can also specifiy the
TWA size (Transaction Work Area). This is an area of storage reserved
for your transaction and terminal(facility). It's unique to your
invocation of the program, and it exists for the life of the
transaction. Two or more users can execute the same program, but each
transaction using that program has its own unique TWA. Any CICS
program can obtain the address of its own TWA, map in into its COBOL
linkage section, and read or write any data to it. I think the
maximum TWA size might be limited to 32K bytes, but that would still
allow you pass a lot of data from one program to the next. And using
TWA used to be significantly faster than DFHCOMMAREA. I'm not sure if
there still is as big a performance difference.
--
http://arnold.trembley.home.att.net/
| |
| arrbee 2006-05-04, 3:55 am |
| So nice of you Arnold. It is a very good information for a beginner
like me.
Thanks a ton. I would come back here if I need more details when I
start practicing more CICS.
| |
|
| In article <9ah6g.39587$eR6.3689@bgtnsc04-news.ops.worldnet.att.net>,
Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
[snip]
>For example, we have in-core memory tables for rapid lookup of
>application data. The in-core table itself is an assembler program
>consisting of DC (Define Constant) statements only, no executable
>code.
[snip]
>And using
>TWA used to be significantly faster than DFHCOMMAREA. I'm not sure if
>there still is as big a performance difference.
Thanks much, Mr Trembley... reviewing such material makes me realise how
stagnant I've grown on my present site.
DD
| |
| Frank Swarbrick 2006-05-07, 6:55 pm |
| Arnold Trembley<arnold.trembley@worldnet.att.net> 05/04/06 12:28 AM >>>
>
>That's useful information, but it's only the beginning. I work with a
>CICS application that uses Temp Storage queues extensively. We use
>MAIN rather than AUX TS queues, because memory is faster than VSAM
>file. A TS queue can be thought of as a Relative file, in the sense
>that a named TS Queue has multiple records (items) identified by item
>number. But you can also use a TS Queue as a storage area identified
>by key, in the sense that each TS Queue has a unique 8-character name.
> You can default to item(1) when reading or writing a named TS Queue.
>
>For example, we have in-core memory tables for rapid lookup of
>application data. The in-core table itself is an assembler program
>consisting of DC (Define Constant) statements only, no executable
>code. The table is loaded into memory during CICS PLTPI
>initialization and marked RESIDENT, so the "table" can never be paged
>out. Then we store the entry point address of the table in a named
>Temp Storage Queue. Every program in the application can now read the
>named TS Queue, obtain the entry point address, and map the in-core
>table into the CICS COBOL program's linkage section. The in-core
>table can be read (or updated) by any program. Some of these in-core
>tables are multi-megabytes in size, and all of them now reside above
>the line, once you get to COBOL II or higher.
Just curious, but why do you use a TS Q to hold the entry point? We have
something similar, and all we do is
EXEC CICS LOAD
SET (ADDRESS OF LS-INCORE-TABLE-AREA)
PROGRAM('INCRTBL')
HOLD
END-EXEC
This loads the "assembler program" (the in-core table) INCRTBL in to memory
and points LS-INCORE-TABLE-AREA to its entry point.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| William M. Klein 2006-05-07, 6:55 pm |
| I have deleted all the comments (some of which were very useful/interesting) and
just wanted to mention that for those on z/OS (sorry about that Frank <G> ), you
might want to look at "channels" available with CICS TS 3.1. Although targeted
at "greater than 32K commareas", I think they might also be useful for some of
what historically went into TSQ/TDQ.
They may also be useful for those getting into XML - as they provide
"auto-magic" UTF (Unicode) conversion facilities.
NOTE:
I have no personal experience with them, but did think they look interesting.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Frank Swarbrick 2006-05-07, 6:55 pm |
| William M. Klein<wmklein@nospam.netcom.com> 05/04/06 1:56 PM >>>
>I have deleted all the comments (some of which were very
useful/interesting) and
>just wanted to mention that for those on z/OS (sorry about that Frank <G> ),
you
>might want to look at "channels" available with CICS TS 3.1. Although
targeted
>at "greater than 32K commareas", I think they might also be useful for some
of
>what historically went into TSQ/TDQ.
>
>They may also be useful for those getting into XML - as they provide
>"auto-magic" UTF (Unicode) conversion facilities.
>
>NOTE:
> I have no personal experience with them, but did think they look
interesting.
You make me  , Bill.
:-)
Check out the following:
http://www.vse2pdf.com/WAVV2006/wav...voteresults.htm
http://www.vse2pdf.com/WAVV2006/WAVV200614.htm
Unfortunately most VSEers didn't know anything about this feature
beforehand. Still, I got a pretty good vote all things considered. Will it
do any good? Who knows...
The thing I like about channels&containers is that, like commareas, they go
away automatically when the task is terminated (unless, of course, you do
RETURN with COMMAREA/CHANNEL). This saves you from having to make sure you
delete the TS queue!
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Arnold Trembley 2006-05-07, 6:55 pm |
|
Frank Swarbrick wrote:
> (snip)
>
> Just curious, but why do you use a TS Q to hold the entry point? We have
> something similar, and all we do is
> EXEC CICS LOAD
> SET (ADDRESS OF LS-INCORE-TABLE-AREA)
> PROGRAM('INCRTBL')
> HOLD
> END-EXEC
>
> This loads the "assembler program" (the in-core table) INCRTBL in to memory
> and points LS-INCORE-TABLE-AREA to its entry point.
>
> Frank
That's a very good question. Before I explain why we do it, let me
just say that we've been doing it this way for nearly 20 years, and we
are very satisfied with the results. But that doesn't mean it's the
only way to do it. I can't even be sure that it's the best possible
solution.
This particular CICS application has a series of programs that run
during PLTPI, the initialization phase of CICS. The first set of
programs LOADS the table programs into memory, and populates them from
VSAM files. The application also checks the date/time stamp contained
in the file data, so that CICS startup can be aborted if we don't have
current files.
Then there is another series of programs that initializes our
Communications layer. We read control cards from a TDQ to configure
various aspects of our COMM layer. Over the years, our COMM layer has
been converted from BTAM to VTAM/SNA, then to CA-Interlink TCP/IP and
finally to IBM TCP/IP. Our COMM layer is table-driven and completely
separated from our application processing. For outbound messages, the
application communicates with the COMM layer by LINKing to an
interface program that initiates COMM layer message processing.
But one of the things our COMM layer does during its initialization is
START several conversational, long-running tasks in our application
layer to process inbound network messages. The actual number of
started tasks is a control card parameter. Then our COMM layer
"rotors" inbound messages across all the available application tasks
in order to balance the workload.
So, now we have our application tasks starting up, how do they obtain
addressability to the in-core tables? The programs that loaded the
in-core tables into memory have terminated. So we can't ask them
where the tables are.
I suppose one way this problem could have been solved would be to
write code to interrogate the CICS internal directory for named
programs and where they are loaded in memory. I think that looked
like the hard way to the original designers, especially since they
were working with CICS 1.6.1 for MVS 3 (this was back in 1987).
The answer is that one of our in-core tables is a "Global Application
Pointer Table" for want of a better term. It has the addresses,
key-lengths, and entry-lengths of all the in-core tables stored in it,
plus other application startup parameters. The program that built the
GAPT also wrote a named Temp Storage Queue, let's call it GAPTADDR,
and stored the load address of the GAPT in the TS Queue.
So, each Conversational, long-running application task simply reads
the GAPTADDR TSQ during its initialization, maps the GAPT into its
linkage section, and copies critical information and addresses into
its TWA (Transaction Work Area). Then the program falls into its main
processing loop, which is driven by an EXEC CICS RETRIEVE WAIT
command. The COMM Layer receives a message from the network and
START's an appropriate application task, passing the message to it.
The application task receives the message using an EXEC CICS RETRIEVE
WAIT command, LINKs or XCTLS to other program to process the message,
and eventually LINKS to the COMM layer interface program to send the
outbound network message. The it returns to its main processing loop
so it can RETRIEVE the next inbound message. Any program LINK'ed or
XCTL'ed off the top program in the Application task gets its addresses
and other parameter data out of the local task TWA.
The GAPT is an assembler program that looks something like this:
WS120010 CSECT * BEGINNING OF STORAGE
PRINT GEN * PRINT ALL GENERATED STATEMENTS
DC A(GAPT0001) * ADCON ADDRESS FOR THE GLOBAL TABLE
*
EYECATCH GLOBAL-APPLICATION-POINTER-TABLE
* * MACRO USED TO PLACE LITERAL AND
* * DATE/TIME STAMP IN THE IN-CORE TABLE
GAPT0001 DC 100D'0' * 100 DOUBLEWORDS
LTORG
END
Most of our tables also have an RMODE ANY statement after the CSECT.
We load the table into memory from a CICS COBOL program much the same
way you do:
EXEC CICS LOAD
PROGRAM (300-PROGRAM-WS120010)
SET (2000-ADDR-GLOBAL-POINTER-TABLE)
HOLD
RESP (800-EIBRESP)
END-EXEC.
IF 800-EIBRESP EQUAL ZERO
MOVE 2000-ADDR-GLOBAL-POINTER-TABLE
TO 1000-BLL-GAPTBAR
800-GAPT-ADDRESS
SET ADDRESS OF 3000-GLOBAL-POINTER-TABLE
TO 1000-BLL-GAPTBAR-PTR
ELSE
PERFORM 9000-PROCESS-LOAD ERROR
END-IF.
The same program loads the table program into memory, and populates it
with data, also writes a very short Temp Storage Queue record
containing the address of the table.
During program initialization, the started application task reads the
GAPTADDR temp storage queue and goes through a similar process to
establish addressability to the Global Application Pointer table, and
Bob's your Uncle.
After the first program in the application task builds its TWA,
subsequent programs in the same task get to the TWA with code like this:
EXEC CICS ADDRESS
TWA (1000-BLL-TWA)
NOHANDLE
END-EXEC.
SET ADDRESS OF 2100-TRANSACTION-WORK-AREA
TO 1000-BLL-TWA-PTR.
For the uninitiated, addresses and pointers in CICS are what we used
to call BLL Cell address. Before COBOL II they were in the Linkage
section. After COBOL II they go in the Working-Storage Section, with
definitions something like this:
01 1000-BLL-CELL-ADDRESSES.
05 1000-BLL-TWA PIC 9(8) COMP VALUE 0.
05 1000-BLL-TWA-PTR REDEFINES
1000-BLL-TWA USAGE IS POINTER.
05 1000-BLL-GAPTBAR PIC 9(8) COMP VALUE 0.
05 1000-BLL-GAPTBAR-PTR REDEFINES
1000-BLL-GAPTBAR USAGE IS POINTER.
Also, since not every CICS programmer gets to do this, any area that
you establish addressability to using this method will be in the
Linkage section of your COBOL program. Of course, it helps to have a
copybook for the layout of your TWA or Global Application Pointer
table, or any other in-core table.
So the short answer to your question is that we use a TSQ to store the
location of the in-core table because the program that built the
in-core table has already terminated. So we have to save the address
of the table in a way that another CICS Task can easily acquire it.
It might not be the best way. It's certainly complicated enough. But
it works for us.
With kindest regards,
--
http://arnold.trembley.home.att.net/
| |
| Frank Swarbrick 2006-05-07, 6:55 pm |
| Arnold Trembley<arnold.trembley@worldnet.att.net> 05/04/06 10:39 PM >>>
>Frank Swarbrick wrote:
have[color=darkred]
memory[color=darkred]
>
>That's a very good question. Before I explain why we do it, let me
>just say that we've been doing it this way for nearly 20 years, and we
>are very satisfied with the results. But that doesn't mean it's the
>only way to do it. I can't even be sure that it's the best possible
>solution.
[detail of solution deleted]
Yikes! I certainly did not mean for you to go through all of that! But it
actually was quite interesting, and in someways comparible to a "TCP/IP card
message switching" interface that I wrote.
One thing that I like about your solution, something that I had never
considered, is the use of the TWA. Here's a (hopefully short) overview of
how my system currently works:
- Receive message on a TCP socket
- START new task passing the received message *prefixed* with a "connection
ID"
- New task does various things, linking and XCTLing when necessary, passing
the connection ID, the message, and other information (this part already
existed; I did not write it)
- New task needs to respond now, so it calls an interface program, passing
the outgoing message prefixed with a header containing the "connection ID"
and a few other things.
- The interface program writes the message to a TD queue and posts and ECB
to let the long running "network manager" know that a new outgoing message
is waiting.
- The network manager program unblocks (it was waiting on TCP sockets and
the ECB), reads the message from the TD queue and sends it out.
I like how you use the TWA to hold information, rather than what we do which
is pass the information around in the COMMAREA. Of course that logic was
already in place in that system, but I did implement the interface in to an
inhouse written Internet Banking application and it might be useful there.
I'm not sure if we use the TWA anywhere right now.
What kind of processing is your system doing? Is it card authorizations, by
chance?
>So the short answer to your question is that we use a TSQ to store the
>location of the in-core table because the program that built the
>in-core table has already terminated. So we have to save the address
>of the table in a way that another CICS Task can easily acquire it.
>
>It might not be the best way. It's certainly complicated enough. But
>it works for us.
It certainly is, but it sounds like it works, so I certainly would not
recommend changing it "just because".
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Arnold Trembley 2006-05-07, 6:55 pm |
|
Frank Swarbrick wrote:
> Arnold Trembley<arnold.trembley@worldnet.att.net> 05/04/06 10:39 PM >>>
>
> [detail of solution deleted]
>
> Yikes! I certainly did not mean for you to go through all of that!
It's no problem. I'm hoping the additional detail might be helpful to
other CICS programmers.
> But it
> actually was quite interesting, and in someways comparible to a "TCP/IP card
> message switching" interface that I wrote.
>
> One thing that I like about your solution, something that I had never
> considered, is the use of the TWA.
I think (although I don't have confirmation) that the performance
difference between using TWA and COMMAREA is that when you LINK or
XCTL with a COMMAREA, CICS probably has to do a GETMAIN to create the
COMMAREA and a FREEMAIN to release when it's no longer needed. TWA is
a piece of storage that is already owned by your task, so using TWA
would not require additional CICS API calls under the covers.
> Here's a (hopefully short) overview of
> how my system currently works:
>
> - Receive message on a TCP socket
> - START new task passing the received message *prefixed* with a "connection
> ID"
> - New task does various things, linking and XCTLing when necessary, passing
> the connection ID, the message, and other information (this part already
> existed; I did not write it)
> - New task needs to respond now, so it calls an interface program, passing
> the outgoing message prefixed with a header containing the "connection ID"
> and a few other things.
> - The interface program writes the message to a TD queue and posts and ECB
> to let the long running "network manager" know that a new outgoing message
> is waiting.
> - The network manager program unblocks (it was waiting on TCP sockets and
> the ECB), reads the message from the TD queue and sends it out.
That's almost exactly how we do it, too.
Here's another possibly interesting detail. For every network message
we process we have to write a transaction log record to an ESDS VSAM
file, for diagnostic purposes and for later batch processing, billing
for example. We don't want our long-running task to wait on the file
I/O, which would increase our message time-in-system. We want to push
the response message out as fast as we can.
So when we need to write a log record, we build it and START an
asynchronous file writer task, passing the log record image as the
START'ed message.
This is a good solution, but we've learned recently that the same
thing can be done by writing the log record to a TDQ (Transient Data
Queue), whose destination would be the asynchronous file-writer Task.
Using the TDQ method may very well be more efficient.
We've recently started using MQ Series to send and receive messages to
remote CICS applications, and we are using the TDQ method to hand off
the messages we send, rather than STARTing the MQ Series "Send" Task.
>
> I like how you use the TWA to hold information, rather than what we do which
> is pass the information around in the COMMAREA. Of course that logic was
> already in place in that system, but I did implement the interface in to an
> inhouse written Internet Banking application and it might be useful there.
> I'm not sure if we use the TWA anywhere right now.
>
> What kind of processing is your system doing? Is it card authorizations, by
> chance?
Yes.
>
>
>
>
> It certainly is, but it sounds like it works, so I certainly would not
> recommend changing it "just because".
> Frank
If it's working and the performance is acceptable there's no reason to
change. But if performance is not good enough (measured in
"Transactions per Second" with subsecond response time), then we will
build alternate approaches and stress test all of them to see which
way works best.
With kindest regards,
--
http://arnold.trembley.home.att.net/
| |
| Frank Swarbrick 2006-05-08, 6:55 pm |
| Arnold Trembley<arnold.trembley@worldnet.att.net> 05/06/06 12:48 AM >>>
>Frank Swarbrick wrote:
>
>It's no problem. I'm hoping the additional detail might be helpful to
>other CICS programmers.
>
card[color=darkred]
>
>I think (although I don't have confirmation) that the performance
>difference between using TWA and COMMAREA is that when you LINK or
>XCTL with a COMMAREA, CICS probably has to do a GETMAIN to create the
>COMMAREA and a FREEMAIN to release when it's no longer needed. TWA is
>a piece of storage that is already owned by your task, so using TWA
>would not require additional CICS API calls under the covers.
Sounds right. Interestingly, the current (2001) version of Murach's "CICS
for the COBOL Programmer" refers to the CWA, TWA and TCTUA saying "You'll
hear and read about the last two areas, but they're largely holdovers from
macro-level CICS and seldem used in command-level programming." Hmm, I
don't know what he thinks replaced them, but the TWA sounds useful to me,
and I *know* that the TCTUA is useful.
"connection[color=darkred]
passing[color=darkred]
passing[color=darkred]
ID"[color=darkred]
ECB[color=darkred]
message[color=darkred]
and[color=darkred]
>
>That's almost exactly how we do it, too.
Great minds? :-)
>Here's another possibly interesting detail. For every network message
>we process we have to write a transaction log record to an ESDS VSAM
>file, for diagnostic purposes and for later batch processing, billing
>for example. We don't want our long-running task to wait on the file
>I/O, which would increase our message time-in-system. We want to push
>the response message out as fast as we can.
>
>So when we need to write a log record, we build it and START an
>asynchronous file writer task, passing the log record image as the
>START'ed message.
I had considered doing that, but in the end I never got around to it.
Mostly because I didn't want to deal with determining how large I would have
to make the log file. How do you deal with this issue?
>This is a good solution, but we've learned recently that the same
>thing can be done by writing the log record to a TDQ (Transient Data
>Queue), whose destination would be the asynchronous file-writer Task.
> Using the TDQ method may very well be more efficient.
Very true. Don't know if it is more efficient, but it may well be.
>We've recently started using MQ Series to send and receive messages to
>remote CICS applications, and we are using the TDQ method to hand off
>the messages we send, rather than STARTing the MQ Series "Send" Task.
We don't have MQ Series. Too expensive, or so I am told.
which[color=darkred]
was[color=darkred]
an[color=darkred]
there.[color=darkred]
by[color=darkred]
>
>Yes.
Thought it might be! You know, it seems like very CICS shop that does card
authorizations over TCP/IP has to reinvent this particular wheel. Seems
like this would have been a great product/interface for someone to have
developed in the late 90s. I've pondered a requirement to IBM for CICS for
this, but I've never been able to think of a "generic" enough way to word
it. Seems like the 3270 bridge could be somehow utilized, but the whole
"listener" piece just doesn't seem to fit in to the "terminal" paradigm. (I
am constantly trying to explain to our network monitors why they can't
"connect" to our ATMs, that the ATMs must connect to us.)
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Arnold Trembley 2006-05-09, 3:55 am |
|
Frank Swarbrick wrote:
> (snip)
> Sounds right. Interestingly, the current (2001) version of Murach's "CICS
> for the COBOL Programmer" refers to the CWA, TWA and TCTUA saying "You'll
> hear and read about the last two areas, but they're largely holdovers from
> macro-level CICS and seldem used in command-level programming." Hmm, I
> don't know what he thinks replaced them, but the TWA sounds useful to me,
> and I *know* that the TCTUA is useful.
I have to admit I have never used the CWA or the TCTUA. We use a lot
of "dummy" terminals (or facility ID's) to force certain tasks to be
single-threaded.
> (more snippage)
>
>
> I had considered doing that, but in the end I never got around to it.
> Mostly because I didn't want to deal with determining how large I would have
> to make the log file. How do you deal with this issue?
Well, it's not really a problem for us, for proprietary reasons I'm
probably not supposed to go into. But suffice it to say that
transaction log file size is under 2 gig. We've considered extended
VSAM to allow us to exceed the 4 gigabyte limit, but we are extremely
unlikely to need it anytime soon.
The individual transaction log records are variable in length, with
the maximum size a little over 1K bytes. The average is about half that.
> (snip some more)
> We don't have MQ Series. Too expensive, or so I am told.
Fortunately, I didn't have to justify the purchase. It's a pretty
interesting tool.
> (snip)
> Thought it might be! You know, it seems like very CICS shop that does card
> authorizations over TCP/IP has to reinvent this particular wheel. Seems
> like this would have been a great product/interface for someone to have
> developed in the late 90s. I've pondered a requirement to IBM for CICS for
> this, but I've never been able to think of a "generic" enough way to word
> it. Seems like the 3270 bridge could be somehow utilized, but the whole
> "listener" piece just doesn't seem to fit in to the "terminal" paradigm. (I
> am constantly trying to explain to our network monitors why they can't
> "connect" to our ATMs, that the ATMs must connect to us.)
>
> Frank
I think we used 3270 bridge for a short time. It didn't really
interface with our VPN, but it allowed certain users to access one of
our green screens over the web. We had to modify the BMS map to
generate an HTML component, and there was a Unix box somewhere in the
middle. We also had to modify our infrastructure slightly because
3270 bridge wouldn't allow our BMS map transaction to be started by
the network inbound interface. But for a typical BMS map program,
there would be no difference. CICS thinks it's talking to a 3270, but
the user is out on the web with a fancy interface.
TCP/IP is a whole different way of communicating. A socket is
completely bi-directional. Our application, built originally for
BTAM, relied on one-way connections, with CICS tasks servicing inbound
ports and different tasks servicing outbound ports. Our COMM layer
kind of fakes this out, so we didn't need to change our application layer.
With kindest regards,
--
http://arnold.trembley.home.att.net/
|
|
|
|
|