TCP/IP sockets programs

Discussion created by ca.portal.admin on Sep 12, 2007
At our site, we have crossed the first hurdle of accessing external web
services using the IDMS sockets interface. Now we are looking at
accepting incoming requests. It appears to me that, in order to handle
multiple users, the generic listener program must somehow hand off the
request to another task for processing. But the sample generic listener
provided by CA does not do that. Can anyone give me some sample code
that does? Or am I getting in over my head here?

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
IDMS Public Discussion Forum


Re: CPU Increase
"Let me EXPAND a bit on Dan's comments, and UNLD some of my thoughts. This
gets into the uglier details Dan avoided, so those with delicate
constitutions should move on to the next message in your inbox at this

First question is how much of the access to the AREA is via sweep, how much
CALC/VIA? For a complex application/environment this is going to be
difficult to determine.

Even for one program (as Dan suggests below) it's not a straightforward

Here are the considerations for each type of access (either within a single
program or global to the system):

For CALC/VIA/Index/DIRECT: as Dan suggests below, an unloaded/reloaded AREA
could save some I/Os due to reduction in the amount of CALC overflows. Even
for an XPAG, this will happen over time (as records come and go), but
shouldn't show any immediate impact. For guesstimation purposes this can
probably be ignored and this portion of the CPU/elapsed time/IOs can be
considered constant.

For sweeps: the total amount of I/Os goes up, by whatever factor, based on
change in number of pages. The elapsed time should keep in step with the
I/O count. The CPU increase % will lag this, possibly by a large factor.
IDMS spends part of the cycles processing the request, part of the cycles
doing I/O. Since the same number of requests are being processed (until
more records are added), the ""processing"" portion of the CPU should remain
constant, while the CPU needed to perform th I/Os goes up proportionately to
the size expansion. So depending on how dense the record populates the
AREA, this portion is greater or lesser (the fewer records, the greater the
percentage of CPU spent just doing I/Os).

The trick then is to somehow analyze a workload (single program or entire
CV) and categorize it into these two components.

For a batch job, a product like STROBE might be able to supply sufficient
data to allow a projection. Possibly even for a CV, although that would be

Don Casey