On 18/11/2020 11:47 pm, Kirk Wolf wrote:
Hey David,
Thank you for rescuing this thread from the ash heap of old hardware model
numbers and tape formats :-)
Topic drift makes this forum almost unreadable these days!
We already have on our list to add ISPF-style enqueue serialization to
putpd
Hey David,
Thank you for rescuing this thread from the ash heap of old hardware model
numbers and tape formats :-)
We already have on our list to add ISPF-style enqueue serialization to
putpds. It just didn't make the first release.
Currently putpds allocates the data set with DISP=OLD (SYSDSN
On Wed, 18 Nov 2020 13:01:53 +0800, David Crayford wrote:
>This is really cool. We could use this right now for our SCLM/Git
>Integration tooling.
>
>Q: How does it handle member ENQs. Does it ENQ using SPFEDIT or SYSDSN?
>One of the problems we ran into with "cp" copying an entire data set is
>it
This is really cool. We could use this right now for our SCLM/Git
Integration tooling.
Q: How does it handle member ENQs. Does it ENQ using SPFEDIT or SYSDSN?
One of the problems we ran into with "cp" copying an entire data set is
it fails if one member is in use.
We worked around this by wri
W dniu 17.11.2020 o 01:57, Wayne Bickerdike pisze:
Atlas rang a bell and then I remembered it was used at the Rutherford labs
in Chilton.
I worked at AERE (Atomic Energy Research Establishment) which was next
door. They were basically the same campus but AERE was secure and
Rutherford wasn't.
t; > Bernd
> >
> >
> >
> > Am 16.11.2020 um 20:46 schrieb Seymour J Metz:
> > > Faster than Atlas?
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > &
t; Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > ____________
> > From: IBM Mainframe Discussion List on
> behalf of Bernd Oppolzer
> > Sent: Sunday, November 15, 2020 5:43 PM
> > To: IBM-MAIN@LISTSERV
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of Bernd
Oppolzer
Sent: Sunday, November 15, 2020 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
Telefunken TR 4, designed 1958, first delivered in 1962.
As a old computer hobbyist I've collected (very) few pictures of TR 4.
Wooden parts of cabinets, construction similar to contemporary 19" racks.
Nice machine, part of IT history.
--
Radoslaw Skorupka
Lodz, Poland
==
Jeśli n
PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
Sorry. First computer to use 8 bits per character.
On Sun, Nov 15, 2020 at 11:09 AM Seymour J Metz wrote:
>
> > You have to remember that S/360 was the first 8 bit computer.
>
> What is the 7030, chopped live
AIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
They only had 7 track tapes at the time.
9 track tapes introduced with S/360 in 1964.
https://secure-web.cisco.com/15XvqSwTkb8sH4cs6M51pKSQPk3d5UMx0-OZWOJ-qVN-Xi3Em6QAF-WxBpwlIxb4H-MIL_lx-Sjm3-fYErj8-_wb3XmyqHn8YwVkyLcFpqfg5HO
Faster than Atlas?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Bernd Oppolzer
Sent: Sunday, November 15, 2020 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, November 15, 2020 6:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
On Sun, 15 Nov 2020 16:28:02 -0600, Mike Schwab wrote:
>They only had 7 track tapes at the time.
>
>9 track tap
FWIW: the Telefunken TR4 indeed only supported half word addressing;
the half words being 24 bits; full words of 48 (plus some extra) bits
had even adresses,
which also were the addresses of the left halfword; the right halfword
had the address
of the left halfword plus one.
The TR 4 offspring
From: IBM Mainframe Discussion List on behalf of
Timothy Sipples
Sent: Monday, November 16, 2020 3:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
Mike Schwab wrote:
>You have to remember that S/360 was the first 8 bit computer.
>[]
>Sorry. Fir
Mike Schwab wrote:
>You have to remember that S/360 was the first 8 bit computer.
>[]
>Sorry. First computer to use 8 bits per character.
I see others have cited the IBM 7030 and Telefunken TR 4 as examples of
early computers that used (or at least were explicitly engineered to use)
8 bit c
On Sun, 15 Nov 2020 16:28:02 -0600, Mike Schwab wrote:
>They only had 7 track tapes at the time.
>
>9 track tapes introduced with S/360 in 1964.
>https://en.wikipedia.org/wiki/9_track_tape
>
Which was no obstacle. There were two modes of I/O to 7-track tapes:
TRTCH=T, which mapped each tape fram
Telefunken TR 4, designed 1958, first delivered in 1962. This predates
IBM/360
by at least 4 years. The fastest mainframe built in Europe at that time.
The internal code ("Zentralcode") was an 8-bit code using 256 characters.
Word structure, a word had 48 bits plus 2 tag bits (tagged architecture
They only had 7 track tapes at the time.
9 track tapes introduced with S/360 in 1964.
https://en.wikipedia.org/wiki/9_track_tape
On Sun, Nov 15, 2020 at 3:36 PM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Sun, 15 Nov 2020 15:13:24 -0600, Mike Schwab wrote:
>
> >S
On Sun, 15 Nov 2020 15:13:24 -0600, Mike Schwab wrote:
>Sorry. First computer to use 8 bits per character.
>
Wikipedia, not necessarily an authority, says:
https://en.wikipedia.org/wiki/IBM_7030_Stretch#Data_formats
Alphanumeric characters are variable length and can use any character cod
; http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf of
> Mike Schwab
> Sent: Saturday, November 14, 2020 9:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Improve OMVS cp performance?
>
> You have
14, 2020 9:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
You have to remember that S/360 was the first 8 bit computer. Prior
computers used 4 bits for a digit and 6 bits for a character. They
designed EBCDIC to be easily converted for use with existing 7 track
tape dri
e Discussion List on
> behalf of Paul Gilmartin <0000000433f07816-dmarc-requ...@listserv.ua.edu>
> > Sent: Saturday, November 14, 2020 6:22 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Improve OMVS cp performance?
> >
> > On Sat, 14 Nov 2020 23:0
t; --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf of
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Saturday, November 14, 2020 6:22 PM
> To: IBM-MAIN@LI
, November 14, 2020 6:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
On Sat, 14 Nov 2020 23:00:00 +, Seymour J Metz wrote:
>Because there was no standard 8-bit code at the time. IBM did push for an
>8-bit ASCII,
>
That's not an obstacle. DEC PDP-8
On Sat, 14 Nov 2020 23:00:00 +, Seymour J Metz wrote:
>Because there was no standard 8-bit code at the time. IBM did push for an
>8-bit ASCII,
>
That's not an obstacle. DEC PDP-8 stored ASCII characters one per
12-bit word. IBM could have simply declared the top bit "reserved"
as they are
ubject: Re: Improve OMVS cp performance?
On Sat, 14 Nov 2020 11:21:08 +1100, Andrew Rowley wrote:
>
>I admit I had never looked at the details of FILEDATA=RECORD. It appears
>that IBM has taken RFC 4506 and made a small change so their
>implementation is incompatible with anything that ac
On 14/11/2020 2:26 pm, Paul Gilmartin wrote:
Is that:
RFC 4506 XDR: External Data Representation Standard May 2006
??? Which section?
Using Data Sets : JCL Parameters for Unix Files says:
"If you code FILEDATA=RECORD, the access method follows a portion of RFC
4506, XDR, Ex
On Sat, 14 Nov 2020 13:52:15 -0600, Kirk Wolf wrote:
>
>> On 14/11/2020 12:54 am, Kirk Wolf wrote:
>>
>> > The new commands (getpds and putpds) use BPAM+BSAM ...
>
>If you were reading a UNIX file, you would need to know whether it had
>IBM-style RDWs, or l4 (which is compatible with FILEDATA=RECOR
On Fri, Nov 13, 2020 at 3:35 PM Andrew Rowley
wrote:
> On 14/11/2020 12:54 am, Kirk Wolf wrote:
>
> > The new commands (getpds and putpds) use BPAM+BSAM along with our
> existing
> > Co:Z record <-> stream processing framework to allow you to copy PDS
> > members to and from z/OS UNIX files. Als
On Sat, 14 Nov 2020 11:21:08 +1100, Andrew Rowley wrote:
>
>I admit I had never looked at the details of FILEDATA=RECORD. It appears
>that IBM has taken RFC 4506 and made a small change so their
>implementation is incompatible with anything that actually follows the RFC.
>
Is that:
RFC 4506
On 14/11/2020 10:16 am, Paul Gilmartin wrote:
Except for UNIX files. From Using Data Sets:
Record Processing for UNIX Files
When a file is accessed as record-oriented (with FILEDATA=RECORD), your program
does not see the record prefixes. The PUT macro adds a prefix to each record in
the same
On Sat, 14 Nov 2020 08:34:15 +1100, Andrew Rowley wrote:
>On 14/11/2020 12:54 am, Kirk Wolf wrote:
>
>> The new commands (getpds and putpds) use BPAM+BSAM along with our existing
>> Co:Z record <-> stream processing framework to allow you to copy PDS
>> members to and from z/OS UNIX files. Also i
On 14/11/2020 12:54 am, Kirk Wolf wrote:
The new commands (getpds and putpds) use BPAM+BSAM along with our existing
Co:Z record <-> stream processing framework to allow you to copy PDS
members to and from z/OS UNIX files. Also included are extensive options
for ISPF stats processing.
Nice wo
On Fri, 13 Nov 2020 11:00:29 -0600, Kirk Wolf wrote:
>
>Are these requests for features that you would actually use?
>
Honestly, no. My employer avoided ISV and FOSS extensions lest
we leak dependencies into customer-facing code.
>re: the line separator option. These are the same as all of the
Gil,
Are these requests for features that you would actually use?
re: the line separator option. These are the same as all of the other
Co:Z tools have been for more than 10 years. It includes support for both
RDWs and 4-byte big endian length.
On Fri, Nov 13, 2020 at 10:41 AM Paul Gilmart
On Fri, 13 Nov 2020 07:54:22 -0600, Kirk Wolf wrote:
>
>For more information:
>https://dovetail.com/docs/zos-utilities/dsp-ref_getpds.html
>https://dovetail.com/docs/zos-utilities/dsp-ref_putpds.html
>https://dovetail.com/docs/cozinstall/changes.html
>Co:Z is available free under our Community Lice
I wanted to update this thread with a bit of news. We have had the
enjoyable experience of working with Lionel and Henri (please check out:
http://zigi.rocks) on requirements for some new shell commands for the Co:Z
Toolkit V6.2.0, which we released this week.
The new commands (getpds and putpds
On Wed, 17 Jun 2020 07:14:39 -0500, Lionel B Dyck wrote:
>Kirk - thank you for the ideas.
>
>What I'm doing is in the ZIGI (see https://zigi.rocks) where I need to copy
>PDS members to/from USS so that Git can manage them. With small projects this
>isn't an issue but with larger projects it coul
so welcome!
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Wednesday, June 17, 2020 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
I think that it is worth an RFE if you can put together a compelling business
case. Be sure to
On Wed, Jun 17, 2020 at 12:12 PM Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:
> I wonder what kind of effort it might be for z/OS to support Unix path
> names as aliases/links to MVS legacy data sets. Probably a lot of work,
> but it seems like it would be quite useful for situations suc
On 18/06/2020 8:01 pm, David Crayford wrote:
Interesting! The Java program probably is probably much faster because
it runs on a full capacity zIIP. At my shop we run an enterprise class
machine and I don't see the same results. It's very difficult to
measure Java vs native when the gcp's also
Interesting! The Java program probably is probably much faster because
it runs on a full capacity zIIP. At my shop we run an enterprise class
machine and I don't see the same results. It's very difficult to measure
Java vs native when the gcp's also run full capacity.
Can you share some of you
esday, June 17, 2020 6:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
Do you think its worth an RFE?
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Wednesday, June 17, 2020 4:52 PM
To: IBM-MAIN@LISTSERV.U
On 18/06/2020 12:24 am, Kirk Wolf wrote:
Lionel,
I wasn't thinking of using the "all members" form of cp - that seems like
it should be *much* better, although it would depend on how cp works under
the covers - evidence indicates that it just loops and does
alloc/open/close/free on each member.
On Thu, 18 Jun 2020 08:52:52 +1000, Andrew Rowley wrote:
>On 18/06/2020 1:43 am, Paul Gilmartin wrote:
>>>
(Concerning preallocating the PDS):
>>
>> I'm mystified that it made a difference since Lionel never used the allocate
>> "dd" in the call to "cp". Only SVC 99 knows.
>
>I was doing some te
Do you think its worth an RFE?
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Wednesday, June 17, 2020 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
I think that technically it would be a piece of cake
On 18/06/2020 1:43 am, Paul Gilmartin wrote:
On Wed, 17 Jun 2020 09:24:58 -0500, Kirk Wolf wrote:
I wasn't thinking of using the "all members" form of cp ...
I'm curious - how much time did you save by preallocating the PDS?
I'm mystified that it made a difference since Lionel never used the a
@LISTSERV.UA.EDU] on behalf of
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Wednesday, June 17, 2020 6:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
I mean technical effort on IBM's part to implement it.
It seems to me that, along with some mapping/naming rules and sen
sets
w/o having to even know that's what they are doing.
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Wednesday, June 17, 2020 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
Technical effort or
e 17, 2020 10:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Improve OMVS cp performance?
>
> CAUTION EXTERNAL EMAIL
>
> Frank - true it is all z/OS but that is like saying it's all Europe - in
> this case z/OS speaks one language and OMVS another - they
@LISTSERV.UA.EDU] on behalf of
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Wednesday, June 17, 2020 1:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
I wonder what kind of effort it might be for z/OS to support Unix path names as
aliases/links to MVS legacy data sets
On Wed, 17 Jun 2020 17:12:11 +, Frank Swarbrick wrote:
>I wonder what kind of effort it might be for z/OS to support Unix path names
>as aliases/links to MVS legacy data sets. Probably a lot of work, but it
>seems like it would be quite useful for situations such as this where the Unix
>ap
On Wed, 17 Jun 2020 11:07:58 -0500, Kirk Wolf wrote:
>On Wed, Jun 17, 2020 at 10:43 AM Paul Gilmartin wrote:
>
>> On Wed, 17 Jun 2020 09:24:58 -0500, Kirk Wolf wrote:
>>
>If you have a reusable allocation, then the cost is less than a new
>allocation. open/close for each member would still be ex
G.B. Shaw was even more famous for it
Jim Horne
Malcom Muggeridge was famous for characterizing UK and US as being *separated*
by a common language.
NOTICE: All information in and attached to the e-mails below may be
proprietary, confidential, privileged and ot
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lionel B Dyck
Sent: Wednesday, June 17, 2020 10:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Improve OMVS cp performance?
CAUTION EXTERNAL EMAIL
Frank - true it is all z/OS but that is like saying it's all Europe
BM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
I wonder what kind of effort it might be for z/OS to support Unix path names as
aliases/links to MVS legacy data sets. Probably a lot of work, but it seems
like it would be quite useful for situations such as this where the Unix
applica
_
From: IBM Mainframe Discussion List on behalf of
Lionel B Dyck
Sent: Wednesday, June 17, 2020 6:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
Kirk - thank you for the ideas.
What I'm doing is in the ZIGI (see https://zigi.rocks) where I
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
It might be more efficient to use XMIT format. Is there a REXX function package
available for unpacking members?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From:
Wolf [k...@wolf-associates.com]
Sent: Wednesday, June 17, 2020 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
On Wed, Jun 17, 2020 at 10:43 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 17 Jun 2020 09:24:58 -0500,
On Wed, Jun 17, 2020 at 10:43 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 17 Jun 2020 09:24:58 -0500, Kirk Wolf wrote:
> >
> >I wasn't thinking of using the "all members" form of cp ...
> >I'm curious - how much time did you save by preallocating the PDS?
>
On Wed, 17 Jun 2020 09:24:58 -0500, Kirk Wolf wrote:
>
>I wasn't thinking of using the "all members" form of cp ...
>I'm curious - how much time did you save by preallocating the PDS?
>
I'm mystified that it made a difference since Lionel never used the allocate
"dd" in the call to "cp". Only SVC
tion merely what others think you are." - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Kirk Wolf
> Sent: Wednesday, June 17, 2020 7:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Improve OMVS cp performance?
>
> Hi
Character is what you are,
reputation merely what others think you are." - John Wooden
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Kirk Wolf
Sent: Wednesday, June 17, 2020 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
Hi Lionel,
dnesday, June 17, 2020 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
Hi Lionel,
Can you provide any more detail on how you are invoking "cp" ?
- With cp, there won't be any way to avoid opening the PDSE for each member,
but you might get some improvement by
On Behalf Of
Kirk Wolf
Sent: Wednesday, June 17, 2020 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
Hi Lionel,
Can you provide any more detail on how you are invoking "cp" ?
- With cp, there won't be any way to avoid opening the PDSE for each member,
t others think you are." - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Paul Gilmartin
> Sent: Tuesday, June 16, 2020 9:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Improve OMVS cp performance?
>
> On Tu
at others think you are." - John Wooden
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Tuesday, June 16, 2020 9:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?
On Tue, 16 Jun 2020 20:34:59 -0500, Lionel B Dyck wrote:
On Tue, 16 Jun 2020 20:34:59 -0500, Lionel B Dyck wrote:
>Any suggestions on how to speed up cp copying multiple file to and from z/OS?
>
>I gave SHAREAS=YES. Anything else? Can I control buffers or ?
>
What's on the non-OMVS side? a PDS(E)? Multiple PS data sets?
I might suggest as an extre
Any suggestions on how to speed up cp copying multiple file to and from z/OS?
I gave SHAREAS=YES. Anything else? Can I control buffers or ?
Lionel B. Dyck <
Website: www.lbdsoftware.com
Sent from my iPhone 8+
Worry more about your character than your reputation. Character is what you
are, rep
70 matches
Mail list logo
