Cobol, Cics, Soap

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

<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]

>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

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

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 i
s
> less efficient than a series of smaller packages. SOAP is providing the XM
L
> layer which is an overhead you take, in return for the advantage of platfo
rm
> independence and RPCing. You can run a Web Service without this layer if y
ou
> 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 w
eb
> 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

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?).

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)
 

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.
 

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.

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.