Home > Archive > Cobol > August 2006 > Cobol, Cics, Soap
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]
|
|
| patrick.sannes@gmail.com 2006-08-07, 3:55 am |
| Hi there,
I have a question about the Cobol/Cics/Soap feature. At this moment I
retreive data from our mainframe trough Cobol (with the businesslogic
implemented in Natural.) In the example application they are creating a
data area of 16M. At this moment it is not possible for us to transfer
more then +/-500K from our mainframe over a webservice (this ammount is
including the tags.) When it is more, Cics goes under stress.
Does someone know if (and how) it is possible to transfer more?
Hopy someone can help us,
regards,
Patrick
| |
| Pete Dashwood 2006-08-07, 7:55 am |
|
<patrick.sannes@gmail.com> wrote in message
news:1154943768.094225.124210@n13g2000cwa.googlegroups.com...
> Hi there,
>
> I have a question about the Cobol/Cics/Soap feature. At this moment I
> retreive data from our mainframe trough Cobol (with the businesslogic
> implemented in Natural.) In the example application they are creating a
> data area of 16M. At this moment it is not possible for us to transfer
> more then +/-500K from our mainframe over a webservice (this ammount is
> including the tags.) When it is more, Cics goes under stress.
> Does someone know if (and how) it is possible to transfer more?
>
> Hopy someone can help us,
>
> regards,
> Patrick
Have you thought about why there is such a recommended limitation on Web
Services?
This is a very unwise use of SOAP. Online transactions (especially SOAP
ones) are best kept small. A 16MB data transmission in most environments is
less efficient than a series of smaller packages. SOAP is providing the XML
layer which is an overhead you take, in return for the advantage of platform
independence and RPCing. You can run a Web Service without this layer if you
don't need the platform independence.
If you DO need the platform independence (and if you are using your
mainframe to talk to other systems you probably do), then you should spend
some time DESIGNING the SOAP transactions. To simply take an application,
wrap it in SOAP, and call it a Web Service, is a certain recipe for
degrading the the whole network, providing bad response times, and really
achieving very little.
Use a series of linked transactions. You have little other option.
Your best course would be to study and understand something about XML as a
transport protocol, SOAP as a wrapper for components which are to become web
services, and the use of Remote Procedure Calls to access server based
components in general.
If you are using dot NET, you can avoid SOAP altogether.
Pete.
| |
|
| In article <4jono6F8ugqoU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><patrick.sannes@gmail.com> wrote in message
>news:1154943768.094225.124210@n13g2000cwa.googlegroups.com...
[snip]
[color=darkred]
>If you DO need the platform independence (and if you are using your
>mainframe to talk to other systems you probably do), then you should spend
>some time DESIGNING the SOAP transactions. To simply take an application,
>wrap it in SOAP, and call it a Web Service, is a certain recipe for
>degrading the the whole network, providing bad response times, and really
>achieving very little.
It will appear to be, however, a rather clear demonstration of an 'all ya
gotta do is' solution.
DD
| |
| Clark F Morris 2006-08-07, 7:55 am |
| On 7 Aug 2006 02:42:48 -0700, patrick.sannes@gmail.com wrote:
>Hi there,
>
>I have a question about the Cobol/Cics/Soap feature. At this moment I
>retreive data from our mainframe trough Cobol (with the businesslogic
>implemented in Natural.) In the example application they are creating a
>data area of 16M. At this moment it is not possible for us to transfer
>more then +/-500K from our mainframe over a webservice (this ammount is
>including the tags.) When it is more, Cics goes under stress.
>Does someone know if (and how) it is possible to transfer more?
>
>Hopy someone can help us,
>
Think about how long it will take to transfer 16 meg. Unless this is
a relatively infrequent occurrence, doing this will do nasty things to
your network regardless of platform at either end.
>regards,
>Patrick
| |
| patrick.sannes@gmail.com 2006-08-08, 3:55 am |
|
Pete Dashwood schreef:
> <patrick.sannes@gmail.com> wrote in message
> news:1154943768.094225.124210@n13g2000cwa.googlegroups.com...
>
> Have you thought about why there is such a recommended limitation on Web
> Services?
>
> This is a very unwise use of SOAP. Online transactions (especially SOAP
> ones) are best kept small. A 16MB data transmission in most environments is
> less efficient than a series of smaller packages. SOAP is providing the XML
> layer which is an overhead you take, in return for the advantage of platform
> independence and RPCing. You can run a Web Service without this layer if you
> don't need the platform independence.
>
> If you DO need the platform independence (and if you are using your
> mainframe to talk to other systems you probably do), then you should spend
> some time DESIGNING the SOAP transactions. To simply take an application,
> wrap it in SOAP, and call it a Web Service, is a certain recipe for
> degrading the the whole network, providing bad response times, and really
> achieving very little.
>
> Use a series of linked transactions. You have little other option.
>
> Your best course would be to study and understand something about XML as a
> transport protocol, SOAP as a wrapper for components which are to become web
> services, and the use of Remote Procedure Calls to access server based
> components in general.
>
> If you are using dot NET, you can avoid SOAP altogether.
>
> Pete.
I know you are right. I whish I do everything with small messages, but
the main problem is, there are some large overviews that need to be
produced. (This is what the business wants, so I can talk with them,
but at this moment it is a functional requirement...)
But if it is not possible to send larger messages, I have to look into
other options, like MQ. Then I can send it in multiple messages and
concat them in dotNet.
Maybe RPC is also a option, but I think then also youre limitation is a
commerea (like 32k?).
Patrick
| |
| Richard 2006-08-08, 3:55 am |
|
patrick.sannes@gmail.com wrote:
> I know you are right. I whish I do everything with small messages, but
> the main problem is, there are some large overviews that need to be
> produced. (This is what the business wants, so I can talk with them,
> but at this moment it is a functional requirement...)
> But if it is not possible to send larger messages, I have to look into
> other options, like MQ. Then I can send it in multiple messages and
> concat them in dotNet.
FTP ? SFTP ?
> Maybe RPC is also a option, but I think then also youre limitation is a
> commerea (like 32k?).
| |
| patrick.sannes@gmail.com 2006-08-08, 3:55 am |
|
Richard schreef:
> patrick.sannes@gmail.com wrote:
>
>
> FTP ? SFTP ?
>
It is a realtime webapplication getting data from our corporate
database. The user know it takes like 4 seconds to retreive (it will
never be 16MB, but I think max 2, but that is more then the 500K I can
do now), so it is not the most efficient (and workable solution) to use
FTP)
[color=darkred]
| |
| patrick.sannes@gmail.com 2006-08-08, 3:55 am |
|
Clark F Morris wrote:
> On 7 Aug 2006 02:42:48 -0700, patrick.sannes@gmail.com wrote:
>
> Think about how long it will take to transfer 16 meg. Unless this is
> a relatively infrequent occurrence, doing this will do nasty things to
> your network regardless of platform at either end.
It is something that will happen very infrequent. It is a bulk of data
I have to transfer. With a maximum of 2000 rows. So we calculated that
It wil be a maximum of 2Meg. So I hope someone can help me out here.
(or can tell me that it is not possible.. ) Then I have to create an
other solution for those functions. The rest of the app don't have much
data to transfer.
[color=darkred]
| |
| Joe Zitzelberger 2006-08-08, 7:55 am |
| In article <1154943768.094225.124210@n13g2000cwa.googlegroups.com>,
patrick.sannes@gmail.com wrote:
> Hi there,
>
> I have a question about the Cobol/Cics/Soap feature. At this moment I
> retreive data from our mainframe trough Cobol (with the businesslogic
> implemented in Natural.) In the example application they are creating a
> data area of 16M. At this moment it is not possible for us to transfer
> more then +/-500K from our mainframe over a webservice (this ammount is
> including the tags.) When it is more, Cics goes under stress.
> Does someone know if (and how) it is possible to transfer more?
>
> Hopy someone can help us,
>
> regards,
> Patrick
You might check the sizing parms on your CICS region. Five hundred K
seems like a very small thing to stress CICS.
Much of this depends on your installation. There are native CICS parms
as well as different products that can control how much memory a tran
can consume, how much CPU, etc. Then there are control parms for the
entire region as well. If these values are set too small, you could
have issues.
| |
| patrick.sannes@gmail.com 2006-08-09, 7:55 am |
|
Joe Zitzelberger wrote:
> In article <1154943768.094225.124210@n13g2000cwa.googlegroups.com>,
> patrick.sannes@gmail.com wrote:
>
>
> You might check the sizing parms on your CICS region. Five hundred K
> seems like a very small thing to stress CICS.
>
> Much of this depends on your installation. There are native CICS parms
> as well as different products that can control how much memory a tran
> can consume, how much CPU, etc. Then there are control parms for the
> entire region as well. If these values are set too small, you could
> have issues.
Found the problem. We turned on ALL31. But it worked after I set the
STACK(ANYWHERE) So no more stress and a working situation.
| |
|
| In article <1155122442.419350.199200@i3g2000cwc.googlegroups.com>,
<patrick.sannes@gmail.com> wrote:
>
>Joe Zitzelberger wrote:
[snip]
[color=darkred]
[snip]
[color=darkred]
>
>Found the problem. We turned on ALL31. But it worked after I set the
>STACK(ANYWHERE) So no more stress and a working situation.
Pardon my display of ignorance here - as opposed, of course, to my
displays of ignorance elsewhere - but these (ALL31, STACK(ANYWHERE)) are
not interpreter or compiler options/directives that I can recall. Where
do they get turned on/set and by what mechanisms?
DD
| |
| William M. Klein 2006-08-09, 7:55 am |
| STACK and ALL31 are LE run-time options. There actually was a "change in
behavior" that was documented a few releases ago in the LE migration guide on
ALL31. If you actually CARE, I can get it for you.
--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:ebcgvu$aog$1@reader2.panix.com...
> In article <1155122442.419350.199200@i3g2000cwc.googlegroups.com>,
> <patrick.sannes@gmail.com> wrote:
>
> [snip]
>
>
> [snip]
>
>
> Pardon my display of ignorance here - as opposed, of course, to my
> displays of ignorance elsewhere - but these (ALL31, STACK(ANYWHERE)) are
> not interpreter or compiler options/directives that I can recall. Where
> do they get turned on/set and by what mechanisms?
>
> DD
>
| |
|
| In article <7OlCg.253409$1Q1.122198@fe03.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>STACK and ALL31 are LE run-time options. There actually was a "change in
>behavior" that was documented a few releases ago in the LE migration guide on
>ALL31. If you actually CARE, I can get it for you.
Thanks much, Mr Klein... but no need to trouble yourself, my curiousity
is, for the moment, well-sated.
DD
>
>--
>Bill Klein
> wmklein <at> ix.netcom.com
><docdwarf@panix.com> wrote in message news:ebcgvu$aog$1@reader2.panix.com...
[snip]
>
>
| |
| Clark F Morris 2006-08-09, 6:55 pm |
| On Wed, 9 Aug 2006 11:30:06 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <1155122442.419350.199200@i3g2000cwc.googlegroups.com>,
> <patrick.sannes@gmail.com> wrote:
>
>[snip]
>
>
>[snip]
>
>
>Pardon my display of ignorance here - as opposed, of course, to my
>displays of ignorance elsewhere - but these (ALL31, STACK(ANYWHERE)) are
>not interpreter or compiler options/directives that I can recall. Where
>do they get turned on/set and by what mechanisms?
They are z/OS (or z/VM) Language Environment parameters that can be
set by the installation when customizing Language Environment (LE),
modified by Parm on a batch execution statement or probably set by a
CICS mechanism for CICS. LE is the common run-time environment for
all languages and has been for almost a decade now.
>
>DD
| |
| Michael Wojcik 2006-08-09, 6:55 pm |
|
In article <1155021975.397187.205590@i42g2000cwa.googlegroups.com>, patrick.sannes@gmail.com writes:
> Richard schreef:
There's no need to change the transport. SOAP is not a great choice
for sending large messages - it's a very poor one, in fact, if
they're going to be encoded as XML - but there are W3C specifications
for including native-encoding binary material in SOAP messages: SOAP
with Attachments[1] and XML-binary Optimized Packaging[2]. SWA and
XOP have more overhead than transmitting only the raw data, but
amortized over a large message it's often tolerable (depending on the
application).
Your SOAP implementation may provide one or both of those mechanisms.
To be frank, I'd suggest that if you weren't aware of them, you're
not sufficiently familiar with SOAP and/or your toolkit to make an
informed decision about how best to approach this problem, so some
research is in order.
And there are other, better TCP-based application transports, such as
HTTP and, as Richard suggested, FTP and (if a secure channel is
required) SFTP.
[color=darkred]
This puts the burden in the wrong place. There are plenty of
transports capable of sending large messages; reconstructing them
in the application layer indicates a design failure.
[color=darkred]
> It is a realtime webapplication getting data from our corporate
> database. The user know it takes like 4 seconds to retreive (it will
> never be 16MB, but I think max 2, but that is more then the 500K I can
> do now), so it is not the most efficient (and workable solution) to use
> FTP)
FTP is likely the most efficient solution available. It dedicates
a conversation to the application data, which it sends without any
overhead whatsoever, as fast as the connection will take it. What
makes you think you can do better?
Do not confuse the FTP protocol with FTP clients and servers you
may have used.
There are open-source implementations of FTP. I don't know if there
are any for CICS, but you really only need one in the client, if you
have the IBM FTP server available from CICS. Dump the multimegabyte
message into a dataset and let the client application transfer it
using FTP.
For that matter, I think there may be a .NET FTP implementation as
part of WCF (Windows Communication Foundation, formerly "Indigo").
[color=darkred]
"RPC" doesn't mean anything in this context. It's a broad term for
any mechanism for transferring control and data between execution
domains (hosts).
[1] http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/
[2] http://www.w3.org/TR/2005/REC-xop10-20050125/
--
Michael Wojcik michael.wojcik@microfocus.com
[After the lynching of George "Big Nose" Parrot, Dr. John] Osborne
had the skin tanned and made into a pair of shoes and a medical bag.
Osborne, who became governor, frequently wore the shoes.
-- _Lincoln [Nebraska] Journal Star_
| |
|
| In article <4gujd21bjvlose13pv62d7mc5hruafmu3q@4ax.com>,
Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:
>On Wed, 9 Aug 2006 11:30:06 +0000 (UTC), docdwarf@panix.com () wrote:
>
[snip]
[color=darkred]
>
>They are z/OS (or z/VM) Language Environment parameters that can be
>set by the installation when customizing Language Environment (LE),
>modified by Parm on a batch execution statement or probably set by a
>CICS mechanism for CICS. LE is the common run-time environment for
>all languages and has been for almost a decade now.
Thanks much!
DD
|
|
|
|
|