Possible DFSORT problem?

[McKown, John]

We are having a problem with a COBOL internal sort. If we run the job with no PARM=, the job abends with U4082-2. If it runs with PARM='TRAP(OFF)', it abends with S0C4-38 in ICEF64A. The latter dump has the following indicative dump:

SYSTEM COMPLETION CODE=0C4 REASON CODE=00000038
TIME=09.01.18 SEQ=26947 CPU=0000 ASID=005D
PSW AT TIME OF ERROR 078D2001 80060D28 ILC 6 INTC 38
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 00060D22 - E2E3D6D9 C540D21D 40006004
AR/GR 0: 00000000/00000000_8005D88E 1: 00000020/00000000_0005F530
2: 00000000/00001199_00000002 3: 00000000/00001199_00000004
4: 00000000/00000000_00074B00 5: 00000000/00000000_00060D28
6: 00000000/000011A1_00000588 7: 00000000/00000008_00000584
8: 00000000/00000000_00000001 9: 00000000/00000000_00060CD8
A: 00000000/00000000_050D7056 B: 00000000/00000000_85145028
C: 00000000/00000000_050D6CC0 D: 00000000/00000000_0005F000
E: 00000000/00000000_850D70B2 F: 00000000/00000000_00000004
END OF SYMPTOM DUMP

I have a SYSMDUMP from both runs. I am indeed running in AMODE(64). The instruction abending is D2 1D 4006 6004. As you can see, R6 has a non-zero value, 000011A1, in the high word of the 64-bit register. And the SYSMDUMP show the TRNE as 000011A1_00000000 .

So, do I have a LE problem or a DFSORT problem? That is, to which should I open a PMR? I'm thinking DFSORT.

I don't see anything like this in IBMLink.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
[phone] phone * (817)-691-6183 cell
***@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Farley, Peter x23353]

-----Original Message-----
Behalf Of McKown, John
Sent: Wednesday, September 08, 2010 10:30 AM
Subject: Possible DFSORT problem?
We are having a problem with a COBOL internal sort. If we run the job with
no PARM=, the job abends with U4082-2. If it runs with PARM='TRAP(OFF)',
it abends with S0C4-38 in ICEF64A. The latter dump has the following
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000038
TIME=09.01.18 SEQ=26947 CPU=0000 ASID=005D
PSW AT TIME OF ERROR 078D2001 80060D28 ILC 6 INTC 38
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 00060D22 - E2E3D6D9 C540D21D 40006004
AR/GR 0: 00000000/00000000_8005D88E 1: 00000020/00000000_0005F530
2: 00000000/00001199_00000002 3: 00000000/00001199_00000004
4: 00000000/00000000_00074B00 5: 00000000/00000000_00060D28
6: 00000000/000011A1_00000588 7: 00000000/00000008_00000584
8: 00000000/00000000_00000001 9: 00000000/00000000_00060CD8
A: 00000000/00000000_050D7056 B: 00000000/00000000_85145028
C: 00000000/00000000_050D6CC0 D: 00000000/00000000_0005F000
E: 00000000/00000000_850D70B2 F: 00000000/00000000_00000004
END OF SYMPTOM DUMP
I have a SYSMDUMP from both runs. I am indeed running in AMODE(64). The
instruction abending is D2 1D 4006 6004. As you can see, R6 has a non-zero
value, 000011A1, in the high word of the 64-bit register. And the SYSMDUMP
show the TRNE as 000011A1_00000000 .
So, do I have a LE problem or a DFSORT problem? That is, to which should I
open a PMR? I'm thinking DFSORT.

Um, and you are running in 64-bit mode with COBOL how, exactly? I had no idea that was a supported COBOL option yet.

In any case, I would recommend switching back to 31-bit addressing mode before invoking SORT. I have a strong suspicion that LE would react badly due to its assumption that any call from a COBOL program can only be 31-bit.

Peter

--

This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

-----Original Message-----
From: IBM Mainframe Discussion List
Sent: Wednesday, September 08, 2010 9:57 AM
Subject: Re: Possible DFSORT problem?

<snip>

Um, and you are running in 64-bit mode with COBOL how,
exactly? I had no idea that was a supported COBOL option yet.
In any case, I would recommend switching back to 31-bit
addressing mode before invoking SORT. I have a strong
suspicion that LE would react badly due to its assumption
that any call from a COBOL program can only be 31-bit.
Peter
--

Sorry - DFSORT apparently did the AMODE switch to 64, not our code. Or something did, but not COBOL. No HLASM subroutines in this mix to do a SAM64 or BSM or BASSM either. But the system was in 64 bit AMODE.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
[phone] phone * (817)-691-6183 cell
***@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Martin Packer]

John McKown said

Post by McKown, John
Sorry - DFSORT apparently did the AMODE switch to 64, not our code.

That's perfectly possible - if the sort was using a large memory object.

Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM

[phone]

email: ***@uk.ibm.com

Twitter / Facebook IDs: MartinPacker





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Steve Comstock]

Post by McKown, John
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000038
TIME=09.01.18 SEQ=26947 CPU=0000 ASID=005D
PSW AT TIME OF ERROR 078D2001 80060D28 ILC 6 INTC 38
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 00060D22 - E2E3D6D9 C540D21D 40006004
AR/GR 0: 00000000/00000000_8005D88E 1: 00000020/00000000_0005F530
2: 00000000/00001199_00000002 3: 00000000/00001199_00000004
4: 00000000/00000000_00074B00 5: 00000000/00000000_00060D28
6: 00000000/000011A1_00000588 7: 00000000/00000008_00000584
8: 00000000/00000000_00000001 9: 00000000/00000000_00060CD8
A: 00000000/00000000_050D7056 B: 00000000/00000000_85145028
C: 00000000/00000000_050D6CC0 D: 00000000/00000000_0005F000
E: 00000000/00000000_850D70B2 F: 00000000/00000000_00000004
END OF SYMPTOM DUMP
I have a SYSMDUMP from both runs. I am indeed running in AMODE(64). The instruction abending is D2 1D 4006 6004. As you can see, R6 has a non-zero value, 000011A1, in the high word of the 64-bit register. And the SYSMDUMP show the TRNE as 000011A1_00000000 .
So, do I have a LE problem or a DFSORT problem? That is, to which should I open a PMR? I'm thinking DFSORT.
I don't see anything like this in IBMLink.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)

John,

It occurs to me to ask: what version of COBOL are you using?
There have been a lot of problems if you run 4.2 without all
the requisite maintenance levels on z/OS and LE.
--
Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

-----Original Message-----
From: IBM Mainframe Discussion List
Sent: Wednesday, September 08, 2010 10:15 AM
Subject: Re: Possible DFSORT problem?

<snip>

John,
It occurs to me to ask: what version of COBOL are you using?
There have been a lot of problems if you run 4.2 without all
the requisite maintenance levels on z/OS and LE.

Enterprise COBOL 3.4

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
[phone] phone * (817)-691-6183 cell
***@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Frank Yaeger]

Post by McKown, John
We are having a problem with a COBOL internal sort. If we run the
job with no PARM=, the job abends with U4082-2. If it runs with
PARM='TRAP(OFF)', it abends with S0C4-38 in ICEF64A.
So, do I have a LE problem or a DFSORT problem? That is, to which
should I open a PMR? I'm thinking DFSORT.

Since ICEF64A is a DFSORT module, a DFSORT PMR is probably appropriate.
The PMR will, of course, be transferred if it turns out to be a
problem in another component.

Frank Yaeger - DFSORT Development Team (IBM) - ***@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

-----Original Message-----
From: IBM Mainframe Discussion List
Sent: Wednesday, September 08, 2010 11:43 AM
Subject: Re: Possible DFSORT problem?
John McKown on IBM Mainframe Discussion List

Post by McKown, John
We are having a problem with a COBOL internal sort. If we run the
job with no PARM=, the job abends with U4082-2. If it runs with
PARM='TRAP(OFF)', it abends with S0C4-38 in ICEF64A.
So, do I have a LE problem or a DFSORT problem? That is, to which
should I open a PMR? I'm thinking DFSORT.

Since ICEF64A is a DFSORT module, a DFSORT PMR is probably
appropriate.
The PMR will, of course, be transferred if it turns out to be a
problem in another component.
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols,
Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

Thanks. I've done that now. And uploaded the TERSED files that were requested.

Personally, I think something in our code is likely overwriting a SORT data area, causing a problem "down the line". But I just can't find it, myself.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
[phone] phone * (817)-691-6183 cell
***@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[William M Klein]

John,

You don't mention whether your Enterprise COBOL 3.4 program was compiled
with FASTSRT or not. My guess is that it was. You might try recompiling
and running it with NOFASTSRT. You said (later in the thread) that you have
created a PMR, but trying with NOFASTSRT might (or might not) help you
identify where the problem is.



You also don't mention if your COBOL SORT has any input or output
procedures. That too might be relevant.



Having said all of this, I am certain that IBM L2 will get to the bottom of
this.



<original note follows>

We are having a problem with a COBOL internal sort. If we run the job with
no PARM=, the job abends with U4082-2. If it runs with PARM='TRAP(OFF)', it
abends with S0C4-38 in ICEF64A. The latter dump has the following indicative
dump:

SYSTEM COMPLETION CODE=0C4 REASON CODE=00000038
TIME=09.01.18 SEQ=26947 CPU=0000 ASID=005D
PSW AT TIME OF ERROR 078D2001 80060D28 ILC 6 INTC 38
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 00060D22 - E2E3D6D9 C540D21D 40006004
AR/GR 0: 00000000/00000000_8005D88E 1: 00000020/00000000_0005F530
2: 00000000/00001199_00000002 3: 00000000/00001199_00000004
4: 00000000/00000000_00074B00 5: 00000000/00000000_00060D28
6: 00000000/000011A1_00000588 7: 00000000/00000008_00000584
8: 00000000/00000000_00000001 9: 00000000/00000000_00060CD8
A: 00000000/00000000_050D7056 B: 00000000/00000000_85145028
C: 00000000/00000000_050D6CC0 D: 00000000/00000000_0005F000
E: 00000000/00000000_850D70B2 F: 00000000/00000000_00000004
END OF SYMPTOM DUMP

I have a SYSMDUMP from both runs. I am indeed running in AMODE(64). The
instruction abending is D2 1D 4006 6004. As you can see, R6 has a non-zero
value, 000011A1, in the high word of the 64-bit register. And the SYSMDUMP
show the TRNE as 000011A1_00000000 .

So, do I have a LE problem or a DFSORT problem? That is, to which should I
open a PMR? I'm thinking DFSORT.

I don't see anything like this in IBMLink.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
[phone] phone * (817)-691-6183 cell
<mailto:***@healthmarkets.com> ***@healthmarkets.com *
<http://www.healthmarkets.com/> www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. HealthMarkets(r) is the brand name for products underwritten and
issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake
Life Insurance Company(r), Mid-West National Life Insurance Company of
TennesseeSM and The MEGA Life and Health Insurance Company.SM

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to <mailto:***@bama.ua.edu> ***@bama.ua.edu with the
message: GET IBM-MAIN INFO
Search the archives at <http://bama.ua.edu/archives/ibm-main.html>
http://bama.ua.edu/archives/ibm-main.html




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

-----Original Message-----
From: IBM Mainframe Discussion List
Sent: Thursday, September 09, 2010 5:29 PM
Subject: Re: Possible DFSORT problem?
John,
You don't mention whether your Enterprise COBOL 3.4
program was compiled
with FASTSRT or not. My guess is that it was. You might try
recompiling
and running it with NOFASTSRT. You said (later in the
thread) that you have
created a PMR, but trying with NOFASTSRT might (or might not) help you
identify where the problem is.
You also don't mention if your COBOL SORT has any input or output
procedures. That too might be relevant.
Having said all of this, I am certain that IBM L2 will get to
the bottom of
this.

This program uses both an INPUT PROCEDURE IS and OUTPUT PROCEDURE IS and so FASTSRT should not be relevant.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
[phone] phone * (817)-691-6183 cell
***@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Schumacher, Otto]

Try recompiling the program with DATA(24). PS all sub-routines must be compiled with DATA(24) if the main program is compiled with DATA(24).

Regards
Otto Schumacher
 
HP Enterprise Services
Infrastructure Specialist
Ahold Account
CICS & Capacity Technical Support
P.O. Box 6462
2000 Wade Hampton Blvd.
LC1-302
Greenville,  South Carolina, 29606
Cell: 864 449 1755
Tel: [phone]
Fax: [phone]
E-mail: ***@hp.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@bama.ua.edu] On Behalf Of William M Klein
Sent: Thursday, September 09, 2010 6:29 PM
To: IBM-***@bama.ua.edu
Subject: Re: Possible DFSORT problem?

John,

You don't mention whether your Enterprise COBOL 3.4 program was compiled
with FASTSRT or not. My guess is that it was. You might try recompiling
and running it with NOFASTSRT. You said (later in the thread) that you have
created a PMR, but trying with NOFASTSRT might (or might not) help you
identify where the problem is.



You also don't mention if your COBOL SORT has any input or output
procedures. That too might be relevant.



Having said all of this, I am certain that IBM L2 will get to the bottom of
this.



<original note follows>

We are having a problem with a COBOL internal sort. If we run the job with
no PARM=, the job abends with U4082-2. If it runs with PARM='TRAP(OFF)', it
abends with S0C4-38 in ICEF64A. The latter dump has the following indicative
dump:

SYSTEM COMPLETION CODE=0C4 REASON CODE=00000038
TIME=09.01.18 SEQ=26947 CPU=0000 ASID=005D
PSW AT TIME OF ERROR 078D2001 80060D28 ILC 6 INTC 38
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 00060D22 - E2E3D6D9 C540D21D 40006004
AR/GR 0: 00000000/00000000_8005D88E 1: 00000020/00000000_0005F530
2: 00000000/00001199_00000002 3: 00000000/00001199_00000004
4: 00000000/00000000_00074B00 5: 00000000/00000000_00060D28
6: 00000000/000011A1_00000588 7: 00000000/00000008_00000584
8: 00000000/00000000_00000001 9: 00000000/00000000_00060CD8
A: 00000000/00000000_050D7056 B: 00000000/00000000_85145028
C: 00000000/00000000_050D6CC0 D: 00000000/00000000_0005F000
E: 00000000/00000000_850D70B2 F: 00000000/00000000_00000004
END OF SYMPTOM DUMP

I have a SYSMDUMP from both runs. I am indeed running in AMODE(64). The
instruction abending is D2 1D 4006 6004. As you can see, R6 has a non-zero
value, 000011A1, in the high word of the 64-bit register. And the SYSMDUMP
show the TRNE as 000011A1_00000000 .

So, do I have a LE problem or a DFSORT problem? That is, to which should I
open a PMR? I'm thinking DFSORT.

I don't see anything like this in IBMLink.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
[phone] phone * (817)-691-6183 cell
<mailto:***@healthmarkets.com> ***@healthmarkets.com *
<http://www.healthmarkets.com/> www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. HealthMarkets(r) is the brand name for products underwritten and
issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake
Life Insurance Company(r), Mid-West National Life Insurance Company of
TennesseeSM and The MEGA Life and Health Insurance Company.SM

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to <mailto:***@bama.ua.edu> ***@bama.ua.edu with the
message: GET IBM-MAIN INFO
Search the archives at <http://bama.ua.edu/archives/ibm-main.html>
http://bama.ua.edu/archives/ibm-main.html




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

This is where I was getting an S0C4-38 in ICEF64A. I think that have found the problem. However, I cannot do anything about it due to the fact that it is, I believe, in a OEM product which we have a perpetual license for, and so did not renew maintenance on it. I.e. we are unsupported. It appears to me that the high fullword (bits 0..31) of general registers 2 and 3 are corrupted. I came to this conclusion by dumping the registers via an HLASM subroutine just before a COBOL READ verb, then immediately after the READ verb. That showed that the high words of GPRs 2&3 were changed. I then took the OEM product out of the mix and reran the program with no problems and no apparent corruption.

My thanks to IBM's DFSORT people for their help on this!

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
[phone] phone * (817)-691-6183 cell
***@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html