Lizette,
I cannot use a mask in the SET command.
Later I realized that the substr function to find text is there of course, but
the replace is what I am missing, like in code to convert old management
classes to new ones, while providing transparacy to JCL roaming around in the
company.
Exampl
I could agree with that too.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Monday, July 15, 2013 9:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF record - IPADDR
In <003801ce8119$55b87300$01295900$
Whatever their timing formulas or model-dependant behavior, in the old days of
non-pipelined or minimally-pipelined CPU engines you ran your batch application
program once with the appropriate test data using the "production" load module
on an unloaded or lightly loaded machine, then you ran it
In
<985915eee6984740ae93f8495c624c6c2319af4...@jscpcwexmaa1.bsg.ad.adp.com>,
on 07/15/2013
at 11:01 AM, "Farley, Peter x23353"
said:
>I remember when I first was disabused of the quaint notion that the
>CPU performance of a batch z/OS application could be measured in a
>deterministic manner,
Gil,
I agree; that sounds like a defect (or enhancement? :-)
On Mon, Jul 15, 2013 at 10:38 AM, Paul Gilmartin wrote:
> On Mon, 15 Jul 2013 09:23:40 -0500, Kirk Wolf wrote:
> >
> >Maybe that is one of the "enhancements" ? :-)
> >
> Exoskeletal "enhancement"? Is there any rationale for making t
IBM Resource Link: Large Systems Performance Reference for IBM System z
This is a starting point. The tuning pros help to keep them honest with
analysis of what is and what is not
in the benchmarks. I remember Cheryl pointed out that the 9672 benchmarks left
out Cobol pgms with 'Indexed by'
du
My sample size must be too small to be significant, but it seems that over the
past decade or two, that vast majority of ACS administrators I've spoken to
would love to have some sort of facility which would allow sharing common
source code between the ACS routines.
> -Original Message---
We have two lpars plexed, sharing DASD and catalogs and run HSM on each. Lpar-1
is supposed to handle the backups.
Lpar-1: AUTOBACKUPSTART(1700 1800 1900)
Lpar-2: AUTOBACKUPSTART( )
Backups start at 17:00 and typically end around 17:11, hence, it seems
sufficient time is provided.
I would like to see world peace and an end to hunger.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Kirk Wolf
Sent: Monday, July 15, 2013 6:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF record - IPADDR
IMO, the proble
Interesting thought. Let me check it out.
David G. Schlecht | Information Technology Professional
State of Nevada | Department of Administration | Enterprise IT Services
T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov
-Original Message-
From: IBM Mainframe Discussion List
David,
Is it possible that your time window for DFHSM backups is not long enough
for the incremental backups to complete?
Regards,
Ulrich Krueger
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David G. Schlecht
Sent: Monday, July 1
A new wrinkle and possibly related. I have a job that creates two GDGs in the
same Management Class. Both should be backed up. However, one gets backed up
while the other doesn't. The backup for the first shows up in HSM's job logs at
the point of backup but the second is entirely absent from HS
Hi,
What we do to get around this is to use ISPF skeletons (with a bit of REXX
involved) which we run as part of a two stop batch process using Naviquest.
Within the REXX, we build a table of our DB2 systems, and then the skeleton has
)DOT constructions to loop around building those 15 WHEN cla
On Mon, 15 Jul 2013 09:23:40 -0500, Kirk Wolf wrote:
>
>Maybe that is one of the "enhancements" ? :-)
>
Exoskeletal "enhancement"? Is there any rationale for making the
ASCII behavior different from the EBCDIC?
>Actually this seems to be an issue with the stream buffering strategy.
>See the C/C+
Peter Farley's lament is understandable, but it is important to
[better] understand that all scientific and engineering questions are
statistical in character and that they become so increasingly as a
subject advances.
Deterministic, Newtonian methods served physics well in the 17th
century; but t
Kees,
Could you expand on the 15 WHEN clauses?
Provide a snippet?
How does the * vs. % not help? Are you really parsing it down that granularly?
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Vernooij, CP - SPLXM
Sent
I remember when I first was disabused of the quaint notion that the CPU
performance of a batch z/OS application could be measured in a deterministic
manner, here on this very list some years ago. The implications of processor
pipelining and branch prediction and AGI and cache lines had just not
On Mon, 15 Jul 2013 16:05:06 +0200, Vernooij, CP - SPLXM
wrote:
>Bingo! This is what I had stored many years ago somewhere in migrated memory:
>the COPYFILT macro.
Ag! Yet another good pun about to be migrated in my flaky memory... ;-)
You're welcome. Thanks!
>I will have a look at
Gil,
Maybe that is one of the "enhancements" ? :-)
Actually this seems to be an issue with the stream buffering strategy.
See the C/C++ RTL Ref for "setvbuf()". Maybe you need to explicitly call
setvbuf() for stdout/stderr with __LIBASCII ??
Kirk Wolf
Dovetailed Technologies
http://dovetail.co
Martin,
I'm sorry that I wasn't clear. I'm not arguing for different data formats
for SMF.
I'm saying that we need something other than Assembler DSECTs as a metadata
description.
Say for example that there were a standard metadata document (maybe in XML
or JSON) that *described* all of the SMF
Bingo! This is what I had stored many years ago somewhere in migrated memory:
the COPYFILT macro. It is not completely automatic, but it takes only one
command to fire the automation of updating multiple tables in multiple routines.
I will have a look at it again to see if it helps me this time.
In <003801ce8119$55b87300$01295900$@com>, on 07/15/2013
at 12:08 AM, "Roger W. Suhr" said:
>I'd vote for both. All IBM product SMF records type 0-200 should be
>documented in the SMF manual.
Alternatively, the SMF and control blocks manuals should have links[1]
to the appropriate product man
Nice idea. Would need some new low level node. Perhaps SXMLSMF? Or
SJSONSMF. I'm not an expert in either, but the relocatable, possibly
repeating, sections might be a bit difficult to document. Perhaps a DTD is
needed as well. SDTDSMF and ADTDSMF in what appears to be IBM's current
SMP/E naming co
While I agree it would be nice to have more consumable data formats I
don't agree documentation isn't a major problem:
As someone who spends a lot of time with the raw data all sorts of
questions come up that the documentation doesn't address, mainly of
provenance and interpretation.
A concord
IMO, the problem with SMF records is not the documentation.
I would like to see IBM publish some sort of machine-readable schema
document (say, in XML or JSON) for each record that describes the structure
and datatypes in each record.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Mon
Management today, especially in large companies, seem to have no
"investment" in the company itself, on a long term basis. They know that
they need to get their "pay off" quickly (before they are replaced) and
that "reducing cost" will get them money in their pockets faster. So there
is little ince
I think this would be resisted by IBM. There are too many basically
separate products which produce SMF records. Some even the same SMF record
number, such as 110 for CICS and DB2. But what we _might_ be able to
convince IBM to do is to create a Web bookshelf, similar to the "z/OS
Messages and Code
Vernooij, CP wrote:
>So I probably mixed some historical info in my memory. It would be nice to
>have, e.g. for dsname- of volser-filtlists used in more than one routine.
>However, there are not many enhancements in ACS routines the last decades, so
>I expect this will remain a wish.
You've g
On Sun, 14 Jul 2013 18:30:46 -0400, John respake:
>I see no evidence that the mainframe is going the way of the dodo.
>What is happening, outside China and several other new markets, is
>that 1) the number of small- and middling-sizeed mainframe shops is
>dropping steadily and 2) that many of the
I found this very fun to listen to, and thought to share it. I particularly
liked the work notes from the people building and programming the computers in
the 50's.
Kind regards,
Lindy
http://www.ted.com/talks/george_dyson_at_the_birth_of_the_computer.html
--
On Sun, 14 Jul 2013 17:19:09 -0400 Richard Verville
wrote:
:>John Gilmore->There is no need for further assertions that things
:>that manifestly do work may not or for something less than clarity
:>about, for example, the fact that AMODE(64) code is faster than
:>AMODE(31) code.<
:>Are you sayin
So I probably mixed some historical info in my memory. It would be nice to
have, e.g. for dsname- of volser-filtlists used in more than one routine.
However, there are not many enhancements in ACS routines the last decades, so I
expect this will remain a wish.
Kees.
-Original Message-
32 matches
Mail list logo
