Re: LOAD/LINK exit

[Steve Thompson]

That would be wonderful. 

Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct 
mistaks 


> On Jun 13, 2019, at 11:26 PM, Jim Mulder  wrote:
> 
>  CSVLLIX1 works only for LLA-managed libraries.  I was still looking for 
> the more comprehensive CSVFETCH exit, which was added in z/OS 2.2.
> Perhaps we should consider mentioning CSVFETCH in the 
> MVS Installation Exits book, with a pointer to the book where CSVFETCH 
> is documented.
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY
> 
> 
> "IBM Mainframe Discussion List"  wrote on 
> 06/13/2019 06:47:09 PM:
> 
>> From: "Charles Mills" 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date: 06/13/2019 11:19 PM
>> Subject: Re: LOAD/LINK exit
>> Sent by: "IBM Mainframe Discussion List" 
>> 
>> @Jim, does CSVLLIX1 satisfy the OP's request? I read that "CSVLLIX1 is
>> called each time a program fetch occurs for LLA managed members."
>> 
>> Does not the OP want to be aware of *every* LOAD and FETCH, even those 
> that
>> do not involve LLA-managed members? He specifically says the LLA exits
>> appear not to be sufficient.
>> 
>> Or am I missing something?
>> 
>> Charles
> 
> 
> 
> --
> 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: LOAD/LINK exit

[Jim Mulder]

  CSVLLIX1 works only for LLA-managed libraries.  I was still looking for 
the more comprehensive CSVFETCH exit, which was added in z/OS 2.2.
Perhaps we should consider mentioning CSVFETCH in the 
MVS Installation Exits book, with a pointer to the book where CSVFETCH 
is documented.
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on 
06/13/2019 06:47:09 PM:

> From: "Charles Mills" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/13/2019 11:19 PM
> Subject: Re: LOAD/LINK exit
> Sent by: "IBM Mainframe Discussion List" 
> 
> @Jim, does CSVLLIX1 satisfy the OP's request? I read that "CSVLLIX1 is
> called each time a program fetch occurs for LLA managed members."
> 
> Does not the OP want to be aware of *every* LOAD and FETCH, even those 
that
> do not involve LLA-managed members? He specifically says the LLA exits
> appear not to be sufficient.
> 
> Or am I missing something?
> 
> Charles



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

Re: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

[Mike Schwab]

Would an IND$FILE transfer work with the CRLF option without the ASCII option?

On Fri, Jun 14, 2019 at 12:49 AM Farley, Peter x23353
 wrote:
>
> In fact I did try it, and Rexx ignored the LRECL=200, as expected.  As I said 
> in an earlier reply, the longest actual record (block) size was 222.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Seymour J Metz
> Sent: Thursday, June 13, 2019 5:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
> script?
>
> I would hope that REXX would ignore LRECL for RECFM=U. If you try it, please 
> let us know what happens.
> --
> 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: Thursday, June 13, 2019 5:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
> script?
>
> On Thu, 13 Jun 2019 21:03:17 +, Seymour J Metz wrote:
>
> >> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998)
> >
> >Despite the LRECL, I take this to mean that the records can be up to 27998.
> >
> What do Rexx (and other utilities) do if a record/block exceeds 200?  Either 
> for input or output.
>
> --
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

[Farley, Peter x23353]

In fact I did try it, and Rexx ignored the LRECL=200, as expected.  As I said 
in an earlier reply, the longest actual record (block) size was 222.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, June 13, 2019 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

I would hope that REXX would ignore LRECL for RECFM=U. If you try it, please 
let us know what happens.
--
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: Thursday, June 13, 2019 5:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

On Thu, 13 Jun 2019 21:03:17 +, Seymour J Metz wrote:

>> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998)
>
>Despite the LRECL, I take this to mean that the records can be up to 27998.
>
What do Rexx (and other utilities) do if a record/block exceeds 200?  Either 
for input or output.

-- 

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

[Farley, Peter x23353]

For RECFM=U it is not the LRECL that governs I/O behavior it is the BLKSIZE (I 
believe that LRECL is ignored for U), so in this particular case anything up to 
27998 would be legal and allowed.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, June 13, 2019 5:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

On Thu, 13 Jun 2019 21:03:17 +, Seymour J Metz wrote:

>> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998)
>
>Despite the LRECL, I take this to mean that the records can be up to 27998.
> 
What do Rexx (and other utilities) do if a record/block exceeds 200?  Either 
for input or output.

-- 

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

[Farley, Peter x23353]

In principle I agree, but in this case recording the maximum length of all 
records during the Rexx conversion process showed none longer than 222.

Whether the vendor records will always stay within that limit is of course 
unknown to me since I do not know the vendor or the product.

The team actually using the vendor and their file have it In their court now, 
so my part is done.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, June 13, 2019 5:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998)

Despite the LRECL, I take this to mean that the records can be up to 27998.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Wednesday, June 12, 2019 7:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

Hi Sri,

Tried that, the first step works without a problem but the second one fails 
with a SYNAD error, "WRNG.LN.RECORD".  I found out that some of the records are 
actually up to 225 or so bytes, and changed the "200" values to 250 but still 
got the SYNAD error.

The actual physical records are varying length but with no BDW/RDW prefix, the 
physical blocks are no more than about 225 bytes long, some as short as 50 
bytes or so.

A Rexx script did the job with no errors though.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Wednesday, June 12, 2019 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

EXTERNAL EMAIL

> We have a vendor-generated file that comes in with
> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998) (don't ask why please, this DCB 
> setting is out of our hands).

Peter,

Give this JCL a try and see if it works for you

//***
//* COPY RECFM=U TO MATCH THE LRECL AND BLKSIZE *
//***
//STEP0100 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INP  DD DISP=SHR,DSN=Your input RECFM=U file,
//RECFM=U,LRECL=200,BLKSIZE=27998
//OUT  DD DSN=&,DISP=(,PASS),SPACE=(CYL,(5,5),RLSE),
//RECFM=U,BLKSIZE=27800
//SYSINDD *
  REPRO INFILE(INP) OUTFILE(OUT)
//*
//***
//* OVERRIDE THE LRECL AND RECFM FOR THE COPIED JCL TO FORMAT   *
//* IT TO 200 BYTE output   *
//***
//STEP0200 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INP  DD DISP=(OLD,PASS),DSN=&,LRECL=200,RECFM=FB,BLKSIZE=27800
//OUT  DD SYSOUT=*,LRECL=200,RECFM=FB,BLKSIZE=27800
//SYSINDD *
  REPRO INFILE(INP) OUTFILE(OUT)
//*


Thanks,
Kolusu
-- 

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: LOAD/LINK exit

[Michael Stein]

On Thu, Jun 13, 2019 at 02:10:32PM -0400, Steve Thompson wrote:
> I seem to recall that there is a way to look at a LOAD/FETCH via an exit.

csvfetch

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa800/csvfetch01.htm

  The CSVFETCH exit provides information about the fetching (or unfetching)
  of a module. The exit is primarily intended to be used as part of
  monitoring (whether for reporting or debugging). The exit will be called
  holding the local lock. The exit routine must not release the local lock.

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

Re: SYS1.MIGLIB and LNKLST

[Mark Zelden]

On Tue, 11 Jun 2019 14:22:51 -0500, John McKown  
wrote:

>On Tue, Jun 11, 2019 at 2:19 PM Carmen Vitullo  wrote:
>
>> I would not do anything to remove ENQ from the running systems MIGLIB
>> what I normally do is on the target volume
>> 1) allocate a new SYS1.MIGLIB.NEW - larger primary and more dir blocks
>> 2) copy the existing target MIGLIB to the new MIGLIB
>> 3) if you have authority you should be able to RENAME ON THAT TARGET
>> VOLUME the SYS1.MIGLIB to SYS1.MIGLIB.OLD, or something
>>
>
>IIRC, you can use IEHPROGM to do that. I don't think it does an ENQ on the
>DSN.
>

Isn't ISPF 3.4 rename a lot easier?   I've been doing that instead of using 
IEHPROGM
or programs like BYPASSNQ / DELNOENQ since the rename while ENQ facility became
available in OS/390 R10 (seems like a life time ago now!). You just need RACF 
(SAF)
access to STGADMIN.DPDSRN.** (or STGADMIN.DPDSRN.dsn_to_rename) in the
FACILITY class. 

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idas300/rname.htm

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD/LINK exit

[Charles Mills]

I think I can say with some confidence that nothing in SMF will tell you every 
LOAD and FETCH, or every module loaded or fetched.

SMF 14 will give you every BSAM, QSAM and BPAM CLOSE INPUT, which will give you 
every load library -- and a whole lot more, unfortunately.

SMF 30 now gives you the "high CPU time" module name, but that is hardly an 
answer.

Of course, some modules might be in zFS ...

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: Thursday, June 13, 2019 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LOAD/LINK exit

Folks:

I seem to recall that there is a way to look at a LOAD/FETCH via 
an exit.

But CSV also stands for comma separated values among other things 
and I keep getting a large number of false positives. None 
seemingly to do with the MVS Contents Supervisor (maker of CDE 
chains and the like, right?).

I've been looking at the MVS Installation Exits and some other 
books for a way to do what I need.

We know that SMF records are produced for the PGM= module/event 
in a JOB. We know of no such record produced for LOAD and 
equivalent.

What we need is a way to see what is being pulled into address 
spaces. We are trying to find all the subroutines being used. And 
I don't think STEPLIBs are included with the LLA Exits.

Now we have a way to scan all the Linkedit listings (that we 
capture), but we are looking for what one might call "dynamic" 
loads.

It is an effort to do self-audit and over time get rid of 
software (especially in-house written OLD subroutines) we aren't 
using/don't need.

I'm sure we aren't the first to need this.

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

Re: LOAD/LINK exit

[Charles Mills]

@Jim, does CSVLLIX1 satisfy the OP's request? I read that "CSVLLIX1 is
called each time a program fetch occurs for LLA managed members."

Does not the OP want to be aware of *every* LOAD and FETCH, even those that
do not involve LLA-managed members? He specifically says the LLA exits
appear not to be sufficient.

Or am I missing something?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Thursday, June 13, 2019 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOAD/LINK exit

CSVLLIX1

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

Re: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

[Seymour J Metz]

I would hope that REXX would ignore LRECL for RECFM=U. If you try it, please 
let us know what happens.


--
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: Thursday, June 13, 2019 5:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

On Thu, 13 Jun 2019 21:03:17 +, Seymour J Metz wrote:

>> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998)
>
>Despite the LRECL, I take this to mean that the records can be up to 27998.
>
What do Rexx (and other utilities) do if a record/block exceeds 200?  Either
for input or output.

-- gil

--
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: VTOC reading

[Mike Shaw]

On 6/13/2019 1:43 PM, Lennie Dymoke-Bradshaw wrote:

Rather than do BSAM reads I think it is better to make use of the CVAF macros. 
These make use of the VTOC Index to assist processing. This will present you 
the data set names in alphabetical order.


CVAF is much slower than BSAM, alphabetical order or not. EXCP with 
chained CCWs is much faster, then just sort the DSNs yourself.


Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

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

Re: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

[Paul Gilmartin]

On Thu, 13 Jun 2019 21:03:17 +, Seymour J Metz wrote:

>> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998) 
>
>Despite the LRECL, I take this to mean that the records can be up to 27998.
> 
What do Rexx (and other utilities) do if a record/block exceeds 200?  Either
for input or output.

-- gil

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

Re: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

[Seymour J Metz]

> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998) 

Despite the LRECL, I take this to mean that the records can be up to 27998.


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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Wednesday, June 12, 2019 7:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

Hi Sri,

Tried that, the first step works without a problem but the second one fails 
with a SYNAD error, "WRNG.LN.RECORD".  I found out that some of the records are 
actually up to 225 or so bytes, and changed the "200" values to 250 but still 
got the SYNAD error.

The actual physical records are varying length but with no BDW/RDW prefix, the 
physical blocks are no more than about 225 bytes long, some as short as 50 
bytes or so.

A Rexx script did the job with no errors though.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Wednesday, June 12, 2019 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

EXTERNAL EMAIL

> We have a vendor-generated file that comes in with
> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998) (don't ask why please, this
> DCB setting is out of our hands).

Peter,

Give this JCL a try and see if it works for you

//***
//* COPY RECFM=U TO MATCH THE LRECL AND BLKSIZE *
//***
//STEP0100 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INP  DD DISP=SHR,DSN=Your input RECFM=U file,
//RECFM=U,LRECL=200,BLKSIZE=27998
//OUT  DD DSN=&,DISP=(,PASS),SPACE=(CYL,(5,5),RLSE),
//RECFM=U,BLKSIZE=27800
//SYSINDD *
  REPRO INFILE(INP) OUTFILE(OUT)
//*
//***
//* OVERRIDE THE LRECL AND RECFM FOR THE COPIED JCL TO FORMAT   *
//* IT TO 200 BYTE output   *
//***
//STEP0200 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INP  DD DISP=(OLD,PASS),DSN=&,LRECL=200,RECFM=FB,BLKSIZE=27800
//OUT  DD SYSOUT=*,LRECL=200,RECFM=FB,BLKSIZE=27800
//SYSINDD *
  REPRO INFILE(INP) OUTFILE(OUT)
//*


Thanks,
Kolusu


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

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
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: What happens if an SMF exit modifies the SMF record?

[Seymour J Metz]

> For example, without having done an exhaustive analysis, I'd guess 
> that all the PI fields in the CVT other than CVTUSER are intended to
> be read-only. 

It's also not safe to assume that you're the only one modifying, e.g.,
CVTUSER, TCBUSER.

BTDT,GTS (no tee shirt, just the scars.)


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


From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Thursday, June 13, 2019 8:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What happens if an SMF exit modifies the SMF record?


> due to security and integrity of the SMF records themselves, IBM is not
talking much about it.

Security by obscurity?


No. These are updates by authorized programs. Neither security nor
integrity is a factor.

One ought to be asking for what reason an exit routine would update an SMF
record. Can it? Sure. Should it? Usually not.

Most programming interfaces (far from all, of course) are intended to be
for read-only but only rarely is that explicitly stated. For example,
without having done an exhaustive analysis, I'd guess that all the PI
fields in the CVT other than CVTUSER are intended to be read-only.
Probably one ought to go with "if it's not obvious that a field is
intended to be written into, then don't write into it (or ask for the
documentation to make it clear one way or another)"

Long ago I had hoped to gain traction for indicating that a PI field was
read-only vs read/write (such as placing that information within the
external classification section of the macro prolog which in turn is used
within the data areas books). Obviously that hope did not come to
fruition.

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: SYS1.MIGLIB and LNKLST

[Seymour J Metz]

Of course IBM never adds new elements in a PTF. Believe that and I'll tell you 
another. BTDT,GTS (no tee shirt, just the scars.)


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


From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Thursday, June 13, 2019 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

To what end?  Directories don't accumulate gas.

sas

On Wed, Jun 12, 2019 at 2:27 PM Seymour J Metz  wrote:

> Don't forget to over-allocate the directory for those libraries that are
> still PDS.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3

--
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: VTOC reading

[Seymour J Metz]

AMASPZAP changes 'FORMAT4.DSCB' to 44x'04'; I don't know of any other IBM 
routine that looks for that name, although there are probably lots on the CBT 
tape. If you're writing a program then there are better ways to access the VTOC 
than opening 44'X04'.


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


From: IBM Mainframe Discussion List  on behalf of 
Bill Ogden 
Sent: Thursday, June 13, 2019 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: VTOC reading

My old memory is failing in too many areas.  Long ago, I seem to recall,
there was an easy way to read a VTOC with simple JCL using a "magic"
DSNAME - obviously not 040404... for JCL, but some other name.  Is my
memory correct?  What is the DSNAME?  While playing with google I cannot
find anything, but I might be using the wrong search words.

Bill Ogden


--
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: LOAD/LINK exit

[Seymour J Metz]

My first take was to use GTF, but it's probably cleaner to use an exit that MVS 
calls regardless of which SVC is used to fetch the module.


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


From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Thursday, June 13, 2019 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LOAD/LINK exit

Folks:

I seem to recall that there is a way to look at a LOAD/FETCH via
an exit.

But CSV also stands for comma separated values among other things
and I keep getting a large number of false positives. None
seemingly to do with the MVS Contents Supervisor (maker of CDE
chains and the like, right?).

I've been looking at the MVS Installation Exits and some other
books for a way to do what I need.

We know that SMF records are produced for the PGM= module/event
in a JOB. We know of no such record produced for LOAD and
equivalent.

What we need is a way to see what is being pulled into address
spaces. We are trying to find all the subroutines being used. And
I don't think STEPLIBs are included with the LLA Exits.

Now we have a way to scan all the Linkedit listings (that we
capture), but we are looking for what one might call "dynamic"
loads.

It is an effort to do self-audit and over time get rid of
software (especially in-house written OLD subroutines) we aren't
using/don't need.

I'm sure we aren't the first to need this.

And I do not want to go write an SVC intercept program to look
for things like this Shades of DUO360... ouch.

If you have any suggestions on this, or if you know of an ISV
product that will do this, I think my management will be interested.

Regards,
Steve Thompson

--
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: WLM Service Definition Formatter

[Paul Gilmartin]

On Wed, 12 Jun 2019 15:31:37 +, Herring, Bobby wrote:

>I have used IBM's WLM Service Definition Formatter spreadsheet tool for years. 
>It's just an Excel spreadsheet with lots of macros under the covers.
>
>It was a download from the WLM web page.
>
>Mine is an older version and has quit working. The last time it worked 
>correctly was last fall.
>
>I went to download a new copy but that download no longer works.
>
>Has anyone else tried downloading this tool and was it successful?
>
>Page:  https://www.ibm.com/it-infrastructure/z/zos-workload-management
>
>Bottom of the page under Service Definition Formatter
>
I had to open "Tools for WLM Analysis", then I can DL from :
ftp://public.dhe.ibm.com/eserver/zseries/zos/wlm/SetUpSvDef.V502.exe

504 $ cksum SetUp*
2530193812 207378 SetUpSvDef.V502.exe
507 $ file SetUp*
SetUpSvDef.V502.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

But many enterprises dread ".exe", fearing an intrusion.

-- gil

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

Re: LOAD/LINK exit

[Gord Tomlin]

On 2019-06-13 14:10, Steve Thompson wrote:

if you know of an ISV product that will do this


The Reference Tracker component of eventACTION does this.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: WLM Service Definition Formatter

[Herring, Bobby]

I tried Chrome, IE and Firefox. Also WS FTP LE and FileZilla.

Thanks, Bobby

From: IBM Mainframe Discussion List  On Behalf Of 
Alan Young
Sent: Wednesday, June 12, 2019 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] WLM Service Definition Formatter

Yes, it is a 207,378 byte file. I was able to extract the spreadsheet, open it 
and load a definition. Is there an anti-virus or malware detection product 
blocking the download? Are you able to try to download with a ftp client or a 
different browser?

-Original Message-
>From: "Herring, Bobby" mailto:bherr...@txfb-ins.com>>
>Sent: Jun 12, 2019 12:06 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: WLM Service Definition Formatter
>
>I had someone at our help desk look at it and he thought his download worked, 
>too. But the file was 0kb.
>
>Did you get an actual exe file to download?
>
>I can download all the other four files on the site, just not that one.
>
>Thanks, Bobby
>
>From: IBM Mainframe Discussion List 
>mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Alan 
>Young
>Sent: Wednesday, June 12, 2019 11:21 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: [IBM-MAIN] WLM Service Definition Formatter
>
>The download works here. I do notice it is a ftp link and not an http(s) link. 
>Is it possible your organization is blocking ftp access?
>
>
>-Original Message-
>>From: "Herring, Bobby" 
>>mailto:bherr...@txfb-ins.com>>
>>Sent: Jun 12, 2019 8:31 AM
>>To: 
>>IBM-MAIN@LISTSERV.UA.EDU>
>>Subject: WLM Service Definition Formatter
>>
>>I have used IBM's WLM Service Definition Formatter spreadsheet tool for 
>>years. It's just an Excel spreadsheet with lots of macros under the covers.
>>
>>It was a download from the WLM web page.
>>
>>Mine is an older version and has quit working. The last time it worked 
>>correctly was last fall.
>>
>>I went to download a new copy but that download no longer works.
>>
>>Has anyone else tried downloading this tool and was it successful?
>>
>>Page: 
>>https://www.ibm.com/it-infrastructure/z/zos-workload-management>
>>
>>Bottom of the page under Service Definition Formatter
>>
>>Bobby Herring
>>Texas Farm Bureau Insurance
>>Waco, TX 76710
>>[http://www.txfb-ins.com/TFBICImages/email.gif>]
>>WWW.TXFB-INS.COM>>>
>>
>>CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is 
>>covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 
>>2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you 
>>in error, do not read it. If you are not the intended recipient, you are 
>>hereby notified that any retention, dissemination, distribution, or copying 
>>of this communication is strictly prohibited. Please reply to the sender that 
>>you have received the message in error, then delete it. Thank you.
>>
>>--
>>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
>[http://www.txfb-ins.com/TFBICImages/email.gif]
>WWW.TXFB-INS.COM>
>
>CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is 
>covered 

Re: LOAD/LINK exit

[Jim Mulder]

CSVLLIX1


Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on 
06/13/2019 02:10:32 PM:

> From: "Steve Thompson" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/13/2019 03:17 PM
> Subject: LOAD/LINK exit
> Sent by: "IBM Mainframe Discussion List" 
> 
> Folks:
> 
> I seem to recall that there is a way to look at a LOAD/FETCH via 
> an exit.
> 
> But CSV also stands for comma separated values among other things 
> and I keep getting a large number of false positives. None 
> seemingly to do with the MVS Contents Supervisor (maker of CDE 
> chains and the like, right?).
> 
> I've been looking at the MVS Installation Exits and some other 
> books for a way to do what I need.
> 
> We know that SMF records are produced for the PGM= module/event 
> in a JOB. We know of no such record produced for LOAD and 
> equivalent.
> 
> What we need is a way to see what is being pulled into address 
> spaces. We are trying to find all the subroutines being used. And 
> I don't think STEPLIBs are included with the LLA Exits.
> 
> Now we have a way to scan all the Linkedit listings (that we 
> capture), but we are looking for what one might call "dynamic" 
> loads.
> 
> It is an effort to do self-audit and over time get rid of 
> software (especially in-house written OLD subroutines) we aren't 
> using/don't need.
> 
> I'm sure we aren't the first to need this.
> 
> And I do not want to go write an SVC intercept program to look 
> for things like this Shades of DUO360... ouch.
> 
> If you have any suggestions on this, or if you know of an ISV 
> product that will do this, I think my management will be interested.



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

Re: LOAD/LINK exit

[graeme]

The Dorana product from Ubiquity did exactly the sort of audit reporting you’re 
looking for, with the same end objectives, and for more than just z/OS. 
Softaudit was another product with similar objectives. I think Softaudit ended 
up being owned by IBM.
Dorana was acquired by IBM some years ago and became some Tivoli component 
who’s name escapes me. I think its direction/emphasis may have been changed by 
IBM.

Cheers to all
Graeme Gibson

> On 13 Jun 2019, at 20:10, Steve Thompson  wrote:
> 
> Folks:
> 
> I seem to recall that there is a way to look at a LOAD/FETCH via an exit.
> 
> But CSV also stands for comma separated values among other things and I keep 
> getting a large number of false positives. None seemingly to do with the MVS 
> Contents Supervisor (maker of CDE chains and the like, right?).
> 
> I've been looking at the MVS Installation Exits and some other books for a 
> way to do what I need.
> 
> We know that SMF records are produced for the PGM= module/event in a JOB. We 
> know of no such record produced for LOAD and equivalent.
> 
> What we need is a way to see what is being pulled into address spaces. We are 
> trying to find all the subroutines being used. And I don't think STEPLIBs are 
> included with the LLA Exits.
> 
> Now we have a way to scan all the Linkedit listings (that we capture), but we 
> are looking for what one might call "dynamic" loads.
> 
> It is an effort to do self-audit and over time get rid of software 
> (especially in-house written OLD subroutines) we aren't using/don't need.
> 
> I'm sure we aren't the first to need this.
> 
> And I do not want to go write an SVC intercept program to look for things 
> like this Shades of DUO360... ouch.
> 
> If you have any suggestions on this, or if you know of an ISV product that 
> will do this, I think my management will be interested.
> 
> Regards,
> Steve Thompson
> 
> --
> 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: Alias Listcat discrepancy betweeen sysplex'd LPARs

[Elaine Beal]

Good point but I checked and Include Additional Qualifiers is selected.
Also, in addition to my ne wdataset, there is one older one that has the same 
issue.

Thanks,
Elaine

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

LOAD/LINK exit

[Steve Thompson]

Folks:

I seem to recall that there is a way to look at a LOAD/FETCH via 
an exit.


But CSV also stands for comma separated values among other things 
and I keep getting a large number of false positives. None 
seemingly to do with the MVS Contents Supervisor (maker of CDE 
chains and the like, right?).


I've been looking at the MVS Installation Exits and some other 
books for a way to do what I need.


We know that SMF records are produced for the PGM= module/event 
in a JOB. We know of no such record produced for LOAD and 
equivalent.


What we need is a way to see what is being pulled into address 
spaces. We are trying to find all the subroutines being used. And 
I don't think STEPLIBs are included with the LLA Exits.


Now we have a way to scan all the Linkedit listings (that we 
capture), but we are looking for what one might call "dynamic" 
loads.


It is an effort to do self-audit and over time get rid of 
software (especially in-house written OLD subroutines) we aren't 
using/don't need.


I'm sure we aren't the first to need this.

And I do not want to go write an SVC intercept program to look 
for things like this Shades of DUO360... ouch.


If you have any suggestions on this, or if you know of an ISV 
product that will do this, I think my management will be interested.


Regards,
Steve Thompson

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

Re: VTOC reading

[Edward Finnell]

FILE182 is an awesome tool with references to other tools to help organize the 
windmills.* Member Original source Description (CP is command processor) 
* -|-|-- 
* BLKDISK | (CBT FILE 296) | Disk block size optimizing CP 
* COBANAL | (CBT FILE 321) | COBOL Analysis program 
* COMPARE | (CBT FILE 296) | COMPARE (based on Yale program) CP 
* COMPAREC | COMXMIT member | COMPAREC CP (Invokes SuperC compare) 
* COMPAREW | COMXMIT member | COMPAREW CP (Invokes Comparex compare) 
* DELINKI | (CBT FILE 090) | Delinker program 
* DISASM | (CBT FILE 217) | Disassembler program 
* DISKMAP | (CBT FILE 792) | DISKMAP track mapping program (EAV) 
* DSAT | (CBT FILE 296) | Disk data set attributes display CP 
* DVOL | (CBT FILE 296) | Disk free space display CP 
* DWNSPDSR | (CBT FILE 090) | Subroutine for DELINKI 
* HEL | (CBT FILE 134) | Full-screen HELP CP 
* MXI | (CBT FILE 410) | MVS eXtended Information program 
* OFFLOAD | (CBT FILE 093) | Offload PDS members to a sequential file 
* PDSLOAD | (CBT FILE 093) | Pdsload PDS members from a sequential file 
* PDSMATCH | (CBT FILE 357) | Compare directories of 2 PDS's for matches 
* RESOURCE | (CBT FILE 234) | Disassembler program for PDSE's 
* REBUILD | (CBT FILE 234) | Disassembler program for PDSE's 
* RELEASE | (CBT FILE 296) | DASD space release CP 
* REVIEW | (CBT FILE 134) | Full-screen data set display CP 
* REVSMF | (CBT FILE 134) | Subroutine for REVIEW 
* VTOC | (CBT FILE 112) | VTOC CP  

In a message dated 6/13/2019 1:03:46 PM Central Standard Time, 
stars...@mindspring.com writes:
Once we see what it is you are looking for, the right process can be identified

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

Re: VTOC reading

[Lizette Koehler]

Like all general questions,  there are lots of tools and processes to do what
you want.

So first, what kind of report are you looking for?

Something like option 3.4 but in batch?

Do you want just DSNs and VOLUMES they are on?

Do you want attributes of DSNs and volumes they are on?  


Provide a quick display of what you want to see.

Next, decide how you want it done

1) Do you want to write your own program?

2)  Do you want to use an IBM Supplied utility  like IEHLIST?

3)  Do you want to use something off the CBTTAPE.org for example


Once we see what it is you are looking for, the right process can be identified



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Lennie Dymoke-Bradshaw
> Sent: Thursday, June 13, 2019 10:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VTOC reading
> 
> Rather than do BSAM reads I think it is better to make use of the CVAF
> macros. These make use of the VTOC Index to assist processing. This will
> present you the data set names in alphabetical order.
> 
> If you are processing each DSN within the VTOC, you may need to make direct
> reads of records due to the pointers from one DSCB to another.
> 
> CVAFSEQ reads records sequentially.
> CVAFDIR reads records directly.
> CVAFDSM maps the VTOC and gives you various statistics.
> 
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  www.rsmpartners.com
> 'Dance like no one is watching. Encrypt like everyone is.'
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> svet...@ameritech.net
> Sent: 13 June 2019 17:40
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] VTOC reading
> 
> Are used to do it in programs a while ago.  First do a dynamic allocate
> Specifying a DS name of 44 characters of hex 04 for 44 characters and specify
> the valves there that you want. There is a mapping macro that describes each
> record that you can use. Do an open a read or a get as appropriate. Then your
> normal close. I can find an example late tonight if you care.
> 
> Sent from my iPhone
> 
> > On Jun 13, 2019, at 11:44, Bill Ogden  wrote:
> >
> > My old memory is failing in too many areas.  Long ago, I seem to
> > recall, there was an easy way to read a VTOC with simple JCL using a
> "magic"
> > DSNAME - obviously not 040404... for JCL, but some other name.  Is
> > my memory correct?  What is the DSNAME?  While playing with google I
> > cannot find anything, but I might be using the wrong search words.
> >
> > Bill Ogden
> >
> >
> > --
> > 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: VTOC reading

[Lennie Dymoke-Bradshaw]

Rather than do BSAM reads I think it is better to make use of the CVAF macros. 
These make use of the VTOC Index to assist processing. This will present you 
the data set names in alphabetical order.

If you are processing each DSN within the VTOC, you may need to make direct 
reads of records due to the pointers from one DSCB to another.

CVAFSEQ reads records sequentially.
CVAFDIR reads records directly.
CVAFDSM maps the VTOC and gives you various statistics.

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
'Dance like no one is watching. Encrypt like everyone is.'

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
svet...@ameritech.net
Sent: 13 June 2019 17:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VTOC reading

Are used to do it in programs a while ago.  First do a dynamic allocate 
Specifying a DS name of 44 characters of hex 04 for 44 characters and specify 
the valves there that you want. There is a mapping macro that describes each 
record that you can use. Do an open a read or a get as appropriate. Then your 
normal close. I can find an example late tonight if you care.

Sent from my iPhone

> On Jun 13, 2019, at 11:44, Bill Ogden  wrote:
> 
> My old memory is failing in too many areas.  Long ago, I seem to 
> recall, there was an easy way to read a VTOC with simple JCL using a "magic"
> DSNAME - obviously not 040404... for JCL, but some other name.  Is 
> my memory correct?  What is the DSNAME?  While playing with google I 
> cannot find anything, but I might be using the wrong search words.
> 
> Bill Ogden
> 
> 
> --
> 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: VTOC reading

[svetter]

Are used to do it in programs a while ago.  First do a dynamic allocate 
Specifying a DS name of 44 characters of hex 04 for 44 characters and specify 
the valves there that you want. There is a mapping macro that describes each 
record that you can use. Do an open a read or a get as appropriate. Then your 
normal close. I can find an example late tonight if you care.

Sent from my iPhone

> On Jun 13, 2019, at 11:44, Bill Ogden  wrote:
> 
> My old memory is failing in too many areas.  Long ago, I seem to recall, 
> there was an easy way to read a VTOC with simple JCL using a "magic" 
> DSNAME - obviously not 040404... for JCL, but some other name.  Is my 
> memory correct?  What is the DSNAME?  While playing with google I cannot 
> find anything, but I might be using the wrong search words.
> 
> Bill Ogden
> 
> 
> --
> 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: Just how secure are mainframes? | Trevor Eddolls

[R.S.]

W dniu 2019-06-12 o 18:29, Wayne Driscoll pisze:

I was one of the developers for Deadbolt, and while we were able to get the product into 
a small number of installations as an "alpha" state release, the project was 
cancelled in early 2008.


... and I remember your name from that time ;-)

Personally I thought that someone tries to tilt at windmills, however I 
saw and enterpreneur was one of BMC founders, so I changed my opinion.
Nowadays, from time perspective I again think it was doomed to failure 
from business point of view, despite of technical (dis)advantages.


BTW: Can you tell us how many people were involved in the project?
It's interesting how many people (man days) would it take to create ESM 
from scratch.


Regards
--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: VTOC reading

[Jesse 1 Robinson]

Perusing our source for the venerable ZAP command, I find these lines:

   TMFLAGS3,FULLVOLF  FULL-VOLUME ZAP? 
   BOFORCVTOC YES   
   CLC   =C'FORMAT4.DSCB',DSNAME  VTOC?
   BNE   NOTVTOC3  

   MVC   DSNAMEL(2),=H'44' 
   MVI   DSNAME,X'04' YES, CHANGE DSN  
   MVC   DSNAME+1(43),DSNAME  TO 44X'04'   
   MVC   DISPDSN,BLANKS   RESET FIELD  
   MVC   DISPDSN(8),=C'VTOC FOR'  SHOW SOMETHING GOOD  
   MVC   DISPDSN+9(6),VOLSER  MOVE IN VOLUME NAME  
   OIFLAGS2,SENSF+LOGFMARK AS SENSITIVE
   CLI   ALLOCDSN,C' 'ALLOCDSN GIVEN?  
   BNE   VTOCOK   YES - VOLSER IS IMPLIED  
   CLI   VOLSER,C' '  CATALOG FOR VTOC?
   BEBADDSN   YES, WHAT DOES THAT MEAN?


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Thursday, June 13, 2019 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: VTOC reading

On Thu, 13 Jun 2019 at 11:48, John McKown 
wrote:

> On Thu, Jun 13, 2019 at 10:44 AM Bill Ogden  wrote:
>
> > My old memory is failing in too many areas.  Long ago, I seem to 
> > recall, there was an easy way to read a VTOC with simple JCL using a "magic"
> > DSNAME - obviously not 040404... for JCL, but some other name.  
> > Is my memory correct?  What is the DSNAME?  While playing with 
> > google I cannot find anything, but I might be using the wrong search words.
>
> Try: DSN=FORMAT4.DSCB,DISP=OLD,UNIT=SYSDA,VOL=SER=volser
>

I'm almost certain this is a kluge/feature implemented only by AMASPZAP, and 
not some JCL magic that works for just any program.

FORMAT4.DSCB is documented in the "SPZAP: Modify data in programs and VTOCs" 
chapter of the "MVS Diagnosis: Tools and Service Aids" book.

Whether you can Dynalloc the VTOC using the true name (44 bytes of 04) is 
another question. For that matter, does JCL reject it (it would have to be 
quoted, of course)?

Tony H.


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

Re: VTOC reading

[Tony Harminc]

On Thu, 13 Jun 2019 at 11:48, John McKown 
wrote:

> On Thu, Jun 13, 2019 at 10:44 AM Bill Ogden  wrote:
>
> > My old memory is failing in too many areas.  Long ago, I seem to recall,
> > there was an easy way to read a VTOC with simple JCL using a "magic"
> > DSNAME - obviously not 040404... for JCL, but some other name.  Is my
> > memory correct?  What is the DSNAME?  While playing with google I cannot
> > find anything, but I might be using the wrong search words.
>
> Try: DSN=FORMAT4.DSCB,DISP=OLD,UNIT=SYSDA,VOL=SER=volser
>

I'm almost certain this is a kluge/feature implemented only by AMASPZAP,
and not some JCL magic that works for just any program.

FORMAT4.DSCB is documented in the "SPZAP: Modify data in programs and
VTOCs" chapter of the "MVS Diagnosis: Tools and Service Aids" book.

Whether you can Dynalloc the VTOC using the true name (44 bytes of 04) is
another question. For that matter, does JCL reject it (it would have to be
quoted, of course)?

Tony H.

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

Re: VTOC reading

[David W Noon]

On Thu, 13 Jun 2019 11:44:24 -0400, Bill Ogden  wrote
abour VTOC reading:

> My old memory is failing in too many areas.  Long ago, I seem to recall, 
> there was an easy way to read a VTOC with simple JCL using a "magic" 
> DSNAME - obviously not 040404... for JCL, but some other name.  Is my 
> memory correct?  What is the DSNAME?  While playing with google I cannot 
> find anything, but I might be using the wrong search words.

  DSN=FORMAT4.DSCB

-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: What happens if an SMF exit modifies the SMF record?

[Charles Mills]

The intent of the question was NOT "I have this neat idea that I could
'improve' SMF records in the exit ..." Not at all. Here is the problem.
Associates have an issue with a corrupted SMF record whose source was an
IEFU8x exit. We see three possibilities:

- They stepped on it themselves somehow. This would seem to be the most
likely possibility, but an inspection of the code comes up with nothing.
- The IBM product cut a bad SMF record. Certainly a possibility, but seems
very unlikely.
- The thought emerged "what if an exit earlier in the IEFU8x chain stepped
on it? Is that even possible?" FWIW my associates were guessing that each
exit received a private copy of the record. (Not an outlandish idea IMHO.
Many products do work that way.) My divining of the manual was that there
was only one copy. I volunteered to ask here.

I did give some thought to "would it ever make sense for an exit to modify
an SMF record?" and the best I could come up with was "shops have done some
amazing things over the years, and after a while they become set in
concrete." The MVS doc indicates that a valid use for an IEFU83 exit would
be to suppress certain SMF records, and suppressing a record is in a sense
the ultimate modification. It does not seem to me to be big leap from, for
example, "I will suppress this record" to "I will keep this record, but get
rid of one triplet section."

I submitted an RCF asking for a clarification.

As always @Peter, thanks for your help.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, June 13, 2019 5:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What happens if an SMF exit modifies the SMF record?


> due to security and integrity of the SMF records themselves, IBM is not 
talking much about it.

Security by obscurity?


No. These are updates by authorized programs. Neither security nor 
integrity is a factor.

One ought to be asking for what reason an exit routine would update an SMF 
record. Can it? Sure. Should it? Usually not.

Most programming interfaces (far from all, of course) are intended to be 
for read-only but only rarely is that explicitly stated. For example, 
without having done an exhaustive analysis, I'd guess that all the PI 
fields in the CVT other than CVTUSER are intended to be read-only. 
Probably one ought to go with "if it's not obvious that a field is 
intended to be written into, then don't write into it (or ask for the 
documentation to make it clear one way or another)"

Long ago I had hoped to gain traction for indicating that a PI field was 
read-only vs read/write (such as placing that information within the 
external classification section of the macro prolog which in turn is used 
within the data areas books). Obviously that hope did not come to 
fruition. 

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

Re: VTOC reading

[John McKown]

On Thu, Jun 13, 2019 at 10:48 AM John McKown 
wrote:

> On Thu, Jun 13, 2019 at 10:44 AM Bill Ogden  wrote:
>
>> My old memory is failing in too many areas.  Long ago, I seem to recall,
>> there was an easy way to read a VTOC with simple JCL using a "magic"
>> DSNAME - obviously not 040404... for JCL, but some other name.  Is my
>> memory correct?  What is the DSNAME?  While playing with google I cannot
>> find anything, but I might be using the wrong search words.
>>
>> Bill Ogden
>>
>
> Try: DSN=FORMAT4.DSCB,DISP=OLD,UNIT=SYSDA,VOL=SER=volser
>

Forgot: DSORG=PS,KEYLEN=44,RECFM=F,BLKSIZE=



>
>
>
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> This is clearly another case of too many mad scientists, and not enough
> hunchbacks.
>
>
> Maranatha! <><
> John McKown
>


-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

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

Re: VTOC reading

[John McKown]

On Thu, Jun 13, 2019 at 10:44 AM Bill Ogden  wrote:

> My old memory is failing in too many areas.  Long ago, I seem to recall,
> there was an easy way to read a VTOC with simple JCL using a "magic"
> DSNAME - obviously not 040404... for JCL, but some other name.  Is my
> memory correct?  What is the DSNAME?  While playing with google I cannot
> find anything, but I might be using the wrong search words.
>
> Bill Ogden
>

Try: DSN=FORMAT4.DSCB,DISP=OLD,UNIT=SYSDA,VOL=SER=volser



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


-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

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

VTOC reading

[Bill Ogden]

My old memory is failing in too many areas.  Long ago, I seem to recall, 
there was an easy way to read a VTOC with simple JCL using a "magic" 
DSNAME - obviously not 040404... for JCL, but some other name.  Is my 
memory correct?  What is the DSNAME?  While playing with google I cannot 
find anything, but I might be using the wrong search words.

Bill Ogden


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

Re: SYS1.MIGLIB and LNKLST

[Steve Smith]

To what end?  Directories don't accumulate gas.

sas

On Wed, Jun 12, 2019 at 2:27 PM Seymour J Metz  wrote:

> Don't forget to over-allocate the directory for those libraries that are
> still PDS.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3

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

Re: SYS1.MIGLIB and LNKLST

[John McKown]

On Thu, Jun 13, 2019 at 7:01 AM Peter Relson  wrote:

> 
> Curious. I have a "WHOHAS" which shows SYSDSN enqueues on a DSN. On both a
> z/OS 1.12 and 2.3 system, it shows:
>
> sys1.miglib,
> OWNERS=  2 ,WAIT EXCLUSIVE=,WAIT SHARED=,
> JOBNAME=XCFAS  ,TYPE=OWNER  ,USE=SHARED,
> JOBNAME=LLA,TYPE=OWNER  ,USE=SHARED,
> 
>
> And your curiosity is? Perhaps "why XCFAS?" That is how LNKLST processing
> has worked since 1992 when dynamic LNKLST was implemented. It has been
> mentioned multiple times over the years. The ENQs are obtained
> specifically so that someone doing something properly (such as a compress
> of a LNKLST data set with DISP=OLD, or a delete) will not be able to get
> through and damage the system (we cannot stop someone who does compress of
> a LNKLST data set with DISP=SHR from damaging the system). XCFAS happened
> to be a convenient full-function never-terminating address space in which
> to obtain the ENQ.
>

The "curious" was you saying there was no need to stop LLA. But LLA also
has the SYSDSN enqueue. The OP was saying that he couldn't do the rename
due to the SYSDSN enqueue. So I was saying that the SETPROG UNALLOCATE had
to be done, and also a STOP LLA. Your sentence above my comment was "There
would have been no reason to stop LLA." Given that the OP did not have &
said he could not get the RACF profile set up which allows renaming an
enqueued dataset. That's why I was curious about why you said "no reason to
stop LLA". Sometimes my phraseology is insufficient.




>
> 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
>


-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

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

Re: SYS1.MIGLIB and LNKLST

[Carmen Vitullo]

Agree Barbara, if it was up to my boss, I'd still be @ -2 applying maint once a 
year, the mentality is, "well were are running fine, no problems", luckily we 
have an association that requires us to be at a certain level every other year, 
getting a little off track, but again, I'm with Barbara, Its become the norm, 
and I've have been very proficient in fixing allocation issues during apply for 
"mostly" linklisted datasets. 


And to Peters point, I'm glad XCFAS hold the ENQ, it protects us from ourselves 
and others, I have a process in place to reallocate my target libraries as 
needed without unallocating from linklist and shutting down LLA 





Carmen Vitullo 

- Original Message -

From: "Barbara Nitz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 13, 2019 12:46:35 AM 
Subject: Re: SYS1.MIGLIB and LNKLST 

>Not to hijack the thread, but... I thought ServerPac already 
>automatically adds 20% (25?) free space, but I could be wrong. In any 
>case, how much free space should be allocated by ServerPac? I saw 50% 
>mentioned. Is that enough? Should it be the same for every data set, 
>or just the three you mention? Is it possible to get any kind of 
>consensus on this topic? 

I am with Carmen on this one. Per company policy I apply ptfs twice a year. 
Every time at least 3 libraries die B37 or D37, and I just hate the wasted time 
to enlarge them. All of this after I already enlarged a lot of the original 
serverpac definitions - and definitely *all* linklist data sets - by 50%, 
including directory space. 
Yes, they're inactive, so easily renamed, but in addition I have to put up with 
incomplete SMS-Definitions, on reallocation SMS forces them to be SMS-managed, 
so I have to delete, reallocate with HLQ sys1, then copy, then rename the sys1 
to what it was before. Or wait at least a day to get the SMS defs done 
correctly. 
Yes, I am running with compress. 

In my opinion every linklist data set should have 50% more primary (no 
secondary) space and 50% more directory space to begin with. Preferably *every* 
data set should have the 50% spare, especially given the wasted space for all 
the zFSs (think font libraries!) Or there should be a ++hold telling you to 
increase the size *before* you do the actual apply, especially for the obscure, 
seldom touched small libraries. 

Barbara 

-- 
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: What happens if an SMF exit modifies the SMF record?

[Peter Relson]

> due to security and integrity of the SMF records themselves, IBM is not 
talking much about it.

Security by obscurity?


No. These are updates by authorized programs. Neither security nor 
integrity is a factor.

One ought to be asking for what reason an exit routine would update an SMF 
record. Can it? Sure. Should it? Usually not.

Most programming interfaces (far from all, of course) are intended to be 
for read-only but only rarely is that explicitly stated. For example, 
without having done an exhaustive analysis, I'd guess that all the PI 
fields in the CVT other than CVTUSER are intended to be read-only. 
Probably one ought to go with "if it's not obvious that a field is 
intended to be written into, then don't write into it (or ask for the 
documentation to make it clear one way or another)"

Long ago I had hoped to gain traction for indicating that a PI field was 
read-only vs read/write (such as placing that information within the 
external classification section of the macro prolog which in turn is used 
within the data areas books). Obviously that hope did not come to 
fruition. 

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: SYS1.MIGLIB and LNKLST

[Peter Relson]

Curious. I have a "WHOHAS" which shows SYSDSN enqueues on a DSN. On both a
z/OS 1.12 and 2.3 system, it shows:

sys1.miglib,
OWNERS=  2 ,WAIT EXCLUSIVE=,WAIT SHARED=,
JOBNAME=XCFAS  ,TYPE=OWNER  ,USE=SHARED,
JOBNAME=LLA,TYPE=OWNER  ,USE=SHARED,


And your curiosity is? Perhaps "why XCFAS?" That is how LNKLST processing 
has worked since 1992 when dynamic LNKLST was implemented. It has been 
mentioned multiple times over the years. The ENQs are obtained 
specifically so that someone doing something properly (such as a compress 
of a LNKLST data set with DISP=OLD, or a delete) will not be able to get 
through and damage the system (we cannot stop someone who does compress of 
a LNKLST data set with DISP=SHR from damaging the system). XCFAS happened 
to be a convenient full-function never-terminating address space in which 
to obtain the ENQ.

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: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

[Wayne Bickerdike]

Peter said...
*Yes, I did one in Rexx and it worked without an issue.*

Well done. I was a bit glib about 2 lines. One at a time is always safer.

I'm always amazed how REXX can crunch these oddball files.

Off topic but I've had some great success with SDSF RGEN this week. Solved
an issue we've had for months...




On Thu, Jun 13, 2019 at 9:31 AM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> That wouldn't work here I'm afraid.  Nothing against Paul, he does some
> amazing stuff,  just not here.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Mike Schwab
> Sent: Wednesday, June 12, 2019 6:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility
> or script?
>
> I think Paul wrote one for his MVS 380 project.
>
> On Wed, Jun 12, 2019 at 10:43 PM Tom Marchant
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > On Wed, 12 Jun 2019 19:05:55 +, Farley, Peter x23353wrote:
> >
> > >The records are actually variable length data, up to 200 bytes of
> actual data with no length prefix (no RDW/BDW).  No binary data, only text
> characters.  I suspect a *ix text-format file as the vendor source but have
> no proof of that.
> >
> > No binary data at all?
> > ASCII or EBCDIC text? Or perhaps Unicode?
> > Or is it text with CR LF or something to delineate the records?
> > If not, how can you tell that the records are up to 200 bytes?
> >
> > Sorry, no answers, just questions.
> >
> > --
> > Tom Marchant
> --
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: [EXTERNAL] Re: WLM Service Definition Formatter

[Sankaranarayanan, Vignesh]

If you're up for it, there's this site where you can upload your WLM and you'll 
get a formatted copy --> https://www.pivotor.com/wlm2html.html

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Alan Young
Sent: 12 June 2019 22:42
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: WLM Service Definition Formatter

Yes, it is a 207,378 byte file. I was able to extract the spreadsheet, open it 
and load a definition. Is there an anti-virus or malware detection product 
blocking the download? Are you able to try to download with a ftp client or a 
different browser?

-Original Message-
>From: "Herring, Bobby" 
>Sent: Jun 12, 2019 12:06 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: WLM Service Definition Formatter
>
>I had someone at our help desk look at it and he thought his download worked, 
>too. But the file was 0kb.
>
>Did you get an actual exe file to download?
>
>I can download all the other four files on the site, just not that one.
>
>Thanks, Bobby
>
>From: IBM Mainframe Discussion List  On
>Behalf Of Alan Young
>Sent: Wednesday, June 12, 2019 11:21 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: [IBM-MAIN] WLM Service Definition Formatter
>
>The download works here. I do notice it is a ftp link and not an http(s) link. 
>Is it possible your organization is blocking ftp access?
>
>
>-Original Message-
>>From: "Herring, Bobby"
>>mailto:bherr...@txfb-ins.com>>
>>Sent: Jun 12, 2019 8:31 AM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: WLM Service Definition Formatter
>>
>>I have used IBM's WLM Service Definition Formatter spreadsheet tool for 
>>years. It's just an Excel spreadsheet with lots of macros under the covers.
>>
>>It was a download from the WLM web page.
>>
>>Mine is an older version and has quit working. The last time it worked 
>>correctly was last fall.
>>
>>I went to download a new copy but that download no longer works.
>>
>>Has anyone else tried downloading this tool and was it successful?
>>
>>Page:
>>https://www.ibm.com/it-infrastructure/z/zos-workload-management>//protect-us.mimecast.com/s/EdeDCNk1yLFMKQ4ir-KHp?domain=ibm.com>
>>
>>Bottom of the page under Service Definition Formatter
>>
>>Bobby Herring
>>Texas Farm Bureau Insurance
>>Waco, TX 76710
>>[http://www.txfb-ins.com/TFBICImages/email.gif>cast.com/s/VbwzCOY9zMh2VgWu5qDsw?domain=txfb-ins.com>]
>>WWW.TXFB-INS.COM>PL?domain=txfb-ins.com>>ecast.com/s/svQJCQWLBnFNGK0FQ1PO-?domain=txfb-ins.com>>
>>
>>CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is 
>>covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 
>>2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you 
>>in error, do not read it. If you are not the intended recipient, you are 
>>hereby notified that any retention, dissemination, distribution, or copying 
>>of this communication is strictly prohibited. Please reply to the sender that 
>>you have received the message in error, then delete it. Thank you.
>>
>>--
>>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
>[http://www.txfb-ins.com/TFBICImages/email.gif]
>WWW.TXFB-INS.COM
>
>CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is 
>covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 
>2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in 
>error, do not read it. If you are not the intended recipient, you are hereby 
>notified that any retention, dissemination, distribution, or copying of this 
>communication is strictly prohibited. Please reply to the sender that you have 
>received the message in error, then delete it. Thank you.
>
>--
>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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile