G'day,
I have some members in a PDS that I have not been able to delete. They are
Endevor backup members (first character of the name is 'FE'x).
I have tried to use LMDELETE, TSO and IDCAMS delete. All have failed.
Are there any utilities that will delete the members?
Thank you.
Regards,
Hello,
Appears this same question back on Jan 10 2006. The reply thread is pasted
below.
Scott Barry
SBBWorks, Inc.
__
***
***
Subject: Does any have a program that can delete non-standard member
names from a PDS
From:
Thank you Scott,
This time the procedure does not work, I'm getting an RC 8 from the LMDELETE
(8 - Member not found).
When I copied the data set the members give the error message:
IEB189I DIRECTORY ENTRY §YB4I2QK IN BLOCK READ FROM DDNAME INVOL1
IS OUT OF SEQUENCE OR DUPLICATE AT TTR
Update:
PDS command does not show them in the member list.
In a 3.4, Member list it is show as:
.YB4I2QK *No Data
Regards,
Herman Stocker
The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
The following discussion on comp.lang.cobol may prove interesting. I
would be curious to read if any of the major claims such as American
Airlines Sabre moving totally to Unix are wrong.
Clark Morris
On Wed, 30 Apr 2008 22:38:36 -0500, in comp.lang.cobol Robert
[EMAIL PROTECTED] wrote:
On Wed,
On Sun, 4 May 2008 05:04:36 -0400, Stocker, Herman wrote:
Thank you Scott,
This time the procedure does not work, I'm getting an RC 8 from the LMDELETE
(8 - Member not found).
When I copied the data set the members give the error message:
IEB189I DIRECTORY ENTRY §YB4I2QK IN BLOCK READ FROM
--snip---
Is it proper, then, to make the assumption that if two authorized
programs fall into a deadlock with each other, and fail to detect or
recover, a developer didn't know what he was doing, and at least one of
the programs should be APARable?
snip---
May I have a go at it, too? Someone just helped me figure this out.
I haven't learned how to set a trap for something like this yet to get a
dump, but I imagine it isn't hard.
But from an SVC dump you find the abending TCB. Then from there look at
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Schwarz, Barry A
Yes it's great if you are allowed to connect your system to
the internet. For the rest (few?) of us who cannot, we still
need maintenance.
And while we are on the subject, why does an internet
On Fri, 2 May 2008 15:13:43 -0700, Schwarz, Barry A wrote:
Yes it's great if you are allowed to connect your system to the
internet. For the rest (few?) of us who cannot, we still need
maintenance.
Get a laptop running Solaris, OS X, Linux, or Windows.
Step A:
- Connect the laptop to the
On Sun, 4 May 2008 09:53:18 -0500, Rick Fochtman wrote:
--snip---
Is it proper, then, to make the assumption that if two authorized
programs fall into a deadlock with each other, and fail to detect or
recover, a developer didn't know what he was doing, and at
I was involved in one of these at a MAJOR Pharm company,
Going from mainframes to Unix, just plain didn't work. Programs couldn't be
converted, ended up moving back to z/OS and mainframes.
Scott Ford
Senior Host Developer | Forging Enterprise Identity | IdentityForge.com
(Main) 678.266.3399
Paul Gilmartin wrote:
it if it exists regardless of syntax rules). If the designers
intended to support mixed case names, as STOW and BLDL do, TSO,
ISPF, and other utilities should not overrule their design by
forcing input to upper case, particularly if the member name
You're imputing too
On Sun, 4 May 2008 14:53:08 -0400 Gerhard Postpischil [EMAIL PROTECTED]
wrote:
:Paul Gilmartin wrote:
: it if it exists regardless of syntax rules). If the designers
: intended to support mixed case names, as STOW and BLDL do, TSO,
: ISPF, and other utilities should not overrule their design by
On Sun, 4 May 2008 14:53:08 -0400, Gerhard Postpischil wrote:
Paul Gilmartin wrote:
it if it exists regardless of syntax rules). If the designers
intended to support mixed case names, as STOW and BLDL do, TSO,
ISPF, and other utilities should not overrule their design by
forcing input to
At 16:23 -0500 on 05/03/2008, Tom Schmidt wrote about Re: SVC99:
I suspect that the problem your program is having has less to do
with the SYSDSN enqueue that S99WTDSN was designed to cope with, and
more to do with the SYSVSAM enqueue that Catalog management and VSAM
use for proper
Paul Gilmartin wrote:
May I not conclude from the fact that STOW accepts percent
signs and other funny characters that the designers intended
them to be legal? (But I haven't tried lately; does STOW
nowadays place such restrictions on member name syntax?)
I haven't tried lately, either; I'm
On Sun, 4 May 2008 15:39:47 -0400, Robert A. Rosenberg wrote:
At 16:23 -0500 on 05/03/2008, Tom Schmidt wrote about Re: SVC99:
I suspect that the problem your program is having has less to do
with the SYSDSN enqueue that S99WTDSN was designed to cope with, and
more to do with the SYSVSAM enqueue
I would like to know how many are specifying allowuserkeycsa=yes in a z/OS
1.9 environment and if there have been any issues?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED]
Clark,
I don't know the particulars of SABRE at this time, but I do find the price
quotes interesting, the reference the price of a z900, without memory.
First of all a z900 is obsolete hardware, given that the z990, z9 and z10
have all been made GA. Second, while it is true that Disk isn't part
To reconfirm again, the load module is authorised (AC=1) and we did not break
the authorisation by coding STEPLIB.
I found few interesting things related to wait on SVC 99 today,
The program XYZ uses SVC 99 in two different places (both using the same
allocation request block allocation
I think Tom Schmidt has already given the reason for SVC 99 wait failure due
to SYSVSAM. And my previous message proves the fact that SVC 99 wait
works fine with SYSDSN only.
--
For IBM-MAIN subscribe / signoff / archive access
22 matches
Mail list logo
