Re: "Computer Error" by Wells Fargo
Harrington, Mark
BUT THAT BEING SAID,
Don't feel bad Sam because you are not alone whens it come to wells
fargo,
I went to Wells Fargo on friday to get my Mom a new atm card because she had
lost hers (my account, i give her a card so
she can get some bucks out). I told them up and down that only her card
needs to be reissued mine is ok. THEY said my card had been reported solen I
told them no it wasn't you are in error. I even took money out of the ATM
right in front of the teller's eyes to prove that this was a good card. My
mom and I then attended a funeral for a family member and I took a whole
bunch of poeple out for lunch afterward (on me) and when i gave them my card
the waitress came back and said that this card had been cancelled !
bunch of f(*&*&ing idiots !
time for a new bank
-----Original Message-----
From: Sam@Lafoode [mailto:s...@LAFOODE.COM]
Sent: Thursday, December 01, 2005 3:10 PM
To: TSO-...@VM.MARIST.EDU
Subject: "Computer Error" by Wells Fargo
Dear Member,
I need your help to identify the cause of a problem that has brought me and
my family tremendous trouble and grief. My bank, Wells Fargo, made errors
in the ownership designations on three of our accounts, attributing the
mistakes to a simple, "computer error"--not human error. I am writing for
your help in determining how and why the following changes did in fact
occur:
(1) Certificates of Deposit: Certificates in my family's name were,
without authorization, put in someone else's name, and ours replaced. The
bank attributes this to a "computer error," without explanation.
(2) Home Mortgage: Wells Fargo changed my home mortgage account, without
consent, so that I was bumped from "primary customer" to "additional
customer," and the same stranger who appeared on the CD accounts became the
"primary customer".
(3) Home Equity Line of Credit: Wells Fargo says the same "computer error"
caused the change in ownership by replacing my spouse's name with that of
the person who appeared on the other accounts.
In the latter two cases, the bank sent mail to my home address, with the
stranger's name appearing instead of my spouse's.
Wells Fargo refuses to explain, beyond a vague "computer error," how this
situation came about and I would appreciate some expert take on this:
Is it possible for a single "computer error" to cause the changes in
multiple accounts? If so, how would such changes occur? How could we trace
them?
Could the errors have occurred by random malfunction? Would an individual
have had to make multiple entries to effect those changes?
Can a bank's computer malfunction on its own, select three of my accounts at
random, and then transfer ownership this way? Or must the server be
programmed to do this?
Do these snafus seem innocent, or do you think something sinister could be
involved?
Is there a way to determine if Wells Fargo's server has been hacked into,
and, if so, to trace who and where the hacker is?
What employee(s) in the bank would have information about how the changes
occurred?
Do you know, or have you heard, of similar activities affecting other Wells
Fargo accounts?
I appreciate any comments or suggestions and thanks for the help. Please
e-mail me at s...@lafoode.com for comments you wish to share with me.
Sincerely,
Sam M.
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
----------------------------------------------------------
IMPORTANT WARNING: This email (and any attachments) is only intended for the use of the person or entity to which it is addressed, and may contain information that is privileged and confidential. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. Unauthorized redisclosure or failure to maintain confidentiality may subject you to federal and state penalties. If you are not the intended recipient, please immediately notify us by return email, and delete this message from your computer.
----------------------------------------------------------
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Ponnappan, Binoj K
I am getting Error while trying to execute the following code
FSTA1 = SYSDSN("'"USERID()".OMS.SYSPRINT'")
IF FSTA1 = 'OK' THEN
"ALLOC DS('"USERID()".OMS.SYSPRINT') DD(SYSPRINT) SHR REUSE"
ELSE
"ALLOC DS('"USERID()".OMS.SYSPRINT') DD(SYSPRINT) NEW SPACE(5,5)"
IF RC > 4 THEN DO
SKIP_FLAG = 'TRUE'
MSG_FLAG = '03'
CALL 99_ERROR_PARA
END
The Error which I receive is as listed below.
IKJ56246I DATA SET NZ3C2Q.OMS.SYSPRINT NOT ALLOCATED, FILE IN USE
RC=12
Can Anyone help me trace why it is saying this error. (the dataset is
not getting created).
Thanks and Regards
--Binoj .P --
Order Management System
EDS-Electronic Data Systems
mailto:binoj.p...@eds.com
The Best Way Out is Always Through
Lizette Koehler
at LOGON time and would need to be freed and re-allocated if it is to be
redirected.
When I use SYSPRINT my process usually entails
1) Free DD(SYSPRINT)
2) ALLOCATE DD(SYSPRINT) ....
3) Test if allocation successful.
Lizette Koehler
Paul Gilmartin
> Date: Sat, 25 Nov 2006 07:33:33 -0500
>
> Did you free SYSPRINT before allocating it? Typically SYSPRINT is allocated
> at LOGON time and would need to be freed and re-allocated if it is to be
> redirected.
>
> When I use SYSPRINT my process usually entails
>
> 1) Free DD(SYSPRINT)
> 2) ALLOCATE DD(SYSPRINT) ....
> 3) Test if allocation successful.
>
For consistency with other applications, it's probably better
not to override the user's data set name prefix.
You probably want to catalogue a new data set (in case SMS
doesn't do this for you).
So my preferred sequence (although more in JCL than in Rexx)
is:
"free dd(SYSPRINT)"
"allocate dd(SYSPRINT) mod catalog space(5,5) dsn(OMS.SYSPRINT)"
"free dd(SYSPRINT)"
"allocate dd(SYSPRINT) shr dsn(OMS.SYSPRINT)"
Test if allocation successful.
-- gil
--
StorageTek
INFORMATION made POWERFUL
Paul Gilmartin
> Date: Sat, 25 Nov 2006 10:41:08 -0700
>
> In a recent note, Lizette Koehler said:
> > Date: Sat, 25 Nov 2006 07:33:33 -0500
> >
> > When I use SYSPRINT my process usually entails
> >
> > 1) Free DD(SYSPRINT)
> > 2) ALLOCATE DD(SYSPRINT) ....
> > 3) Test if allocation successful.
>
> So my preferred sequence (although more in JCL than in Rexx)
> is:
>
> "free dd(SYSPRINT)"
> "allocate dd(SYSPRINT) mod catalog space(5,5) dsn(OMS.SYSPRINT)"
> "free dd(SYSPRINT)"
> "allocate dd(SYSPRINT) shr dsn(OMS.SYSPRINT)"
> Test if allocation successful.
>
Hmmm. We both forgot about "REUSE". How about:
"allocate dd(SYSPRINT) mod catalog space(5,5) dsn(OMS.SYSPRINT) reuse"
"allocate dd(SYSPRINT) shr dsn(OMS.SYSPRINT) reuse"
Test if allocation successful.
Irritated question: Why is "REUSE" mutually exclusive with "PATH"?
Andreas Lerch
> "allocate dd(SYSPRINT) mod catalog space(5,5) dsn(OMS.SYSPRINT) reuse"
> "allocate dd(SYSPRINT) shr dsn(OMS.SYSPRINT) reuse"
> Test if allocation successful.
> Irritated question: Why is "REUSE" mutually exclusive with "PATH"?
I think they use the same request-unit in SVC99 (dynalloc) macro
like DUMMY and SYSOUT :-)
Einen schoenen Tag
Andreas Lerch
Bob Hamilton
bobh
On Sat, 25 Nov 2006 10:50:16 -0700
Paul Gilmartin <gil...@UNIX.STORTEK.COM> wrote:
<SNIP>
> Hmmm. We both forgot about "REUSE". How about:
>
> "allocate dd(SYSPRINT) mod catalog space(5,5)
> dsn(OMS.SYSPRINT) reuse"
> "allocate dd(SYSPRINT) shr dsn(OMS.SYSPRINT) reuse"
> Test if allocation successful.
>
> Irritated question: Why is "REUSE" mutually exclusive
> with "PATH"?
>
Paul Gilmartin
> Date: Sun, 26 Nov 2006 14:04:23 -0500
>
> I don't see how mod would be compatible with reuse. . .
>
I don't see why there should be a problem. Evidently, neither
did the TSO developers. Simply, it works (or try it yourself):
READY
allocate dd(sysprint) sysout
READY
allocate dd(sysprint) dsn(foo.bar) mod
IKJ56246I DATA SET user.FOO.BAR NOT ALLOCATED, FILE IN USE
IKJ56112A ENTER 'FREE' OR 'END'+-
end
READY
allocate dd(sysprint) dsn(foo.bar) mod reuse
READY
> > Irritated question: Why is "REUSE" mutually exclusive
> > with "PATH"?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Hamilton, Robert L
bobh
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Paul Gilmartin
Subject: Re: Allocation Error for SYSPRINT Dataset
READY
allocate dd(sysprint) sysout
READY
allocate dd(sysprint) dsn(foo.bar) mod
IKJ56246I DATA SET user.FOO.BAR NOT ALLOCATED, FILE IN USE
IKJ56112A ENTER 'FREE' OR 'END'+-
end
READY
allocate dd(sysprint) dsn(foo.bar) mod reuse
READY
Steve Comstock
air....@VINTAGE-AERO.COM writes:
>
> I don't see how mod would be compatible with reuse. . .
"reuse" relates to the DDname's use in allocation,
not anything about the data set; it says "if I am
using this DDname currently, change the mapping of
the specified DDname to connect to this new data set"
"mod" says "if the dataset has data, add new data
to the end, otherwise, we are creating the file".
Kind regards,
-Steve Comstock
>
> bobh
>
> On Sat, 25 Nov 2006 10:50:16 -0700
> Paul Gilmartin <gil...@UNIX.STORTEK.COM> wrote:
> <SNIP>
> >Hmmm. We both forgot about "REUSE". How about:
> >
> >"allocate dd(SYSPRINT) mod catalog space(5,5)
> >dsn(OMS.SYSPRINT) reuse"
> >"allocate dd(SYSPRINT) shr dsn(OMS.SYSPRINT) reuse"
> >Test if allocation successful.
> >
> >Irritated question: Why is "REUSE" mutually exclusive
> >with "PATH"?
> >
>
>
Ponnappan, Binoj K
dataset.
Thanks for you help
:-)
Thanks
--Binoj--
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Paul Gilmartin
Tony Harminc
> I don't see how mod would be compatible with reuse. . .
Why would there be a conflict? REUSE just says to free any existing
allocation of the specified DDAME before trying the new one. It's
essentially equivalent to issuing FREE DDNAME(...) with a "silent" option
before trying the ALLOC.
As Paul points out, there is a bizarre prohibition against using REUSE with
PATH, which is surely just a bug introduced by someone who didn't understand
ALLOC.
A lot of the confusion here arises from use of "file" to mean "DDNAME". Many
many people over the decades since the TSO developers chose this name have
understood "file" to mean "DSNAME". I suspect the IBMer who wrote in the
mutual exclusivity of PATH and REUSE thought the same.
Tony H.
Paul Gilmartin
> Date: Mon, 27 Nov 2006 10:36:29 -0500
>
> > I don't see how mod would be compatible with reuse. . .
>
> Why would there be a conflict? REUSE just says to free any existing
> allocation of the specified DDAME before trying the new one. It's
> essentially equivalent to issuing FREE DDNAME(...) with a "silent" option
> before trying the ALLOC.
>
Actually, given the convoluted description of reusing allocations
in the DYNALLOC manual, Steve C. might be closer with his description
that it doesn't really do a FREE and an ALLOCATE; it just changes
the data set name in the existing control structures. This strikes
me as cycle-parsimonious and function-foolish.
> As Paul points out, there is a bizarre prohibition against using REUSE with
> PATH, which is surely just a bug introduced by someone who didn't understand
> ALLOC.
>
And, as above, I believe there's a statement in TFM that an allocation
for a DSNAME can't be REUSEd for a PATH, presumably because the changes
required are too profound. But why, then, can an existing allocation
to a PATH be REUSEd for a DSNAME? And why can't it REUSE an existing
allocation for a PATH with a different PATH? And when it absolutely
can't REUSE the existing allocation, it ought just to FREE and start
over.
> A lot of the confusion here arises from use of "file" to mean "DDNAME". Many
> many people over the decades since the TSO developers chose this name have
> understood "file" to mean "DSNAME". ...
This reaches a low point with, e.g.:
READY
allocate dd(foo) path('/tmp')
READY
allocate dd(foo) dsname('SYS1.MACLIB')
IKJ56246I DATA SET SYS1.MACLIB NOT ALLOCATED, FILE IN USE
... which reports "FILE IN USE", but names in the message not the
offending "FILE" but the innocent data set.
allocate dd(foo) dsname('SYS1.MACLIB') reuse
READY
(It does let me REUSE a PATH allocation as a DSNAME allocation.)
> ... I suspect the IBMer who wrote in the
> mutual exclusivity of PATH and REUSE thought the same.
>
Or was as confused as I am by the description of DYNALLOC in TFM,
or merely insisted on a dogmatic interpretation.
Thanks for your insights; perhaps Steve has some more.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Imbriale, Donald , Exchange
ALLOCATE command allows FILE as a synonym for DDNAME.
So if you used ALLOCATE FILE(FOO) . . .
then the use of FILE in message IKJ56246I should not offend your
sensibility.
Don Imbriale
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Paul Gilmartin
Sent: Monday, November 27, 2006 11:37 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Allocation Error for SYSPRINT Dataset
This reaches a low point with, e.g.:
READY
allocate dd(foo) path('/tmp')
READY
allocate dd(foo) dsname('SYS1.MACLIB')
IKJ56246I DATA SET SYS1.MACLIB NOT ALLOCATED, FILE IN USE
... which reports "FILE IN USE", but names in the message not the
offending "FILE" but the innocent data set.
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
McKown, John
> From: TSO REXX Discussion List
> [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Paul Gilmartin
> Sent: Saturday, November 25, 2006 11:41 AM
> To: TSO-...@VM.MARIST.EDU
<snip>
> So my preferred sequence (although more in JCL than in Rexx)
> is:
>
> "free dd(SYSPRINT)"
> "allocate dd(SYSPRINT) mod catalog space(5,5) dsn(OMS.SYSPRINT)"
> "free dd(SYSPRINT)"
> "allocate dd(SYSPRINT) shr dsn(OMS.SYSPRINT)"
> Test if allocation successful.
>
> -- gil
> --
I will mention that this would not work here in most cases because 90%+
of our TSO users run with PROFILE NOPREFIX. To be more "fail safe", it
would be a good idea to check for this and user the USERID() if there is
no PREFIX.
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
Paul Gilmartin
> Date: Mon, 27 Nov 2006 08:29:25 -0600
>
> I will mention that this would not work here in most cases because 90%+
> of our TSO users run with PROFILE NOPREFIX. To be more "fail safe", it
> would be a good idea to check for this and user the USERID() if there is
> no PREFIX.
>
Errr... If the user runs with PROFILE NOPREFIX he is declaring his
intention that unquoted data set names be treated as fully qualified.
I've certainly used NOPREFIX at times for this purpose. Why would
you choose to thwart this?
TSO's conventions, for better or worse, are as they are. You only
move toward chaos by overriding in an individual application.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Paul Gilmartin
> Date: Mon, 27 Nov 2006 11:44:38 -0500
>
> FILE is the DDNAME, not the data set name. In fact, the syntax for the
> ALLOCATE command allows FILE as a synonym for DDNAME.
>
> So if you used ALLOCATE FILE(FOO) . . .
>
Ah, but I didn't. A user-friendly interface would report using
the same terminology used by the requestor.
> then the use of FILE in message IKJ56246I should not offend your
> sensibility.
>
My sensibility is offended less by its use of "FILE" than by
the message's failing to name the "FILE" causing the problem
and misleading me by naming something entirely different. This
is apt to send me off searching for ENQ conflicts on the DSNAME
it cites.
It could be better; there's no reason it needs to be as bad as it is.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Imbriale, Donald , Exchange
you allocate file(foo) and it says there's a problem with that file, why
would you look to any other name than the one you just tried in the
command?
It's really not that bad; thousands of people have used it for decades
with great success. But I suppose that if it was as you wish it to be,
you would find something else about it that you disliked. Perhaps the
long-awaited PG/OS would reach perfection and provide you what you
need/want.
Don Imbriale
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Paul Gilmartin
Sent: Monday, November 27, 2006 12:20 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Allocation Error for SYSPRINT Dataset
>
My sensibility is offended less by its use of "FILE" than by
the message's failing to name the "FILE" causing the problem
and misleading me by naming something entirely different. This
is apt to send me off searching for ENQ conflicts on the DSNAME
it cites.
It could be better; there's no reason it needs to be as bad as it is.
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
----------------------------------------------------------------------
Paul Gilmartin
> Date: Mon, 27 Nov 2006 12:52:33 -0500
>
> You are misleading yourself by assuming that FILE means data set. If
> you allocate file(foo) and it says there's a problem with that file, why
> would you look to any other name than the one you just tried in the
> command?
>
By the same reasoning, why do they bother to name the data set when
you would not expect me to look to any other name than the one I
just tried. If then feel the need to name any entity in the message,
it's most informative to name the one with which there's a problem.
> It's really not that bad; thousands of people have used it for decades
> with great success.
>
Admitted. But it could be made better. Why not?
I admire the design feedback Cowlishaw described for Rexx. During
development he released preliminary versions to tester/users and
modified the product as guided by their feedback. I suspect enough
novice TSO users have stumbled over this point in ALLOCATE that it
could have been improved if the designers had solicited and heeded
user feedback. I doubt that they did.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Schwarz, Barry A
command.
-----Original Message-----
From: Ponnappan, Binoj K [mailto:snip]
Sent: Monday, November 27, 2006 6:36 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Allocation Error for SYSPRINT Dataset
It works fine when I issue a Free DD(SYSPRINT) before Allocating the
dataset.
Thanks for you help
:-)
Thanks
--Binoj--
----------------------------------------------------------------------
Tony Harminc
> In a recent note, Tony Harminc said:
> > Why would there be a conflict? REUSE just says to free any existing
> > allocation of the specified DDAME before trying the new one. It's
> > essentially equivalent to issuing FREE DDNAME(...) with a
> "silent" option before trying the ALLOC.
> >
> Actually, given the convoluted description of reusing allocations
> in the DYNALLOC manual, Steve C. might be closer with his description
> that it doesn't really do a FREE and an ALLOCATE; it just changes
> the data set name in the existing control structures. This strikes
> me as cycle-parsimonious and function-foolish.
I very much doubt that it works this way, if only because there is no "reuse
this ddname with a new dsname" option on DYNALLOC. I don't believe the REUSE
option on the TSO ALLOC command has anything to do with the - as you say -
convoluted description of reusing existing allocations with DYNALLOC.
The ALLOC doc is also convoluted, and doubtless reflects the overall amount
of effort put into TSO in recent years. For instance, the very first
paragraph of ALLOC digresses into a bizarre and misleading discussion of HFS
filesystem datasets!
The description of REUSE here says "specifies the file name being allocated
is to be freed and reallocated if it is currently in use". But then it goes
on to claim that REUSE cannot be used to "reallocate a file from a
disposition of OLD to a disposition of SHR", which is certainly not true -
it works fine, as expected.
> This reaches a low point with, e.g.:
>
> READY
> allocate dd(foo) path('/tmp')
> READY
> allocate dd(foo) dsname('SYS1.MACLIB')
> IKJ56246I DATA SET SYS1.MACLIB NOT ALLOCATED, FILE IN USE
>
> ... which reports "FILE IN USE", but names in the message not the
> offending "FILE" but the innocent data set.
It's even worse if you reverse the order of your two ALLOCATEs:
IKJ56246I PATH /tmp NOT ALLOCATED, FILE IN USE
Changing the message to say DDNAME would solve a great deal of this.
Tony H.
Paul Gilmartin
> Date: Mon, 27 Nov 2006 14:21:54 -0500
>
> It's even worse if you reverse the order of your two ALLOCATEs:
>
> IKJ56246I PATH /tmp NOT ALLOCATED, FILE IN USE
>
> Changing the message to say DDNAME would solve a great deal of this.
>
Alas, there are the ilk of Mr. Imbriale, who feel TSO is ideal
as it is, and that it's harmful to consider ways it might be
made better.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Imbriale, Donald , Exchange
Please review this thread and let me know where I said it was ideal or
that it would be harmful to consider ways to make it better.
Don Imbriale
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Paul Gilmartin
Sent: Monday, November 27, 2006 4:59 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Allocation Error for SYSPRINT Dataset
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
----------------------------------------------------------------------
Paul Gilmartin
> Date: Mon, 27 Nov 2006 17:59:33 -0500
>
> I do not appreciate you putting words in my mouth.
>
> Please review this thread and let me know where I said it was ideal or
> that it would be harmful to consider ways to make it better.
>
I stand corrected. You merely said the perceptibly sarcastic:
It's really not that bad; thousands of people have used it for
decades with great success. But I suppose that if it was as
you wish it to be, you would find something else about it that
you disliked. Perhaps the long-awaited PG/OS would reach
perfection and provide you what you need/want.
And you came perilously close to putting words in my mouth, except
you hedged with "I suppose". Is it OK, then, for me to say that
"I suppose" that Don Imbriale considers TSO ideal, and that it
would be harmful to consider ways to make it better? Or may
I assume that we can respect each other's obviously divergent
opinions on the virtues of TSO and its features, and that individual
wishes for improvements are a suitable and harmless topic for
consideration?
Ryerse, Robin
Robin Ryerse
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Paul Gilmartin
Sent: November 27, 2006 12:31 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Allocation Error for SYSPRINT Dataset
Paul Gilmartin
> Date: Wed, 29 Nov 2006 09:09:42 -0500
>
> Ever try using IRXFIND as delivered from IBM with PROFILE NOPREFIX?
>
No. Have you? And:
Search Results for a Shelf
___________________________________________________________________
Search results for shelf: EZ2ZO10G "z/OS V1R7.0 Collection,
April 2006 - z/OS V1R7.0 elements and features"
0 documents have matches for: irxfind
___________________________________________________________________
No search hits found for: irxfind
I guess I shall not for a while. No hits on Google either, and no
alternative spellings suggested.
Lindy Mayfield
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, November 29, 2006 4:51 PM
To: TSO-...@VM.MARIST.EDU