Did you notice the z/OS 1.13 enhancement in SMS, where the creation time
is also stored in the new F9 DSCB? Currently only for datasets that
create a F9 DSCB.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent:
On 6/6/2013 11:39 PM, Vernooij, CP - SPLXM wrote:
Did you notice the z/OS 1.13 enhancement in SMS, where the creation time
is also stored in the new F9 DSCB? Currently only for datasets that
create a F9 DSCB.
DS9JOBNAME DS CL8 Job name used to create the
*
I think it would be better , to use ZFS instead of HFS.
On 06.06.2013 23:57, baby eklavya wrote:
Greetings ,
Thanks everyone for your inputs .
I converted those volumes to SMS managed and added them to a new storage
group . Modified the STGROUP ACS routines by adding DSNTYPE = HFS . coding
When we perform a region switch we reverse XRC replication before bringing up
the production systems.
Essentially as follows (some sequences shortened/omitted!)
Shut down Region A production systems
Shut down SDM in Region B
Start SDM system in Region A looking at Region B dasd
Load production
On Thu, 6 Jun 2013 23:48:46 -0700, Ed Jaffe wrote:
... the creation time is also stored in the new F9 DSCB
...
DS9TIME DS XL6 Number of microseconds since
* midnight, local time, that the data
* set
G'Day,
I would like to migrate 23 volumes (to ML2) because of space issues. However I
noticed that there are several USER.catalogs on these disks. Would HSM migrate
the USERCATS as well (which I don't want). Here is the command I plan to use
to migrate the volumes:
Are these SMS managed volumes? If so, datasets will migrate according to their
MGMTCLAS attributes. Catalogs should not be eligible for migration.
If non-SMS, and not allocated to the CATALOG address space (which is also true
for SMS-managed), then they probably would migrate.
Most catalogs
Robert,
Sorry, I should have mentioned that the volumes are SMS managed. Thanks.
From: Richards, Robert B. robert.richa...@opm.gov
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, 7 June 2013 6:48 AM
Subject: Re: DFHSM QUESTION - MIGRATE VOLUMES
Are these SMS
We are looking at it. We pulled together a month of SMF data for them to
analyze to assess is we're a good candidate or not. Now awaiting those
results. In our initial meetings SAG believed we may indeed be a good
candidate due to our heavy batch environment.
On 6/6/2013 7:30 PM, Longnecker,
I am not sure I understand Paul Gilmartin's last post.
XL6 specifies a target, assembled length of six bytes. There are 6 x
8 = 48 bits available in these 6 bytes.
A 24-hour day contains 60 x 60 x 24 x 1,000,000 = 29,664,400,000,000 µsec
2^48 - 1 = 281,474,976,710,655
These six bytes are
John Gilmore wrote:
These six bytes are thus entirely adequate to contain any unsigned elapsed- µ
- sec value in a 24-hour day.
Agreed. Only if all users of that 6 bytes are still using it as *un-signed*
value.
There must be a reason, why such precision is needed? Any one willing to share
I agree. One argument that I have gotten in the past was but I can easily
allocate an HFS filesystem using simple JCL. To allocate a ZFS, I need to
run an IDCAMS, then the initialization program. What a bother!. Well,
assuming that your ZFS data sets are SMS managed, you can easily allocate
and
I'd say first: there must be a reason to store the creation time. What was the
reason?
So if IBM decided to store the creation time rounded only to minutes or
seconds, people would complain that it should be more accurate. If so, it is a
wise decision to store it accurate enough for now and
Is this an additional charge feature or just a startup option?
Bob Shannon
Rocket Software
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I believe there is an additional charge.
On 6/7/2013 8:23 AM, Bob Shannon wrote:
Is this an additional charge feature or just a startup option?
Bob Shannon
Rocket Software
--
For IBM-MAIN subscribe / signoff / archive access
IMO, if IBM were to store the creation date time, then the only logical
value to store is the STCKE value taken somewhere within the allocation
process. It is 16 bytes in length and cannot be made any more accurate
because the hardware doesn't support a greater accuracy. It is not human
readable,
Thank you! But that main(Stringݨ What are those characters?
On Thu, Jun 6, 2013 at 11:02 PM, Donald J. dona...@4email.net wrote:
Here is a java program EmptyFrame1.java you can easily compile:
// file: EmptyFrame1.java
import java.awt.event.*;
import javax.swing.*;
class
Pedantry follows:
John McKown wrote of an STCKE value it is 16 bytes in length . . . ,
and this is literally true, but the rightmost two-byte
programmable-field value is not part of the TOD value.
The leftmost 14-byte/112-bit substring is the TOD value.
John Gilmore, Ashland, MA 01721 - USA
Open and close square bracket, I expect.
Cheers, Martin
Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM
+44-7802-245-584
email: martin_pac...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Blog:
On Fri, 7 Jun 2013 07:29:09 -0500, John McKown wrote:
IMO, if IBM were to store the creation date time, then the only logical
value to store is the STCKE value taken somewhere within the allocation
process. It is 16 bytes in length and cannot be made any more accurate
because the hardware
That was the problem.
Some other issues with deprecated APIs. Maybe if I look at the sample C
code I can figure out what to change in the java code.
On Fri, Jun 7, 2013 at 9:00 AM, Martin Packer martin_pac...@uk.ibm.comwrote:
Open and close square bracket, I expect.
Cheers, Martin
Martin
Thank you for the update.
Norma Mowry
DECC-Mechanicsburg
Operating Systems Support (ESB11)
(717)-605-7865 DSN:430
e-mail address: norma.e.mowry@mail.mil
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John Gilmore
Sent:
You will also have to compile the xauth c program.
I don't think IBM supplies a binary for it.
--
Donald J.
dona...@4email.net
On Fri, Jun 7, 2013, at 06:07 AM, Mark Pace wrote:
That was the problem.
Some other issues with deprecated APIs. Maybe if I look at the sample C
code I can
The sequence of both STCK and STCKE values is a unique, monotone
ascending ones, so that even two successive STCK[E] instructions
executed on the same CP yield such values. The programmable field
serves a different purpose. It identifies which TOD clock in a
multiclock SYSPLEX provided a
Commands like this will be needed when compiling xauth:
export
_C89_PSYSLIB=SYS1.IBM.CEE.SCEEOBJ:SYS1.IBM.CEE.SCEECPP:SYS1.IBM.CBC.SCLBDLL
export
_C89_LSYSLIB=SYS1.IBM.CEE.SCEELKEX:SYS1.IBM.CEE.SCEELKED:SYS1.IBM.CBC.SCCNOBJ:SYS1.CSSLIB
_C89_CCMODE=1 make /home/sys/luhe338/xauth/output.log
--
You could setup the Catalogs to have a NOMIG setting in the management
class. But if the catalog is open to the catalog address space, I don't
think they will migrate.
Issue a F CATALOG,REPORT (I think) command. It should show the list of
catalogs and status
Lizette
-Original
I'd personally go for a larger CI size, like 12K (12288) or 26K (26624).
Storage (both DASD virtual) is no longer a problem. I think for 26K CI size
VSAM will actually store CIs in 2K physical blocks, for 12K CI size - VSAM will
store a CI in 4K physical blocks (best 3390 geometry DASD track
In
9110584664893861.wa.elardus.engelbrechtsita.co...@listserv.ua.edu,
on 06/06/2013
at 09:44 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za
said:
Shmuel did not said *what* libraries, but I believe he means LE (and
macros) libraries.
Compiler and LE transient (dynamic) libraries. I
Now this is something I never expected to see.
# export
export: Command not found.
# find / -name export
#
/bin/export is gone?!?!
On Fri, Jun 7, 2013 at 9:22 AM, Donald J. dona...@4email.net wrote:
Commands like this will be needed when compiling xauth:
export
DOH! I'm no UNIX expert. I had changed my shell to TCSH because I liked
using tab key for autocomplete and arrow up to go back through command
history. Surprise! That was the problem. I put my shell back SH and
export works again. ARGH!
On Fri, Jun 7, 2013 at 9:42 AM, Farley, Peter x23353
On Thu, 6 Jun 2013 23:48:46 -0700, Ed Jaffe wrote:
DS9TIME DS XL6 Number of microseconds since
* midnight, local time, ...
Did I fail to read this correctly previously? Now that I look more
carefully, it seems to be saying that the field
Nicely avoiding DST problems and leaving them to the customer.
The leapsecond is added after 23:59:59, so before midnight. No confusion there.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Friday, June
Going back to the /bin/sh shell I was able to
export DISPLAY=172.16.0.6:0.0
/usr/lpp/java/J6.0/bin/java EmptyFrame1
And I got a blank window to pop-up on my Xwindows server.
Thanks very much!!!
On Fri, Jun 7, 2013 at 9:47 AM, Mark Pace pacemainl...@gmail.com wrote:
DOH! I'm no UNIX
The TCSH equivalent to the export builtin is setenv.
On Fri, Jun 7, 2013 at 8:47 AM, Mark Pace pacemainl...@gmail.com wrote:
DOH! I'm no UNIX expert. I had changed my shell to TCSH because I liked
using tab key for autocomplete and arrow up to go back through command
history. Surprise!
On Fri, 7 Jun 2013 09:47:38 -0400, Mark Pace wrote:
DOH! I'm no UNIX expert. I had changed my shell to TCSH because I liked
using tab key for autocomplete and arrow up to go back through command
history. Surprise! That was the problem. I put my shell back SH and
export works again. ARGH!
I
On 2013-06-07, at 08:09, Vernooij, CP - SPLXM wrote:
Nicely avoiding DST problems and leaving them to the customer.
Indeed.
The leapsecond is added after 23:59:59, so before midnight. No confusion
there.
Is it well specified whether the leap second is added after
23:59:59 UTC or after
Don,
While I work for IBM, I am not in the z/OS development team, but here is my
personal take. Having 2 API's, one internal, one external has a large
number of negative consequences, including increasing maintenance effort,
because if there is a defect, both API's have to be investigated, and
Thank you. And I found the format is slightly different.
export DISPLAY=172.16.0.6:0.0
setenv DISPLAY 172.16.0.6:0.0
On Fri, Jun 7, 2013 at 10:12 AM, John McKown
john.archie.mck...@gmail.comwrote:
The TCSH equivalent to the export builtin is setenv.
On Fri, Jun 7, 2013 at 8:47 AM, Mark
On 6/7/2013 5:23 AM, Bob Shannon wrote:
Is this an additional charge feature or just a startup option?
It appears to be an additional charge, which is interesting. AFAIK,
every other vendor from IBM, to CA, to (Phoenix--that's us!), to
you-name-it has offered zIIP enablement free as a way to
https://en.wikipedia.org/wiki/Leap_second
Time of day adjustments occur on the last second of any day of any
month, but so far have only occurred on Dec 31 or Jun 30.
You could skip 23:59:59 or add 23:59:60 UTC, simultaneously around the world.
On Fri, Jun 7, 2013 at 9:32 AM, Paul Gilmartin
My cynicism and knowing Sag's attitude towards subcapacity licensing leads me
to expect that they charge close to what they would charge for a full CP.
Natural is a good language, but Sag's growth model is in other areas of their
product line. Adabas/Natural shops are a captive revenue
On 6/7/2013 at 10:10 AM, Mark Pace pacemainl...@gmail.com wrote:
Going back to the /bin/sh shell I was able to
export DISPLAY=172.16.0.6:0.0
/usr/lpp/java/J6.0/bin/java EmptyFrame1
And I got a blank window to pop-up on my Xwindows server.
Is that the IP address of your MVS system, or
Hello,
Am looking for the specs of a dataset into which the output from a
COBOL/CICS/SQL //DBRMLIB should go. Have searched docs, can't pin the right
one, a pointer would be useful please. I put it in a source file PDS but a
browse suggests it should be in a loadlib PDS. Would I be right?
Leap seconds increment a seconds counter (or a surrogate for one).
The appropriate conversion routine then produces a Gregorian date or
the like from this value.
Never, never try to increment or decrement a calendar date
programmatically: that way madness lies. Conceptial confusion lies
there
On 6/7/2013 5:29 AM, John McKown wrote:
IMO, if IBM were to store the creation date time, then the only logical
value to store is the STCKE value taken somewhere within the allocation
process. It is 16 bytes in length and cannot be made any more accurate
because the hardware doesn't support a
:: -Original Message-
:: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:: Behalf Of John Gilmore
:: Sent: Friday, June 07, 2013 4:52 AM
:: To: IBM-MAIN@LISTSERV.UA.EDU
:: Subject: Re: Age of datasets in hours, not days?
::
:: I am not sure I understand Paul
On 6/7/2013 9:25 AM, retired mainframer wrote:
:: A 24-hour day contains 60 x 60 x 24 x 1,000,000 = 29,664,400,000,000
:: µsec
Your calculator broken or are using a base other than 10?
Should be 86,400,000,000 µsec.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive
Of course, for 100% coverage of all possible usage scenarios, time stamps
should contain both UTC and local time
One timestamp and the GMT offset takes less space and is IMO all that is needed.
Barry Merrill
Herbert W. “Barry” Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
I am or was then, I hope temporarily, the thing broken.
The correct value is: 86,400,000,000 µsec
Fortunately/serendipitously my argument is unimpaired.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff
In this case the export DISPLAY IP is my desktop running the X server. It
appears to me that xauth is not compiled. So I get a message about xauth,
but I do get the X window, so it is working.
On Fri, Jun 7, 2013 at 12:02 PM, Mark Post mp...@suse.com wrote:
On 6/7/2013 at 10:10 AM, Mark
Does this page dealing with pre-processor files provide the info you're looking
for?
http://pic.dhe.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2z10.doc.apsg/src/tpc/db2z_precompiler_data_sets.htm
-Original Message-
From: Graham Hobbs [mailto:gho...@cdpwise.net]
Sent: Friday,
On Fri, 7 Jun 2013 12:12:01 -0400, John Gilmore wrote:
Never, never try to increment or decrement a calendar date
programmatically: that way madness lies. Conceptial confusion lies
there too: there is no xx.xx.60 UTC
From:
On 6/7/2013 at 01:04 PM, Mark Pace pacemainl...@gmail.com wrote:
In this case the export DISPLAY IP is my desktop running the X server. It
appears to me that xauth is not compiled. So I get a message about xauth,
but I do get the X window, so it is working.
Well, what is working is _not_
Splain why a database is needed if the GMT offset value is the correct delta,
that
is, of course, reset when times are changed between GMT and offset value.
Or explain why the second datetime stamp, which would have the same delta as the
offset in effect, adds anything?
Barry
-Original
I appreciate the heads-up, Mark. But this traffic is going through a VPN,
so I'm not concerned about it. I will make note of this if I ever have to
do this in the clear.
On Fri, Jun 7, 2013 at 1:31 PM, Mark Post mp...@suse.com wrote:
On 6/7/2013 at 01:04 PM, Mark Pace pacemainl...@gmail.com
In 51b2083c.3060...@phoenixsoftware.com, on 06/07/2013
at 09:20 AM, Ed Jaffe edja...@phoenixsoftware.com said:
Of course, for 100% coverage of all possible usage scenarios, time
stamps should contain both UTC and local time.
I'd prefer UTC and local offset.
--
Shmuel (Seymour J.)
Sure appreciate everyone's input...thanks!
I probably should have added a little more info upfront. Currently, we have
primary, secondary, and tertiary volumes. We run off the tertiary volumes
after flashing from the secondary' and clipping off the primary's. This works
great for running a
It does! Thanks very much.
Graham
--
On 07/06/2013 1:08 PM, Sambataro, Anthony (NIH/NBS) [E] wrote:
Does this page dealing with pre-processor files provide the info you're looking
for?
W dniu 2013-06-07 19:07, Norman.Hollander pisze:
CA used to offer % of zIIP pricing. Example, if you used the base IDMS, it
offloaded up to
40% to zIIP for no additional dollars. If you want 75%, there was a OTC
offered for the feature.
If you wanted 100%, you needed a big-ticket Enterprise
On 6/7/2013 9:34 AM, Barry Merrill wrote:
One timestamp and the GMT offset takes less space and is IMO all that is needed.
That would suffice.
Of course, one must remember to save the offset, then issue STCK[E], and
then compare the saved offset against the current offset. If any change
As Robert Anson Heinlein once wrote in The Moon Is a Harsh Mistress
TANSTAAFL - There Ain't No Such Thing As A Free Lunch. Especially in
marketing. What the buyer hopes is that the software cost reduction from
other products is greater than the cost increase to the other.
On Fri, Jun 7, 2013 at
It may be that Dr Merrill and I have different objectives.
My interest is only incidentally in this instant's STCKE value. It is
in the use of such values as date-time values in both the post-1900
past and the not too remote future.
John Gilmore, Ashland, MA 01721 - USA
On 6/7/2013 11:34 AM, R.S. wrote:
But in case when the third party software is offloaded by its
manufacturer it's OK.
In that case, it is not a third party.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
Steve,
Thank you for that elucidation of 'Splain'. I am old enough, but I
just did not watch ILL.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
On Fri, 7 Jun 2013 13:53:38 -0400, Mark Pace wrote:
I appreciate the heads-up, Mark. But this traffic is going through a VPN,
so I'm not concerned about it. I will make note of this if I ever have to
do this in the clear.
Your initial stated objective was to get X11 forwarding working and
On Fri, 7 Jun 2013 14:58:01 -0400, John Gilmore wrote:
Precession very gradually brings UTC (and other lunisolar calendars
too) out of alignment with the seasons on earth. Leap seconds correct
for this precession, keeping UTC seasonally aligned, or nearly so.
That's the purpose of leap years.
Please forgive my ignorance: I'm a developer, not a hardware configuration
guy.
On a client machine I've got a whole lot of datasets (1 - 500 tracks). Each
VOLSER shows up in ISPF 3.4 with a + sign after it. If I drill down I
eventually get to
All allocated volumes:
The rotation is not constant, and is too slow. It takes (a very little) more
than 24 hours for the earth to make one rotation.
What have I started!?! All I wanted to know was whether LISTCAT or the like
supported dataset age granularity finer than one day!
Charles
-Original Message-
Number of volumes allocated: 3
CCXZ08 * *
What is ISPF trying to tell me? Every single dataset is like this -- even
small ones (1 track).
This means you can allocate up to three volumes, but only one is in use, now.
It's more than an academic question
On Fri, 7 Jun 2013 15:28:21 -0700, Charles Mills wrote:
The rotation is not constant, and is too slow. It takes (a very little) more
than 24 hours for the earth to make one rotation.
What have I started!?! All I wanted to know was whether LISTCAT or the like
supported dataset age granularity
So what you are seeing are Candidate Volumes. So probably your DataClass
has the setup to have at least 3 volumes. I would need to look this up, but
my guess is either a VOLCOUNT or DYNACOUNT type parm in the ISMF panels.
Lizette
-Original Message-
From: IBM Mainframe Discussion List
Well, everything is software these days. Cylinders exist only in software
any more.
So if a dataset is *eligible* to span more than one volume, you can't
release unused space? Even though the dataset has never occupied more than
one volume?
What if it is allocated with // DD SPACE(,,RLSE) and
Microseconds? Milliseconds? Who cares? They're both too small to be much
concerned with.
I'd settle for AM/PM at this point. It would be an improvement in granularity
on local calendar days.
Charles
-Original Message-
From: IBM Mainframe Discussion List
If the volume shows a star (*) then it is a place holder only. Takes up no
room or space. Just lets you know that if you need to go beyond one volume
you can.
Check out candidate volume in the SMS manuals.
There is no SPACE to release when there is a * for the volser
So rather than specifying
Julian-calendar leap years are defined very simply as those that have
serial numbers divisible by 4, those in the doubly infinite sequence
. . . -12, -8, -4, 0, +4, +8, +12 . . .
A four-year Julian-calendar cycle thus contains a mean of
(3 x 365 + 1 x 366)/4 = 365.25 days.
This is
No, I'm not trying to release space that isn't there! LOL
These datasets definitely occupy space. A typical dataset is 150 tracks of
which 5 are in use. The volume list shows as CCXZ08 * * so presumably all of
the 150 tracks are on CCZZ08 and that is where I want to release space (not
on * and
Leap seconds deal with accumulating precession that is not dealt with
effectively by the definition of the Gregorian calendar.
I don't *think* so. I think they deal with the rotation of the earth on its
axis taking more than 24 hours, as opposed to a rotation around the sun
taking more than 365
Here I was dealing with the precession of the vernal equinox. The
position of the sun at the time of the vernal equinox is slowly
shifting westward in the sky. This is a standard, not at all arcane
usage.
I don't think Charles Mills knows much about what he is talking
about in this case, but I
They are allocated in tracks. (I am familiar with how ISPF 3.4 reports space
in tracks even though the dataset may be allocated in cylinders. So a
dataset reported as 150 tracks, with 5 occupied, might be expected to come
down to 15 tracks, not 5.) They are utterly vanilla PS FBS 27920. The ISPF F
Then from that message I would suggest that the candidate volumes prevent
the freeing of space. So how is your DataClass set up for this file?
For a multivolume data set that is not in extended format, or is in extended
format with a stripe count of 1, CLOSE releases space only on the current
Lizette, thanks. You (a.) have given me some things to look at and (b.) are
pushing the boundaries of my knowledge. (I design software; I try to avoid
writing JCL LOL and I sure don't do much SMS.)
No, not extended format (unless SMS is doing something I don't anticipate).
As I said, utterly
FWIW typical JCL and allocation messages:
//SYSPRINT DD BLKSIZE=0,DISP=(NEW,CATLG),
// DSN=qualifiers.SYSPRINT,DSORG=PS,LRECL=133,
// RECFM=FBA,SPACE=(TRK,(150,120,0))
(I said FBS. So shoot me. If it looks a little odd it's because it is
generated JCL, not
At 08:03 -0500 on 06/07/2013, Paul Gilmartin wrote about Re: Age of
datasets in hours, not days?:
On Fri, 7 Jun 2013 07:29:09 -0500, John McKown wrote:
IMO, if IBM were to store the creation date time, then the only logical
value to store is the STCKE value taken somewhere within the
At 14:58 -0400 on 06/07/2013, John Gilmore wrote about Re: Age of
datasets in hours, not days?:
The arithmetic of multiple moduli and several simultaneous cycles
used to convert counter values into calendar dates always numbers
seconds in the sequence
0, 1, 2, . . . , 59
It knows nothing
At 07:09 -0500 on 06/07/2013, Elardus Engelbrecht wrote about Re: Age
of datasets in hours, not days?:
John Gilmore wrote:
These six bytes are thus entirely adequate to contain any unsigned
elapsed- µ - sec value in a 24-hour day.
Agreed. Only if all users of that 6 bytes are still using
At 08:32 -0600 on 06/07/2013, Paul Gilmartin wrote about Re: Age of
datasets in hours, not days?:
Is it well specified whether the leap second is added after
23:59:59 UTC or after 23:59:59 local time if the two happen to
differ?
It is added just after 23:59:59 UTC (making the next second
At 09:20 -0700 on 06/07/2013, Ed Jaffe wrote about Re: Age of
datasets in hours, not days?:
As a software developer, I have had multiple occasions to process
event times stored as all or part of a TOD value. For obvious
reasons, end users prefer everything displayed to them in local
time.
How is your DCSEQ setup in the Data Class?
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, June 07, 2013 6:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Multiple volume dataset question
FWIW
If you can update the JCL, try adding VOL=(,,,1)
- that's 3 commas. With luck that will be allowed by your SMS rules, and you'll
get a single volume dataset.
Shane ...
On Fri, 7 Jun 2013 18:04:46 -0700, Charles Mills wrote:
FWIW typical JCL and allocation messages:
//SYSPRINT DD
Charles,
You should know by now that what you ask for is not always what you get!
Eric Bielefeld
z/OS Systems Programmer
Milwaukee, Wisconsin
414-475-7434
- Original Message -
From: Charles Mills charl...@mcn.org
Subject: Re: Age of datasets in hours, not days?
The rotation is not
Note: Volume Count adds * volsers to volume list, but dynamic volume count
does not.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Lizette Koehler
Sent: Friday, June 07, 2013 7:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re:
Your point is well taken. However, I figured that the customer ENF API and
the IBM internal ENF API would likely be quite different due to having
different goals. The internal API could have features that IBM might not be
willing to extend to the customer or even other vendors.
-Original
:: -Original Message-
:: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:: Behalf Of Charles Mills
:: Sent: Friday, June 07, 2013 3:28 PM
:: To: IBM-MAIN@LISTSERV.UA.EDU
:: Subject: Re: Age of datasets in hours, not days?
::
:: The rotation is not constant, and is
93 matches
Mail list logo
