Did you get a Reason Code?
In a message dated 07/26/13 00:46:05 Central Daylight Time, d10j...@us.ibm.com
writes:
specification is still there, exists, I apparently lost that battle
--
For IBM-MAIN subscribe / signoff /
...@us.ibm.com
To: IBM-MAIN@listserv.ua.edu
Date: 07/26/2013 09:15 AM
Subject: Re: BLKSIZE=3120
Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
A customer (mildly) complained thatsome of our product allocations still
use
BLKSIZE=3120. I vaguely remember trying to change all
California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: Jim Mulder d10j...@us.ibm.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 07/25/2013 10:46 PM
Subject:Re: BLKSIZE=3120
Sent
On Fri, 26 Jul 2013 01:45:34 -0400, Jim Mulder wrote:
A customer (mildly) complained ...
Clearly, it wasn't I.
... TRANSMIT/RECEIVE would cease to override that on the DCB and thus
no longer change the BLKSIZE to 3120. Since the stupid DCB
specification is still there, exists, I apparently
charl...@mcn.org
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, July 22, 2013 12:28:26 PM
Subject: Re: BLKSIZE=3120
I took the giant leap several years ago and stopped using 3120 for TSO XMIT.
I hard-code 27920. Not as wonderful as 0, but better than 3120. Several
years now with no issues.
Charles
On Mon, 22 Jul 2013 15:32:37 -0400, Jim Mulder wrote:
If there are any restrictions, they should be APAR'ed. 3120, 6160,
6144, etc. is SO 20th century. It's amazing to me how many IBM and OEM
products still ship these crappy blocksizes. It's why I submitted a
SHARE requirement to have
Jul 2013 22:42:06
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=3120
Looks similar to the HUGE problem (g) with having old catalogs still defined
with IMBED and REPLICATE. Another hanger-on from days of yore that no one
A customer (mildly) complained thatsome of our product allocations still
use
BLKSIZE=3120. I vaguely remember trying to change all of them to
BLKSIZE=0 many years ago (probably before OS/390) and running into some
issues with certain IBM utilities. Unfortunately, I can't remember the
retired mainframer wrote:
snip
With a blocksize of 3120, 15 blocks fit on a track for a total of 585
records. Almost a 50% improvement. My preference is 6160 (reasonably
efficient for both 3390 and 3380 - yes we have very old archived datasets
which occasionally must be restored) which will
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: Ed Gould edgould1...@comcast.net
To: IBM-MAIN@listserv.ua.edu,
Date: 07/23/2013 05:39 AM
Subject:Re: BLKSIZE=3120
Sent by:IBM Mainframe Discussion List IBM
:: -Original Message-
:: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:: Behalf Of Tom Marchant
:: Sent: Monday, July 22, 2013 1:36 PM
:: To: IBM-MAIN@LISTSERV.UA.EDU
:: Subject: Re: BLKSIZE=3120
snip
::
:: AFAIK, Innovation (FDR, etc.) still ships
On Mon, 22 Jul 2013 13:36:01 -0400, Thomas Conley pinnc...@rochester.rr.com
wrote:
Isn't it ironic that a
utility designed to save DASD space uses a 6144 blocksize and actually
wastes DASD?
Taking the risk of starting another flame war here...
Are there still any shops that have actual SLED?
W dniu 2013-07-23 12:32, Jantje. pisze:
Taking the risk of starting another flame war here...
Are there still any shops that have actual SLED? In today's world of emulated
DASD, would it really still hold true that using smaller block sizes is
actually wasting space? After all, these bytes
On Mon, 22 Jul 2013 21:25:23 -0400, Robert A. Rosenberg wrote:
At 16:51 -0500 on 07/22/2013, Tom Marchant wrote about Re: BLKSIZE=3120:
Most PTFs should be able to be applied, restored and applied again
without issues.
This is an issue since the design of RESTORE is broken due to its
poor
on this subject.
Eric Bielefeld
Retired z/OS Systems Programmer
Milwaukee, Wisconsin
414-475-7434
- Original Message -
From: Jantje. jan.moeyers...@gfi.be
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, July 23, 2013 5:32 AM
Subject: Re: BLKSIZE=3120
Taking
It is certainly true that BLKSIZE= values now have less importance
than they had on spnning physical CKD DASD, but that is not very
important. It is almost irrelevant.
I/O performance is very much better for large BLKSIZE= values. This
is now indeed the principal rationale for using them.
-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=3120
I believe that the net result of coding smaller blocksizes does result in
being able to store less data. If you had 1,000 volumes all defined as
3390-9s, and each volume had 100 datasets that filled the volume blocked at
512 bytes, you would store
Retired z/OS Systems Programmer
Milwaukee, Wisconsin
414-475-7434
- Original Message - From: Jantje. jan.moeyers...@gfi.be
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, July 23, 2013 5:32 AM
Subject: Re: BLKSIZE=3120
Taking the risk of starting
-
:: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:: Behalf Of Eric Bielefeld
:: Sent: Tuesday, July 23, 2013 10:21 AM
:: To: IBM-MAIN@LISTSERV.UA.EDU
:: Subject: Re: BLKSIZE=3120
::
:: I believe that the net result of coding smaller blocksizes does result
:: in
:: being
Riddle me this. Which one transfers fastest? RU size maxbufrs, transmission
speed,compression, Consistent, repeatable, less than 4k?
In a message dated 7/23/2013 4:34:00 P.M. Central Daylight Time,
retired-mainfra...@q.com writes:
Almost a 50% improvement. My preference is 6160
Where's Shai Hess when we need him?
Sent from Tony's iPhone.
On Jul 23, 2013, at 1:10 PM, John Gilmore jwgli...@gmail.com wrote:
It is certainly true that BLKSIZE= values now have less importance
than they had on spnning physical CKD DASD, but that is not very
important. It is almost
Ed,
That is a very small subset these days.
AFAIK - OBJ Decks from compilers, TSO XMIT datasets, TRSMAIN (though I think
this is 6k) and a few others are still dependent on 3120 blksize. However,
I would think allowing your users to specify BLKSIZE=0 would be a benefit.
Unless you have one of
Subject:Re: BLKSIZE=3120
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
I took the giant leap several years ago and stopped using 3120 for TSO
XMIT.
I hard-code 27920. Not as wonderful as 0, but better than 3120. Several
years now with no issues.
Charles
On 7/22/2013 9:28 AM, Charles Mills wrote:
I took the giant leap several years ago and stopped using 3120 for TSO XMIT.
I hard-code 27920. Not as wonderful as 0, but better than 3120. Several
years now with no issues.
Good to know. I suppose for errors in help, rather than in the manual,
I've
: 07/22/2013 11:28 AM
Subject: Re: BLKSIZE=3120
Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
I took the giant leap several years ago and stopped using 3120 for TSO
XMIT.
I hard-code 27920. Not as wonderful as 0, but better than 3120. Several
years now with no issues.
Charles
W dniu 2013-07-22 18:08, Ed Jaffe pisze:
A customer (mildly) complained thatsome of our product allocations
still use BLKSIZE=3120. I vaguely remember trying to change all of
them to BLKSIZE=0 many years ago (probably before OS/390) and running
into some issues with certain IBM utilities.
On 7/22/2013 12:08 PM, Ed Jaffe wrote:
A customer (mildly) complained thatsome of our product allocations still
use BLKSIZE=3120. I vaguely remember trying to change all of them to
BLKSIZE=0 many years ago (probably before OS/390) and running into some
issues with certain IBM utilities.
I am not getting
customer complaints.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: Monday, July 22, 2013 10:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=3120
W dniu 2013-07-22 18:08, Ed Jaffe pisze
3120 * 15 = 46800 / 55996 = 83.58% of maximum.
On Mon, Jul 22, 2013 at 12:41 PM, Charles Mills charl...@mcn.org wrote:
Hmm. I *may* need to take back what I said. It looks like for XMIT I specify
27920 but it forces 3120. Would need to do more research and no time at the
moment.
I *know* I
On 7/22/2013 10:41 AM, Charles Mills wrote:
Hmm. I *may* need to take back what I said. It looks like for XMIT I specify
27920 but it forces 3120. Would need to do more research and no time at the
moment.
This finding is consistent with John Kalinich's post where he describes
the availability
83.58% is hardly the end of the world IMHO.
27920 x 2 ~= 99.7%
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike Schwab
Sent: Monday, July 22, 2013 11:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=3120
3120 * 15
.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of R.S.
Sent: Monday, July 22, 2013 10:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=3120
W dniu 2013-07-22 18:08, Ed Jaffe pisze:
A customer (mildly) complained thatsome of our product
If there are any restrictions, they should be APAR'ed. 3120, 6160,
6144, etc. is SO 20th century. It's amazing to me how many IBM and OEM
products still ship these crappy blocksizes. It's why I submitted a
SHARE requirement to have AMATERSE support SDB. Isn't it ironic that a
utility
: BLKSIZE=3120
To: IBM-MAIN@LISTSERV.UA.EDU
If there are any restrictions, they should be APAR'ed. 3120, 6160,
6144, etc. is SO 20th century. It's amazing to me how many IBM and OEM
products still ship these crappy blocksizes. It's why I submitted a
SHARE requirement to have
I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made
installation simple via ShopzSeries. I put in my order. I eventually get an
email saying it is ready. I log on to get the download information that I
need and run a single SMP/E job which downloads and sets it up
.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John McKown
Sent: Monday, July 22, 2013 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=3120
I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made
FTP has some bizarre default, something like RECFM=U, BLKSIZE=511.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Dave Salt
Sent: Monday, July 22, 2013 12:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=3120
A few
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Duffy Nightingale
Sent: Monday, July 22, 2013 12:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=3120
Hello,
I see another developer on here. And we send our product out using TSO XMIT.
Which gives rise
sustained as a result of viruses.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of John McKown
Sent: Monday, July 22, 2013 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=3120
I, personally, as a z/OS system programmer
On Mon, 22 Jul 2013 15:32:37 -0400, Jim Mulder wrote:
AMATERSE assigns a blocksize of 6144, which was a reasonable thing
to do when AMATERSE was designed (before the existence of SDB).
If you explicitly assign a blocksize when you allocate the
data set, AMATERSE will use your blocksize.
ITYM
On Mon, 22 Jul 2013 12:16:00 -0700, Duffy Nightingale wrote:
we send our product out using TSO XMIT. Which gives rise to a
question. I saw some techie state that he would not install a
product unless he could use SMP/E. Is this something us developers
should explore or is it a big headache
Subject: Re: BLKSIZE=3120
To: IBM-MAIN@LISTSERV.UA.EDU
On Mon, 22 Jul 2013 12:16:00 -0700, Duffy Nightingale wrote:
we send our product out using TSO XMIT. Which gives rise to a
question. I saw some techie state that he would not install a
product unless he could use SMP/E
On Mon, 22 Jul 2013 16:41:12 -0400, Dave Salt wrote:
SimpList can be added to that list as well. One reason is because many
developers want to try SimpList by installing it in their own private
libraries, and they don't have access to SMP/E.
Shame on IBM for transmogrifying SMP/E into a
Ed:
Some time ago (before the binder IIRC) the input into the link editor
had a max block size of 3200 (if memory serves me). I think with the
binder the restriction has been removed.
Ed
On Jul 22, 2013, at 11:28 AM, Charles Mills wrote:
I took the giant leap several years ago and
On Mon, 22 Jul 2013 15:53:01 -0500, Paul Gilmartin wrote:
On Mon, 22 Jul 2013 15:35:49 -0500, Tom Marchant wrote:
IMO if a vendor doesn't do their SMP/E packaging correctly,
it is better that they not bother.
Where can I find some Rules of Thumb; an SMP/E style checker?
I'm not aware of
On Mon, 22 Jul 2013 09:08:12 -0700, Ed Jaffe wrote:
A customer (mildly) complained thatsome of our product allocations still
use BLKSIZE=3120. I vaguely remember trying to change all of them to
BLKSIZE=0 many years ago (probably before OS/390) and running into some
issues with certain IBM
At 16:51 -0500 on 07/22/2013, Tom Marchant wrote about Re: BLKSIZE=3120:
Most PTFs should be able to be applied, restored and applied again
without issues.
This is an issue since the design of RESTORE is broken due to its
poor handling of SUPS/PREs If I can Apply a SYSMOD I should be able
Long prior to the advent of SDB, I had formed the habit of omitting
BLKSIZE in my Rexx EXECs. The Rexx function library was smart:
it chose good BLKSIZEs and/or I didn't much care about fractional
deviations from absolute optimality. And, for all I knew (and didn't
care) it adapted well to
You can still use native SMP/E in batch to retain control of your system
installs/maintenance: just do CBIPO instead of IBM's 'recommended'
installs (the distribution tapes should still be in the original format).
IBM had been trying to force us to use their SMP/E 'dialogs' since the
mid/late
In 025801ce86f6$64021d20$2c065760$@mindspring.com, on 07/22/2013
at 09:13 AM, Lizette Koehler stars...@mindspring.com said:
AFAIK - OBJ Decks from compilers, TSO XMIT datasets, TRSMAIN (though
I think this is 6k) and a few others are still dependent on 3120
blksize.
My recollection is that
In 7455665327418361.wa.m42tomibmmainyahoo@listserv.ua.edu, on
07/22/2013
at 04:51 PM, Tom Marchant m42tom-ibmm...@yahoo.com said:
This is not likely an exhaustive list.
o Don't use RELFILE for ++ APAR or ++ PTF
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2
In 00a401ce870f$e7dd43e0$b797cba0$@soundsoftware.us, on 07/22/2013
at 12:16 PM, Duffy Nightingale du...@soundsoftware.us said:
I see another developer on here. And we send our product out using
TSO XMIT. Which gives rise to a question. I saw some techie state
that he would not install a
Jim,
Good memory.
My memory is a bit different (not by much though).
DFP 3.1 first offered SDB
TSOe (I think) at 2.1 ++ many PTF's for Rexx .
I recall having not to implement XA for REXX (not being fully ready
and SWA (above) not being fully supported by vendors. In one case I
had to change
53 matches
Mail list logo
