Web Services (Retouch)

I'm back again into the drawing board here :)

Tried Pete Dashwood/Jimmy Gavan web services Cobol codes and now
"fitting" my own WSDL files created into MS SOAP toolkit v3 (accessing
enterprise COM/COM+). It works perfectly well as I put it... thanks to
them. Tried it with 128kbps connectivity and it is processing in
1:09sec per trip (read/write/update).

The problem I had is when the connectivity shuts down in the middle...
the OLE GUI system return with a dialog box (or window) with a "Yes/
No" message. Of course it is needed to view detailed error of the
process, say error 65573... but then I do not need it. What I need is
my own dialog window saying the "Connectivity is disconnected...".

Could we possibly bypass the default window instead, and just abort
any processing if in case there is an offline connection?

"Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
news:1182654551.771351.181830@e9g2000prf.googlegroups.com...
> I'm back again into the drawing board here :)
>
> Tried Pete Dashwood/Jimmy Gavan web services Cobol codes and now
> "fitting" my own WSDL files created into MS SOAP toolkit v3 (accessing
> enterprise COM/COM+). It works perfectly well as I put it... thanks to
> them. Tried it with 128kbps connectivity and it is processing in
> 1:09sec per trip (read/write/update).

That's across an Enterprise LAN? Or via the Internet? You can make it
quicker by making the web service "smarter". I just got mine down to under a
second for batch access,  running a 16000 mile round trip across the
Internet and 4000 lines of OO COBOL on the server (not all of which get
executed, of course). Smarten up the Web Service so it only instantiates the
COM object when it has to, and smarted up the client so it only instantiates
a web service instance when it has to... Instantiation and DB connection
(with consequent buffer loads) are the big time takers...
>
> The problem I had is when the connectivity shuts down in the middle...
> the OLE GUI system return with a dialog box (or window) with a "Yes/
> No" message. Of course it is needed to view detailed error of the
> process, say error 65573... but then I do not need it. What I need is
> my own dialog window saying the "Connectivity is disconnected...".
>
> Could we possibly bypass the default window instead, and just abort
> any processing if in case there is an offline connection?
>

I think you're using MF so I don't know your environment intimately, but OLE
doesn't have a GUI system as such. If you are seeing a dialog box you need
to know where it is coming from. If the OLE support Class provided by MF
raises it, then you should be able to trap it with COM/OLE Exception
processing; if it is being raised on the Client when it detects that the
connection is broken it should also be trappable.  Either way, find where it
comes from and trap it with Exception Class processing, then issue your own
Dialog.

HTH,

Pete.

"Rene_Surop" <infodynamics_ph@yahoo.com> wrote:
> I'm back again into the drawing board here :) ...


I recently had use for accessing a web service from a Unisys A Series
mainframe. Unfortunately, as far as we can tell from the Unisys
documentation, it never occurred to Unisys that someone might want to access
a web service from a Unisys A Series mainframe, instead of on one. We put
the web service access in a PC based client, and transferred the data to the
mainframe using named pipes. It works, but the Unisys documentation for
named pipes is, to the extent that it even exists, very incomplete and
inaccurate. I spent many happy years programming Burroughs/Unisys
mainframes, and it dens me to say that Unisys does not seem to know how
to adapt to the current environment.
--
Judson McClendon      judmc@sunvaley0.com (remove zero)
Sun Valley Systems     http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

On Jun 23, 9:59 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> That's across an Enterprise LAN? Or via the Internet?
>
> I think you're using MF so I don't know your environment intimately, but O
LE
> doesn't have a GUI system as such. If you are seeing a dialog box you need
> to know where it is coming from. If the OLE support Class provided by MF
> raises it, then you should be able to trap it with COM/OLE Exception
> processing; if it is being raised on the Client when it detects that the
> connection is broken it should also be trappable.  Either way, find where 
it
> comes from and trap it with Exception Class processing, then issue your ow
n
> Dialog.
>
> Pete.

Tried it via Internet. I did some record reading from my side
(client)... and updating or writing a record on the other end (web/
data server) and the processing time per record is 1:09sec. That is
from the indicated bandwidth that I mentioned.

Looking at the "original posted" code below, with a modified
"updateAcctRecord" method;


*> This class adapated by James J. Gavan for Net Express V 3.1.
*> If using later versions of Net Express then REPOSITORY
syntax
*> can replace the 'Class-Control' entries below


*>---------------------------------------------------------------
Class-id.        Soaptest.
*>               Soaptest inherits from Base.

*> Where no inheritance is specified it defaults to Base

Class-Control.
*> olebase          is class "olebase"
oleexceptionmanager is class "oleexpt"
Soaptest            is class "soaptest"
Mssoap              is class "$OLE$MSSOAP.SoapClient30".

:
:
:

invoke objSOAPClient "updateAcctRecord"
using by reference wIn-acctCode   *>input/output interface
block
by reference wIn-acctName
by reference wIn-otherData
by reference wIn-sessionID
returning wOut-returnSw


somehow when the Internet connectivity is dead, when processing in the
middle of my "updateAcctRecord" loop... a window is appearing. Yes, Im
using N/E v3.10. From the code above, I guess the window is coming
from "oleexpt" class, or "$OLE$MSSOAP.SoapClient30". Tried overriding
this dialog window... but I can't seemed to removed it yet.

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:P5yfi.5222$G9.4925@bignews6.bellsouth.net...
> "Rene_Surop" <infodynamics_ph@yahoo.com> wrote: 
>
>
> I recently had use for accessing a web service from a Unisys A Series
> mainframe. Unfortunately, as far as we can tell from the Unisys
> documentation, it never occurred to Unisys that someone might want to
> access a web service from a Unisys A Series mainframe, instead of on one.
> We put the web service access in a PC based client, and transferred the
> data to the mainframe using named pipes. It works, but the Unisys
> documentation for named pipes is, to the extent that it even exists, very
> incomplete and inaccurate. I spent many happy years programming
> Burroughs/Unisys mainframes, and it dens me to say that Unisys does not
> seem to know how to adapt to the current environment.
> --
> Judson McClendon      judmc@sunvaley0.com (remove zero)
> Sun Valley Systems     http://sunvaley.com
> "For God so loved the world that He gave His only begotten Son, that
> whoever believes in Him should not perish but have everlasting life."
>
Hi Judson (nice to see you back here... :-)).

From what you are describing, maybe there's a market there? If you have
experimented in this area and got stuff working, you might be able to sell
this knowledge on. Or package it so that people can easily use it?)

It is a certainty that Web Services will be part of the future (as more and
more people cotton on to the advantages of SOA, it is likely that people
currently bound by the mainframe will want to share in these services (just
as you did)).

Pete.

Nikki Cox and Catherine Z. Jone
s Strap On Lesbian XXXXing!

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote:
>
> "Judson McClendon" <judmc@sunvaley0.com> wrote: 
>
> Hi Judson (nice to see you back here... :-)).
>
> From what you are describing, maybe there's a market there? If you have
> experimented in this area and got stuff working, you might be able to sell
> this knowledge on. Or package it so that people can easily use it?)
>
> It is a certainty that Web Services will be part of the future (as more
> and more people cotton on to the advantages of SOA, it is likely that
> people currently bound by the mainframe will want to share in these
> services (just as you did)).
>
> Pete.

Hello Pete, (it's nice to get a chance to check back in. :-)

We are developing the developing the technology, are using it in a second
project now, and hope to use it in future applications. For the last several
months I've been studying and developing in Visual Studio 2005, .NET 2.0,
ASP.NET, etc. Working eyebrow deep in OO these days, but my opinions
regarding OO haven't changed much. :-)  I'm impressed with how easy it is to
go from writing Windows applications in VS 2005 to writing ASP.NET
applications.
--
Judson McClendon      judmc@sunvaley0.com (remove zero)
Sun Valley Systems     http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:Oqbgi.3668$3G2.687@bigfe9.bellsouth.net...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote: 
>
> Hello Pete, (it's nice to get a chance to check back in. :-)
>
> We are developing the developing the technology, are using it in a second
> project now, and hope to use it in future applications. For the last
> several months I've been studying and developing in Visual Studio 2005,
> .NET 2.0, ASP.NET, etc. Working eyebrow deep in OO these days, but my
> opinions regarding OO haven't changed much. :-)  I'm impressed with how
> easy it is to go from writing Windows applications in VS 2005 to writing
> ASP.NET applications.

Ah, pleased to see you have finally come to the true path... :-)

VS 2005, ASP.NET ... makes you wonder what we could have done with COBOL if
it had had such an IDE... :-)

(Probably not much more than we did anyway, but we certainly could have done
it quicker...:-))

Generating Web Services, indeed, anything web related, in this environment
is so easy... I'm working on a very complex web site that also includes Web
Services, that in turn, wrap a COM component written in Fujitsu COBOL. The
whole thing works seamlessly, thanks to InteropServices and the DotNET
framework. I wouldn't have even considered the approach I have taken on this
if I hadn't had VS 2005.

"Give us the tools and we will finish the job..." W. S. Churchill

(or, as someone on a team I once managed remarked..."Give us the job and we
will finish the tools..." :-))

Pete.

On Wed, 27 Jun 2007 13:53:09 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>VS 2005, ASP.NET ... makes you wonder what we could have done with COBOL if
>it had had such an IDE... :-)
>
>(Probably not much more than we did anyway, but we certainly could have don
e
>it quicker...:-))

I'm thinking of how many people in the many shops I've worked in have
used interactive debuggers for CoBOL beyond trying them out.

That would be zero.

"Howard Brazee" <howard@brazee.net> wrote in message
 news:j7q483harmef4b6kktj2kqrjb27ohomp3a@
4ax.com...
> On Wed, 27 Jun 2007 13:53:09 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> I'm thinking of how many people in the many shops I've worked in have
> used interactive debuggers for CoBOL beyond trying them out.
>
> That would be zero.

I think I've tried two or three mainframe COBOL debuggers. Genuine use: 0

I've tried one PC COBOL stepping debugger. Genuine use: 0

I tried one Unix COBOL stepping debugger. Genuine use: 0

I've tried one PC (MS-DOS) BASIC stepping debugger. Genuine use: maybe twice
over ten ten years.

I've tried one PC (Windows) BASIC stepping debugger. Genuine use: 0

OTOH, I know programmers who START their testing/debugging by running via a
stepping debugger, and swear  by them.

I'm probably not a good example, since I work almost 100% with my own code,
which is written so that it *can* be tested and debugged *without* resorting
to a stepping debugger. But I can see where one might be handy if you get
thrown into a situation where you have to maintain some unstructured
monstrosity.

MCM