[hercules] hi there ...

[raheel nomani]

thank you...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: emptying a PDS

[Brian Westerman]

This is very nice.  It's much better than the process I have been using.  Now I 
have to worry about doing it to the wrong dataset.

Brian

On Tue, 20 Oct 2020 04:40:14 +0100, CM Poncelet  wrote:

>+2
>
>On 19/10/2020 16:58, Steve Smith wrote:
>> +1
>>
>> Some of the proposals sounded akin to writing IEFBR14 in C++.
>>
>> sas
>>
>>
>> On Mon, Oct 19, 2020 at 11:46 AM David Staudacher 
>> wrote:
>>
>>> Given the specification to EMPTY a PDS, nothing is simpler than just
>>> reinitializing the directory.
>>> Assemble this source and keep it around as a utility:
>>>  *-*
>>>  * INITIALIZE PDS/PDSE TO EMPTY STATE  *
>>>  *-*
>>>  PDSINIT CSECT
>>>  SAVE  14
>>>  LR12,15
>>>  USING PDSINIT,12
>>>  OPEN  (PDS,OUTPUT) OPEN PDS
>>>  STOW  PDS,,IINITIALIZE PDS
>>>  CLOSE PDS   CLOSE PDS
>>>  RETURN 14   RETURN
>>>  PDS DCB DDNAME=PDS,DSORG=PO,MACRF=W
>>>  END PDSINIT
>>>
>>>
>>> Run PDSINIT with this JCL:
>>> // EXEC PGM=PDSINIT
>>> //STEPLIB DD DISP=SHR,DSN=
>>> //PDS DD DISP=SHR,DSN=S17666D.TEST.PDSE
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> .
>>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Timothy Sipples]

Paul Gilmartin asked:
>(But is ICSF separately priced with no provision for free trial?)

No. The z/OS Integrated Cryptographic Service Facility (ICSF) is part of 
the z/OS Cryptographic Services, a base element of the z/OS operating 
system. There's no additional charge for ICSF; it's included with your 
z/OS base operating system license.

References:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zb100/baseel.htm

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.csf/csf.htm

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: emptying a PDS

[CM Poncelet]

+2

On 19/10/2020 16:58, Steve Smith wrote:
> +1
>
> Some of the proposals sounded akin to writing IEFBR14 in C++.
>
> sas
>
>
> On Mon, Oct 19, 2020 at 11:46 AM David Staudacher 
> wrote:
>
>> Given the specification to EMPTY a PDS, nothing is simpler than just
>> reinitializing the directory.
>> Assemble this source and keep it around as a utility:
>>  *-*
>>  * INITIALIZE PDS/PDSE TO EMPTY STATE  *
>>  *-*
>>  PDSINIT CSECT
>>  SAVE  14
>>  LR12,15
>>  USING PDSINIT,12
>>  OPEN  (PDS,OUTPUT) OPEN PDS
>>  STOW  PDS,,IINITIALIZE PDS
>>  CLOSE PDS   CLOSE PDS
>>  RETURN 14   RETURN
>>  PDS DCB DDNAME=PDS,DSORG=PO,MACRF=W
>>  END PDSINIT
>>
>>
>> Run PDSINIT with this JCL:
>> // EXEC PGM=PDSINIT
>> //STEPLIB DD DISP=SHR,DSN=
>> //PDS DD DISP=SHR,DSN=S17666D.TEST.PDSE
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: emptying a PDS

[Seymour J Metz]

I realize that you can get away with not chaining a new save area in this case, 
but it creates a booby trap for anybody who modifies the code.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Staudacher [dlstaudac...@gmail.com]
Sent: Monday, October 19, 2020 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS

Given the specification to EMPTY a PDS, nothing is simpler than just 
reinitializing the directory.
Assemble this source and keep it around as a utility:
 *-*
 * INITIALIZE PDS/PDSE TO EMPTY STATE  *
 *-*
 PDSINIT CSECT
 SAVE  14
 LR12,15
 USING PDSINIT,12
 OPEN  (PDS,OUTPUT) OPEN PDS
 STOW  PDS,,IINITIALIZE PDS
 CLOSE PDS   CLOSE PDS
 RETURN 14   RETURN
 PDS DCB DDNAME=PDS,DSORG=PO,MACRF=W
 END PDSINIT

Run PDSINIT with this JCL:
// EXEC PGM=PDSINIT
//STEPLIB DD DISP=SHR,DSN=
//PDS DD DISP=SHR,DSN=S17666D.TEST.PDSE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: emptying a PDS

[Seymour J Metz]

Back in the day, one of the clowns (Rube Goldberg?) writing for a trade rag 
wrote an article on how clumsy the OS/2 API allegedly was. To "prove" his 
point, he showed the code needed to create a popup window, display "Hello, 
World" in it, wait for a reply and close the popup. He then compared it to the 
classic Hello World C program, never realizing that it was a perfectly valid 
OS/2 program, far shorter than his contrived version.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Smith [sasd...@gmail.com]
Sent: Monday, October 19, 2020 11:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: emptying a PDS

+1

Some of the proposals sounded akin to writing IEFBR14 in C++.

sas


On Mon, Oct 19, 2020 at 11:46 AM David Staudacher 
wrote:

> Given the specification to EMPTY a PDS, nothing is simpler than just
> reinitializing the directory.
> Assemble this source and keep it around as a utility:
>  *-*
>  * INITIALIZE PDS/PDSE TO EMPTY STATE  *
>  *-*
>  PDSINIT CSECT
>  SAVE  14
>  LR12,15
>  USING PDSINIT,12
>  OPEN  (PDS,OUTPUT) OPEN PDS
>  STOW  PDS,,IINITIALIZE PDS
>  CLOSE PDS   CLOSE PDS
>  RETURN 14   RETURN
>  PDS DCB DDNAME=PDS,DSORG=PO,MACRF=W
>  END PDSINIT
>
>
> Run PDSINIT with this JCL:
> // EXEC PGM=PDSINIT
> //STEPLIB DD DISP=SHR,DSN=
> //PDS DD DISP=SHR,DSN=S17666D.TEST.PDSE
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Batch SFTP without client keys or USS files?

[Wendell Lovewell]

I guess I misspoke.  I'm trying to connect to a server supporting SFTP on port 
.  FTP and FTPS on other ports.  Sorry.   

The Windows SFTP command works fine.  I just can't see the difference in my job 
between yours and Ed's.  

Thanks, 
Wendell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Sasso, Len]

Manfred:

Thank You So Much and Please Be Safe!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office: Tue., Oct. 20th  - 1:30 PM - Wed., Oct 21st @ 7 AM
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com





From: IBM Mainframe Discussion List  on behalf of 
Manfred Lotz 
Sent: Monday, October 19, 2020 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Checksum/Md5 file



 [External: Use caution with links & attachments]

Hi Len,

On Mon, 19 Oct 2020 18:03:03 +
"Sasso, Len"  wrote:

> Hello Manfred !
>
> We are at z/OS 2.3 and have not been able to locate these files:
>
> "In z/OS UNIX they can be found in the /bin directory.
>
> /bin/md5
> /bin/rmd160
> /bin/sha1
> /bin/sha224
> /bin/sha256
> /bin/sha384
> /bin/sha512"
>
>

Please check in SMP/E if you have applied PTF UJ03194.  Otherwise
receive and apply it and you have them.


> Thank You and Please Be Safe!
>

Thanks. All the best to you as well.


--
Stay healthy,
Manfred

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM KEYXFER rexx

[Lennie Dymoke-Bradshaw]

I have a copy of this. The last update on mine 10/08/2009, which I think is 8th 
October. 
I confess I never used it. From memory, I think it requires the source and 
target systems to use the same master key.

I have another facility for moving DES and 3DES keys between systems using a 
transport key.

Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Dave Jousma
Sent: 19 October 2020 14:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM KEYXFER rexx

All,

Do any of you have a copy of IBM AS-IS utility “KEYXFER”?   The copy I have is 
from 2006, was updated in 2018.   IBM has moved all their stuff into GITHUB 
now, and the README is there, but not the REXX code.   The code also used to 
live at ftp://ftp.software.ibm.com/s390/zos/tools/keyxfer/.  I'm able to get to 
the site, but cant download anything.  

FYI, this utility is for exporting/importing PKDS keys out of ICSF.

I do have a ticket open with IBM on this, but they seem to be dragging their 
feet trying to put it back out on GITHUB.

If anyone has a copy, I’d appreciate someone sending it to me?



For the curious, here is the readme

keyxfer
A Key Transfer Tool
Introduction
The key transfer tool (KEYXFER) is a REXX exec that runs on MVS. KEYXFER 
facilitates the transfer of PKDS or CKDS key tokens between systems that use 
the Integrated Cryptographic Services Facility (ICSF).
The KEYXFER tool assumes the following:
1.  ICSF is running on the systems involved in the key transfer
2.  ICSF has an active Key Data Set (CKDS/PKDS)
For a PKA key token transfer the tool retrieves the token from the active PKDS 
and writes it to a data set (file). For a symmetric key token transfer the tool 
retrieves the token from the active CKDS and writes it to a data set (file).
The data set can then be transmitted to any number of systems. On each system 
the tool can be used to read the key token from the transmitted file and store 
it into the active PKDS or CKDS. The tokens are referenced by label.
The format of the command is illustrated below:
Syntax
KEYXFER   OPER, LABEL, DSN,  OPTION

OPER  = READ_PKDS reads from the transmitted data set
 WRITE_PKDS writes to the transmitted data set
 READ_CKDS reads from the transmitted data set
 WRITE_CKDS writes to the transmitted data set
LABEL = label of PKDS or CKDS record to be retreived/stored
DSN   = name of data set holding the token
OPTION= OVERWRITE a label in the PKDS or CKDS.
 If OVERWRITE is specified in the option 
 field then an existing label will
 be overwritten with the token from the
 transmitted data set.
DATA SET: A PS or PDS data set can be used. An LRECL=80 is recommended, but not 
required The information stored in the KEYXFER data set consists of the 
following: Date KDS label Length of token Token Notes External key tokens can 
be received on any ICSF system. If the key token is an internal key token (see 
ICSF Application Programmers Guide) then it is encrypted under the ICSF master 
key of the system. Transferring the key token requires that the receiving 
systems use the same ICSF master key.
If ICSF services are RACF protected (CSFSERV) then access will be required by 
the user for the CSNDKRC, CSNDKRR, and CSNDKRW services for PKDS transfers or 
CSNBKRC, CSNBKRR and CSNBKRW for CKDS transfers.
Samples
•   Write the key token stored in the active PKDS under the label 
PKDS.KEY.LABEL to the data set TEMP.MEM
KEYXFER WRITE_PKDS, PKDS.KEY.LABEL, TEMP.MEM
•   Read the key token contained in the data set TEMP.MEM and write the 
token to the active PKDS under the label PKDS.KEY.LABEL. (If the label already 
exists in the PKDS the operation will fail.)
KEYXFER READ_PKDS, PKDS.KEY.LABEL, TEMP.MEM
•   Read the key token contained in the data set TEMP.MEM and write the 
token to the active PKDS under the label PKDS.KEY.LABEL (If the label already 
exists in the PKDS the token for that label will be overwritten.)
KEYXFER READ_PKDS, PKDS.KEY.LABEL, TEMP.MEM, OVERWRITE
•   Read the key token contained in the data set TEMP.MEM and write the 
token to the active PKDS. Since no PLABEL was specified the label Contained in 
the file is used as the label for the token on the new system.
KEYXFER READ_PKDS, , TEMP.MEM
•   Write the key token stored in the active CKDS under the label 
CKDS.KEY.LABEL to the data set TEMP.MEM
KEYXFER WRITE_CKDS, CPKDS.KEY.LABEL, TEMP.MEM

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Manfred Lotz]

Hi Len,

On Mon, 19 Oct 2020 18:03:03 +
"Sasso, Len"  wrote:

> Hello Manfred !
> 
> We are at z/OS 2.3 and have not been able to locate these files:
> 
> "In z/OS UNIX they can be found in the /bin directory.
> 
> /bin/md5
> /bin/rmd160
> /bin/sha1
> /bin/sha224
> /bin/sha256
> /bin/sha384
> /bin/sha512"
> 
> 

Please check in SMP/E if you have applied PTF UJ03194.  Otherwise
receive and apply it and you have them.


> Thank You and Please Be Safe!
> 

Thanks. All the best to you as well.


-- 
Stay healthy,
Manfred

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Sasso, Len]

Hello Manfred !

We are at z/OS 2.3 and have not been able to locate these files:

"In z/OS UNIX they can be found in the /bin directory.

/bin/md5
/bin/rmd160
/bin/sha1
/bin/sha224
/bin/sha256
/bin/sha384
/bin/sha512"




Thank You and Please Be Safe!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office: Tue., Oct. 20th  - 1:30 PM - Wed., Oct 21st @ 7 AM
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com





From: IBM Mainframe Discussion List  on behalf of 
Manfred Lotz 
Sent: Monday, October 19, 2020 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Checksum/Md5 file



 [External: Use caution with links & attachments]

On Fri, 16 Oct 2020 18:53:39 +
"Sasso, Len"  wrote:

> Anyone know if a Checksum/Md5 file can be created on a IBM Mainframe?
>
> If so, how?
>
>

I may be a bit late to the party but if you happen to have z/OS 2.4 or
z/OS 2.3 then there is

APPLICABLE COMPONENT LEVEL/SU:
R7C0 PSY UJ03195 UP20/06/24 P F006
R7B0 PSY UJ03194 UP20/06/24 P F006

Functionality

The new cryptographic hash utilities, including md5, rmd160, sha1,
sha224, sha256, sha384 and sha512, use the ICSF One-Way Hash Generate
callable service to generate cryptographic hash for input files
respectively. The utilities can check cryptographic hashes read from
input files. MVS sequential data sets are supported as well.

In z/OS UNIX they can be found in the /bin directory.

/bin/md5
/bin/rmd160
/bin/sha1
/bin/sha224
/bin/sha256
/bin/sha384
/bin/sha512

You find documentation in the z/OS Version 2 Release 4 UNIX System
Services Command Reference here 
https://urldefense.us/v3/__https://www-01.ibm__;!!JRQnnSFuzw7wjAKq6ti6!iiXsjKTnrZYeajZ4uAGST44mYRWMTOrKnkTbodrHTZLiN6UwOezSUa21xtIEDA$
 .
com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa232280?OpenDocument


--
Hope this helps,
Manfred

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: emptying a PDS

[Paul Gilmartin]

On Mon, 19 Oct 2020 10:46:29 -0500, David Staudacher wrote:

>Given the specification to EMPTY a PDS, nothing is simpler than just 
>reinitializing the directory. 
>Assemble this source and keep it around as a utility: 
>
Unfortunately, tnat's true.  But some customers prefer something
simpler than assemble and link before using.  And especially suppiiers
do not wish to burden their clients with such a process.  It would be
simpler yet if IBM were to distribute with z/OS base a program object
which could be invoked with TSO CALL or Rexx LINKMVS.

For flexibility, the DDNAME shouldn't be hard-coded.  It should
be supplied via PARM or alternate DDNAME list.

Re-entrancy?

> *-* 
> * INITIALIZE PDS/PDSE TO EMPTY STATE  * 
> *-* 
> PDSINIT CSECT   
> SAVE  14   
> LR12,15 
> USING PDSINIT,12
> OPEN  (PDS,OUTPUT) OPEN PDS 
> STOW  PDS,,IINITIALIZE PDS   
> CLOSE PDS   CLOSE PDS
> RETURN 14   RETURN   
> PDS DCB DDNAME=PDS,DSORG=PO,MACRF=W   
> END PDSINIT   
>
>
>Run PDSINIT with this JCL:
>// EXEC PGM=PDSINIT
>//STEPLIB DD DISP=SHR,DSN=
>//PDS DD DISP=SHR,DSN=S17666D.TEST.PDSE 

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: emptying a PDS

[Steve Smith]

+1

Some of the proposals sounded akin to writing IEFBR14 in C++.

sas


On Mon, Oct 19, 2020 at 11:46 AM David Staudacher 
wrote:

> Given the specification to EMPTY a PDS, nothing is simpler than just
> reinitializing the directory.
> Assemble this source and keep it around as a utility:
>  *-*
>  * INITIALIZE PDS/PDSE TO EMPTY STATE  *
>  *-*
>  PDSINIT CSECT
>  SAVE  14
>  LR12,15
>  USING PDSINIT,12
>  OPEN  (PDS,OUTPUT) OPEN PDS
>  STOW  PDS,,IINITIALIZE PDS
>  CLOSE PDS   CLOSE PDS
>  RETURN 14   RETURN
>  PDS DCB DDNAME=PDS,DSORG=PO,MACRF=W
>  END PDSINIT
>
>
> Run PDSINIT with this JCL:
> // EXEC PGM=PDSINIT
> //STEPLIB DD DISP=SHR,DSN=
> //PDS DD DISP=SHR,DSN=S17666D.TEST.PDSE
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: emptying a PDS

[David Staudacher]

Given the specification to EMPTY a PDS, nothing is simpler than just 
reinitializing the directory. 
Assemble this source and keep it around as a utility: 
 *-* 
 * INITIALIZE PDS/PDSE TO EMPTY STATE  * 
 *-* 
 PDSINIT CSECT   
 SAVE  14   
 LR12,15 
 USING PDSINIT,12
 OPEN  (PDS,OUTPUT) OPEN PDS 
 STOW  PDS,,IINITIALIZE PDS   
 CLOSE PDS   CLOSE PDS
 RETURN 14   RETURN   
 PDS DCB DDNAME=PDS,DSORG=PO,MACRF=W   
 END PDSINIT
  

Run PDSINIT with this JCL:
// EXEC PGM=PDSINIT
//STEPLIB DD DISP=SHR,DSN=
//PDS DD DISP=SHR,DSN=S17666D.TEST.PDSE 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Paul Gilmartin]

On Mon, 19 Oct 2020 10:09:07 -0500, Bill Godfrey wrote:

>It's not an operational/production system, just a sandbox.
> 
That should make it easy to request functions needed for testing.
(But is ICSF separately priced with no provision for free trial?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEBPDSE (was: emptying a PDS ...)

[Seymour J Metz]

That doesn't mean that there are no concurrency issues.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tabari Alexander [thale...@us.ibm.com]
Sent: Monday, October 19, 2020 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPDSE (was: emptying a PDS ...)

> Yes. That doesn't mean that there are no concurrency issues.

(Sorry for the double post)

You are correct on the first part. PDSE is aware of any extents that are added 
to the data set while it is open. This is true both for opens on the same 
system and opens on different systems within the sysplex, with the latter only 
enabled with PDSE Extended mode sharing.

Tabari

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Paul Gilmartin]

On Mon, 19 Oct 2020 15:23:02 +0200, Manfred Lotz wrote:
>
>> /bin/md5
>> /bin/rmd160
>> /bin/sha1
>> /bin/sha224
>> /bin/sha256
>> /bin/sha384
>> /bin/sha512
>
>https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa232280?OpenDocument
>
Are these savvy to record boundaries, in contrast to e.g. the
CMS Pipelines DIGEST stage which hashes identically:
FOOBAR
and
FOO
BAR
???  This might be solved by (optionally) including the RDWs in the hash.

OTOH, if I REPRO a fixed-80 data set to VB-84, preserving trailing spaces,
should the hash be unchanged?

Can I hash an entire VSAM cluster or PDS(E), or must it be done
member-by-member?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Bill Godfrey]

It's not an operational/production system, just a sandbox.

On Mon, 19 Oct 2020 16:20:37 +0200, Manfred Lotz wrote:

>On Mon, 19 Oct 2020 09:10:38 -0500
>Bill Godfrey wrote:
>
>> These z/OS UNIX commands require ICSF to be active.
>> Otherwise you get this:
>> $ echo testing | md5
>> FSUMF437 ICSF is required but not available.
>> $ echo testing | sha256
>> FSUMF437 ICSF is required but not available.
>>
>
>Yes, exactly. This was mentioned in the functionality part I posted.
>
>Question: Do you run a z/OS system without having ICSF active? If yes,
>does this make sense?
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Manfred Lotz]

On Mon, 19 Oct 2020 09:10:38 -0500
Bill Godfrey  wrote:

> These z/OS UNIX commands require ICSF to be active.
> Otherwise you get this:
> $ echo testing | md5
> FSUMF437 ICSF is required but not available.
> $ echo testing | sha256
> FSUMF437 ICSF is required but not available.
> 

Yes, exactly. This was mentioned in the functionality part I posted.

Question: Do you run a z/OS system without having ICSF active? If yes,
does this make sense?


-- 
Manfred

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Bill Godfrey]

These z/OS UNIX commands require ICSF to be active.
Otherwise you get this:
$ echo testing | md5
FSUMF437 ICSF is required but not available.
$ echo testing | sha256
FSUMF437 ICSF is required but not available.

Bill

On Mon, 19 Oct 2020 15:23:02 +0200, Manfred Lotz wrote:

>On Mon, 19 Oct 2020 15:07:01 +0200
>Manfred Lotz wrote:
>
>> On Fri, 16 Oct 2020 18:53:39 +
>> "Sasso, Len" wrote:
>>
>> > Anyone know if a Checksum/Md5 file can be created on a IBM
>> > Mainframe?
>> >
>> > If so, how?
>> >
>> >
>>
>> I may be a bit late to the party but if you happen to have z/OS 2.4 or
>> z/OS 2.3 then there is
>>
>> APPLICABLE COMPONENT LEVEL/SU:
>> R7C0 PSY UJ03195 UP20/06/24 P F006
>> R7B0 PSY UJ03194 UP20/06/24 P F006
>>
>> Functionality
>>
>> The new cryptographic hash utilities, including md5, rmd160, sha1,
>> sha224, sha256, sha384 and sha512, use the ICSF One-Way Hash Generate
>> callable service to generate cryptographic hash for input files
>> respectively. The utilities can check cryptographic hashes read from
>> input files. MVS sequential data sets are supported as well.
>>
>> In z/OS UNIX they can be found in the /bin directory.
>>
>> /bin/md5
>> /bin/rmd160
>> /bin/sha1
>> /bin/sha224
>> /bin/sha256
>> /bin/sha384
>> /bin/sha512
>>
>> You find documentation in the z/OS Version 2 Release 4 UNIX System
>> Services Command Reference here https://www-01.ibm.
>> com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa232280?OpenDocument
>>
>>
>
>Sorry for the bad formatting of the link in my previous reply
>
>https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa232280?OpenDocument
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM KEYXFER rexx

[Jackson, Rob]

I can get to it and download the files.  That's with IE.  Chrome doesn't do 
well with anonymous FTP on the corporate network.  I didn't try a standard FTP 
client.  At any rate, reply off list, and I would be happy to send the files to 
you, though they are not anywhere near as recent as 2018:


10/Aug/2011 00:00

   7 KB

keyxfer.readme.txt

02/Aug/2011 00:00

   64.8 KB

keyxfer.rexx

10/Aug/2011 00:00

   64.8 KB

keyxfer.rexx.txt

02/Aug/2011 00:00

   7 KB

readme.txt






First Horizon Bank

Mainframe Technical Support





-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Dave Jousma
Sent: Monday, October 19, 2020 9:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM KEYXFER rexx



[External Email. Exercise caution when clicking links or opening attachments.]



All,



Do any of you have a copy of IBM AS-IS utility “KEYXFER”?   The copy I have is 
from 2006, was updated in 2018.   IBM has moved all their stuff into GITHUB 
now, and the README is there, but not the REXX code.   The code also used to 
live at ftp://ftp.software.ibm.com/s390/zos/tools/keyxfer/.  I'm able to get to 
the site, but cant download anything.



FYI, this utility is for exporting/importing PKDS keys out of ICSF.



I do have a ticket open with IBM on this, but they seem to be dragging their 
feet trying to put it back out on GITHUB.



If anyone has a copy, I’d appreciate someone sending it to me?







For the curious, here is the readme



keyxfer

A Key Transfer Tool

Introduction

The key transfer tool (KEYXFER) is a REXX exec that runs on MVS. KEYXFER 
facilitates the transfer of PKDS or CKDS key tokens between systems that use 
the Integrated Cryptographic Services Facility (ICSF).

The KEYXFER tool assumes the following:

1.  ICSF is running on the systems involved in the key transfer

2.  ICSF has an active Key Data Set (CKDS/PKDS)

For a PKA key token transfer the tool retrieves the token from the active PKDS 
and writes it to a data set (file). For a symmetric key token transfer the tool 
retrieves the token from the active CKDS and writes it to a data set (file).

The data set can then be transmitted to any number of systems. On each system 
the tool can be used to read the key token from the transmitted file and store 
it into the active PKDS or CKDS. The tokens are referenced by label.

The format of the command is illustrated below:

Syntax

KEYXFER   OPER, LABEL, DSN,  OPTION



OPER  = READ_PKDS reads from the transmitted data set

 WRITE_PKDS writes to the transmitted data set

 READ_CKDS reads from the transmitted data set

 WRITE_CKDS writes to the transmitted data set

LABEL = label of PKDS or CKDS record to be retreived/stored

DSN   = name of data set holding the token

OPTION= OVERWRITE a label in the PKDS or CKDS.

 If OVERWRITE is specified in the option

 field then an existing label will

 be overwritten with the token from the

 transmitted data set.

DATA SET: A PS or PDS data set can be used. An LRECL=80 is recommended, but not 
required The information stored in the KEYXFER data set consists of the 
following: Date KDS label Length of token Token Notes External key tokens can 
be received on any ICSF system. If the key token is an internal key token (see 
ICSF Application Programmers Guide) then it is encrypted under the ICSF master 
key of the system. Transferring the key token requires that the receiving 
systems use the same ICSF master key.

If ICSF services are RACF protected (CSFSERV) then access will be required by 
the user for the CSNDKRC, CSNDKRR, and CSNDKRW services for PKDS transfers or 
CSNBKRC, CSNBKRR and CSNBKRW for CKDS transfers.

Samples

•   Write the key token stored in the active PKDS under the label 
PKDS.KEY.LABEL to the data set TEMP.MEM

KEYXFER WRITE_PKDS, PKDS.KEY.LABEL, TEMP.MEM

•   Read the key token contained in the data set TEMP.MEM and write the 
token to the active PKDS under the label PKDS.KEY.LABEL. (If the label already 
exists in the PKDS the operation will fail.)

KEYXFER READ_PKDS, PKDS.KEY.LABEL, TEMP.MEM

•   Read the key token contained in the data set TEMP.MEM and write the 
token to the active PKDS under the label PKDS.KEY.LABEL (If the label already 
exists in the PKDS the token for that label will be overwritten.)

KEYXFER READ_PKDS, PKDS.KEY.LABEL, TEMP.MEM, OVERWRITE

•   Read the key token contained in the data set TEMP.MEM and write the 
token to the active PKDS. Since no PLABEL was specified the label Contained in 
the file is used as the label for the token on the new system.

KEYXFER READ_PKDS, , TEMP.MEM

•   Write the key 

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[David Spiegel]

Hi Peter,
How about this situation ...
I am part of a team of people who plan maintenance upgrades many months 
in advance.

There is no possibility of IPL (for many of the maintenance upgrades).
All Batch is held (other than implementation jobs); DFSMShsm, CICS, IMS 
and DB2 are down.

TSO is limited to implementers.
SCSQAUTH (an MQ LNKLSTd Dataset) is emptied, its contents replaced and 
LLA is REFRESHd.
MQ, CICS, IMS and DB2 are started and tested by implementers and then by 
the customer.
After everyone signs off, it's back to "business as usual" and Batch is 
restarted.


Do you see any holes in this approach?

Thanks and regards,
David

On 2020-10-19 09:46, Peter Relson wrote:

You delete members (let alone delete all members) from any LNKLST data set
at your own risk. If you're going to do that, you'd better not have LLA
active.
Maybe you get away with it with LLA up and a refresh. That doesn't mean it
worked or didn't leave you undesirably exposed.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEBPDSE (was: emptying a PDS ...)

[Tabari Alexander]

> Yes. That doesn't mean that there are no concurrency issues.

(Sorry for the double post)

You are correct on the first part. PDSE is aware of any extents that are added 
to the data set while it is open. This is true both for opens on the same 
system and opens on different systems within the sysplex, with the latter only 
enabled with PDSE Extended mode sharing.

Tabari

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Batch SFTP without client keys or USS files?

[Kurt Quackenbush]

On 10/16/2020 5:10 PM, Wendell Lovewell wrote:

Is this a typo?


Just a reminder: I'm going from a z/OS sftp client to a non-z/os ftp server 
where I can't store user keys.
Do you really mean you are connecting to a non-z/OS *FTP* server?  Or do 
you mean an *sftp* server?  'Cuz if the former, then that's the problem.


Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Peter Relson]

You delete members (let alone delete all members) from any LNKLST data set 
at your own risk. If you're going to do that, you'd better not have LLA 
active.
Maybe you get away with it with LLA up and a refresh. That doesn't mean it 
worked or didn't leave you undesirably exposed.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Shopz Question

[Richards, Robert B.]

Marna,

Thank you for taking the time to respond. I was of the opinion that I was 
obviously doing something wrong as I only saw 5.5 as an upgrade path. I worked 
with a support engineer after opening a SR (SEV3) on the issue and based on the 
error I am seeing, it may be a combination of my authority level *and* an 
entitlement issue.

Curiously though, what is the difference on Shopz that enables me to order via 
a z/OSMF-packaged ServerPac versus the original ServerPac dialog radio button? 
I do not see the z/OSMF version as a choice. It that now the default?

Bob

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Marna WALLE
Sent: Saturday, October 17, 2020 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz Question

Robert,
I might be a little confused as to what you were looking for...  I just logged 
onto Shopz, and I can order CICS TS V5.6 [5655-Y04] on a ServerPac - AND I 
could even get that ServerPac packaged for a z/OSMF installation method should 
I wish.

Is this only an entitlement question, or it is a CBPDO vs ServerPac question?

I'd like to encourage all folks, who are ordering any CICS or CICS program 
product, to order it via a z/OSMF-packaged ServerPac.

Thanks,
Marna WALLE
z/OS System Installation
IBM Poughkeepsie

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

IBM KEYXFER rexx

[Dave Jousma]

All,

Do any of you have a copy of IBM AS-IS utility “KEYXFER”?   The copy I have is 
from 2006, was updated in 2018.   IBM has moved all their stuff into GITHUB 
now, and the README is there, but not the REXX code.   The code also used to 
live at ftp://ftp.software.ibm.com/s390/zos/tools/keyxfer/.  I'm able to get to 
the site, but cant download anything.  

FYI, this utility is for exporting/importing PKDS keys out of ICSF.

I do have a ticket open with IBM on this, but they seem to be dragging their 
feet trying to put it back out on GITHUB.

If anyone has a copy, I’d appreciate someone sending it to me?



For the curious, here is the readme

keyxfer
A Key Transfer Tool
Introduction
The key transfer tool (KEYXFER) is a REXX exec that runs on MVS. KEYXFER 
facilitates the transfer of PKDS or CKDS key tokens between systems that use 
the Integrated Cryptographic Services Facility (ICSF).
The KEYXFER tool assumes the following:
1.  ICSF is running on the systems involved in the key transfer
2.  ICSF has an active Key Data Set (CKDS/PKDS)
For a PKA key token transfer the tool retrieves the token from the active PKDS 
and writes it to a data set (file). For a symmetric key token transfer the tool 
retrieves the token from the active CKDS and writes it to a data set (file).
The data set can then be transmitted to any number of systems. On each system 
the tool can be used to read the key token from the transmitted file and store 
it into the active PKDS or CKDS. The tokens are referenced by label.
The format of the command is illustrated below:
Syntax
KEYXFER   OPER, LABEL, DSN,  OPTION

OPER  = READ_PKDS reads from the transmitted data set
 WRITE_PKDS writes to the transmitted data set
 READ_CKDS reads from the transmitted data set
 WRITE_CKDS writes to the transmitted data set
LABEL = label of PKDS or CKDS record to be retreived/stored
DSN   = name of data set holding the token
OPTION= OVERWRITE a label in the PKDS or CKDS.
 If OVERWRITE is specified in the option 
 field then an existing label will
 be overwritten with the token from the
 transmitted data set.
DATA SET: A PS or PDS data set can be used. An LRECL=80 is recommended, but not 
required The information stored in the KEYXFER data set consists of the 
following: Date KDS label Length of token Token
Notes
External key tokens can be received on any ICSF system. If the key token is an 
internal key token (see ICSF Application Programmers Guide) then it is 
encrypted under the ICSF master key of the system. Transferring the key token 
requires that the receiving systems use the same ICSF master key.
If ICSF services are RACF protected (CSFSERV) then access will be required by 
the user for the CSNDKRC, CSNDKRR, and CSNDKRW services for PKDS transfers or 
CSNBKRC, CSNBKRR and CSNBKRW for CKDS transfers.
Samples
•   Write the key token stored in the active PKDS under the label 
PKDS.KEY.LABEL to the data set TEMP.MEM
KEYXFER WRITE_PKDS, PKDS.KEY.LABEL, TEMP.MEM
•   Read the key token contained in the data set TEMP.MEM and write the 
token to the active PKDS under the label PKDS.KEY.LABEL. (If the label already 
exists in the PKDS the operation will fail.)
KEYXFER READ_PKDS, PKDS.KEY.LABEL, TEMP.MEM
•   Read the key token contained in the data set TEMP.MEM and write the 
token to the active PKDS under the label PKDS.KEY.LABEL (If the label already 
exists in the PKDS the token for that label will be overwritten.)
KEYXFER READ_PKDS, PKDS.KEY.LABEL, TEMP.MEM, OVERWRITE
•   Read the key token contained in the data set TEMP.MEM and write the 
token to the active PKDS. Since no PLABEL was specified the label Contained in 
the file is used as the label for the token on the new system.
KEYXFER READ_PKDS, , TEMP.MEM
•   Write the key token stored in the active CKDS under the label 
CKDS.KEY.LABEL to the data set TEMP.MEM
KEYXFER WRITE_CKDS, CPKDS.KEY.LABEL, TEMP.MEM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Manfred Lotz]

On Mon, 19 Oct 2020 15:07:01 +0200
Manfred Lotz  wrote:

> On Fri, 16 Oct 2020 18:53:39 +
> "Sasso, Len"  wrote:
> 
> > Anyone know if a Checksum/Md5 file can be created on a IBM
> > Mainframe?
> > 
> > If so, how?
> > 
> >   
> 
> I may be a bit late to the party but if you happen to have z/OS 2.4 or
> z/OS 2.3 then there is
> 
> APPLICABLE COMPONENT LEVEL/SU:
> R7C0 PSY UJ03195 UP20/06/24 P F006
> R7B0 PSY UJ03194 UP20/06/24 P F006
> 
> Functionality
> 
> The new cryptographic hash utilities, including md5, rmd160, sha1,
> sha224, sha256, sha384 and sha512, use the ICSF One-Way Hash Generate
> callable service to generate cryptographic hash for input files
> respectively. The utilities can check cryptographic hashes read from
> input files. MVS sequential data sets are supported as well.
> 
> In z/OS UNIX they can be found in the /bin directory.
> 
> /bin/md5
> /bin/rmd160
> /bin/sha1
> /bin/sha224
> /bin/sha256
> /bin/sha384
> /bin/sha512
> 
> You find documentation in the z/OS Version 2 Release 4 UNIX System
> Services Command Reference here https://www-01.ibm.
> com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa232280?OpenDocument
> 
> 

Sorry for the bad formatting of the link in my previous reply

https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa232280?OpenDocument

-- 
Manfred

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Manfred Lotz]

On Fri, 16 Oct 2020 18:53:39 +
"Sasso, Len"  wrote:

> Anyone know if a Checksum/Md5 file can be created on a IBM Mainframe?
> 
> If so, how?
> 
> 

I may be a bit late to the party but if you happen to have z/OS 2.4 or
z/OS 2.3 then there is

APPLICABLE COMPONENT LEVEL/SU:
R7C0 PSY UJ03195 UP20/06/24 P F006
R7B0 PSY UJ03194 UP20/06/24 P F006

Functionality

The new cryptographic hash utilities, including md5, rmd160, sha1,
sha224, sha256, sha384 and sha512, use the ICSF One-Way Hash Generate
callable service to generate cryptographic hash for input files
respectively. The utilities can check cryptographic hashes read from
input files. MVS sequential data sets are supported as well.

In z/OS UNIX they can be found in the /bin directory.

/bin/md5
/bin/rmd160
/bin/sha1
/bin/sha224
/bin/sha256
/bin/sha384
/bin/sha512

You find documentation in the z/OS Version 2 Release 4 UNIX System
Services Command Reference here https://www-01.ibm.
com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa232280?OpenDocument


-- 
Hope this helps,
Manfred

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Checksum/Md5 file

[Jantje.]

On Fri, 16 Oct 2020 18:53:39 +, Sasso, Len  wrote:

>Anyone know if a Checksum/Md5 file can be created on a IBM Mainframe?
Yes.


>If so, how?

package com.jantje.checksum;

import com.ibm.jzos.FileFactory;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;


public class MD5CheckSum {

public static byte[] createChecksum(String filename) throws IOException, 
NoSuchAlgorithmException {

InputStream inputStream = FileFactory.newInputStream(filename);
//InputStream inputStream = new FileInputStream(filename);

byte[] buffer = new byte[1024];
MessageDigest complete = MessageDigest.getInstance("MD5");
int numRead;
do {
numRead = inputStream.read(buffer);
if (numRead > 0) {
complete.update(buffer, 0, numRead);
}
} while (numRead != -1);
inputStream.close();
return complete.digest();
}

public static String getMD5Checksum(String filename) throws IOException, 
NoSuchAlgorithmException {
byte[] b = createChecksum(filename);
String result = "";
for (int i = 0; i < b.length; i++) {
result +=
Integer.toString((b[i] & 0xff) + 0x100, 16).substring(1);
}
return result;
}

public static void getMD5CheckSums(String parmFileName) throws IOException, 
NoSuchAlgorithmException {

BufferedReader fileNames = FileFactory.newBufferedReader(parmFileName);
try {
String datasetName;
while ((datasetName = fileNames.readLine()) != null) {
System.out.print(String.format("%1$-50s", datasetName));
System.out.println(getMD5Checksum(datasetName));
}
} finally {
fileNames.close();
}
}

public static void main(String args[]) {
try {
getMD5CheckSums(args[0]);
} catch (Exception e) {
e.printStackTrace();
}
}
}


Cheers,

Jantje.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down

[Binyamin Dissen]

On Sat, 17 Oct 2020 18:04:38 -0500 Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

:>On Sat, 17 Oct 2020 17:48:57 -0500, Steve Horein wrote:

:>>Good ole IDCAMS anyone?
:>>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/dgt3i231.htm
 
:>How might one delete a PDS member named "*   "?

Modify the program that created it. STOW D is easier than STOW A.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN