>I recall seeing a notice that it was so; I can't look
>for it now, as I'm on the road and a little busy, but
>I've got it in my course that the behavior of COBOL
>OPEN was changed to be sensitive in this way. Maybe
>Tom Ross can chime in here with a note from one of
>his "What's New in COBOL" SHAR
Bill Klein wrote:
Such a SHARE requirement already exists:
SSLNGC03003 Compiler option to make BLOCK CONTAINS clause SMS
sensitive
which states in part:
"This requirement requests a compiler option that would allow the
default for
when the "BLOCK CONTAINS" clause is omitted to be set to
Such a SHARE requirement already exists:
SSLNGC03003 Compiler option to make BLOCK CONTAINS clause SMS
sensitive
which states in part:
"This requirement requests a compiler option that would allow the
default for
when the "BLOCK CONTAINS" clause is omitted to be set to the same
processing
In <[EMAIL PROTECTED]>, on 01/23/2007
at 08:56 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>I wonder why the omitted the central implementation detail,
They didn't.
>and why they did not include EXCP as a supported access technique.
Their idea of supported includes not breaking customer cod
In a recent note, Bruce Black said:
> Date: Wed, 24 Jan 2007 17:25:14 -0500
>
> Sorry, Gil, you are wrong. As long as DSORG=, RECFM= and LRECL= are
> specified, SDB does calculate a blocksize at allocation time. I just
> ran your test to prove it.
>
I'll readily stand corrected. Thank
There should be no conflict. SDB also doesn't operate until the DCB
is opened for output. It must, in fact, be deferred until after
the DCB OPEN exit has had an opportunity to supply RECFM and LRECL
(as well as DSORG). Easy enough to verify: allocate a data set with
BLKSIZE=0; verify
Paul Gilmartin wrote:
In a recent note, R.S. said:
Date: Wed, 24 Jan 2007 16:42:40 +0100
This is something I fight against. Sometimes the dataset is never
opened. For example it is kind of "exception report". In case of no
exceptions the dataset remains "untouched". It cannot be backed
True but you can always use a default data class to provide a dsorg, etc
if one is not provided.
Jack Kelly
LA Systems @ US Courts
x 202-502-2390
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [
In a recent note, R.S. said:
> Date: Wed, 24 Jan 2007 16:42:40 +0100
>
> This is something I fight against. Sometimes the dataset is never
> opened. For example it is kind of "exception report". In case of no
> exceptions the dataset remains "untouched". It cannot be backed up due
> to in
o: IBM-MAIN@BAMA.UA.EDU
Subject: Re: BLKSIZE=0
Date: Wed, 24 Jan 2007 16:42:40 +0100
Paul Gilmartin wrote:
> In a recent note, Ron Hawkins said:
>
>> Date: Wed, 24 Jan 2007 13:22:59 +0800
>>
>> This conflicts with BLKSIZE=0 being used for SD
Paul Gilmartin wrote:
In a recent note, Ron Hawkins said:
Date: Wed, 24 Jan 2007 13:22:59 +0800
This conflicts with BLKSIZE=0 being used for SDB. SDB does not work
unless
DSORG can be established. BLKSIZE=0 is a null - SDB requires DSORG and
no
BLKSIZE. Additional DCB depends on
In a recent note, Ron Hawkins said:
> Date: Wed, 24 Jan 2007 13:22:59 +0800
>
> This conflicts with BLKSIZE=0 being used for SDB. SDB does not work unless
> DSORG can be established. BLKSIZE=0 is a null - SDB requires DSORG and no
> BLKSIZE. Additional DCB depends on the
--- snip --
Bruce,
This conflicts with BLKSIZE=0 being used for SDB. SDB does not work unless
DSORG can be established. BLKSIZE=0 is a null - SDB requires DSORG and no
BLKSIZE. Additional DCB depends on the DSORG.
Most sites have a default DATACLAS that will allocate with DSORG=PS if
nothing
Bruce,
This conflicts with BLKSIZE=0 being used for SDB. SDB does not work unless
DSORG can be established. BLKSIZE=0 is a null - SDB requires DSORG and no
BLKSIZE. Additional DCB depends on the DSORG.
Most sites have a default DATACLAS that will allocate with DSORG=PS if
nothing else can be
On Tue, 23 Jan 2007 12:50:09 -0500, Bruce Black wrote:
>
> > publibz. And note that the mechanism is not described. It could
> > be by writing an EOF at the beginning; it could be that a flag is
> > set (in the DSCB?) to indicate that the data set is uninitialized.
> >
> It is done by writing an
Hmmm. I had understood that this works only if DSORG is known.
But the wording appears back to the oldest OS/390 doc I find on
publibz. And note that the mechanism is not described. It could
be by writing an EOF at the beginning; it could be that a flag is
set (in the DSCB?) to indicate that t
---<>
Prohibit reading beyond DS1LSTAR, and enforce management of DS1LSTAR so
it is never allowed to point past uninitialized space.
What about datasets that have no EOF mark and depend rather on
en
I just saw a post on another thread about saving old tapes, and that
reminded me that once in the early 1970s I was sent a scratch tape from a
SHARE
buddy who worked at a bank so that I could copy all my local HASP mods onto
the
tape and mail it back to him. After copying the data to the
In a recent note, Ed Gould said:
> Date: Tue, 23 Jan 2007 07:50:04 -0600
>
> I believe there has been an option in SMS (since the early 1990's
> anyway) to write an eof into empty datasets, just by specifying it in
> the IGDSMSxx member in parmlib. IIRC this refers to any dataset that
> h
On Jan 23, 2007, at 7:20 AM, Paul Gilmartin wrote:
OTOH, writing an EOF at the beginning of every newly allocated extent
_regardless_of_DSORG_ would add little performance burden, and make
behavior more predictable, but it wouldn't address the data security
issue. Isn't there an option to e
In a message dated 1/23/2007 7:20:52 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
>Prohibit reading beyond DS1LSTAR, and enforce management
of DS1LSTAR so it is never allowed to point past uninitialized space.
An unauthorized program can read beyond DS1LSTAR quite easily as long
In a recent note, "(IBM Mainframe Discussion List)" said:
> Date: Mon, 22 Jan 2007 10:52:29 EST
>
> In a message dated 1/22/2007 8:16:41 A.M. Central Standard Time,
> [EMAIL PROTECTED] writes:
> >think IBM's answer to the security issue is an erase feature.
> There is no other way to enf
(IBM Mainframe Discussion List) wrote:
In a message dated 1/22/2007 8:16:41 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
think IBM's answer to the security issue is an erase feature.
There is no other way to enforce the requirement that user A's data cannot
be read by us
Charles Mills wrote:
99% sure the answer is yes. I know it is possible to open a new dataset and
ATTEMPT to read the data already on the tracks. My tests have tended to
"fail" (so to speak) for the reason that I am not "trying" to read someone
else's data, and the tests tend to fail on bad block
;
>Is this a (relatively) new problem? As far as I know, OS/360 didn't
>allow BLKSIZE=0 so this should not happen. At some time later,
>the ability to specify BLKSIZE=0 was added, along with this problem.
Depends on what you mean. You could certainly code BLKSIZE=0 on your
pro
In a message dated 1/22/2007 8:16:41 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
>think IBM's answer to the security issue is an erase feature.
There is no other way to enforce the requirement that user A's data cannot
be read by user B after user A has released ownership of the
en herrmannsfeldt
Sent: Monday, January 22, 2007 12:13 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: BLKSIZE=0
Charles Mills wrote:
> 1. It IS on SMS DASD. This is not a theoretical problem -- it happens in
> real life. The problem is ***not*** with DS1LSTAR or EOF markers. The
> problem is tha
On Mon, 22 Jan 2007 00:12:34 -0800, glen herrmannsfeldt
<[EMAIL PROTECTED]> wrote:
>Also, is it still possible to open a new data set and read the
>existing data on the tracks? >
>-- glen
It was certainly the case under XA (2.2.3 IIRC), when I encountered the
same issue.
Steve O.
-
iagnoses the situation with a message that
> it takes a CCW expert to decode -- rather than diagnosing an easily
> diagnosable situation with a simple explanation.
Is this a (relatively) new problem? As far as I know, OS/360 didn't
allow BLKSIZE=0 so this should not happen. At some tim
In <[EMAIL PROTECTED]>,
on 06/03/2005
at 10:34 AM, "Farley, Peter x23353" <[EMAIL PROTECTED]> said:
>That is a bad example. A period is needed after each occurrence of a
>symbolic when an alpha character follows
You're right; sorry.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
I
57I THE SYMBOL OVRD2 WAS NOT USED
7 IEFC630I UNIDENTIFIED KEYWORD &OVRD1DSN
8 IEFC630I UNIDENTIFIED KEYWORD &OVRD2DSN
-Original Message-
From: Shmuel Metz (Seymour J.) [mailto:[EMAIL PROTECTED]
Sent: Frida
In <[EMAIL PROTECTED]>,
on 06/01/2005
at 09:21 AM, "DOMINGUEZ MARTIN, ANGEL LUIS"
<[EMAIL PROTECTED]> said:
> I remember, in the seventies, that a person told me that DCBD block
>was built taking and overlaping information, in this order, from
>
> 1) VTOC
> 2) JCL
>
In <[EMAIL PROTECTED]>, on 05/31/2005
at 11:37 PM, "Edward E. Jaffe" <[EMAIL PROTECTED]> said:
>I don't think SYSOUT is the best (or even a good) way to test these
>"rules". JES2/JES3 SSI allocation and OPEN routines may have been
>(but probably never were) 100% compatible with DFP (or whatev
In <[EMAIL PROTECTED]>, on 06/01/2005
at 02:31 PM, Charles Mills <[EMAIL PROTECTED]> said:
>then there was no "parameter" way for the user (caller) to "dummy
>out" MYDD. Stating it differently, there was no way to code a DD
>statement inside a proc that based on a user parameter could be
>eithe
Yet, SDB appears to have filled in BLKSIZE for a data set that was never
opened.
SDB determines the blocksize twice. At allocation time, even if the
dataset was never opened, it calculates the blocksize from the supplied
RECFM and LRECL. Then it sets a flag saying that it did so.
At OPEN
On Wed, 1 Jun 2005 14:31:42 -0700 Charles Mills <[EMAIL PROTECTED]> wrote:
:>I remember (I believe) when DSN=NULLFILE came along. The altering of DD
:>statements in a proc is the whole essence of DSN=NULLFILE. Before
:>NULLFILE came along, if you had a proc with the DD statement
:>//MYDD DD DSN=&
...
Yet, SDB appears to have filled in BLKSIZE for a data set that was never
opened.
...
If you allocated it under ISPF, it was opened.
ISPF ALLOC opens and closes all datasets.
Also, you don't need SMS to implement SDB.
We had SDB about a year before we wrote any ACS.
[EMAIL PROTECTED]
In a recent note, Chris Langford said:
> Date: Wed, 1 Jun 2005 16:35:52 -0500
>
> In <[log in to unmask]>, on 06/01/05
>at 12:50 PM, Leonard Woren <[log in to unmask]> said:
> [snip]
>
> >It should also be noted that DUMMY and DSN= are defined as mutually
> >exclusive. Therefore on
In <[EMAIL PROTECTED]>, on 06/01/05
at 12:50 PM, Leonard Woren <[EMAIL PROTECTED]> said:
[snip]
>It should also be noted that DUMMY and DSN= are defined as mutually
>exclusive. Therefore on a DD override, DSN= supercedes DUMMY and
>DUMMY supercedes DSN=. (This statement applies only to overr
rame Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Gilmartin
Sent: Tuesday, May 31, 2005 8:47 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DUMMY and BLKSIZE=0
In a recent note, john gilmore said:
> Date: Tue, 31 May 2005 15:16:36 +
>
> Once written within a proce
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Leonard Woren
Sent: Wednesday, June 01, 2005 12:51 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DUMMY and BLKSIZE=0
[snip]
> I seem to recall that ASMF's macro language *required* all
>
ou just (may) have to supply more info on the
override.
> On the other hand
>
> //SYSPRINT DD DSN=NULLFILE,BLKSIZE=0,LRECL=137,RECFM=VBA
>
> can be altered readily by simply supplying a different licit value of DSN=.
Not likely. DISP= is missing and the default of (NEW,DELETE) is
seldo
Paul Gilmartin wrote:
In a recent note, Greg Price said:
I expect "DFSMS: Using Data Sets" to talk about the OPEN-time SDB,
and "DFSMS: Implementing System Managed Storage" (SC26-7407-02) to
talk about the DADSM end of things including allocation-time SDB.
I suppose it might be nice if ea
YSPRINT DD DSN=NULLFILE,BLKSIZE=0,LRECL=137,RECFM=VBA
|
| can be altered readily by simply supplying a different licit value of
| DSN=. This
| difference was the basis for my statement that DSN=NULLFILE was superior to
| DUMMY when used inside procedures.
|
Did you try the following:
~ //MYP
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Greg Price
Sent: Wednesday, June 01, 2005 7:40 AM
>It's been a while, but IIRC I used to have ACS routines which set
>DSORG=PS for DASD data sets whenever a null DSORG was found at
>creation time. F
In a recent note, ibm-main said:
> Date: Wed, 1 Jun 2005 22:43:05 +1000
>
> > ...APARs extended the rules, but it appears that such changes were not
> > reflected back to the manuals.
>
> This is a general "beef" now.
> TNLs are consigned to history. Nowadays, changes (e.g. DOC) introduc
In a recent note, Greg Price said:
> Date: Wed, 1 Jun 2005 22:40:25 +1000
>
> >>Well, here's my theory:
> >
> > Does this have to be done by theory and/or experiment, or is it made
> > clear in the documentation?
>
> I believe theory/experiment/doco all agree on how "the system" behaves
From: "Paul Gilmartin"
> ...APARs extended the rules, but it appears that such changes were not
> reflected back to the manuals.
>
This is a general "beef" now.
TNLs are consigned to history. Nowadays, changes (e.g. DOC) introduced by
APAR/PTF are only reflected *forward* (from current/next) into
[EMAIL PROTECTED] wrote:
> In a recent note, Greg Price said:
>
>
>>Date: Wed, 1 Jun 2005 14:16:51 +1000
>>
>>Well, here's my theory:
>>
>
> Does this have to be done by theory and/or experiment, or is it made
> clear in the documentation?
I believe theory/experiment/doco all agree on
In a recent note, Edward E. Jaffe said:
> Date: Tue, 31 May 2005 23:37:51 -0700
>
> Paul Gilmartin wrote:
>
> >It's more complicated than that. I wrote a little assembler program.
> >I did not supply RECFM, LRECL, or BLKSIZE in the DCB macro. To simulate
> >an "old" DCB, I did:
> >
> >
> >
> > why is the date 6/1/2005
>
> Because there is no 5/32/2005?
>
But January was so long ago - does anyone still care
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Kevin Clark
>
> why is the date 6/1/2005
Because there is no 5/32/2005?
-jc-
--
For IBM-MAIN subscribe / signoff / archive access instruct
-Original Message-
From: john gilmore
On the other hand
//SYSPRINT DD DSN=NULLFILE,BLKSIZE=0,LRECL=137,RECFM=VBA
can be altered readily by simply supplying a different licit value of DSN=.
This
difference was the basis for my statement that DSN=NULLFILE was superior to
DUMMY when used
In <[EMAIL PROTECTED]>, on 05/31/2005
at 03:16 PM, john gilmore <[EMAIL PROTECTED]> said:
>It will he helpful to go back in time to the early years of OS/MFT
>for the System/360.
FSVO early. Also, "OS/MFT" should be OS/360, and the rules were the
same[1] whether or not you generated the MFT
others) to have all the information (is BLKSIZE parameter coded in program
macro DCB?)
I did more test about and SDB appears to be in effect, for SMS and
NO-SMS files, when the program does the OPEN macro and this OPEN is for
OUTPUT, provided the values in VTOC/JCL are BLKSIZE=0 and on
Paul Gilmartin wrote:
It's more complicated than that. I wrote a little assembler program.
I did not supply RECFM, LRECL, or BLKSIZE in the DCB macro. To simulate
an "old" DCB, I did:
XCDCBDSORG,DCBDSORG
In the JCL:
//SYSUT2 DD SYSOUT=(,),RECFM=VB,LRECL=125
I then did:
Sorry and thanks Paul
After OPEN, the BLKSIZE is O.K. For REAL datasets. SDB is O.K.
Angel luis domÃnguez
Bbva - spain
-Mensaje original-
De: Paul Gilmartin [mailto:[EMAIL PROTECTED]
> Date: Tue, 31 May 2005 10:53:25 +0200
>
> - After OPEN. The BLKSIZE obtained is the same as
in the SYSUT2 DD statement,
but copied from SYSUT1 if omitted from DD? I had imagined that it was
simply done in the DCB EXIT -- IF BLKSIZE==0 THEN Copy from SYSUT1.
> In summary, SDB gets two opportunities to run:
> 1) during allocation,
> 2) during OPEN,
> but only for TAPE or DASD when
or PO.
During OPEN the DSORG _must_ be known, so SDB gets another chance to
run if BLKSIZE=0 is still true (for PS and PO).
Re IEBGENER, it seems that IEBGENER will use any valid blocksize
in the data set labels before OPEN, including an SDB set during
data set allocation, for the SYSPRINT file.
...
why is the date 6/1/2005
...
Having not seen the headers, I cannot answer the question directly.
But, the Canadian BlackBerry Server (RIM) has a few bugs regarding time-stamps.
[EMAIL PROTECTED]
--
For IBM-MAIN subscri
why is the date 6/1/2005
-- Original message --
> ...
> I seem to recall that the
> DSORG must be PS and known to data management in time to apply SDB
> ...
>
> The DSORG can also be PO.
> I've used it for years, that way.
>
>
> [EMAIL PROTECTED]
>
> -
...
I seem to recall that the
DSORG must be PS and known to data management in time to apply SDB
...
The DSORG can also be PO.
I've used it for years, that way.
[EMAIL PROTECTED]
--
For IBM-MAIN subscribe / signoff / archive a
[EMAIL PROTECTED] wrote:
In a recent note, Bob Wright said:
Date: Tue, 31 May 2005 11:45:55 -0400
Try again with DSORG=PS added to the DCB attributes. I don't have a
book detailing SDB requirements nearby, but I seem to recall that the
DSORG must be PS and known to data management i
<[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> In a recent note, john gilmore said:
>
> And on this question, I have yet no empirical evidence that, for example,
> "DUMMY,DCB=..." behaves any differently from "DSN=NULLFILE,DCB=..."
> I'm inclined to believe that the writers of
In a recent note, Bob Wright said:
> Date: Tue, 31 May 2005 11:45:55 -0400
> >
> Try again with DSORG=PS added to the DCB attributes. I don't have a
> book detailing SDB requirements nearby, but I seem to recall that the
> DSORG must be PS and known to data management in time to apply SDB
In a recent note, john gilmore said:
> Date: Tue, 31 May 2005 15:16:36 +
>
> Once written within a procedure neither of the DD statements
>
> // DD DUMMY
>
> or
>
> // DD DUMMY, . . .
>
> can be altered into one that in fact is functional, permits non-null
> outputs to be written
[EMAIL PROTECTED] wrote:
In reaction to the recent DUMMY and ISPLOG BLKSIZE=0 thread, I did a test
with the following:
//GENEREXEC PGM=IEBGENER
//SYSPRINT DD DISP=(NEW,CATLG),
// DSN=&SYSUID..IEBGENER.SYSPRINT,
// DCB=(RECFM=FBA,LRECL=121,BLKSIZE=0),
//
be picked off in logical sequence no
matter where they appear in a macro instruction.
Once written within a procedure neither of the DD statements
// DD DUMMY
or
// DD DUMMY, . . .
can be altered into one that in fact is functional, permits non-null outputs
to be written or non-null
inputs to be
In reaction to the recent DUMMY and ISPLOG BLKSIZE=0 thread, I did a test
with the following:
//GENEREXEC PGM=IEBGENER
//SYSPRINT DD DISP=(NEW,CATLG),
// DSN=&SYSUID..IEBGENER.SYSPRINT,
// DCB=(RECFM=FBA,LRECL=121,BLKSIZE=0),
// UNIT=SYSDA,SPACE=(TRK,1)
(Note
In a recent note, DOMINGUEZ MARTIN, ANGEL LUIS said:
> Date: Tue, 31 May 2005 10:53:25 +0200
>
> - After OPEN. The BLKSIZE obtained is the same as specified in JCL for all
> (DUMMY, NULLFILE or REAL) or ZERO in case param where not present.
This result,
E=129
Wiht a "cosmetic" purpose, somebody (of sysprog team) changed BLKSIZE=129 to
BLKSIZE=0. We are in z/OS 1.4 and SMS active.
Any information about DUMMY and BLKSIZE=0
008D4E88 5200 46D0
>
> //ISPLOG DD DUMMY,RECFM=VB,LRECL=125,BLKSIZE=129
>
> Wiht a "cosmetic" purpose, somebody (of sysprog team) changed BLKSIZE=129 to
> BLKSIZE=0. We are in z/OS 1.4 and SMS active.
>
System Determined Blocksize apparently chooses a blocks
, we
had the following DD included in one of our's TSO LOGON PROCS
//ISPLOG DD DUMMY,RECFM=VB,LRECL=125,BLKSIZE=129
Wiht a "cosmetic" purpose, somebody (of sysprog team) changed BLKSIZE=129 to
BLKSIZE=0. We are in z/OS 1.4 and SMS active.
Any information about DUMMY and BLKSIZE=0
73 matches
Mail list logo
