We have been asked to remove CA-PDSMAN from our Mainframes. Looking around I
haven't found much for replacements. We currently use the following features
of PDSMAN.
Ezyedit
Fast Copy
Member archiving
LLA extensions
Scan and Replace
Member Titles
Does anyone have any suggestions
: breese.ste...@mayo.edu
Subject: Looking for CA-PDSMAN replacements
To: IBM-MAIN@bama.ua.edu
We have been asked to remove CA-PDSMAN from our Mainframes. Looking around I
haven't found much for replacements. We currently use the following features
of PDSMAN.
Ezyedit
Fast Copy
Member archiving
to remove CA-PDSMAN from our Mainframes. Looking around
I haven't found much for replacements. We currently use the following
features of PDSMAN.
Ezyedit
Fast Copy
Member archiving
LLA extensions
Scan and Replace
Member Titles
Does anyone have any suggestions for replacement products
Hi,
In a related topic Death of the Mainframe Steve Ware did a really nice
presentation at SHARE in Seattle based on a simple premise A CICS
support person should be able to articulate the current capabilities of
CICS and the mainframe, and make compelling arguments in favor of
continuing to
:[EMAIL PROTECTED] On Behalf
Of Gary Green
Sent: Monday, March 20, 2006 8:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: The Replacements ???
Interesting article. If it's already been posted, I'm sorry...
http://www.treknature.com/gallery/South_America/Brazil/photo13127.htm
Interesting article. If it's already been posted, I'm sorry...
http://www.treknature.com/gallery/South_America/Brazil/photo13127.htm
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL
Sorry, sorry, sorry
The correct URL is:
http://www.ccnmag.com/news.php?id=4123
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Gary Green
Sent: Monday, March 20, 2006 8:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: The Replacements
Well I did wonder whether the zseries connection was 'blue' .
Hank
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at
didn't enhance the
image of Poughkeepsie.
- Original Message -
From: Gary Green [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Tuesday, 21 March, 2006 2:38 AM
Subject: Re: The Replacements ???
Sorry, sorry, sorry
The correct URL is:
http
Does anyone have an opinion as to whether or not VOLCATs should use ECS ?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives
In [EMAIL PROTECTED], on 07/19/2005
at 09:13 AM, Bill Fairchild [EMAIL PROTECTED] said:
You did.
No I didn't. Read my message more carefully.
If it begins at the level of an atrocity and then gets worse,
Then it's a worse atrocity. Even were you to convince me that worse
than atrocious
In [EMAIL PROTECTED], on
07/18/2005
at 07:59 AM, McKown, John [EMAIL PROTECTED] said:
I may be able to top that.
You;d have to do do better than a performance issue. The code in
question modified an existing SMF exit to accomodate an IBM code
change by swapping two Rx EQU definitions instead
In [EMAIL PROTECTED], on
07/18/2005
at 08:26 AM, McKown, John [EMAIL PROTECTED] said:
Well, why is FIVE a magic number? If you're going to go to the
trouble of using a variable, name the variable so that somebody
else knows what it is, conceptually.
AOL. Programmers should worry more about
In [EMAIL PROTECTED], on 07/18/2005
at 09:10 AM, Bill Fairchild [EMAIL PROTECTED] said:
Starting one's ALC career on a S/360 is a very good guess, as the
S/360 would generate a program interrupt if you tried to do a LH or
STH with an address that was not halfword aligned.
Close; the
In [EMAIL PROTECTED], on 07/18/2005
at 09:15 AM, Bill Fairchild [EMAIL PROTECTED] said:
OK, I'll byte (pun intended). Why is LH r,=H'5' rather than LA r,5
atrocious?
Extra cache hits and perhaps extra page hits.
And why is LH r,FIVE with FIVE DC H'5' worse than atrocious?
What does
In [EMAIL PROTECTED], on 07/18/2005
at 01:35 AM, Bill Fairchild [EMAIL PROTECTED] said:
I don't understand this reply. What is the risk?
The obvious one; collateral damage.
I assumed, but did not state, that the person doing the patching
had already checked the cross-reference list to
In [EMAIL PROTECTED],
on 07/18/2005
at 12:00 AM, Ted MacNEIL [EMAIL PROTECTED] said:
DUH. Thanks for pointing that out.
Whoosh!
The code shown specifically used =H'5'. There is no case where that
*specic* instruction could not have been written instead as an LA r,5.
--
Shmuel
...
[EMAIL PROTECTED] Canadian BLACKBERRY said:
DUH. Thanks for pointing that out.
Whoosh!
...
I didn't say it!
I was quoting some of somebody else's text.
It's almost getting to the point that including text from an OP is not worth it.
Not just me; I have seen other people get quoted text
In a message dated 7/19/2005 7:26:58 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
And why is LH r,FIVE with FIVE DC H'5' worse than atrocious?
What does worse than atrocious mean and who[1] said that it was?
You did.
On 07/16/2005 Gerhard Postpischil said:
And atrocities
In a message dated 7/19/2005 7:29:11 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
I assumed, but did not state, that the person doing the patching
had already checked the cross-reference list to see if the half
word in the literal pool was used anywhere else where such a patch
In a message dated 7/19/2005 7:29:12 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
The code shown specifically used =H'5'. There is no case where that
*specic* instruction could not have been written instead as an LA r,5.
You are correct. You are still missing my point.
2005 09:41
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Highly used programs: any better replacements out there?
In a message dated 7/19/2005 7:29:12 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
The code shown specifically used =H'5'. There is no case where that
*specic* instruction could
In a recent note, Rob Scott said:
Date: Tue, 19 Jul 2005 09:53:49 -0400
Maybe this is a bit of a religious war - but I have always disliked LA
Rx,integer - for maintainability (and readability) I would much prefer
L Rx,=F'integer'.
The maintainability issue has been made very
In a message dated 7/19/2005 9:22:04 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Yet, I prefer L Rx,=A(equated-symbol) so the equated symbol may
be used in other contexts, such as storage declarations.
Another reason why I also prefer this technique is so the equated symbol
In a recent note, Bill Fairchild said:
Date: Tue, 19 Jul 2005 12:04:30 EDT
techniques. I don't see an extra page fault as a big performance hit unless
the code is being executed a huge number of times per second. It is a fine
If the code is executed a huge number of times per
In [EMAIL PROTECTED], on 07/19/2005
at 08:21 AM, Paul Gilmartin [EMAIL PROTECTED] said:
How do other readers feel about:
SIZE EQU 2 * SIZE of an array entry
...
MHRx,=Y(SIZE)
versus:
ARRx,Rx * Multiply by SIEZ of an array entry
... for performance,
In [EMAIL PROTECTED],
on 07/19/2005
at 12:00 AM, Ted MacNEIL [EMAIL PROTECTED] said:
I didn't say it!
I was quoting some of somebody else's text.
The standard Internet convention[1] for indicating that is to prefix
the text with a character.
It's almost getting to the point that including
In [EMAIL PROTECTED], on 07/19/2005
at 09:33 AM, Bill Fairchild [EMAIL PROTECTED] said:
Overlooking a reference to an instruction about to be changed with a
patch
What is at issue is changing a datum that is not an instruction. Such
data typically have more references than instructions do,
In [EMAIL PROTECTED], on 07/19/2005
at 09:41 AM, Bill Fairchild [EMAIL PROTECTED] said:
You are correct. You are still missing my point. Suppose the
original instruction was
LA Rx,4095 and for whatever reason the logic needs to be changed
into LA Rx,4096.
I find it hard to imagine
What is at issue is changing a datum that is not an instruction. Such
data typically have more references than instructions do, and the
references are more likely to be unrelated to each other.
Similarly overlooking a reference to a source code instruction
about to be reassembled may also
Bill Fairchild wrote:
instruction was LHRx,=H'4095' then the half word literal can be patched from
4095 to 4096. In the former case no simple patch is possible. In the
latter case a simple patch is possible. It is also possible that, for whatever
reason, the logic of a LA Rx,5
Rob Scott wrote:
Maybe this is a bit of a religious war - but I have always disliked LA
Rx,integer - for maintainability (and readability) I would much prefer
L Rx,=F'integer'.
Depends on what you wish to do. These days I much prefer using A
constants to let the assembler generate appropriate
Bill Fairchild wrote:
My point was not how close 5 is to 4095, but rather the difficulty in
patching an instruction when the patch only allows 12 bits to be changed (in an LA
instruction) vs. when the patch allows 16 bits to be changed (when changing a
half word literal).
A zap is a
In a message dated 7/18/2005 7:31:40 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
A zap is a zap. I see no difference in degree of difficulty patching one
bit, 12 bits, or 16. The real problem with patching a literal is that it
might be referenced by more than one instruction.
Bill Fairchild wrote:
Right. There is no difference in difficulty. My point was that if the
needed zap involves changing a constant of 4095 to 4096, then you can't do it by
zapping a 12-bit displacement in a LA instruction but you can do it if
affected instruction is using a halfword,
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.)
Sent: Sunday, July 17, 2005 5:23 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Highly used programs: any better replacements out there?
In [EMAIL PROTECTED], on 07
In a message dated 7/18/2005 7:57:25 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Except for the problem I mentioned earlier that a literal can be
referenced by more than one instruction. I prefer to always use
immediate instructions when possible.
A named halfword can also be
The first sentence below is from Gerhard Postpischil.
And atrocities like LH r,=H'5' rather than LA r,5 are still timely.
It gets worse[1]; I've seen stuff like LH r,FIVE with FIVE DC H'5'.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
OK, I'll byte (pun intended).
...
5 is always less than 4095.
DUH. Thanks for pointing that out. And 4094 is also always less than 4095.
...
2 + 2 = 5 (for extremely large values of '2')
(8-{]}
-teD
In God we Trust!
All others bring data!
-- W. Edwards Deming
...
(They run a lot faster!)
...
If you can show me (outside of contrived benchmarks) that this will make a
difference in your next upgrade
then I shall believe that it's relevant.
-teD
In God we Trust!
All others bring data!
-- W. Edwards Deming
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Fairchild
Sent: Monday, July 18, 2005 8:15 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Highly used programs: any better replacements out there?
snip
OK, I'll byte (pun intended
In a recent note, McKown, John said:
Date: Mon, 18 Jul 2005 08:26:49 -0500
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[log in to unmask]] On Behalf Of Bill Fairchild
And why is LH r,FIVE with FIVE DC H'5' worse than atrocious?
Well, why is FIVE
approach. Even though IBM's initial
performance problems have long been corrected, you will still find
people that insist on custom coding replacements as needed to
'improve performance'.
These two common expectations have been non-issues for many years now.
My on personal best surprise moment
In a message dated 7/17/2005 9:25:01 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Your comments about LH r,=H'5' being an atrocity is certainly on
the mark.
There is at least one case where LH Rx,=H'5' is preferable to LA Rx,5.
The LA instruction can load a maximum
These days, LHI serves the purpose much more easily.
Bob
Bill Fairchild wrote:
In a message dated 7/17/2005 9:25:01 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Your comments about LH r,=H'5' being an atrocity is certainly on
the mark.
There is at least one case where
In [EMAIL PROTECTED], on 07/16/2005
at 01:27 AM, Gerhard Postpischil [EMAIL PROTECTED] said:
Depends on what we're talking about. LA r,0 vs. SLR r,r probably is
irrelevant these days. LA r,0(s) vs. LA r,0(,s) isn't.
Some processors have a 3-way adder in the I-unit and the performance
is the
In [EMAIL PROTECTED], on 07/16/2005
at 12:43 PM, Rolf Ernst [EMAIL PROTECTED] said:
That's because TSO spawns a subtask for every command.
No. It's because the TMP waits for the subtask to complete. Also, note
that I was suggesting multiple address spaces to avoid running out of
virtual
Shmuel Metz (Seymour J.) wrote:
Note for new code loading large values: LHI is available on any
zSeries processor.
LHI also works well for loading negative values -- even trivially small
ones (something LA can't do).
LHI is available on many non-zSeries processors and is guaranteed on
In a message dated 7/17/2005 7:03:57 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
5 is always less than 4095.
DUH. Thanks for pointing that out. And 4094 is also always less than 4095.
The poster used 5 as an example. He could also have used 4094 or 4095 as
an example, in
In a recent note, Gerhard Postpischil said:
Date: Sat, 16 Jul 2005 01:27:46 -0400
I consulted at a government agency where I found code that's very clear
and easy to understand:
TM flag,1
BZ label
NI flag,255-1
label .
Well, the
In a recent note, Rolf Ernst said:
Date: Sat, 16 Jul 2005 12:43:41 -0500
That's because TSO spawns a subtask for every command. There is probably
little you can do about it besides VLF.
Gee, hasn't IBM heard that attached tasks can run concurrently?
Shmuel Metz (Seymour J.)
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Martin Kline
How about coding EXEC PGM=NULL (or whatever name you want)
instead of IEFBR14?
One could even go as far as making it a parmlib option as to
what program name is the null program. Maybe even add a
On Jul 14, 2005, at 10:33 PM, Gerhard Postpischil wrote:
Bill Fairchild wrote:
Best reason of all. Time saved is in the order of nanoseconds;
time spent on discussing, thinking about, different keystrokes,
etc., far outweighs the benefit UNLESS the code is executed
thousands of times
In a recent note, Chase, John said:
Date: Fri, 15 Jul 2005 06:43:12 -0500
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Martin Kline
How about coding EXEC PGM=NULL (or whatever name you want)
instead of IEFBR14?
One could even go as far as
Joe Zitzelberger wrote:
What was hyper-efficient last year might not be today. Many of the
'efficiency' tricks that programmers have used for decades are now
actually hinderances.
Depends on what we're talking about. LA r,0 vs. SLR r,r probably is
irrelevant these days. LA r,0(s) vs. LA
Bill Fairchild wrote:
In a message dated 7/13/2005 8:35:47 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Wouldn't XR R15,R15 have been more efficient?
No. Yes. On what processor?
Even in the S/360 days the answer would depend on the box. Likewise SR
versus SLR vs LA.
Right
In a message dated 7/14/2005 1:25:33 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Bill Fairchild wrote:
However, even though it is not of much value, it is certainly of
interest.
If you really want to know how to speed instructions up, you must be
prepared
to read lots of
In a message dated 7/14/2005 5:33:58 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
The model 30 had a simple set of numbers with
no variables. Load Address was something like 19 microseconds no matter
what.
Not quite, IIRC if the index register is not zero then add a
If it ain't broke don't fix it? That would introduce new
potentiality for errors and would increase the overhead
for everything other than IEFBR14. How expensive is one
ATTACH and how much are you willing to pay to get rid
of it?
Oh boo hoo! If you're afraid of the -potential- for errors,
Martin Kline wrote:
If it ain't broke don't fix it? That would introduce new
potentiality for errors and would increase the overhead
for everything other than IEFBR14. How expensive is one
ATTACH and how much are you willing to pay to get rid
of it?
Oh boo hoo! If you're afraid of the
One interesting result was that one MVCL for 1K takes about
as long as four MVCs of 256; below that MVCs are faster on
every processor I tested.
Probably not as surprising as you think. There is only one
move instruction on the z Series. MVCL and other complex
moves are implemented in
In a recent note, Craddock, Chris said:
Date: Thu, 14 Jul 2005 09:21:08 -0500
Another surprise (?) was that two STs were faster than an STM
for two registers.
Once again, no big surprise in terms of cache and memory
design. It might even turn out that the advantage holds true
I'd estimate we use IEFBR14 10,000 times per day.
Correction - after further analysis, we run IEFBR14
over 30,000 times per day. This seems high.
Does anyone else have actual counts?
CONFIDENTIALITY NOTICE: This electronic transmission (including any
accompanying attachments) is intended
One of the companies I worked for had a standard that was required for
their restart procedures. Output datasets were created in iefbr14
step and then referenced as disp=old in the program step. All the
programs were checkpoint restartable but not with IBM checkpoint. The
default CA7/11 restart
Another surprise (?) was that two STs were faster than an STM
for two registers.
Once again, no big surprise in terms of cache and memory
design. It might even turn out that the advantage holds true
for a larger number of registers. Try it.
Might this also depend on whether the
In a message dated 7/14/2005 10:22:13 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Might this also depend on whether the storage operand is
doubleword aligned, and whether the registers are an
even/odd pair?
It definitely depends on the alignment of the storage operand. This is one
In a recent note, Martin Kline said:
Date: Thu, 14 Jul 2005 08:07:40 -0500
The extra overhead for non-IEFBR14 steps is two instructions,
CLC and BC. Since the cost of setting up the step, attaching
the program, generating stats, etc is likely many thousands
of instructions, it's a
How about coding EXEC PGM=NULL (or whatever name you want)
instead of IEFBR14?
One could even go as far as making it a parmlib option as to what program
name is the null program. Maybe even add a console command to
set and remove it.
Additionally, if you want to make it harder (and prone to
Bill Fairchild wrote:
Best reason of all. Time saved is in the order of nanoseconds; time spent
on discussing, thinking about, different keystrokes, etc., far outweighs the
benefit UNLESS the code is executed thousands of times per second in critical
paths, like disabled interrupt
In [EMAIL PROTECTED], on 07/12/2005
at 10:34 AM, Paul Gilmartin [EMAIL PROTECTED] said:
I find that when I go to ISPF 3.4 and type 'D' before a few dozen
data set names, my terminal is unavailable for an uncomfortably long
time during processing.
That ties into the issue of allowing multiple
In [EMAIL PROTECTED], on 07/11/2005
at 04:26 PM, Richard Peurifoy [EMAIL PROTECTED] said:
Many people use this to create/delete datasets.
Or, at least, so they believe. At least it's a less expensive
placeholder than IEHPROGM.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO
In
[EMAIL PROTECTED],
on 07/11/2005
at 04:51 PM, Steve Grimes [EMAIL PROTECTED] said:
Wouldn't XR R15,R15 have been more efficient?
No. Yes. On what processor?
Even in the S/360 days the answer would depend on the box. Likewise SR
versus SLR vs LA.
--
Shmuel (Seymour J.) Metz,
In a message dated 7/13/2005 8:35:47 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Wouldn't XR R15,R15 have been more efficient?
No. Yes. On what processor?
Even in the S/360 days the answer would depend on the box. Likewise SR
versus SLR vs LA.
Right on, Shmuel.
I learned
Bill Fairchild wrote:
However, even though it is not of much value, it is certainly of interest.
If you really want to know how to speed instructions up, you must be prepared
to read lots of highly arcane technical papers on instruction processing
units, pipelines, instruction caches,
IEFBR14 already does as near to nothing as possible
(SR R15,R15 BR R14
Why hasn't IBM come out with a JCL option that says, There is no
program, just set return code zero? It could avoid all the setup for
calling IEFBR14 - LOAD, DELETE, RB setup, save area, recovery,
etc.
CONFIDENTIALITY
Why hasn't IBM come out with a JCL option that
says, There is no program, just set return code
zero? It could avoid all the setup for calling
IEFBR14 - LOAD, DELETE, RB setup, save area,
recovery, etc.
Is this comment just noise or do you seriously expect
IBM to change/eliminate IEBGENER?
Please reread my suggestion. It says nothing about
IEBGENER. I also wouldn't expect anyone to eliminate
IEFBR14. Just have the initiator recognize that the
program is effectively a null operation if so
specified. Of course, still perform any JCL functions
like dataset allocation and deletion.
I
Why hasn't IBM come out with a JCL option that says, There is no
program, just set return code zero? It could avoid all the setup for
calling IEFBR14 - LOAD, DELETE, RB setup, save area, recovery, etc.
...
Eh?
IEFBR14 is simpler to maintain than a special case in JCL processing
(especially
...
Just have the initiator recognize that the
program is effectively a null operation if so
specified.
...
Why code the special case?
What we have works; why complicate it with special code paths?
-teD
In God we Trust!
All others bring data!
--Deming
Is this just noise or do you seriously expect
IBM to implement this?
It's a serious suggestion, but I do not expect IBM to
give it serious consideration. There's no money to make.
CONFIDENTIALITY NOTICE: This electronic transmission (including any
accompanying attachments) is intended solely
Why code the special case?
What we have works; why complicate it with special code paths?
Why do anything? DOS 1.0 worked, too.
CONFIDENTIALITY NOTICE: This electronic transmission (including any
accompanying attachments) is intended solely for its authorized
recipient(s), and may contain
I've tried teaching them better (use IDCAMS), but
this is the way that I've done it since 1975 and
I'm not changing!
What we have works; why complicate it?
CONFIDENTIALITY NOTICE: This electronic transmission (including any
accompanying attachments) is intended solely for its authorized
On 11-Jul-2005, Abbacabba [EMAIL PROTECTED] wrote:
IEFBR14 is one of our most USED program with ~1500 uses a day.
You won't gain anything by trying to make a more efficient IEFBR14. But that
isn't your goal. We don't have any business needs to have IEFBR14 run. What
we have are needs to
programs: any better replacements out there?
IDCAMS, IEFBR14
On Mon, 2005-07-11 at 00:00 +, Ted MacNEIL wrote:
I didn't intend to talk down, but I know many APPDEV-types
who think of this as the only way to create/delete.
I once had an applications guy (a new hire) ask me where the IEFBR14
...
Did you tell him about the IEFBR15 utility?
...
IBM used to use one in the early days of bench-mark(ett)ing to get rid of the
low utilisation effect.
-teD
In God we Trust!
All others bring data!
--Deming
--
Rob Scott wrote:
If only there was an easy way to do this ...h..
How about a program that just sets the return code to zero and returned
to the usereven better than that - why don't we put it in LPA so
that there is no LOAD/DELETE overhead.
Or one of my favorites:
Richard Pinion wrote:
Sorry I have the copy write on that program!!!
OK. Just so long as you don't own the copyright.
--
-
| Edward E. Jaffe||
| Mgr, Research Development|
I guess I failed spelling, copy write!!
I have the copyright on that program, ABEND806.
[EMAIL PROTECTED] 07/12/05 12:03 PM
Sorry I have the copy write on that program!!!
[EMAIL PROTECTED] 07/12/05 12:02 PM
Rob Scott wrote:
If only there was an easy way to do this ...h..
How
In a recent note, Martin Kline said:
Date: Tue, 12 Jul 2005 07:43:18 -0500
It's a serious suggestion, but I do not expect IBM to
give it serious consideration. There's no money to make.
IBM will respond to serious customer requirements. But you
need to make a business case. You
On Tue, 12 Jul 2005 09:02:01 -0700, Edward E. Jaffe
[EMAIL PROTECTED] wrote:
Or one of my favorites:
//***/
//* Generate S806 Abend */
//***/
//ABEND806 EXEC PGM=ABEND806
This job step works as advertised without a load module of *any* kind!
-Original Message-
From: Paul Gilmartin [EMAIL PROTECTED]
Date: Tue, 12 Jul 2005 10:34:34
To:IBM-MAIN@BAMA.UA.EDU
Subject: Re: Highly used programs: any better replacements out there? IDCAMS,
IEFBR14
In a recent note, Martin Kline said:
Date: Tue, 12 Jul 2005 07:43:18
Paul Gilmartin wrote:
I find that when I go to ISPF 3.4 and type 'D' before a few
dozen data set names, my terminal is unavailable for an
uncomfortably long time during processing.
I used to experience similar delays when deleting large numbers of data
sets. Then came Enhanced Catalog
Sorry about that.
Some times the (fat) finger is quicker than the eye.
-Original Message-
From: Ted MacNEIL [EMAIL PROTECTED]
Date: Tue, 12 Jul 2005 00:00:00
To:IBM-MAIN@BAMA.UA.EDU
Subject: Re: Highly used programs: any better replacements out there? IDCAMS,
IEFBR14
On Tue, 12 Jul 2005 09:48:12 -0700, Edward E. Jaffe
[EMAIL PROTECTED] wrote:
Issue the 'f catalog,ecshr(status)' system command to find out if you're
using this important catalog performance enhancement.
After first asking yourself am I running a parallel sysplex? and
am I not sharing catalogs
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Edward E. Jaffe
Sent: Tuesday, July 12, 2005 11:02 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Highly used programs: any better replacements
out there? IDCAMS, IEFBR14
snip
Or one
On 12-Jul-2005, [EMAIL PROTECTED] (Edward E. Jaffe) wrote:
Or one of my favorites:
//***/
//* Generate S806 Abend */
//***/
//ABEND806 EXEC PGM=ABEND806
This job step works as advertised without a load module of *any* kind!
Especially
Edward E. Jaffe wrote:
Mark Zelden wrote:
On Tue, 12 Jul 2005 09:02:01 -0700, Edward E. Jaffe
[EMAIL PROTECTED] wrote:
Or one of my favorites:
//***/
//* Generate S806 Abend */
//***/
//ABEND806 EXEC PGM=ABEND806
This job step works as
: any better replacements out there?
IDCAMS, IEFBR14
On Tue, 12 Jul 2005 09:57:33 -0700, Edward E. Jaffe
[log in to unmask] wrote:
Issue the 'f catalog,ecshr(status)' system command to find out if you're
using this important catalog performance enhancement.
After first
On Tue, 12 Jul 2005 11:51:50 -0600, Paul Gilmartin
[EMAIL PROTECTED] wrote:
It would sure be nice if 3.4 scanned prefix commands for 'D' and
generated a batch IDCAMS job (one; not one per prefix), at least
optionally.
I suppose I could write an EXEC. I'm almost too old to indulge
in such
Mark Zelden wrote:
On Tue, 12 Jul 2005 09:57:33 -0700, Edward E. Jaffe
[EMAIL PROTECTED] wrote:
Issue the 'f catalog,ecshr(status)' system command to find out if you're
using this important catalog performance enhancement.
After first asking yourself am I running a parallel
1 - 100 of 120 matches
Mail list logo
