On Sat, 20 Jan 2024 00:14:58 -0500, Cheryl Watson wrote:
>I know that I’m late to this game, but we used to have a free tool to handle
>this called ‘WWUNTERSE’, which has been used by hundreds of people. It is now
>being made available by its original developer, Mario Bezzi, at this link -
I know that I’m late to this game, but we used to have a free tool to handle
this called ‘WWUNTERSE’, which has been used by hundreds of people. It is now
being made available by its original developer, Mario Bezzi, at this link -
https://www.ap4zlabs.com/free-tools.
All my best,
Cheryl
On Wed, 25 Jan 2023 20:24:59 +, Andrew N Wilt wrote:
>... Apparently, they are able to decipher the RDW records resulting from
> uploading a RECFM=VBS as a RECFM=U. Unfortunately, at this time, GDKUTIL
> doesn't have the smarts to parse the bytestream as RDW+data as it is writing
> to
And just an FYI, but the logical record lengths SAS reads can be up
to 16,777,215.
Michael
At 05:40 PM 1/25/2023, Kirk Wolf wrote:
ISTR that distributed SAS has an option to read binary byte stream
files with BDW+RDWs, which is what you would get if the program were
to produce a merged
On 26/01/2023 10:40 am, Kirk Wolf wrote:
ISTR that distributed SAS has an option to read binary byte stream files with
BDW+RDWs, which is what you would get if the program were to produce a merged
RECFM=U DCB.
It does, but I can't see any reason to implement that other than to
workaround
On 26/01/2023 10:20 am, Paul Gilmartin wrote:
It's possibly catering to the novice user rather than the journeyman.
Unfortunately I don't think that's the case. When transferring variable
length binary records, the default options give you unusable (I would
call it corrupted) data. You need
Hi Paul,
Do you DFSMSdss->AMATERSE->XMIT large amounts of SMF Data? (Probably not.)
I would never try to XMIT a Dataset like this (assuming that you could
even have enough space for the XMIT Output.)
Not only that , but BLKSIZE=3120 is inefficient and really slow (and
with no Transmit Exit,
ISTR that distributed SAS has an option to read binary byte stream files with
BDW+RDWs, which is what you would get if the program were to produce a merged
RECFM=U DCB.
Kirk Wolf
Dovetailed Technologies, LLC
http://coztoolkit.com
Dovetailed Technologies: +1 636.300.0901
Note: Our website and
Terse the file and be done with it
Sent from my iPhone
No one said I could type with one thumb
> On Jan 25, 2023, at 17:31, Paul Gorlinsky wrote:
>
> From my experience with one of the vendors, NOT SAS, all of these products
> just expect a stream of data to process. If you are using PC
From my experience with one of the vendors, NOT SAS, all of these products just
expect a stream of data to process. If you are using PC versions, just download
as binary ... the VBS data. The import programs parse the data correctly.
Going from Mainframe to Mainframe, save yourself a lot of
On Thu, 26 Jan 2023 09:23:54 +1100, Andrew Rowley wrote:
>On 26/01/2023 7:24 am, Andrew N Wilt wrote:
>...
>I would be slightly surprised if SAS can't read VB records properly
>formatted with the RDW. RECFM U was a workaround for the problem where
>FTP stripped out the RDW. So GDKUTIL seems
On 26/01/2023 7:24 am, Andrew N Wilt wrote:
The GDKUTIL utility does allow an Upload of something with RECFM=U.
This was done at the behest of a customer that was using ftp to put SMF data
out for processing by the SAS tool. Apparently, they are able to decipher the
RDW records
On Wed, 25 Jan 2023 20:24:59 +, Andrew N Wilt wrote:
>...
> The GDKUTIL utility does allow an Upload of something with RECFM=U.
> This was done at the behest of a customer that was using ftp to put SMF data
> out for processing by the SAS tool. Apparently, they are able to decipher
@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Transmitting SMF records
On 20/01/2023 7:07 am, Glenn Wilcock wrote:
> Late to the party on this discussion... DFSMS recently shipped a new utility
> named GDKUTIL. It converts z/OS data sets and UNIX files to cloud objects
> and visa-versa.
On 20/01/2023 7:07 am, Glenn Wilcock wrote:
Late to the party on this discussion... DFSMS recently shipped a new utility
named GDKUTIL. It converts z/OS data sets and UNIX files to cloud objects and
visa-versa.
Reading the documentation, the following note looks like a problem:
@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Transmitting SMF records
Glenn Wilcock shared
https://public.dhe.ibm.com/eserver/zseries/zos/DFSMS/CDA/OA62318/Cloud_Object_Utility_Pub_updates.pdf
The document at this URL states: z/OS MVS Programming: Callable Services for
High Level Languages
a newer link to IBM documentation where I can find this
updated version of the SA23-1377 document?
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Glenn Wilcock
Sent: Thursday, January 19, 2023 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Transmitting SMF records
Late to the party on this discussion... DFSMS recently shipped a new utility
named GDKUTIL. It converts z/OS data sets and UNIX files to cloud objects and
visa-versa. This enables utilizing cloud object storage as a method for z/OS
sharing data, such as SMF, as opposed to FTPing. Use GDKUTIL
Sent: Thursday, December 15, 2022 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Transmitting SMF records
>From Barry Merrill :
My mxg.com email server company, RACKSPACE, took a Ransomeware attack and I'm
unable to originate mail from ba...@mxg.com, although I am receiving forwards.
Can
Ah, I missed that or forgot by the time I got to posting. I haven't tried it
myself, but have heard it is problematic to get the data back into a z/OS
dataset in a usable fashion.
On Sat, 17 Dec 2022 09:47:39 +1100, Andrew Rowley
wrote:
>The OP specified being able to reverse the process,
On Fri, 16 Dec 2022 15:03:54 -0600, Kirk Wolf wrote:
>The OP didn't specify IBM FTP, so I'll mention that could use Co:Z SFTP, which
>has a subcomment "dsput" which will allocate a dataset on the target system
>matching the source system and then upload the dataset in binary, preserving
On Sat, 17 Dec 2022 09:47:39 +1100, Andrew Rowley wrote:
>
>This seems to be surprisingly difficult - IBM doesn't seem to have
>considered round trip capability when they wrote the FTP functions.
>(Although I haven't tried it with a RECFM U transfer.)
>
Surprisingly difficult or predictably IBM?
On 16/12/2022 11:33 pm, Scott Chapman wrote:
We have customers (S)FTP(S)ing us data every day directly referencing the
output of IFASMFDP with DCB=RECFM=U with no problem.
The OP specified being able to reverse the process, so my understanding
was it needed to transfer back to a dataset on
write a VB(S) file. I've known of
> windows-based utilities that process FTPed SMF data (raw or tersed) so the
> technical knowledge is out there.
> Date:Wed, 14 Dec 2022 13:22:27 -0600
> From: Boesel Guillaume
> Subject: Re: [EXTERNAL] Re: Transmitting SMF records
&
We have customers (S)FTP(S)ing us data every day directly referencing the
output of IFASMFDP with DCB=RECFM=U with no problem. From our standard
instructions:
//SENDFTP EXEC PGM=FTP,PARM='(EXIT=12'
//SYSPRINT DD SYSOUT=*
//OUTPUT DD SYSOUT=*
//SMFFILEA DD
On 16/12/2022 1:43 am, Gary Weinhold wrote:
As an alternative, it wouldn't seem very difficult to create a utility to read
the FTPed data (received as a sequential file with an arbitrary record length)
and reformat the data to write a VB(S) file.
It is not difficult. The biggest problem is
>From Barry Merrill :
>...
>But if the destination is for ASCII and SAS, you can use IEBGENER to create a
>copy of
>the data, on z/OS, but using RECFM=U, which ftp can't muck-up, and SAS on
>ASCII processes that data using RECFM=S370VBS, since the file has the BDW and
>RDW, so the
On Thu, 15 Dec 2022 15:31:31 +, Seymour J Metz wrote:
>There are several facilities for encoding variable-length recrds into FB,
>e.g., XMIT. A bit kludgy, but it works.
>
Alas, one needs to operate at both the sending and receiving ends because
z/OS sort lacks anything such as a QUOTE SITE
From Barry Merrill :
My mxg.com email server company, RACKSPACE, took a Ransomeware attack and I'm
unable to originate mail from ba...@mxg.com, although I am receiving forwards.
Can you post this to the IBM-MAIN track for me.
The problem with moving SMF records with ftp is that whenever ftp
On Thu, 15 Dec 2022 15:24:04 +, Pommier, Rex wrote:
>What I remember from a discussion long ago was that the reason a VBS dataset
>can't be put back together again is that when the VBS dataset is sent to a
>Windows intermediary, some of the binary metadata defining the records and
>blocks
On Thu, 15 Dec 2022 14:43:48 +, Gary Weinhold wrote:
>I'm glad there was a solution.
>
>But the underlying problem seems to be that z/OS FTP appears to be limited to
>processing a binary (image) transfer as a stream of bytes unless the transfer
>is between a z/OS client and z/OS server.
Weinhold [weinh...@dkl.com]
Sent: Thursday, December 15, 2022 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Transmitting SMF records
I'm glad there was a solution.
But the underlying problem seems to be that z/OS FTP appears to be limited to
processing a binary (image) transfer as a stream
Doesn't XMIT/RECEIVE handle VBS in both directions? I thought it did.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Pommier, Rex
Sent: Thursday, December 15, 2022 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Transmitting SMF records
What I remember
@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Transmitting SMF records
I'm glad there was a solution.
But the underlying problem seems to be that z/OS FTP appears to be limited to
processing a binary (image) transfer as a stream of bytes unless the transfer
is between a z/OS client and z/OS server
there.
Date:Wed, 14 Dec 2022 13:22:27 -0600
From:Boesel Guillaume
Subject: Re: [EXTERNAL] Re: Transmitting SMF records
Hi Rex,
Great. You are right, tersing file from tape to tape works well.
It took around 80-90 MSU during an hour for just one file but it worked.
Hoping that Ituriel will be able
I have not done z/OS to z/OS. But I do download SMF to Windows for SCRT.
I do:
bin
quote site rdw
get zos.smf windows.smf
On Wed, Dec 14, 2022, 07:57 Ituriel do Neto <
03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote:
> Hi all,
>
> I know we can TERSE or use XMIT a SMF dataset to generate
Hi Rex,
Great. You are right, tersing file from tape to tape works well.
It took around 80-90 MSU during an hour for just one file but it worked.
Hoping that Ituriel will be able to read this file.
Regards and thanks !
--
For
dred bucks and fit in a shirt pocket.
Rex
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Wednesday, December 14, 2022 12:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Transmitting SMF records
On Wed, 14 Dec 2022 16:27:07 +, Keith Goo
:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Transmitting SMF records
On Wed, 14 Dec 2022 16:27:07 +, Keith Gooding wrote:
>... The problem is that as far as I know the receiver code is not
> available to ISVs. AMAPDUPL processing can be performed by the z/OSMF Problem
> M
On Wed, 14 Dec 2022 16:27:07 +, Keith Gooding wrote:
>... The problem is that as far as I know the receiver code is not
> available to ISVs. AMAPDUPL processing can be performed by the z/OSMF Problem
> Management function and it would be nice if ISVs could receive data sent by
>
this on a regular basis, FTPing large (~100
GB) files straight from tape to Windows.
Rex
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Boesel Guillaume
Sent: Wednesday, December 14, 2022 10:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Transmitting SMF records
Hi all
On Wed, 14 Dec 2022 13:56:59 +, Ituriel do Neto wrote:
>
>I have a customer that has a huge SMF dataset that can't be TERSED or XMITTED
>because of a lack of space.
>
>Is there a way to send it, without previous use of XMIT or TRS ?
>
This feels like a motivation for an RFE for AMATERSE to
Although not a solution to your problem you may know that the z/os AMAPDUPL
utility solves this problem by automatically tersing the data, splitting it
into chunks, and transmitting the chunks to the IBM support site in a number of
overlapping ftp or https streams. I think it uses pipes to
Hi all,
"I have a customer that has a huge SMF dataset"
I'm the "customer" who sent these huge SMF datasets.
We are not able to offload them on DASD to terse or xmit them, there are really
to much huge (around 80-100 GB per files), we don't have enough disk space.
I sent the same files to IBM
My €0.02:
1. Be specific. Provide us as many details as needed. Huge size, lack
of space for TERSE (really)? - all those details were provided later.
2. CHANGE SOMETHING. You have to change something.
3. First I would discuss the size of SMF dataset. SMF repository need
not to be single huge
If tape is shared... Then use IEBGENER ( ICEGENER ) to copy the XMIT dataset to
tape... and restore that DSN from tape to feed RECEIVE
FTP is horrible to use ... too much latencies ... Using TERSE in there adds
verification that the data is intact ...
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
rpinion865
Sent: Wednesday, December 14, 2022 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Public] RE: EXTERNAL: Re: Transmitting SMF records
Like I said earlier, you can TERSE to a tape dataset. I use that method all
SMF data is usually VBS format, Variable Block Span. Physical blocks 4K but
records can be much larger.
First question: Are the two z/OS machines connected via TCP/IP ? if so TERSE
XMIT to the 2nd machine, RECEIVE, DETERSE else
Second: Is the data VB or still VBS?
Using TERSE and then
C.
>
> Sent: Wednesday, December 14, 2022 8:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Public] RE: EXTERNAL: Re: Transmitting SMF records
>
> Sorry, I see what you mean.
>
> I've installed a couple of IBM tools from my Windows workstation that were in
> XMIT format. I upload
think you are.” - - - John Wooden
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Crawford, Robert C.
Sent: Wednesday, December 14, 2022 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Public] RE: EXTERNAL: Re: Transmitting SMF records
Sorry, I see what you mean.
I've installed
go/mfmfrontdoor
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Ituriel do Neto
Sent: Wednesday, December 14, 2022 8:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Transmitting SMF records
The idea is to send an SMF dataset from one z/OS to anothe
The idea is to send an SMF dataset from one z/OS to another one, but first, it
needs to be downloaded to windows to be sent to us, also in windows. Once we
have the file, we upload it to our mainframe to process it.
It is possible to split the original SMF dataset in smaller pieces but demands
er 14, 2022 7:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Transmitting SMF records
Hi all,
I know we can TERSE or use XMIT a SMF dataset to generate a fixed-form dataset,
that can be downloaded in binary mode, transmitted, and then recovered
following the reverse order.
My att
Are you processing this on another z/OS system ? You indicated you’re
downloading it so I wanted to make sure I understand the requirements.
For “downloading” are you using FTP, SFTP or SCP. Are you processing the data
on a non-Z platform ?
Matt Hogstrom
m...@hogstrom.org
“It may be
Why don't you divide the huge file into sections? TRY idcams copy
fromnumber with count
*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **| *
*|* *Email**: i_mugz...@securiteam.co.il **|*
You could try extracting a subset of records based on start time and end
time... then xmiting those, and at the far end concatenation them
Colin
On Wed, 14 Dec 2022 at 13:57, Ituriel do Neto <
03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote:
> Hi all,
>
> I know we can TERSE or use XMIT a
You can TERSE to a "tape" dataset.
Sent with Proton Mail secure email.
--- Original Message ---
On Wednesday, December 14th, 2022 at 8:56 AM, Ituriel do Neto
<03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote:
> Hi all,
>
> I know we can TERSE or use XMIT a SMF dataset to
Hi all,
I know we can TERSE or use XMIT a SMF dataset to generate a fixed-form dataset,
that can be downloaded in binary mode, transmitted, and then recovered following
the reverse order.
My attempts of downloading the SMF dataset directly, in binary, and then
uploading
it to another SMF dataset
58 matches
Mail list logo
