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 -
>htt
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 Watson
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 t
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 RECFM=
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 IBM
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 t
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, gene
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 do
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 ver
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 he
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 to
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 result
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
-MAIN@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:
-MAIN@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 Languag
Can anyone provide 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: Tran
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.
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, so
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
>record
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 z
ngth) and reformat the data to 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] R
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 DSN=*.SMFDMP.DUMPOUT,DCB=RECFM=U,BLKSIZE
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 th
>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 downloaded
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 see
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 stre
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 rem
: IBM-MAIN@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
l
knowledge is out 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
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
ndred 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 +, Keit
ber 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 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
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
> AMAPDUP
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
H
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 sup
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 ove
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 us
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 d
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 of
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 XMIT
obert 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
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
nt door at
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 a
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
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 cognit
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 S
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 gener
56 matches
Mail list logo
