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 I
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 CPACF have neither processor "books" nor MCMs.
Th
Or allow the end user/customer to choose the encoding via an external
parameter setting and assume a "sensible," perhaps OS-sensitive default
value if unspecified?
It'd also probably be a good idea to handle gracefully the exception Java
throws if someone attempts to run a bit of platform-specific
I think that's a good summary, Joel, of some of the considerations in how
to go about adopting PDSEs. Thanks. Though I would point out that many/most
of those considerations are not necessarily *unique* to this particular
compiler upgrade. Juggling multiple libraries and changing build/test/run
pro
On Thu, 19 Sep 2013 19:48:54 -0400, Gerhard Postpischil wrote:
>
>At a minimum, DSN=NULLFILE, unlike a plain DD DUMMY, can be used to
>carry more JFCB information to a program (volsers, DCBs, etc.). I use
>this when a program may allocate a file dynamically, and the DSORG and
>size are determined d
I guess this doesn't apply to br14
Previous topic | Next topic | Contents | Index | Contact z/OS | Library | PDF |
BOOK
Allocating Space for a PDS
z/OS V1R12.0 DFSMS Using Data Sets
SC26-7410-10
To allocate a PDS, specify PDS in the DSNTYPE parameter and the number of
directory blocks
I tried, unsuccessfully, four or five years ago to write an EOF record with a
non-zero key length but a zero data length, and it failed with a permanent I/O
error. I don't recall if this possible combination is documented in any
Control Unit Reference book as not being allowed.
Bill Fairchil
On 9/19/2013 6:05 PM, Paul Gilmartin wrote:
By analogy, unless you create at least one record in a PS data set,
what good is it? Therefore, DSN=NULLFILE is pointless.
I suspect that there are some programmers who will disagree with that.
At a minimum, DSN=NULLFILE, unlike a plain DD DUMMY, ca
On Thu, 19 Sep 2013 13:50:22 -0400, Gerhard Postpischil
wrote:
>On 9/19/2013 1:17 PM, Doug Henry wrote:
>> Obviously Barbara intentionally didn't request any directory blocks.
>> I would expect and I am sure she did also that would produce a JCL
>> error.
>
>I'm conflicted whether this should pr
On 18 September 2013 11:39, John P Kalinich wrote:
> This web link has end of service dates for IBM products.
>
> http://www-01.ibm.com/software/support/lifecycle/index_e.html
Where clicking on the z/OS 1.13 line gives me a nice friendly IBM message:
"Internal Server Error
The server encounter
On 9/19/2013 3:43 PM, efinnell15 wrote:
If there's a vote I'd vote for the early JCL error for PO with no directory
blocks
and DISP new.
If someone opens a SHARE requirement, there will be a vote.
Otherwise...not. :(
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive N
If there's a vote I'd vote for the early JCL error for PO with no directory
blocks
and DISP new.
In a message dated 09/19/13 16:45:40 Central Daylight Time, gerh...@valley.net
writes:
Regardless, the current action would seem to be APARable as a security
exposure.
--
On Thu, 19 Sep 2013 17:45:02 -0400, Gerhard Postpischil wrote:
>On 9/19/2013 3:06 PM, Doug Henry wrote:
>> Of course their are methods to default the number of directory
>> blocks. One that easily comes to mind is dataclass. But isn't all of
>> this something that occurs during allocation and ope
Don't know but perhaps it's one of the environment properties/strings returned
in ZUtil.getEnvironment() or ZUtil.environ()?
http://www.ibm.com/developerworks/java/zos/javadoc/jzos/com/ibm/jzos/ZUtil.html#getEnvironment()
> signature = 6 lines follows <
Neil Duffee, Joe Sysprog
On 9/19/2013 3:06 PM, Doug Henry wrote:
Of course their are methods to default the number of directory
blocks. One that easily comes to mind is dataclass. But isn't all of
this something that occurs during allocation and open is to late.
Unless you create at least one directory block for a pds ,
Kirk Wolf wrote:
>Some examples:
>- The HMAC and Cipher calls that are better on CPACF than card anyway
>- With the latest (A0) level of ICSF, the Unix /dev/random and /dev/urandom
>devices will work if ICSF is started, and no longer require a co-processor
>card
>Both of these examples will signi
On 9/19/2013 3:19 PM, Richard Peurifoy wrote:
On 9/19/2013 8:13 AM, Paul Gilmartin wrote:
By surmise, I'll add another piece to the puzzle. Since the specified
directory blocks is 0, allocation does not format a directory, and does
not write the terminating EOF. Later, allocation sees that DS
W dniu 2013-09-19 17:04, Tiegox QQ pisze:
> Are coprocessors supposed resided in CPU book?crypto card is different.
Since z990 (approx. 10 years) you can have crypto cards - the cards are
similar in format to ESCON, FICON or OSA cards.
The card is named CryptoExpress. The card inside contains whol
On Thu, 19 Sep 2013 14:06:25 -0500, Doug Henry wrote:
>On Thu, 19 Sep 2013 13:50:22 -0400, Gerhard Postpischil wrote:
>
>>In any case, IBM should be persuaded to either produce a JCL error or
>>modify the directory build to write an EOF.
>
>Of course their are methods to default the number of dire
Were the same features in both z/OS 1.11 and 1.13? If 1.13 had more features,
mode would be dumped.
I do know that the z/OS USS ROOT hfs/zfs grew significantly, irrespective of
additional features.
z/OSMF had several significant enhancements and was significantly larger as
well, again, irrespect
Hi,
We have a set of weekly full volume dasd dumps just for our non-sms mvs
volumes
(sysres, pre-ipl vols etc), housing many of our system datasets that are
almost purely static...ie do not grow or do not get written to.
On July 21st, the lpar that run our weekly full volume dumps
was upgraded to z
W dniu 2013-09-19 16:48, John Chase pisze:
Hi, List,
On z/OS 1.13:
Q1: Is there anything to be gained, running ICSF without any cryptographic
coprocessors installed?
Q2: Is anything "lost" by NOT running ICSF without cryptographic coprocessors
installed?
TIA,
-jc-
-
On 9/19/2013 8:13 AM, Paul Gilmartin wrote:
By surmise, I'll add another piece to the puzzle. Since the specified
directory blocks is 0, allocation does not format a directory, and does
not write the terminating EOF. Later, allocation sees that DSORG=PO,
and does not write an EOF (which would
Doug,
I would imply based on that fact this is a bug ...
Scott J Ford
Software Engineer
http://www.identityforge.com/
From: Doug Henry
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, September 19, 2013 3:36 PM
Subject: Re: Allocation test
On Thu, 19 Sep 20
On Thu, 19 Sep 2013 13:50:22 -0400, Gerhard Postpischil
wrote:
>On 9/19/2013 1:17 PM, Doug Henry wrote:
>> Obviously Barbara intentionally didn't request any directory blocks.
>> I would expect and I am sure she did also that would produce a JCL
>> error.
>
>I'm conflicted whether this should pr
Barbara,
I have the same problem, our environment ..z/OS 1.13 slu 1209 no SMS
Heres our DIAGxx
VSM TRACK CSA(ON) SQA(ON) 0135
VSM TRACE GETFREE(OFF) 0140
Bott
On Thu, 19 Sep 2013 13:50:22 -0400, Gerhard Postpischil
wrote:
>On 9/19/2013 1:17 PM, Doug Henry wrote:
>> Obviously Barbara intentionally didn't request any directory blocks.
>> I would expect and I am sure she did also that would produce a JCL
>> error.
>
>>In any case, IBM should be persuaded
On Thu, 19 Sep 2013 10:07:48 -0500, Doug Henry wrote:
>
>This is true. In SC26-7407-07 DFSMS Implementing System-Managed Storage it says
>
>"Ensured Data Integrity on New Allocations
>The system provides data integrity for newly allocated data sets that have not
>been written to. For these data s
On 9/19/2013 1:17 PM, Doug Henry wrote:
Obviously Barbara intentionally didn't request any directory blocks.
I would expect and I am sure she did also that would produce a JCL
error.
I'm conflicted whether this should produce a JCL error. Programmers have
been using RDJFCB/OPENJ and changing a
On Thu, 19 Sep 2013 11:26:54 -0500, Paul Gilmartin wrote:
>On Thu, 19 Sep 2013 10:07:48 -0500, Doug Henry wrote:
>>
>>This is true. In SC26-7407-07 DFSMS Implementing System-Managed Storage it
>>says
>>
>>"Ensured Data Integrity on New Allocations
>>The system provides data integrity for newly
On Thu, 19 Sep 2013 09:00:21 -0700, Scott Ford wrote:
>I had the same question ..can a vendor query where the crypto card is
>installed or not ? so it could be used...?
The Redbook I referenced earlier has a Rexx Exec that shows how to uses CSFIQF
interface to display information. The comment
On Thu, 19 Sep 2013 23:04:26 +0800, Tiegox QQ wrote:
>Are coprocessors supposed resided in CPU book?crypto card is different.
This is incorrect. The crypto card is configured as a coprocessor (or can also
be used in accelerator mode).
.
John Chase wrote :
>> Hi, List,
>>
>> On z/OS 1.13:
>>
I just started using PDSEs , found out if I use C with longnames, you have to ..
Scott J Ford
Software Engineer
http://www.identityforge.com/
From: R.S.
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, September 19, 2013 9:37 AM
Subject: Re: Allocation test
Right
Some examples:
- The HMAC and Cipher calls that are better on CPACF than card anyway
- With the latest (A0) level of ICSF, the Unix /dev/random and /dev/urandom
devices will work if ICSF is started, and no longer require a co-processor
card
Both of these examples will significantly improve
I had the same question ..can a vendor query where the crypto card is installed
or not ? so it could be used...?
Scott J Ford
Software Engineer
http://www.identityforge.com/
From: John Chase
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, September 19, 2013 1
A1: Yes, the clear-key ICSF encrypt/decrypt functions (which use only the
CPACF CPU instructions, no crypto-card needed) can be used with clear keys
stored securely in the CKDS. It may be (don't know this for a fact) that the
recently announced "protected" clear keys can be used without a c
On Thu, 19 Sep 2013 08:12:56 -0500, Paul Gilmartin wrote:
>>Is the EOF written only if the data set is SMS-managed, or is this one
>of those thingys that requires only that the SMS STC/ASID be active
>at the time of creation?
>
>I say the EOF (had it been written) must be real, not pseudo, to
>pr
Sorry, yes a typo. I meant ISO8859-1.
re:new String(byte[])
- read the javadoc for this. It builds a String using the current
System.getProperty("file.encoding")
In generaly, you should *always* specify the encoding that you want when
making a String from bytes - unless what you really wa
On 09/18/2013 10:52 PM, Timothy Sipples wrote:
> Tom Conley offers a nomination:
>> Simple. With Java, we didn't have 40 years and thousands (millions?)
>> of libraries to convert. That's what makes COBOL different, the
>> conversion effort. Java had no code base to convert, so we could
>> start ne
Are coprocessors supposed resided in CPU book?crypto card is different.
发自我的 iPhone
> 在 2013年9月19日,22:48,John Chase 写道:
>
> Hi, List,
>
> On z/OS 1.13:
>
> Q1: Is there anything to be gained, running ICSF without any cryptographic
> coprocessors installed?
>
> Q2: Is anything "lost" by N
On 09/19/13 10:48, John Chase wrote:
Hi, List,
On z/OS 1.13:
Q1: Is there anything to be gained, running ICSF without any cryptographic
coprocessors installed?
Q2: Is anything "lost" by NOT running ICSF without cryptographic coprocessors
installed?
TIA,
-jc-
---
Hi, List,
On z/OS 1.13:
Q1: Is there anything to be gained, running ICSF without any cryptographic
coprocessors installed?
Q2: Is anything "lost" by NOT running ICSF without cryptographic coprocessors
installed?
TIA,
-jc-
---
In article
you wrote:
> Minor suggestion; should use:
> System.out.println( new String(cpuid,
> ZFile.DEFAULT_EBCDIC_CODE_PAGE) );
> otherwise, the default file.encoding is used, which is very often
> "ISO8849-1" on z/OS
I'm guessing you meant ISO8859-1. It's not that way at our shop,
The DLm8000s use VMAX for the back end storage, so the replication is SRDF. I
believe
the maximum distance for SRDF/S is 200km.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:m...@mzelden.com
ITIL v3 Foundation Certified
IEFBR14 merely allocates space. It does not open the dataset in any way. What
you are seeing is residual data.
SMS *WILL* write an EOF marker when the dataset is allocated, however, you have
indicated that SMS is being bypassed
Unless you erase (RACF option) data on scratch (or the hardware equi
Good point, Ed. Regarding my previous test and posting, I have my VSM rule set
to "NO". So that could make a good reason
for the results I saw.
On Thu, 19 Sep 2013 06:40:11 -0700, Ed Jaffe
wrote:
>On 9/19/2013 5:17 AM, DASDBILL2 wrote:
>> It sounds as if one of the allocation routines is get
Elardus,
I agree , there is a Zoom pull down for increasing font which I just found
..which helps with the every so tiny fonts...
Regards,
Scott J Ford
Software Engineer
http://www.identityforge.com/
From: Elardus Engelbrecht
To: IBM-MAIN@LISTSERV.UA.
Do you have an ALLOCxx active on your system? I tried your test and have no
issues with the dataset and ISPF. I shows the
information as reported previously, and B gives "No members" message. I have
an ALLOCxx active on my system(s) which specifies
several defaults for dataset allocation. The
On 9/19/2013 5:17 AM, DASDBILL2 wrote:
It sounds as if one of the allocation routines is getting some temporary
storage but not zeroing all of it out, and the storage it happens to get
contains residual data from whoever used some of that storage previously.
That's exactly what I was going to
W dniu 2013-09-19 10:33, nitz-...@gmx.net pisze:
// EXEC PGM=IEFBR14
//DD1 DD DISP=(,CATLG),DSN=TEST,
// SPACE=(TRK,(1,0,0)),RECFM=F,LRECL=20,DSORG=PO
My output:
Organization . . . : PO
Record format . . . : F
Record length . . . : 20
Block size . . . . : 20
1st extent tracks . : 1000
Pommier, Rex wrote:
>It isn't that this is the first time I encountered this "feature" of IE, it's
>just that in prior positions I could install and use Firefox so I would just
>not bother trying to figure out the IE font problem.
Glad you could decipher my fonts in my post! ;-D
I often found
Rex,
I wish ..very funny ...my normal system is a Amd box with 12m and windows 7
pro...
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Sep 19, 2013, at 9:12 AM, "Pommier, Rex" wrote:
> Scott,
>
> You're running Windows 7 pro and IE10 on your IPAD?
Willie,
COBOL 4.2 is supported with z/OS V2.1. This is how I found it out (and you can
use this process in general, to see any product that is supported with z/OS
V2.1):
1) Look in Appendix B of the z/OS V2.1 Planning for Installation book,
specifically Table 11. This book has been available
On Thu, 19 Sep 2013 15:01:58 +0200, nitz-...@gmx.net wrote:
>> IIRC the (pseudo) eof is only written for SMS managed PS datasets, so a PO
>> dataset could well be allocated over old data which will then be readable.
>> Can you force the problem PO dataset to anther place by making sure the
>> s
Scott,
You're running Windows 7 pro and IE10 on your IPAD? Why???
Sorry, couldn't resist...
Rex
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Scott Ford
Sent: Thursday, September 19, 2013 7:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
S
Elardus,
It isn't that this is the first time I encountered this "feature" of IE, it's
just that in prior positions I could install and use Firefox so I would just
not bother trying to figure out the IE font problem.
Rex
-Original Message-
From: IBM Mainframe Discussion List [mailto:IB
> IIRC the (pseudo) eof is only written for SMS managed PS datasets, so a PO
> dataset could well be allocated over old data which will then be readable.
> Can you force the problem PO dataset to anther place by making sure the space
> for the 66000 dataset is still in use when the problem PO da
IIRC the (pseudo) eof is only written for SMS managed PS datasets, so a PO
dataset could well be allocated over old data which will then be readable. Can
you force the problem PO dataset to anther place by making sure the space for
the 66000 dataset is still in use when the problem PO dataset is
Yeah, I am on IE 10 ..Windows 7 Pro...
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Sep 19, 2013, at 6:39 AM, Elardus Engelbrecht
wrote:
> Jantje wrote:
>
>>> http://www-03.ibm.com/systems/z/os/zos/bkserv/
>>> http://support.microsoft.com/kb/
It sounds as if one of the allocation routines is getting some temporary
storage but not zeroing all of it out, and the storage it happens to get
contains residual data from whoever used some of that storage previously.
Bill Fairchild
Franklin, TN
- Original Message -
From: "nitz-..
Ted MacNeil wrote:
You're an enthusiastic prosletisor of the panacea you believe in!
If Mr MacNeil is going to be pretentious he has an obligation to get
his pretentions right. The word 'prosletisor' is not one. Someone
who proselytises|proselytizes is a proselytiser|proselytizer.
Moreover, wh
I've been using the PDF's most of the time, but seems like the IC's are getting
more and more common now days. And yes, I use a 27" monitor too.
_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830
> In my case it certainly is NOT by ACS-routines! I can only think of reuse of
> space with a (part of) member index.
>
> And this must in a production environment imply a security leak ?!
Having spent quite a bit of time recently with the different ways a DCB is
populated, this is an invali
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of nitz-...@gmx.net
> Sent: Thursday, September 19, 2013 12:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Allocation test
>
> All,
>
> > Be aware of the trap that Elardus hinted
All,
> Be aware of the trap that Elardus hinted to: your allocation can be
> modified by ACS routines, possibly differently on different LPARs,
> caused by different variables passed to it.
Thanks for testing. On our system, I am the master of everything (SMS,
allocation), you name it. There isn
Jantje wrote:
>>http://www-03.ibm.com/systems/z/os/zos/bkserv/
>>http://support.microsoft.com/kb/956197
>I couldn't read it. The font is too small...
Very funny. Which website?
If you use CTRL and + you can enlarge the text. CTRL and - shrink them. CTRL
and zero restore to original s
On Wed, 18 Sep 2013 08:39:25 -0500, Kevin Minerley wrote:
>Also, as mentioned many months ago in IBM-MAIN, LookAt is being sunset. It
>is NOT available starting in zOS v2r1.
Hmmm - news to me. Not that I doubt the fact.
> LookAt was always provided as a free "courtesy" with no guarantee imp
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jantje.
> Sent: Thursday, September 19, 2013 12:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM Information centers font size.
>
> On Wed, 18 Sep 2013 23:39:55 -0500, Paul Gi
On Wed, 18 Sep 2013 23:39:55 -0500, Paul Gilmartin wrote:
>Has anyone mentioned the notice:
>
>http://www-03.ibm.com/systems/z/os/zos/bkserv/
>
>Note: If you are using Microsoft Internet Explorer® 8 or 9 to view our
>Information Centers and the font is too small, please see this arti
BUT!:
=
Browse on S000TBE.NITZ:
Menu Functions Confirm Utilities Help
S000TBE DSLISTS000TBE.NITZ Row 1 of 1
Command ===>
On 19/09/2013 3:10 AM, Kirk Wolf wrote:
Minor suggestion; should use:
System.out.println( new String(cpuid,
ZFile.DEFAULT_EBCDIC_CODE_PAGE) );
otherwise, the default file.encoding is used, which is very often
"ISO8849-1" on z/OS
Yuk! Is that a general ROT? If so would it be a good
Others moan about edit, so I continue with my test:
Created member 'PEST'
BROWSETEST.BNITZRow 1 of
1
Command ===> Scroll ===> CSR
Name Prompt Size Created C
Barbara,
Be aware of the trap that Elardus hinted to: your allocation can be
modified by ACS routines, possibly differently on different LPARs,
caused by different variables passed to it.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Be
Thanks, Thomas.
that confirms that there is a bug somewhere in allocation. The same job should
result in the same allocation on two different lpars, I'd say, and it should
not use a random number for directory information. At the very least I would
have expected that the directory information i
Bizarre... I get this:
Current Allocation
Allocated tracks . : 1
Allocated extents . : 1
Maximum dir. blocks : 1
Current Utilization
Used track
nitz-...@gmx.net wrote:
>Can someone please run this iefbr14 job and tell me what the space allocation
>is (number of directory blocks) on your system?
>// EXEC PGM=IEFBR14
>//DD1 DD DISP=(,CATLG),DSN=TEST,
>// SPACE=(TRK,(1,0,0)),RECFM=F,LRECL=20,DSORG=PO
Sniff! sniff! what a smelly job!
Hi Barbara,
at our site here (z/OS 1.13) both allocations has ended with 0, are displayed
as PO-datasets,
but in both cases ISPF shows an I/O Error after hitting command 'I'.
So I can not confim this behaviour ...
ciao Lutz
-
In my system the dir blocks are 0 in both cases.
I've tried different runs and the info command worked differently from time
in time.
In most cases it say "I/O Error" with "An I/O error occurred while reading
the PDS directory.".
Other times everything seems to be ok but of course any edit try r
S000TBE DSLIST Data Set Information
Command ===>
Data Set Name . . . . : S000TBE.NITZ
Can someone please run this iefbr14 job and tell me what the space allocation
is (number of directory blocks) on your system?
// EXEC PGM=IEFBR14
//DD1 DD DISP=(,CATLG),DSN=TEST,
// SPACE=(TRK,(1,0,0)),RECFM=F,LRECL=20,DSORG=PO
Note that I deli
80 matches
Mail list logo