Hello vse-L friends,

I have returned from a sabbatical (rode Harley Road King from Columbus,OH. to
Sturgis,SD and back),
and after reviewing some of the postings from the:
"RE: SOCKET RECEIVE techniques..." thread
I have decided to start a new thread and change the title from:
"RE: SOCKET RECEIVE techniques..."
to:
"CSI TCP/IP Socket Send Techniques",
and add some actual send techniques for sending data.

The assembler SOCKET macro is the lowest level api that we provide,
and allows the assembler based applications the flexibility to send
data with or without waiting for sent data to be acknowledged by the
foreign stack.

The SEND operation can transmit chunks of data of almost any size. The
data will be queued and carved-up into proper sized chunks to send over
the network.

One comment on this solution since this also applied to my VTAPE performance issue. There is documentation on the IBM web-site that would indicate the tweaking the defaults of the TCP/IP $SOCKOPT will suffice. I found that the regestry change on the Windows server was really required to achieve the desired effect. I think that IBM and the IP stack vendors should cooperate on a document that details what needs to be done to achieve the highest performance for there varied uses of the TP connectivity to the LAN. The performance of the FTP raffic is obvious but we are seeing more applications (VSAM redirector, VTAPE, etc) that inherently benefit from very high performance since they tend to have "windowed" requirements. When you have a 1GB QDIO Ethernet adapter it's a good thing to be able...

This Thursday, August 21st at 11:00 AM EDT,
please join us for a recap of the recent z/VSE V4.2
announcement.

On August 5th, IBM announced z/VSE Version 4 Release 2
and z/VM Version 5 Release 4.

After adding TcpAckFrequency to a Server 2003 box and setting it to '1',
here is what the VSAM Redirector Loader statistics showed.

TcpAckFrequency = default:
4,771,938 records
13,361 seconds for Overall Duration
7,446 seconds for Transfer Duration

TcpAckFrequency = 1:
4,781,173 records
11,487 seconds for Overall Duration
2,652 seconds for Transfer Duration

Looks like the TcpAckFrequency parameter has a huge affect on transfer
times.

Mike Moore
IT Manager
Alabama Judicial Datacenter
300 Dexter Ave
Montgomery, AL 36104
334-954-5025

SAG has not given me any info about any fixes related to hard waits and has not refused to "accept the possibility that their software could cause a hard wait".
I just received info from IBM that the hard wait dump shows that the "VSE" lock file was corrupted or overlayed. I am forwarding that info to SAG.

----- Original Message ----
From: Rich Smrcina wi.rr.com>
To: VSE Discussion List Lehigh.EDU>
Sent: Monday, August 18, 2008 10:26:36 AM
Subject: Re: z/VSE HARD WAIT

So were there no fixes related to hard waits or did they refuse to
accept the possibility that their software could cause a hard wait?

In either event I suggest that you call them back and push a little harder.

Error Code Error Code  Error Code
Dec            Hex             Reg 15=       Issued By   Explanation18             X
                                                                        set to UA.’12’           X’08’          OPEN         The address in an ASSGN statement for a VSAM volume wasProgrammer Response: Change the device address in the ASSGN statement to that of the VSAM volume being opened.

...Roland

----- Original Message ----
From: "abunton@co.slo.ca.us"
To: VSE Discussion List Lehigh.EDU>
Sent: Monday, August 18, 2008 1:04:54 PM
Subject: VSAM error - what's wrong?

Listers,

We are getting the following error starting this morning. The file is the primary DB2 accounting file. The ALTACCT command was issued, so the file should be closed. ARIACC1 and ZJF010P are the same file.

F3-0003 ARI0062A ZE20CA :                                              05:40:22
                Enter a DB2 Server for VSE operator command.           05:40:22
C1 0062 ASO> F3 3 ALTACCT              ...

been there.. done that.. no help..

----- Original Message ----
From: Rich Smrcina wi.rr.com>
To: VSE Discussion List Lehigh.EDU>
Sent: Monday, August 18, 2008 10:04:53 AM
Subject: Re: z/VSE HARD WAIT

If you suspect a problem with the ADABAS SVC it should be reported to
Software AG.  Check with them for any fixes related to hard waits.

jim michaels wrote:

Listers,

We are getting the following error starting this morning. The file is the
primary DB2 accounting file. The ALTACCT command was issued, so the file
should be closed. ARIACC1 and ZJF010P are the same file.

F3-0003 ARI0062A ZE20CA : 05:40:22
Enter a DB2 Server for VSE operator command. 05:40:22
C1 0062 ASO> F3 3 ALTACCT XCM G3 05:40:26
3 ALTACCT 05:40:26
F3 0003 ARI0079I Accounting file ARIACC1 CLOSED. 05:40:26
F3 0003 ARI0079I Accounting file ARIACC2 OPENED. 05:40:26
F3 0003 ARI0065I Operator command processing is complete. 05:40:26
C1 0062 ASO> F7 7 XCM G3 05:40:29
7 05:40:29
F7 0007 * SAVE THE ZE20 PRIMARY ACCOUNTING FILE - ARIACC1 05:40:29
F7 0007 4228I FILE ZJF010P OPEN ERROR X'12'(018) CAT=UCKD055 05:40:29
(OPNIN-50) RC X'00000012' FROM IKQLAB 05:40:29

F7 0007 0V15I REQUEST FROM SYSTEM SERVICE ROUTINE 05:40:29
F7 0007 0S08I LOG. TRANS. AREA CANCELED, PHASE = $$BOSMXT 05:40:29

z/VSEv3.1. ADA813. NAT422. PRD441. EXX722.
We have 2 LPARS, TEST and PROD.
Scenario:
1. We installed ADASVC81 on TEST LPAR 6 weeks ago.
2. We converted 4 ADABAS databases to v8 2 weeks ago (8-9-2008).
3. Received 2 HARD WAIT last week (none prior).
4. Sent Dump to IBM (no response yet).
5. We installed ADASVC81 on PROD LPAR 8-16-2008 (no databases converted).
6. Received HARD WAIT this morning 8-18-2008.

NOTEs:
1. We are using the ADA743 "ADABAS" and "ADALNK" link routines.
2. Our Systems Programs say that no hardware changes have been made in last 2 months and no System Software changes (except our ADAv813 changes).
3. No errors have occurred from any applications that might be related to ADAv8 vs ADAv7.
4. The Operations Master Console only issued "Error in Supervisor" and a PSW address.

z/VSEv3.1. ADA813. NAT422. PRD441. EXX722.
 
We have 2 LPARS, TEST and PROD.
Scenario:
1. We installed ADASVC81 on TEST LPAR 6 weeks ago.
2. We converted 4 ADABAS databases to v8 2 weeks...

I am still running tests but it looks like setting TcpAckFrequency to
'1' has made the VSAM Redirector Loader about 3 to 4 times faster. Here
are the particulars:

BSI stack
Windows Server 2003 server at SP2
GB OSAs and NICs

The TcpAckFrequency parameter is available at SP2 for Windows Server
2003 but you manually have to add the entry to the registry---the Hotfix
for anything older than SP 2 enables the facility but does NOT add the
entry. That wasn't real clear in the MS docs. I used Regedit to add it,
set it to '1' and things appear to be very happy. If the tests continue
to show this improvement, I will go ahead and set the parameter on all
of our file-transfer servers.

Mike Moore
IT Manager
Alabama Judicial Datacenter
300 Dexter Ave
Montgomery, AL 36104
334-954-5025