John:
One warning that hit me. We used to do weekly dump & restore of the HSM
cds's.Make sure you make two copies of the backup tape. Either after dump copy
to another tape or create 2 copies with the dump.This saved my ass more than
once. Tape is not even close to being 100 percent dependable.
Umm, I suspect Ed is remembering that IBM-MAIN is not exclusively
about z/.. . That Power 795 sounds like a fairly ferocious beast, if
it really can support 70,000 concurrent "users", no matter how
trivial their transactions, as the quoted benchmark results
suggest. Certainly a very powerful
On Sat, 23 Oct 2010 22:20:26 -0400 Micheal Butz
wrote:
:> If a main program uses a Estae rtn then does Multiple Attaches specifying
:>the same ESTAE rtn on the ESTAI parm of the attach can the recovery routine
:>determine the abending TCB
The abending task will be the current TCB.
--
Binyamin
>You won't find any COBOL compiler in my production LPAR.
>Or SMP/E datasets for that matter.
>No compiling needed outside development and only Target data cloned for the
>LPARs.
Their product (QUIKREF) is rarely used in the production environment.
Rather the majority of users are in development
I am out of the office until 10/31/2010.
Note: This is an automated response to your message "IBM-MAIN Digest - 22
Oct 2010 to 23 Oct 2010 (#2010-296)" sent on 10/24/10 0:00:01.
This is the only notification you will receive while this person is away.
-
Real
Mike
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Phil Smith
Sent: Thursday, October 21, 2010 3:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Storage usage in a job
Mike Toole wrote:
>The 120T in SDSF refers to 120 thousand frames.
On Sun, 2010-10-24 at 00:05 -0700, Ed Gould wrote:
> John:
> One warning that hit me. We used to do weekly dump & restore of the HSM
> cds's.Make sure you make two copies of the backup tape. Either after dump
> copy to another tape or create 2 copies with the dump.This saved my ass more
> than o
ESTAI runs under the abending task (it can even retry witin that task).
Thus the answer is the same that would apply to any ESTAE-type recovery
routine (or FRR).
You can look at PSATOLD to see what task (or, for FRR, if it's a task)
that you're running under
Peter Relson
z/OS Core Technology D
and for only a little topic drift, another recent article
The Scariest Company in Tech
http://www.conceivablytech.com/3637/business/the-scariest-company-in-tech
it references a presentation from 2001 that mentions the fastest DBMS
on the largest IBM computer. I noticed, in part because of referen
To all who may be trying to follow this thread
I suggested a change to the text in the referenced Technote from "You may
need to specify the APPLID and LOGMODE using another format, ..." to "You
may be more used to specifying the APPLID and LOGMODE using another
format, ..." but I forgot to exp
> Dave Cameron is out of the office
Close on 50% of the UK electorate wish that this were indeed so!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-
In most shops I've been in that had QuickRef, the product was used in
production as well as development and testing. In the wee hours of the
morning when a production job goes belly up, those shooting the problem
need/want quick access to relevant information. QuickRef would usually
provide that.
Any COBOL messages to be displayed should be those for the level of the
compiler that was used to compile the program, not necessarily the level
that is currently installed.
- Don Imbriale
On Sat, Oct 23, 2010 at 12:16 PM, Mike Shaw wrote:
>
> Our ISV product displays message descriptions under
>Any COBOL messages to be displayed should be those for the level of the
>compiler that was used to compile the program, not necessarily the level that
>is currently installed.
A good point, and the same is valid for HLASM; how does QUIKREF determine that.
It would be even trickier than determin
>In most shops I've been in that had QuickRef, the product was used in
>production as well as development and testing.
I've worked in environments where developers rarely sign on to production,
especially since the compilers aren't there ((8-{]}).
With shared spool, sysplex, archivers such as S
On 24 Oct 2010 08:51:33 -0700, in bit.listserv.ibm-main you wrote:
>Any COBOL messages to be displayed should be those for the level of the
>compiler that was used to compile the program, not necessarily the level
>that is currently installed.
If the compiled program is generating a COBOL message
On 24 Oct 2010 07:25:30 -0700, in bit.listserv.ibm-main you wrote:
>> Dave Cameron is out of the office
>
>Close on 50% of the UK electorate wish that this were indeed so!
Couldn't you substitute a large number of politician's names and
countries in that statement and have it still true. If thei
Mike Butz writes:
If a main program uses a Estae rtn then does Multiple Attaches specifying
> the same ESTAE rtn on the ESTAI parm of the attach can the recovery routine
> determine the abending TCB
>
If you are getting control in any non-FRR recovery routine (ESTAI, ESTAE(x)
or ARR) then the
The TSO SEND command can send a message from one TSO user to another TSO
user. This works even if the two users are on different z/OS images, so
long as they are in the same JESPLEX. This also appears to work for the
z/OS SEND operator command. The closest equivalent to this that I can
find for thi
At 11:49 -0400 on 10/24/2010, Don Imbriale wrote about Re: How do I
determine Enterprise COBOL for z/OS release le:
Any COBOL messages to be displayed should be those for the level of the
compiler that was used to compile the program, not necessarily the level
that is currently installed.
- Do
>That would show the level of LE on the system not the compiler level (since LE
>routines can get called by a
program compiled by a lower version because LE has alias names for the
downlevel Cobol Versions of the dynamically called routines).
And, as I've stated before, what if the LE is in pro
Charles Mills asked:
| A PDSE can hold program objects that are effortlessly
| converted to conventional load modules when you copy
| them to a PDS. How's that?
IEBCOPY invokes the Program Binder to do the conversion. For example:
> IEB1135I IEBCOPY FMID HDZ1A10 SERVICE LEVEL NONE
Hi,
Was wondering did anyone ever experience an RSMDATA data area validity check
processing
an IPCS dump
When I ran the exception report it dumped the RCE data area
--
For IBM-MAIN subscribe / signoff / archive access instr
William Blair wrote
| . . . back and forth, back and forth, as long as no Program Object-only
constructs are included . . .
This is nearly correct; but 1) the PDSE-only constructs are usually the point;
and 2) the maximal size of a PDS-resident load module is 16 megabytes and that
of a PDSE
On Mon, 25 Oct 2010 02:28:32 +, john gilmore wrote:
>
>The decision not to support IPL-time use of PDSEs was an unconscionable one.
>It would indeed be easy to caricature it as sabotage.
>
Perhaps likewise the decision not to support network-mounted files
at IPL-time. But Mr. Blair is w
On 10/25/2010 1:38 AM, Paul Gilmartin wrote:
I understand that when a PDS member name is removed by BLDL
aliases are not removed. Whether this is "radically
deficient" depends in large part on what happens when the
remaining aliases are referenced or when the PDS is
compressed. I don't know.
26 matches
Mail list logo
