Wow, this has snowballed. To summarize:
I am allocating a DSORG=PO data set with an explicit zero space value for
directory blocks. This data set *is* SMS-managed. The ACS routines don't
interfere with any DCB attributes, and there is no ALLOCxx anywhere within the
parmlib concatenation. (And
One suggestion I would like to make. When a dataset is deleted, a
very tiny EOF record is written to each track. Just enough so the
actual dasd unit erases all records on that track. If we were still
using real 3390s, I would suggest a track full of EOF records. And
not an intensive rewrite of
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Doug Henry
Sent: Thursday, September 19, 2013 9:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Allocation test
On Thu, 19 Sep 2013 13:50:22 -0400, Gerhard Postpischil
W dniu 2013-09-20 06:48, Timothy Sipples pisze:
Radoslaw Skorupka writes:
Form the other hand, inside the BOOK, inside the MCM (multi-chip-module)
there is CPACF chip (actually it's share between 2 CPs depending on the
CPC model).
A couple perhaps pedantic points:
1. Some machine models with
I followed this thread quietly for a long time, but now I'd like to ask
some questions
related to our site, if I'm allowed to do so:
- we are PL/1, not COBOL, but I believe that we will have this issue in
the not so
far future too, is this true?
- we have a home grown tool which does the
I repeated Barbaras job with SPACE=(TRK,(0,0,0)) as a reference:
S000TBE DSLIST Data Set Information
Command ===
Data
Barbara Nitz wrote:
Not sure if that helps, but I guess you should look into defining and
assigning a dataclas with valid space parms whenever a DSORG=PO is allocated
with the invalid space parms I used. Or feel free to open a PMR with IBM,
citing the doc and the obvious not-adherence to the
How about this for a failed project. £10bn blowout on a doomed IT system
for the UK National Health Service
http://www.theguardian.com/society/2013/sep/18/nhs-records-system-10bn.
UK government appear to have learned their lesson by using the cloud and
open source software
Let me add my comments on some of this discussion.
ICSF will try to use whatever is best for any particular requested operation.
For example, if you want to do a clear-key TDES encryption of some data, it
will use the CPACF even if you also have a Crypto Express (CEX) coprocessor.
It does
Hello. We have cobol programs where we are seeing lots of unused variables. Is
there a way we get all the unused variables from the program?
Thanks
Ron T
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
Check out the compiler option XREF
snip
Hello. We have cobol programs where we are seeing lots of unused variables. Is
there a way we get all the unused variables from the program?
/snip
--
For IBM-MAIN subscribe / signoff /
Ron Thomas wrote:
Hello. We have cobol programs where we are seeing lots of unused variables. Is
there a way we get all the unused variables from the program?
Beside eating up valuable storage during execution, is this a problem?
You need to use Two Tools: XREF(FULL) and your eyes.
But, be
On 9/20/2013 7:05 AM, Staller, Allan wrote:
Check out the compiler option XREF
snip
Hello. We have cobol programs where we are seeing lots of unused variables. Is
there a way we get all the unused variables from the program?
/snip
If you are using current COBOL, the compile option
Tim, I have to disagree in part with the statement you made below that ... it
couldn't be avoided. It most certainly *could* have been avoided.
It may have been a ... reasonable, responsible technical choice from IBM's
more-than-occasionally myopic point of view, but not necessarily the best
what do you expect...Gov... first failure.. Microsoft...second
failureCSC/India...oh yes--what a combo...LINUX..LINUX..LINUX...and
for something with Tera bytes of data..tell me a Mainframe--I/O subsystem
would not fit?? .
From: David Crayford dcrayf...@gmail.com
To:
Funny
From: David Crayford dcrayf...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 09/20/2013 07:06 AM
Subject:UK NHS £10bn project failure
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
How about this for a failed project. £10bn blowout on a doomed IT
Bernd,
IBM C/C++ and PL/I are scheduled to use the same backend machinery,
and it would be my guess that they will do so at about the same time;
but the actual dates associated with these scheduling decisions have
not been announced.
John Gilmore, Ashland, MA 01721 - USA
On Thu, 19 Sep 2013 12:19:37 -0400, Farley, Peter x23353 wrote:
QTE6CVllcywgdGhlIGNsZWFyLWtleSBJQ1NGIGVuY3J5cHQvZGVjcnlwdCBmdW5jdGlvbnMgKHdo
aWNoIHVzZSBvbmx5IHRoZSBDUEFDRiBDUFUgaW5zdHJ1Y3Rpb25zLCBubyBjcnlwdG8tY2FyZCBu
[. . .]
But it was readable before I quoted it using the listserv web
On Fri, 20 Sep 2013 07:48:23 -0500, Todd Arnold arno...@us.ibm.com wrote:
Let me add my comments on some of this discussion.
One post said It may be ... that the recently announced protected clear
keys can be used without a coprocessor, increasing the security level even for
clear keys. This
On 09/20/13 09:45, John Chase wrote:
On Thu, 19 Sep 2013 12:19:37 -0400, Farley, Peter x23353 wrote:
QTE6CVllcywgdGhlIGNsZWFyLWtleSBJQ1NGIGVuY3J5cHQvZGVjcnlwdCBmdW5jdGlvbnMgKHdo
aWNoIHVzZSBvbmx5IHRoZSBDUEFDRiBDUFUgaW5zdHJ1Y3Rpb25zLCBubyBjcnlwdG8tY2FyZCBu
[. . .]
But it was readable before I
W dniu 2013-09-20 15:52, Doug Henry pisze:
On Fri, 20 Sep 2013 07:48:23 -0500, Todd Arnold arno...@us.ibm.com wrote:
Let me add my comments on some of this discussion.
One post said It may be ... that the recently announced protected clear keys can
be used without a coprocessor, increasing
On 20 September 2013 09:28, Farley, Peter x23353
peter.far...@broadridge.com wrote:
Tim, I have to disagree in part with the statement you made below that ...
it couldn't be avoided. It most certainly *could* have been avoided.
It may have been a ... reasonable, responsible technical choice
No. The crypto cards preceded the z machines. They were available as part of
the 9672s. There are several different ones with slightly different
capabilities. They are all on the I/O bus so they are slightly slower than the
CPACF hardware for the same operation, but they may be more secure
On 09/20/2013 08:13 AM, Elardus Engelbrecht wrote:
Ron Thomas wrote:
Hello. We have cobol programs where we are seeing lots of unused variables.
Is there a way we get all the unused variables from the program?
Beside eating up valuable storage during execution, is this a problem?
You
Tony,
The 'Java' backend has has almost certainly prevailed. Its use in the
new COBOL compiler was obviously long meditated, and it is now all but
irreversible.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe /
On Fri, 20 Sep 2013 08:41:56 +0200, nitz-...@gmx.net wrote:
I agree with Gerhard on In any case, IBM should be persuaded to either
produce a JCL error or modify the directory build to write an EOF.
I tend to the second solution: Write the EOF in any case. (In setting up my
testcases, I have
On Fri, 20 Sep 2013 09:00:08 -0500, Joel C. Ewing wrote:
It is a common and good practice to use Copy Books to define identical
record layouts for record structures that are accessed by multiple
programs, even if some of the programs only need to access a single
field in the record or just
On 9/20/2013 2:05 AM, Mike Schwab wrote:
One suggestion I would like to make. When a dataset is deleted, a
very tiny EOF record is written to each track. Just enough so the
actual dasd unit erases all records on that track. If we were still
using real 3390s, I would suggest a track full of
Hi,
I agree.. anybody that thinks they need to remove unused variables in a
Cobol program should rather RETIRE or vote for TED CRUZ.
Kerneels
On 9/20/2013 9:12 AM, John Gilmore wrote:
The idea of eliminating unreferenced variables in COBOL record
declarations is of course absurd, and
I suspect that the reason why this was originally implemented this way is that
the function was added back in the day when there were only reel tapes, tape
drives were at a premium and individual ds migrate commands were infrequest, so
individual command migrations were single threaded and
The idea of eliminating unreferenced variables in COBOL record
declarations is of course absurd, and fulminations against it are at
best otiose. It is always possible to construct quietist arguments
against change, any and all change; but this straw man is too
obviously so to very useful to
Kerneels, keep your political commentary out of this, please.
Rex
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of AbsKerneels
Sent: Friday, September 20, 2013 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unused variables
Hi,
My read from previous remarks in this thread is that IBM's long-term
direction is toward program objects and PDSEs for all compilers, because
that sounds like the only easy way to provide new features and also
provide a common run-time environment and debugging capability across
multiple source
Ron,
See Tom Ross's Share presentation slide 21 ...SR1541TR.ppt..it's a simple way
opt(full) + map look for BL=X Hth
Regards
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Sep 20, 2013, at 8:54 AM, Ron Thomas ron5...@gmail.com wrote:
I wouldn’t normally jump on something like this, but as I mentioned, I am in
the middle of a maintenance cycle anyway. What's one more PTF in an already
long list.
_
Dave Jousma
Assistant Vice President, Mainframe Engineering
Guys,
Answer this simple question, Barbara said it best ...job executes, her sample
rc=0 , being a IEFBR14 ..I know does basically nothing ...it must drive
catalog management ..but with a 0 allocation for a PDS directory it should have
never worked according to manuals and to me common sense
Hello ,
Is there a way to list out all the indirect catalogued datasets from a z/os
1.11 system ?
Regards,
Baby
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the
Well all I can say seen this a lot..lack of knowledge, insufficient specs,
inability to critical think...and the worst one, not listening to heavy hitters
who know what they are doing
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Sep 20, 2013, at
On Fri, 20 Sep 2013 18:46:58 +, Jousma, David david.jou...@53.com wrote:
I wouldn’t normally jump on something like this, but as I mentioned, I am in
the middle
of a maintenance cycle anyway. What's one more PTF in an already long list.
What's 10 or 20 more? Just sayin' ...:-)
On
Can you explain what you are looking to do with the information?
A LISTC command will list the information but you need to parse it to
determine what is indirect.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of baby eklavya
We have our program products currently on the respack and they are
indirectly catalogued .As a part of the OS upgrade , we are trying to
separate them from the respack and put them on a new volume ..Then have the
new volume hard coded in the catalog using DEF NVSAM .
On Sat, Sep 21, 2013 at
On 9/19/2013 8:56 PM, Paul Gilmartin wrote:
But I'll welcome a refutation, with accompanying test cases.
(Un)fortunately, you won't get one. I just ran a number of tests, and in
each case the DUMMY allocation produced both a TIOT and JFCB identical
to the one with DSN=NULLFILE. I tried a
Then I would probably write a REXX to do a LISTC ENT('nameof file') VOL
Then check to see if it was indirect
If it was, then I would write out the IDCAMS statements to change the volser
to the one you want.
Note, if the file is allocated, then it will not be able to be re-assigned
Also, if you
On Fri, 20 Sep 2013 12:01:44 -0400, Gerhard Postpischil wrote:
On 9/19/2013 8:56 PM, Paul Gilmartin wrote:
But I'll welcome a refutation, with accompanying test cases.
(Un)fortunately, you won't get one. I just ran a number of tests, and in
each case the DUMMY allocation produced both a TIOT
Baby ,
I thought you are on z/os 1.11 . If that's the case , i dont think you can do
indirect cataloging on VSAM datasets .
Lizette , please correct me if am wrong .
From: Lizette Koehler stars...@mindspring.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent:
FYI,
Just wanted to give a heads up to be on the lookout for OA42799.
Initiator may loop due to PDSE job end code, and cannot be cancelled or
forced. You can get a slip from PDSE L2 to abend the looping task.
APAR is not marked HIPER, so stay frosty.
Regards,
Tom Conley
I would try using DFDSS to move datasets. You would specify the origin volume
and recatalog. I don't have a system to try this on so I can't say it will
work. I would expect that IBM took these indirect volumes into account.
Jon Perryman.
From: baby eklavya
No you are correct, z/OS V1.11 does not allow VSAM to be indirectly
cataloged. However, since it was stated 3rd party products needed to be
moved off the sysres, I wanted to just expand the thought because there
might be cataloged VSAM files on the sysres as well as the indirect catalog.
z/OS
48 matches
Mail list logo
