Re: SYS1.MIGLIB and LNKLST

[Barbara Nitz]

>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

Re: [Project] Open frame to the main.

[Gord Tomlin]

On 2019-06-12 15:07, Seymour J Metz wrote:

I'd suggest that you 
checkhttps://github.com/hacksomeheavymetal/zOS/blob/master/vocabulary.md  
against IBM documentation; some acronyms are incorrect and some are misleading. 
A grammar checker wouldn't hurt. In some cases an acronym that is familiar to 
us (TINU) is unintelligible to an outsider unless you do more than spell out 
what the letters stand for.


Further to the above suggestion, I think you should sort the acronym 
list so that someone looking up an acronym can quickly locate it.


--

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: [Project] Open frame to the main.

[hacksomeheavymetal]

Thanks smetz3, all feedback is welcome.

Please note that the optimal way to contribute to the project is to create a 
pull request.


Hacksomeheavymetal


‐‐‐ Original Message ‐‐‐
On Thursday, 13 June 2019 05:07, Seymour J Metz  wrote:

> I'd suggest that you check 
> https://github.com/hacksomeheavymetal/zOS/blob/master/vocabulary.md against 
> IBM documentation; some acronyms are incorrect and some are misleading. A 
> grammar checker wouldn't hurt. In some cases an acronym that is familiar to 
> us (TINU) is unintelligible to an outsider unless you do more than spell out 
> what the letters stand for.
>
>
> ---
>
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> hacksomeheavymetal 024c53751ff5-dmarc-requ...@listserv.ua.edu
>
> Sent: Wednesday, June 12, 2019 10:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Project] Open frame to the main.
>
> Despite of anakata's motives one thing is certain, thanks to him some
> people got hooked and started to talk about the security of mainframes.
> Since then, few individuals, and before that even fewer, did their best
> sharing their knowledge in the field and contributing to the infosec and
> mainframe communities. This however was still not enough to close the gap
> between mainframes and the rest of the world.
>
> I'm sharing the bits and pieces (braindump) gathered over the years and
> kicking-off an open/libre project where everyone can
> contribute. Currently, the project is available on Github
> https://secure-web.cisco.com/1rLjDV_Qe3vHPwaJ2Evx-DbkZmuly0S_ut6XaRXgviD9D15iMxHTwQXLjIocOZj7n4PtYPg9X_AfYCyAcSHKdztQk-VgtfhqjRmOr4A_7VDv-O1XE4MBQQ66Ig2cXToxgLy4E0NxhRxzhax9ZnR41oBU5GgeZM0ZJ0AUFQnUFC5e8SSiGsxgbR0oANQtHMILZUeiBfFM8E33oQ3COHTJ_dWnYpxfqIvEuIddgtu0TQ0_0xnkS3vSHqwV0Jc85yBmnotgEevOHy7rXtWHznkCDsgv57vtqtyryYlibvWTn9-QCuvNgCpsJxq3_K46zerInAzipZVm6SB3g0RZVLxqjS_9Kb4Aab4WGH9xvcYsfP3fWSRJf5y6j8V08xyobLWJethI48zlMCJxRfxpmsmgH12Sq_1ORAe9lLFlP-WM41m7ulVUWOPZ2B_I8gS-F4AwS/https%3A%2F%2Fgithub.com%2Fhacksomeheavymetal%2FzOS%2Ftree%2Fmaster
>  but who knows,
> perhaps with time it will migrate
> to 
> https://secure-web.cisco.com/1HwMSGI3_dMeo2ibzTbw9ilOuzMjttldBWBIbQtS4K5gd5VRmJnmMDSeBa40CEEuYzMhtxhItE1f7yqUJw0qgnUiCBkMlMnvgeNSFST2gI7BYvJ6dEXuAW-CW0VzH7hDCozugFNKoiuEWnb4DqPvLc2ha1BsTSOJb3x6-qdfySa5k3VprI8ls2hb3VFT80R7SZNlF0J5mgvIbUlDCqGq5QPwxJ2TeKvjlJ41kMUCxhRKh6NqbkwIkY2XmyDbzG2XxSnVvzl6ZYd7M_gXVLZZcWWDThZQMljxtD9owE9P9ZmHkoQVRqkYgURQunIAuzIATOb4Hr1KlG6Rn91-TWPrtwVYqtTzRmjhL7_NwvROaroWI5i7P0aJX3rv7Ei615ydiY8o_a7tUYlQagvP4K-fpmVku2wJ-8MO5oDYO8vYHPyQxnsyvSlACt_wW5-PzsbTg/https%3A%2F%2Fwww.openmainframeproject.org%2Fprojects%2Fsupported-projects,
> if only that would mean more people will contribute.
>
> There's a possibility that at some point it will become a go to place for
> everyone who would like to have fun and learn about mainframe security,
> exactly the same way OWASP became such place for web apps. Or not.
>
> Hacksomeheavymetal
>
> 

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

[Farley, Peter x23353]

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

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

[Farley, Peter x23353]

Yes, definitely no binary data at all, no trailing CR or NL or LF at all.

I guessed at the max size by browsing the file in HEX mode (too big to EDIT in 
TSO), and browse in HEX shows you where the physical end of the record is.

And I did find some records longer than 200, max about 225, so I had to 
increase the final VB LRECL to 250 to accommodate all of them.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Wednesday, June 12, 2019 6:43 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 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.

-- 

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]

Tried that too, but apparently my HFS file is having some trouble being mounted 
and I have to get the storage guys involved to fix it.  Bureaucratic nightmare.

When that's fixed I will definitely try it, thanks for the suggestion.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John McKown
Sent: Wednesday, June 12, 2019 4:51 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

Copy it to a UNIX file with FILEDATA=TEXT using IENGENER or other. Then
copy it back to a PS dataset with appreciate LRECL and RECFM. The first
step will copy each physical record to UNIX, and put a LF at the end to be
a regular UNIX text file. The second step will copy the UNIX file back to
FB or VB. If FB, it will pad with space. If VB, it will put the right LLBB
at the front.

On Wed, Jun 12, 2019, 14:06 Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> 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).
>
> 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.
>
> We have tried every utility we could think of (IEBGENER, IDCAMS REPRO,
> SORT INREC BUILD=(1,200)) to copy this data to a more usable z/OS record
> format but so far nothing we tried works.
>
> Am I correct that only a Rexx or awk script could do this conversion
> (given the update to Rexx to support RECFM=U files and awk's native
> capabilities) or an HLL program coded to handle U-format input can do this
> conversion?
>
> Any other ideas you have to help us perform the conversion without writing
> an HLL program would be much appreciated.
>
> Peter
--

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]

Well, 6 lines (DO WHILE RC = 0 ... END added for one-record-at-a-time 
processing, plus 2 EXECIO ... (FINIS at the end.

Overkill, I know, but that's just me.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Wayne Bickerdike
Sent: Wednesday, June 12, 2019 4:32 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?

Hmmm,

2 ines of REXX in batch, a couple more if run interactively for the ALLOC
statements...

On Thu, Jun 13, 2019 at 5:21 AM Sri h Kolusu  wrote:

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

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

[Farley, Peter x23353]

Yes, the records are actually one per physical block, about 140K records 
(blocks) total.

Rexx handled it without a problem (one record at a time, EXECIO 1 ...  rather 
than EXECIO * ...).

Using Sri's JCL I did try a number of lrecl/blksize combinations, but they all 
failed in the second REPRO with wrong length record error on the first record 
(0 records copied).

I did try to use the SYNCSORT option to pad input records, but I may not have 
done it right.

It's our vendor, but I am told they are recalcitrant.  Not my application area 
(I'm just helping out a co-worker here) so I don't have any input into the 
negotiations.  I would give'em h-e-double-hockey-sticks for an attitude like 
that, but like I said, not my area.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joel C. Ewing
Sent: Wednesday, June 12, 2019 4:25 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?

Are you saying the records are just one per physical block and that by
conventional usage the file should be defined as BLKSIZE=200 with no
LRECL?   If this is a file with a very large number of unblocked records
using a physical block size of 200 or less, it would obviously be an
incredibly poor choice for DASD space utilization and performance --
which suggests the file size is not that large.

The issue of whether REXX is a good solution long term depends on the
volume of data involved.  If talking about 100,000 records daily maybe
look for more efficient solution than REXX.   For small record volume,
take the first solution that works.

If you know for certain that the maximum physical blocksize is actually
200, I would be tempted to try specifying a more-conventional overriding
"BLKSIZE=200" on an input DD for the file and see if that gets any
better results trying to use the standard utilities to generate a
RECFM=VB,LRECL=204,BLKSIZE=??? (SDB or suitable value) output file.  

At one point I think SORT required you to explicitly specify that you
wanted short records to be extended and the padding byte if you
specified fields that extended beyond the size of the record.

If the vendor-generated file is from one of your vendors, I would be
sorely tempted to do some vendor education to improve their
understanding of z/OS.  If it is a vendor of one of your customers, that
obviously is not an option.
    Joel C. Ewing


On 6/12/19 2:05 PM, Farley, Peter x23353 wrote:
> 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).
>
> 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.
>
> We have tried every utility we could think of (IEBGENER, IDCAMS REPRO, SORT 
> INREC BUILD=(1,200)) to copy this data to a more usable z/OS record format 
> but so far nothing we tried works.
>
> Am I correct that only a Rexx or awk script could do this conversion (given 
> the update to Rexx to support RECFM=U files and awk's native capabilities) or 
> an HLL program coded to handle U-format input can do this conversion?
>
> Any other ideas you have to help us perform the conversion without writing an 
> HLL program would be much appreciated.
>
> Peter
-- 

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]

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

Re: Copy error Java module

[Andrew Rowley]

The instructions are in the JZOS Batch Launcher and Toolkit Installation 
and User's Guide:


ftp://public.dhe.ibm.com/software/Java/Java80/JZOS/jzos_users_guide_v8.pdf

They suggest the command:

cp -X JVMLDM80 "//'SYS1.SIEALNKE(JVMLDM80)'"

(Substitute your own dataset name, obviously.)

The destination must be a PDS/E.


Andrew Rowley


On 12/06/2019 1:48 pm, Jake Anderson wrote:

Hi

Cross posted

I am trying to copy a java load module JVMLDMxx using TSO ISHELL copy
function to a preallocated dataset with the attribute(library type,
recfm=u,blocksize=32760).

It fails with message

THERE ID A RECORD FORMAT ERROR FOR A MVS DATASET SYS5.JAVA.LOADLIB. EITHER
THE OUTPUT RECORD FORMAT IS UNDEFINED FOR A TEXT INPUT FILE, OR THE OUTPUT
RECORD FORMAT IS NOT VALID

Has anyone faced this message and what is the attribute of output dataset
that can help moving the module from OMVS to a MVS.

Jake

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


--
Andrew Rowley
Black Hill Software

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

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

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, June 12, 2019 3:15 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?

Well, I would probably do it with assembler, but what's wrong with writing a 
REXX script? or a Perl script, for that matter?


--
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 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

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

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.

We have tried every utility we could think of (IEBGENER, IDCAMS REPRO, SORT 
INREC BUILD=(1,200)) to copy this data to a more usable z/OS record format but 
so far nothing we tried works.

Am I correct that only a Rexx or awk script could do this conversion (given the 
update to Rexx to support RECFM=U files and awk's native capabilities) or an 
HLL program coded to handle U-format input can do this conversion?

Any other ideas you have to help us perform the conversion without writing an 
HLL program would be much appreciated.

Peter
-- 

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?

[Mike Schwab]

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

[Tom Marchant]

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

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

[Alan Young]

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

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

[John McKown]

Copy it to a UNIX file with FILEDATA=TEXT using IENGENER or other. Then
copy it back to a PS dataset with appreciate LRECL and RECFM. The first
step will copy each physical record to UNIX, and put a LF at the end to be
a regular UNIX text file. The second step will copy the UNIX file back to
FB or VB. If FB, it will pad with space. If VB, it will put the right LLBB
at the front.

On Wed, Jun 12, 2019, 14:06 Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> 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).
>
> 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.
>
> We have tried every utility we could think of (IEBGENER, IDCAMS REPRO,
> SORT INREC BUILD=(1,200)) to copy this data to a more usable z/OS record
> format but so far nothing we tried works.
>
> Am I correct that only a Rexx or awk script could do this conversion
> (given the update to Rexx to support RECFM=U files and awk's native
> capabilities) or an HLL program coded to handle U-format input can do this
> conversion?
>
> Any other ideas you have to help us perform the conversion without writing
> an HLL program would be much appreciated.
>
> Peter
> --
>
> 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: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

[Wayne Bickerdike]

Hmmm,

2 ines of REXX in batch, a couple more if run interactively for the ALLOC
statements...

On Thu, Jun 13, 2019 at 5:21 AM Sri h Kolusu  wrote:

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


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

[Joel C. Ewing]

Are you saying the records are just one per physical block and that by
conventional usage the file should be defined as BLKSIZE=200 with no
LRECL?   If this is a file with a very large number of unblocked records
using a physical block size of 200 or less, it would obviously be an
incredibly poor choice for DASD space utilization and performance --
which suggests the file size is not that large.

The issue of whether REXX is a good solution long term depends on the
volume of data involved.  If talking about 100,000 records daily maybe
look for more efficient solution than REXX.   For small record volume,
take the first solution that works.

If you know for certain that the maximum physical blocksize is actually
200, I would be tempted to try specifying a more-conventional overriding
"BLKSIZE=200" on an input DD for the file and see if that gets any
better results trying to use the standard utilities to generate a
RECFM=VB,LRECL=204,BLKSIZE=??? (SDB or suitable value) output file.  

At one point I think SORT required you to explicitly specify that you
wanted short records to be extended and the padding byte if you
specified fields that extended beyond the size of the record.

If the vendor-generated file is from one of your vendors, I would be
sorely tempted to do some vendor education to improve their
understanding of z/OS.  If it is a vendor of one of your customers, that
obviously is not an option.
    Joel C. Ewing


On 6/12/19 2:05 PM, Farley, Peter x23353 wrote:
> 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).
>
> 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.
>
> We have tried every utility we could think of (IEBGENER, IDCAMS REPRO, SORT 
> INREC BUILD=(1,200)) to copy this data to a more usable z/OS record format 
> but so far nothing we tried works.
>
> Am I correct that only a Rexx or awk script could do this conversion (given 
> the update to Rexx to support RECFM=U files and awk's native capabilities) or 
> an HLL program coded to handle U-format input can do this conversion?
>
> Any other ideas you have to help us perform the conversion without writing an 
> HLL program would be much appreciated.
>
> Peter


-- 
Joel C. Ewing

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

[Sri h Kolusu]

> 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

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

[Seymour J Metz]

Well, I would probably do it with assembler, but what's wrong with writing a 
REXX script? or a Perl script, for that matter?


--
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 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

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

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.

We have tried every utility we could think of (IEBGENER, IDCAMS REPRO, SORT 
INREC BUILD=(1,200)) to copy this data to a more usable z/OS record format but 
so far nothing we tried works.

Am I correct that only a Rexx or awk script could do this conversion (given the 
update to Rexx to support RECFM=U files and awk's native capabilities) or an 
HLL program coded to handle U-format input can do this conversion?

Any other ideas you have to help us perform the conversion without writing an 
HLL program would be much appreciated.

Peter
--

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: [Project] Open frame to the main.

[Seymour J Metz]

I'd suggest that you check 
https://github.com/hacksomeheavymetal/zOS/blob/master/vocabulary.md against IBM 
documentation; some acronyms are incorrect and some are misleading. A grammar 
checker wouldn't hurt. In some cases an acronym that is familiar to us (TINU) 
is unintelligible to an outsider unless you do more than spell out what the 
letters stand for.


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


From: IBM Mainframe Discussion List  on behalf of 
hacksomeheavymetal <024c53751ff5-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, June 12, 2019 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Project] Open frame to the main.

Despite of anakata's motives one thing is certain, thanks to him some
people got hooked and started to talk about the security of mainframes.
Since then, few individuals, and before that even fewer, did their best
sharing their knowledge in the field and contributing to the infosec and
mainframe communities. This however was still not enough to close the gap
between mainframes and the rest of the world.

I'm sharing the bits and pieces (braindump) gathered over the years and
kicking-off an open/libre project where everyone can
contribute. Currently, the project is available on Github
https://secure-web.cisco.com/1rLjDV_Qe3vHPwaJ2Evx-DbkZmuly0S_ut6XaRXgviD9D15iMxHTwQXLjIocOZj7n4PtYPg9X_AfYCyAcSHKdztQk-VgtfhqjRmOr4A_7VDv-O1XE4MBQQ66Ig2cXToxgLy4E0NxhRxzhax9ZnR41oBU5GgeZM0ZJ0AUFQnUFC5e8SSiGsxgbR0oANQtHMILZUeiBfFM8E33oQ3COHTJ_dWnYpxfqIvEuIddgtu0TQ0_0xnkS3vSHqwV0Jc85yBmnotgEevOHy7rXtWHznkCDsgv57vtqtyryYlibvWTn9-QCuvNgCpsJxq3_K46zerInAzipZVm6SB3g0RZVLxqjS_9Kb4Aab4WGH9xvcYsfP3fWSRJf5y6j8V08xyobLWJethI48zlMCJxRfxpmsmgH12Sq_1ORAe9lLFlP-WM41m7ulVUWOPZ2B_I8gS-F4AwS/https%3A%2F%2Fgithub.com%2Fhacksomeheavymetal%2FzOS%2Ftree%2Fmaster
 but who knows,
perhaps with time it will migrate
to 
https://secure-web.cisco.com/1HwMSGI3_dMeo2ibzTbw9ilOuzMjttldBWBIbQtS4K5gd5VRmJnmMDSeBa40CEEuYzMhtxhItE1f7yqUJw0qgnUiCBkMlMnvgeNSFST2gI7BYvJ6dEXuAW-CW0VzH7hDCozugFNKoiuEWnb4DqPvLc2ha1BsTSOJb3x6-qdfySa5k3VprI8ls2hb3VFT80R7SZNlF0J5mgvIbUlDCqGq5QPwxJ2TeKvjlJ41kMUCxhRKh6NqbkwIkY2XmyDbzG2XxSnVvzl6ZYd7M_gXVLZZcWWDThZQMljxtD9owE9P9ZmHkoQVRqkYgURQunIAuzIATOb4Hr1KlG6Rn91-TWPrtwVYqtTzRmjhL7_NwvROaroWI5i7P0aJX3rv7Ei615ydiY8o_a7tUYlQagvP4K-fpmVku2wJ-8MO5oDYO8vYHPyQxnsyvSlACt_wW5-PzsbTg/https%3A%2F%2Fwww.openmainframeproject.org%2Fprojects%2Fsupported-projects,
if only that would mean more people will contribute.

There's a possibility that at some point it will become a go to place for
everyone who would like to have fun and learn about mainframe security,
exactly the same way OWASP became such place for web apps. Or not.

Hacksomeheavymetal

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

[Herring, Bobby]

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

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

[Farley, Peter x23353]

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

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.

We have tried every utility we could think of (IEBGENER, IDCAMS REPRO, SORT 
INREC BUILD=(1,200)) to copy this data to a more usable z/OS record format but 
so far nothing we tried works.

Am I correct that only a Rexx or awk script could do this conversion (given the 
update to Rexx to support RECFM=U files and awk's native capabilities) or an 
HLL program coded to handle U-format input can do this conversion?

Any other ideas you have to help us perform the conversion without writing an 
HLL program would be much appreciated.

Peter
-- 

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

[Seymour J Metz]

Don't forget to over-allocate the directory for those libraries that are still 
PDS.


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


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, June 12, 2019 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

Just as an aside, the underlying issue is LPALIB, LINKLIB and MIGLIB are 
underallocated in the ServerPac dialog, I've opened a case with the serverpac 
folks years ago and alway "TRY" to remember to change the allocation of these 
libraries prior to them being allocated.
the libraries are allocated with just enough space to install the OS from the 
ServerPac, no room for maint in most cases.



Carmen Vitullo

- Original Message -

From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 12, 2019 6:07:46 AM
Subject: Re: SYS1.MIGLIB and LNKLST

Big Thumbs up! In that case, assuming you have access, you could have just 
allocated a larger .NEW version, copy old to new, and done the renames via ISPF 
3.4 with VOLSER, and bypassed the enqueuer warnings? Would have saved a lot of 
fanagaling

_
Dave Jousma
AVP | Manager, Systems Engineering

Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546
616.653.8429 | fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Veryl Ellis
Sent: Tuesday, June 11, 2019 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Applying maintenance to a target SYSRES volume.
I never apply maintenance to a running system.

S. Veryl

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Tuesday, June 11, 2019 3:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

Veryl,


You are getting a lot of feedback that I consider a bit scary. Can you clarify 
something? Are you trying to apply maintenance to your running SYSRES? Or a 
copy of it, and are dealing with that type of enqueuer? If the latter, then 
yes, allocate a .NEW version of MIGLIB, copy the contents from the old to the 
new, and using appropriate tools, do the renames.

If you are contemplating doing these activities on your running system, well 
then, let me pop up a bowl of popcorn, and pour a cocktail for this show.

_
Dave Jousma
AVP | Manager, Systems Engineering

Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546
616.653.8429 | fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Veryl Ellis
Sent: Tuesday, June 11, 2019 2:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SYS1.MIGLIB and LNKLST

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran out 
of space (S/D37).
Can anyone tell me how to get SYS1.MIGLIB out of the running Link List 
concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB?
The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't 
work on SYS1.MIGLIB.

Thanks for any assist.



S. Veryl Ellis


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or 

Re: SYS1.MIGLIB and LNKLST

[Carmen Vitullo]

>As for size, no need to hog wild on freespace *if* the only time it is an 
>issue is applying to non-running sysres volume. 

Especially if you use RETRY and COMPRESS on your APPLY. 

IME - not for every instance - I use RETRY - COMPRESS 


Carmen Vitullo 

- Original Message -

From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, June 12, 2019 1:10:23 PM 
Subject: Re: SYS1.MIGLIB and LNKLST 

On Wed, 12 Jun 2019 17:15:15 +, Jousma, David wrote: 

>As for size, no need to hog wild on freespace *if* the only time it is an 
>issue is applying to non-running sysres volume. 

Especially if you use RETRY and COMPRESS on your APPLY. 

-- 
Tom Marchant 

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

[Tom Marchant]

On Wed, 12 Jun 2019 17:15:15 +, Jousma, David wrote:

>As for size, no need to hog wild on freespace *if* the only time it is an 
>issue is applying to non-running sysres volume.

Especially if you use RETRY and COMPRESS on your APPLY.

-- 
Tom Marchant

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

Re: What do y'all think of this? No password expiration time

[Paul Gilmartin]

On Wed, 12 Jun 2019 16:54:47 +, Wayne Driscoll wrote:

>It clearly isn't buried in TSO logon, because the same ICH70001I message 
>issued at TSO login is also issued to the JESMSGLG dataset of a batch job. I 
>believe it has to do with the use of the MSGxxx operands on the RACROUTE 
>request.
> 
Whatever.  The root question is, why doesn't ssh login display it likewise?

>-Original Message-
>From:  Paul Gilmartin
>Sent: Wednesday, June 12, 2019 10:46 AM
>
>>>True. I really like the fact that wnen I log into TSO, it tells me the
>>>last time my ID was used for some purpose. I wish that the log in to
>>>z/OS UNIX, via ssh, did the same thing.
>>
>I believe Walt Farrell(?) commented, years ago, that that function is buried 
>inextricably in TSO logon processing.
>
>Conway's Law.  Another case where IBM designers appear to flee from reusable 
>code.  Some systems even have a user command to display that information 
>electively.

-- gil

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

I've worked at site where I did not "HA VE AUTHORITY TO OVERRIDE THIS TEST" 
working for an outsourcer at one time we ordered ONE ServerPac for all 
customers, so the size of the order was very large and applying maint sometime 
was a nightmare, the process that was in place there was to copy the SYSRES 
around to all client systems, using IFAPRDxx to turn off, turn on products for 
each client, not the best approach but one I had to adhere to, so space was an 
issue and a little bit more cushion would have helped. 


Carmen Vitullo 

- Original Message -

From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, June 12, 2019 12:15:15 PM 
Subject: Re: SYS1.MIGLIB and LNKLST 

I guess I still don’t understand all the hubbub If you aren’t applying 
maintenance to running system, then "fixing" sys1.miglib on another volume is a 
piece of cake, and does NOT involve any LLA unallocate commands etc 

When I go to rename SYS1.MIGLIB on my maintenance SYSRES RSM02A, I get: 

IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS (040B0446), 
IKJACCNT,RSM02A,SYS1.MIGLIB 
DATA SET NAME IS IN USE BUT YOU HAVE AUTHORITY TO OVERRIDE THIS TEST 

And then I press enter... 

Rename Data Set In Use 
Command ===> 

Data Set Name . : SYS1.MIGLIB 
Volume . . . . : RSM02A 

The system detected that a data set with the above name is in use 
(possibly on another system) but it cannot determine whether it is the 
data set you wish to rename. If it is the same data set and any program 
has it open, renaming it could cause serious system and data integrity 
problems. 

You have the extra security authority to rename the data set even though 
its name is in use. Refer to the DFSMS documentation on the RENAME macro 
for further information. 

Instructions: 
Press ENTER to override data set name protection and rename the data 
set. 
Enter CANCEL or EXIT to cancel the rename request. 

Am I missing something? As for size, no need to hog wild on freespace *if* the 
only time it is an issue is applying to non-running sysres volume. 
_
 
Dave Jousma 
AVP | Manager, Systems Engineering 

Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 
616.653.8429 | fax: 616.653.2717 


-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Kurt Quackenbush 
Sent: Wednesday, June 12, 2019 11:18 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SYS1.MIGLIB and LNKLST 

**CAUTION EXTERNAL EMAIL** 

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails** 

On 6/12/2019 9:06 AM, Carmen Vitullo wrote: 
> Just as an aside, the underlying issue is LPALIB, LINKLIB and MIGLIB 
> are underallocated in the ServerPac dialog, I've opened a case with 
> the serverpac folks years ago and alway "TRY" to remember to change 
> the allocation of these libraries prior to them being allocated. the 
> libraries are allocated with just enough space to install the OS from 
> the ServerPac, no room for maint in most cases. 

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? 

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 **CAUTION EXTERNAL 
EMAIL** 

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails** 

This e-mail transmission contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated. 


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

[Jousma, David]

I guess I still don’t understand all the hubbub  If you aren’t applying 
maintenance to running system, then "fixing" sys1.miglib on another volume is a 
piece of cake, and does NOT involve any LLA unallocate commands etc

When I go to rename SYS1.MIGLIB on my maintenance SYSRES RSM02A, I get:

IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS (040B0446), 
 IKJACCNT,RSM02A,SYS1.MIGLIB   
 DATA SET NAME IS IN USE BUT YOU HAVE AUTHORITY TO OVERRIDE THIS TEST  

And then I press enter...

  Rename Data Set In Use   
Command ===>   
   
Data Set Name . : SYS1.MIGLIB  
Volume  . . . . : RSM02A   
   
  The system detected that a data set with the above name is in use
  (possibly on another system) but it cannot determine whether it is the   
  data set you wish to rename. If it is the same data set and any program  
  has it open, renaming it could cause serious system and data integrity   
  problems.
   
  You have the extra security authority to rename the data set even though 
  its name is in use. Refer to the DFSMS documentation on the RENAME macro 
  for further information. 
   
Instructions:  
  Press ENTER to override data set name protection and rename the data 
  set. 
  Enter CANCEL or EXIT to cancel the rename request.   
   
Am I missing something?   As for size, no need to hog wild on freespace *if* 
the only time it is an issue is applying to non-running sysres volume.
_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kurt Quackenbush
Sent: Wednesday, June 12, 2019 11:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

On 6/12/2019 9:06 AM, Carmen Vitullo wrote:
> Just as an aside, the underlying issue is LPALIB, LINKLIB and MIGLIB 
> are underallocated in the ServerPac dialog, I've opened a case with 
> the serverpac folks years ago and alway "TRY" to remember to change 
> the allocation of these libraries prior to them being allocated. the 
> libraries are allocated with just enough space to install the OS from 
> the ServerPac, no room for maint in most cases.

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?

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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: What do y'all think of this? No password expiration time

[Wayne Driscoll]

It clearly isn't buried in TSO logon, because the same ICH70001I message issued 
at TSO login is also issued to the JESMSGLG dataset of a batch job. I believe 
it has to do with the use of the MSGxxx operands on the RACROUTE request.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, June 12, 2019 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What do y'all think of this? No password expiration time

On Wed, 12 Jun 2019 11:13:47 -0400, Phil Smith III wrote:

>John McKown wrote:
>
Which article are you replying to?  I can't find it.  IIRC, I even commented on 
it.  URL?

>>True. I really like the fact that when I log into TSO, it tells me the
>>last time my ID was used for some purpose. I wish that the log in to
>>z/OS UNIX, via ssh, did the same thing.
>
I believe Walt Farrell(?) commented, years ago, that that function is buried 
inextricably in TSO logon processing.

Conway's Law.  Another case where IBM designers appear to flee from reusable 
code.  Some systems even have a user command to display that information 
electively.

>>Which makes me wonder if some sort of daily (weekly?) report should be
>>done for each RACF ID associated with a "person" which reports all the "logon"
>>and perhaps "logoff" activity and then email it to them
>
>Nice idea...but most folks would just delete it unread after the first week.
>
>As for the article: NIST said the same thing last year, but now that Microsoft 
>is repeating it, it's finally getting some press. That's kind of sad and scary.
>
Cite?  URLs?  I find:

https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpages.nist.gov%2F800-63-FAQ%2F%23q-b5data=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%7C7de3610ad2424deaed6e08d6ef4d1d8d%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636959511824788501sdata=6qxbbdgBeuB5U8qvJFuv0Z6PS3bYzi6u8bagTpS4UxE%3Dreserved=0
On password expiration

https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxkcd.com%2F936%2Fdata=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%7C7de3610ad2424deaed6e08d6ef4d1d8d%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636959511824798497sdata=hsSarv97DDKnEkQd3wZfRe9Gh52aQWuy5jRUOwGGz4I%3Dreserved=0

-- gil

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

[Wayne Driscoll]

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.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, June 11, 2019 1:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Just how secure are mainframes? | Trevor Eddolls

I have never found much barrier to entry with the IBM Business Partner process.

The HUGE obstacle is customer inertia and conservatism. Customers may complain 
about software costs, but they are the big barriers to entry for small 
competitors. At my former employer we had customers say specifically "we love 
your product but we are not taking on any new software vendors." (In some cases 
you could overcome that by partnering with a reseller.)

I would not want to be out there pitching "my ESM from Mills & Associates is 
way superior to RACF, Mr. Wells Fargo or Mr. Fidelity or whatever. You should 
drop RACF and install the Mills & Associates ESM."

There is a concept in software marketing called "stickiness." A search engine 
has zero stickiness. If a better search engine came along tomorrow you would 
start using it in a heartbeat. An ESM is way sticky. Even if I could sell 
Mr. Fargo on the superiority of my ESM, who is going to migrate all their RACF 
rules and administrative processes and TEST them?

Barry tried (or is still trying?) with a product (or prototype or concept) 
called DEADBOLT. 
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fibmsystemsmag.com%2Fmainframe%2Ftrends%2Fztalk%2Fbarry-schrager%2Fdata=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%7C3dccc79ac19e457f709508d6ee9a6b83%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636958744343975330sdata=UJAwz6fOG%2BZrEIO%2FqUTAMl1nUJyyHSzxGrm4L2qb5GQ%3Dreserved=0
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dignus.com%2Fsuccess_stories%2FJME%2Fpaper.htmldata=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%7C3dccc79ac19e457f709508d6ee9a6b83%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636958744343975330sdata=K4dbKJR1i85k6dd9246I7t4FNVS47OksBYu4UHlOV4Y%3Dreserved=0

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, June 11, 2019 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Just how secure are mainframes? | Trevor Eddolls

On Tue, Jun 11, 2019 at 11:26 AM Bob Bridges  wrote:

> If that's what it stands for I should think those aren't just the big
> three but the ~only~ three.  At least, I've never heard of any others.
> Which is odd, when you think about it; surely there's someone out
> there wanting to break into the market?  So says my capitalist
> assumptions.  But apparently not.
>

Most likely the entry cost. Developing z/OS software is _expensive_. I don't 
know, but when I looked a couple of years ago, the zPDT was something like 
$5000 / year with annual renewal. And you need to be approved by IBM as a 
"Business Partner". That is a stiff barrier to entry, IMO. I know some business 
people here have a zPDT system, but I doubt that Phoenix Software would really 
want to go up against IBM and CA for that market. Also, unlike a productivity 
tool such as (E)JES, an ESM is (or should be) "business critical" for 
protection. To convince a company to go with a "new & unknown" product in this 
era of PHI, HIPAA, GDPR, and so on is so unlikely as to be silly to even 
consider. Better to go with products such as (E)JES (Phoenix Software) or 
Systems/ASM (Dignus) which, I feel, are more likely to be considered without 
the company auditors having a fit.

The reason I love Linux is the _zero_ cost of the GNU and other software.
Basically I only pay for the hardware and electricity. Of course, I am not a 
software developer, just a bit of a dilettante so far as programming is 
concerned.



>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Nearly all men can stand adversity.  If you want to test a man's
> character, give him power.  -Abraham Lincoln */
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Pommier, Rex
> Sent: Thursday, May 30, 2019 11:22
>
> I have been under the impression it stands for External Security
> Manager, of which the "big 3" would be RACF, ACF2, Top Secret.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Brennan
> Sent: Thursday, May 30, 2019 10:21 AM
>
> I've seen the acronym ESM a few times in this thread.  I'll assume
> that means "Enterprise Security Management", and I'll guess it refers
> to security processes (not RACF), such as assigning userid's, making
> sure people have just the access they need, periodic audits, etc.
>
> Am I even close?
>
> 

Re: WLM Service Definition Formatter

[Alan Young]

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

Re: What (presumably SYSEVENT) function is equivalent to "E job,Q"

[Rob Scott]

Yeah - you might have to code a little STIMER routine waiting for OUCBRQSC to 
be set if you must ensure that ASID is actually quiesced (with some "give up" 
max limit).

OUCB is marked PSPI so take that into consideration.

Alternative is to periodically issue SYSEVENT REQFASD and wait for RASDQSC to 
be set - but that seems like overkill to me.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Wednesday, June 12, 2019 3:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What (presumably SYSEVENT) function is equivalent to "E job,Q"

Thanks.

Also obviously asynchronous, but certainly easier and faster.

On Wed, 12 Jun 2019 11:19:39 + Rob Scott 
wrote:

:>WLM services macro : IWMRESET
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
:>Sent: Wednesday, June 12, 2019 12:04 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: What (presumably SYSEVENT) function is equivalent to "E job,Q"
:>
:>What (presumably SYSEVENT) function is equivalent to "E job,Q"
:>
:>I am trying to test something while the job is being quiesced. And I am not 
sure of the timing should I use MGCR(E).

--
Binyamin Dissen 
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dissensoftware.comdata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7Ced78ece60f4e43d38bb208d6ef4482e5%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636959474881551144sdata=VFhUCMOTwNaZ063m51TK60Ame%2BAGjsaLRu044tLEKsw%3Dreserved=0

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: What do y'all think of this? No password expiration time

[Phil Smith III]

John McKown wrote:

> Which article are you replying to?  I can't find it.  IIRC, I even commented 
> on it.  URL?

 

My bad. This was on RACF-L. You posted it!

https://www.sans.org/security-awareness-training/blog/time-password-expiration-die

 

Re NIST: jeez, it wasn't LAST year, it was almost three years ago. This is the 
article I remember:

https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

But yes, 800-63.


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

Re: What do y'all think of this? No password expiration time

[Paul Gilmartin]

On Wed, 12 Jun 2019 11:13:47 -0400, Phil Smith III wrote:

>John McKown wrote:
> 
Which article are you replying to?  I can't find it.  IIRC, I even commented on 
it.  URL?

>>True. I really like the fact that when I log into TSO, it tells me the last
>>time my ID was used for some purpose. I wish that the log in to z/OS UNIX,
>>via ssh, did the same thing.
> 
I believe Walt Farrell(?) commented, years ago, that that function is buried
inextricably in TSO logon processing.

Conway's Law.  Another case where IBM designers appear to flee from
reusable code.  Some systems even have a user command to display
that information electively.

>>Which makes me wonder if some sort of daily (weekly?) report should be done
>>for each RACF ID associated with a "person" which reports all the "logon"
>>and perhaps "logoff" activity and then email it to them
>
>Nice idea...but most folks would just delete it unread after the first week. 
>
>As for the article: NIST said the same thing last year, but now that Microsoft 
>is repeating it, it's finally getting some press. That's kind of sad and scary.
> 
Cite?  URLs?  I find:
https://pages.nist.gov/800-63-FAQ/#q-b5
On password expiration
https://xkcd.com/936/

-- gil

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

Das geeks hit crowdfunding target: IBM mainframes are coming home

[ITschak Mugzach]

from "theregister" saving an old ibm 360 from German company auction.
https://www.theregister.co.uk/2019/06/03/das_geeks_hit_crowdfunding_target/


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: [EXTERNAL] WLM Service Definition Formatter

[Horne, Jim - James S]

WLM Service Definition Formatter has been replaced by zOSMF according to IBM

Jim Horne

NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

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

WLM Service Definition Formatter

[Herring, Bobby]

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

Re: SYS1.MIGLIB and LNKLST

[Carmen Vitullo]

Thank you Kurt for validating this, and yes, it is better, but for me, I will 
generally apply RSU maint every quarter, so 4 times a year, btu there are 
instances where I still run out of room, also I have issues with the CEE 
runtime library running out of room, 50 % cushion would help tremendously 



Carmen Vitullo 

- Original Message -

From: "Kurt Quackenbush"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, June 12, 2019 10:17:33 AM 
Subject: Re: SYS1.MIGLIB and LNKLST 

On 6/12/2019 9:06 AM, Carmen Vitullo wrote: 
> Just as an aside, the underlying issue is LPALIB, LINKLIB and MIGLIB 
> are underallocated in the ServerPac dialog, I've opened a case with 
> the serverpac folks years ago and alway "TRY" to remember to change 
> the allocation of these libraries prior to them being allocated. the 
> libraries are allocated with just enough space to install the OS from 
> the ServerPac, no room for maint in most cases. 

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? 

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 


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

[Kurt Quackenbush]

On 6/12/2019 9:06 AM, Carmen Vitullo wrote:

Just as an aside, the underlying issue is LPALIB, LINKLIB and MIGLIB
are underallocated in the ServerPac dialog, I've opened a case with
the serverpac folks years ago and alway "TRY" to remember to change
the allocation of these libraries prior to them being allocated. the
libraries are allocated with just enough space to install the OS from
the ServerPac, no room for maint in most cases.


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?


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: What do y'all think of this? No password expiration time

[Phil Smith III]

John McKown wrote:

>True. I really like the fact that when I log into TSO, it tells me the last

>time my ID was used for some purpose. I wish that the log in to z/OS UNIX,

>via ssh, did the same thing.

 

>Which makes me wonder if some sort of daily (weekly?) report should be done

>for each RACF ID associated with a "person" which reports all the "logon"

>and perhaps "logoff" activity and then email it to them

 

Nice idea...but most folks would just delete it unread after the first week.

 

As for the article: NIST said the same thing last year, but now that Microsoft 
is repeating it, it's finally getting some press. That's kind of sad and scary.


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

[Project] Open frame to the main.

[hacksomeheavymetal]

Despite of anakata's motives one thing is certain, thanks to him some
people got hooked and started to talk about the security of mainframes.
Since then, few individuals, and before that even fewer, did their best
sharing their knowledge in the field and contributing to the infosec and
mainframe communities. This however was still not enough to close the gap
between mainframes and the rest of the world.

I'm sharing the bits and pieces (braindump) gathered over the years and
kicking-off an open/libre project where everyone can
contribute. Currently, the project is available on Github
https://github.com/hacksomeheavymetal/zOS/tree/master but who knows,
perhaps with time it will migrate
to https://www.openmainframeproject.org/projects/supported-projects,
if only that would mean more people will contribute.

There's a possibility that at some point it will become a go to place for
everyone who would like to have fun and learn about mainframe security,
exactly the same way OWASP became such place for web apps. Or not.

Hacksomeheavymetal

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

Re: What (presumably SYSEVENT) function is equivalent to "E job,Q"

[Binyamin Dissen]

Thanks.

Also obviously asynchronous, but certainly easier and faster.

On Wed, 12 Jun 2019 11:19:39 + Rob Scott 
wrote:

:>WLM services macro : IWMRESET
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
:>Sent: Wednesday, June 12, 2019 12:04 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: What (presumably SYSEVENT) function is equivalent to "E job,Q"
:>
:>What (presumably SYSEVENT) function is equivalent to "E job,Q"
:>
:>I am trying to test something while the job is being quiesced. And I am not 
sure of the timing should I use MGCR(E).

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

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

[Elardus Engelbrecht]

Charles Mills wrote:

>Thanks @Scott and @Elardus.

You're most welcome!


>I have submitted an RCF and copied @Scott.

Cool! Keep them busy. ;-)


>@Elardus -- don't forget IEFU86.

Yes, you're right. I just copied (in a hurry!) the list of the IEFU8x involved 
from a bookie in KC.


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

Perhaps, There is even a way to create and validate SMF records with digital 
signatures. But, still, you can modify it as per earlier discussion, then at 
the last stage, those records are then signed.

"Security by obscurity" - is only working in theory ... ;-)

Look at https://en.wikipedia.org/wiki/Security_through_obscurity for some 
discussion...

Groete / Greetings
Elardus Engelbrecht

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

Re: Copy error Java module

[Barkow, Eileen]

ISHELL COPY option has a 'BINARY COPY' option.

If selected the module will be copied to the PDSE.

This is not a java module - it is the JZOS load module residing in the java HFS







Copying from file:

/usr/lpp/java/J8.0_64/mvstools/JVMLDM86



Destination for copy:

__  1.  File...

2.  Data set...



Select additional options for data set copy:

X_  Binary copy

_  Conversion...







F1=Help  F3=Exit  F6=Keyshelp F12=Cancel



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, June 12, 2019 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Copy error Java module



> Cross posted

On 2019-06-11, at 21:48:40, Jake Anderson wrote:

>

> I am trying to copy a java load module JVMLDMxx ...

>

If it's in a UNIX file, it's not a load module.  Is it a program object, a jar, 
or something else?



> ... using TSO ISHELL copy function

>

"copy function" is pretty vague.  What command, options, and operands did you 
use?



> ... to a preallocated dataset with the attribute(library type,

> recfm=u,blocksize=32760).

>

> It fails with message

>

> THERE ID A RECORD FORMAT ERROR FOR A MVS DATASET SYS5.JAVA.LOADLIB.

> EITHER THE OUTPUT RECORD FORMAT IS UNDEFINED FOR A TEXT INPUT FILE, OR

> THE OUTPUT RECORD FORMAT IS NOT VALID

>

> Has anyone faced this message and what is the attribute of output

> dataset that can help moving the module from OMVS to a MVS.



-- gil



--

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



This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail 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: Copy error Java module

[Paul Gilmartin]

> Cross posted
On 2019-06-11, at 21:48:40, Jake Anderson wrote:
> 
> I am trying to copy a java load module JVMLDMxx ...
>  
If it's in a UNIX file, it's not a load module.  Is it a program object,
a jar, or something else?

> ... using TSO ISHELL copy function
>  
"copy function" is pretty vague.  What command, options, and operands
did you use?

> ... to a preallocated dataset with the attribute(library type,
> recfm=u,blocksize=32760).
> 
> It fails with message
> 
> THERE ID A RECORD FORMAT ERROR FOR A MVS DATASET SYS5.JAVA.LOADLIB. EITHER
> THE OUTPUT RECORD FORMAT IS UNDEFINED FOR A TEXT INPUT FILE, OR THE OUTPUT
> RECORD FORMAT IS NOT VALID
> 
> Has anyone faced this message and what is the attribute of output dataset
> that can help moving the module from OMVS to a MVS.

-- gil

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

Thanks @Scott and @Elardus.

I have submitted an RCF and copied @Scott.

@Elardus -- don't forget IEFU86.

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

Security by obscurity?

Charles

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

Charles Mills wrote:

>What happens if an SMF exit modifies the SMF record? Do the next exit in the 
>chain, SYS1.MANx and/or the stream see the modified record, or is the exit 
>only modifying a "private copy" of the SMF record?

It should be able to do that provided the SMF exit is getting the address 
(fullword) of the SMF record in register 1. Each SMF record is passed to an 
installation exit (either IEFU83, IEFU84, or IEFU85) before it is written to 
the SMF data set. But there is one catch, Inside the SMF exit, you cannot use 
the SMFWTM or SMFEWTM macro to write to the SMF data set, because the exits are 
called by SMFWTM/SMFEWTM.

Of course, SMF records needed to be collected and then written out instead of 
being suppressed by the exits themselves.

Cheryl Watson and Frank Kyne once wrote in November 2014 this:

"An application would pass a record to SMF using the SMFWTM macro, and SMF 
would call IEFU83 with the record. The exit could choose to delete the record, 
modify it or perform some action based on the record’s contents. "

(From: 
http://enterprisesystemsmedia.com/article/smf-exits-and-the-life-of-a-job )


>It would seem to me to be an important point, and the documentation is pretty 
>much silent (or I am visually challenged). However, I tend to interpret "Word 
>1: The address of the record that SMF is to write" as implying that there is 
>only a single copy that will get passed on down the line.

Your interpretation is correct, but strangely just like you and Scott 
Ballentine, I also don't see it documented specifically that your SMF exits can 
modify a record all the way from one exit to other until it is finally written 
out to the SMF VSAM datasets.

I believe the reason is that due to security and integrity of the SMF records 
themselves, IBM is not talking much about it. 

For IEFACTRT, I see this note: 

"When the data for an SMF record exceeds 32,756 bytes in length, the system 
constructs one or more "continuation" or "additional" records to ensure that no 
individual record exceeds that length. The system invokes IEFACTRT once for the 
original record and once for each continuation record."

So, I believe SMF records can be changed many times until it is written out 
finally.


>I will submit an RCF once I get a definitive answer here.

Please do so.

Groete / Greetings
Elardus Engelbrecht

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

[John McKown]

On Wed, Jun 12, 2019 at 8:06 AM Carmen Vitullo  wrote:

> Just as an aside, the underlying issue is LPALIB, LINKLIB and MIGLIB are
> underallocated in the ServerPac dialog, I've opened a case with the
> serverpac folks years ago and alway "TRY" to remember to change the
> allocation of these libraries prior to them being allocated.
> the libraries are allocated with just enough space to install the OS from
> the ServerPac, no room for maint in most cases.
>

IIRC, I used some option in the dialogs to increase the allocations by
about 50%. I hate to say it, but I consider this to be another of the
"penny wise, pound foolish" things that people in I.T. do. That is,
"allocate no more than is minimally necessary to contain the modules which
are currently in the library". They basically leave no room for expansion,
such as with maintenance.



>
> Carmen Vitullo
>
>
-- 
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]

I think maybe the assumption is no one is using 
LIBRARIES(-LNKLST-) in the CSVLLA00 member ? 
MIGLIB and LINKLIB (SYS1) are automagically added to linklib so I think this is 
why LLA's GOT 'EM 


Carmen Vitullo 

- Original Message -

From: "John McKown"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, June 12, 2019 8:05:15 AM 
Subject: Re: SYS1.MIGLIB and LNKLST 

On Wed, Jun 12, 2019 at 7:49 AM Peter Relson  wrote: 

> >I never apply maintenance to a running system. 
> 
> If true, then it sounds like your case is the exact one for which LNKLST 
> UNALLOCATE and LNKLST ALLOCATE were created. 
> You are (I hope) enlarging an uncataloged-on-this-system SYS1.MIGLIB data 
> set. 
> And the only problem would have been the running system's ENQ on the 
> running system's SYS1.MIGLIB data set. 
> So you use LNKLST UNALLOCATE. 
> Then you do whatever you want with your uncataloged data set. 
> 
> There would have been no reason to stop LLA. 
> 

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, 
ENTER DSNAME WITHOUT QUOTES - NO LEADING BLANKS, 




> 
> But if you are playing with LNKLST SETs then either you shouldn't be or 
> your initial statement is not true. 
> 
> There is no way to remove SYS1.MIGLIB from a LNKLST set. You would have 
> had to IPL with a SYSLIB MIGLIB statement. 
> 
> And while you appear to have lucked out in whatever you did, you put your 
> system at risk while you were doing it. 
> 
> Peter Relson 
> z/OS Core Technology Design 
> 
> 
-- 
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 


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

Re: Copy error Java module

[Barkow, Eileen]

Select the BINARY option

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Tuesday, June 11, 2019 11:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Copy error Java module

Hi

Cross posted

I am trying to copy a java load module JVMLDMxx using TSO ISHELL copy function 
to a preallocated dataset with the attribute(library type, 
recfm=u,blocksize=32760).

It fails with message

THERE ID A RECORD FORMAT ERROR FOR A MVS DATASET SYS5.JAVA.LOADLIB. EITHER THE 
OUTPUT RECORD FORMAT IS UNDEFINED FOR A TEXT INPUT FILE, OR THE OUTPUT RECORD 
FORMAT IS NOT VALID

Has anyone faced this message and what is the attribute of output dataset that 
can help moving the module from OMVS to a MVS.

Jake

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



This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail 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: SYS1.MIGLIB and LNKLST

[Carmen Vitullo]

Just as an aside, the underlying issue is LPALIB, LINKLIB and MIGLIB are 
underallocated in the ServerPac dialog, I've opened a case with the serverpac 
folks years ago and alway "TRY" to remember to change the allocation of these 
libraries prior to them being allocated. 
the libraries are allocated with just enough space to install the OS from the 
ServerPac, no room for maint in most cases. 



Carmen Vitullo 

- Original Message -

From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, June 12, 2019 6:07:46 AM 
Subject: Re: SYS1.MIGLIB and LNKLST 

Big Thumbs up! In that case, assuming you have access, you could have just 
allocated a larger .NEW version, copy old to new, and done the renames via ISPF 
3.4 with VOLSER, and bypassed the enqueuer warnings? Would have saved a lot of 
fanagaling 

_
 
Dave Jousma 
AVP | Manager, Systems Engineering 

Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 
616.653.8429 | fax: 616.653.2717 


-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Veryl Ellis 
Sent: Tuesday, June 11, 2019 3:43 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SYS1.MIGLIB and LNKLST 

**CAUTION EXTERNAL EMAIL** 

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails** 

Applying maintenance to a target SYSRES volume. 
I never apply maintenance to a running system. 

S. Veryl 

-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David 
Sent: Tuesday, June 11, 2019 3:32 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SYS1.MIGLIB and LNKLST 

Veryl, 


You are getting a lot of feedback that I consider a bit scary. Can you clarify 
something? Are you trying to apply maintenance to your running SYSRES? Or a 
copy of it, and are dealing with that type of enqueuer? If the latter, then 
yes, allocate a .NEW version of MIGLIB, copy the contents from the old to the 
new, and using appropriate tools, do the renames. 

If you are contemplating doing these activities on your running system, well 
then, let me pop up a bowl of popcorn, and pour a cocktail for this show. 

_
 
Dave Jousma 
AVP | Manager, Systems Engineering 

Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 
616.653.8429 | fax: 616.653.2717 


-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Veryl Ellis 
Sent: Tuesday, June 11, 2019 2:59 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: SYS1.MIGLIB and LNKLST 

**CAUTION EXTERNAL EMAIL** 

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails** 

I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran out 
of space (S/D37). 
Can anyone tell me how to get SYS1.MIGLIB out of the running Link List 
concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB? 
The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't 
work on SYS1.MIGLIB. 

Thanks for any assist. 



S. Veryl Ellis 


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails** 


This e-mail transmission contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated. 

-- 
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 **CAUTION EXTERNAL 
EMAIL** 

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails** 


This e-mail transmission contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. 

Re: SYS1.MIGLIB and LNKLST

[John McKown]

On Wed, Jun 12, 2019 at 7:49 AM Peter Relson  wrote:

> >I never apply maintenance to a running system.
>
> If true, then it sounds like your case is the exact one for which LNKLST
> UNALLOCATE and LNKLST ALLOCATE were created.
> You are (I hope) enlarging an uncataloged-on-this-system SYS1.MIGLIB data
> set.
> And the only problem would have been the running system's ENQ on the
> running system's SYS1.MIGLIB data set.
> So you use LNKLST UNALLOCATE.
> Then you do whatever you want with your uncataloged data set.
>
> There would have been no reason to stop LLA.
>

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,
ENTER DSNAME WITHOUT QUOTES - NO LEADING BLANKS,




>
> But if you are playing with LNKLST SETs then either you shouldn't be or
> your initial statement is not true.
>
> There is no way to remove SYS1.MIGLIB from a LNKLST set. You would have
> had to IPL with a SYSLIB MIGLIB statement.
>
> And while you appear to have lucked out in whatever you did, you put your
> system at risk while you were doing it.
>
> Peter Relson
> z/OS Core Technology Design
>
>
-- 
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: Save the date - Next meeting of the GSE UK Security Working Group

[z/OS scheduler]

I suppose It will become more and more exclusive as Brexit Progresses?

Op ma 18 mrt. 2019 om 14:08 schreef Mark Wilson :

> Ladies and Gentlemen,
>
> We are pleased to announce that the next meeting of the GSE UK Security
> Working Group, will take place on Thursday 6th June 2019 at the new offices
> of RSM Partners in Bromsgrove, UK (a 40 minute drive from Birmingham
> Airport). Please note that registration is now open, which you can access
> via our Events page >
> http://www.racf.gse.org.uk/content/content_events.php
>
> The agenda is currently being finalised and will be published at the end
> of March.
>
> Please save the date in your calendar and keep an eye on your mailbox for
> further updates from us.
>
> Regards
>
> Mark Wilson and Jamie Pease
>
> Jamie Pease CISA, CISM, CISSP, MBCS CITP
>
> Chairman of the GSE UK Security Working Group
>
> Website: www.racf.gse.org.uk
> Email: jamie.pe...@gse.org.uk
> Mobile: +44(0)7961 971938
>
>
> --
> 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

DCOLLECT and IGD103I and IGD104I

[Elardus Engelbrecht]

Good day

What is DCOLLECT doing with these datasets and showing these messages?

IGD103I SMS ALLOCATED TO DDNAME SYS03179   
IGD104I ???.???.???   RETAINED,  
DDNAME=SYS03179

We just use this IDCAMS statement plus the MCDS and BCDS DD statements in the 
DCOLLECT batch job:

   DCOLLECT OUTFILE (???) VOLUMES (*) EXV  (EX*, ...etc...) 

Of course FACILITY Class, profile STGADMIN.IDC.DCOLLECT is in place. (With this 
profile, it does not matter whether the DCOLLECT job has access to these 
datasets or not.)

Out of gazillion datasets and volsers details, we are getting about 3000 such 
IGD103I and IGD104I messages. 

Does DCOLLECT want more info from the VTOC entries or Catalogs? Where is this 
behaviour documented?

Many thanks in advance.

Groete / Greetings
Elardus Engelbrecht

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

>I never apply maintenance to a running system.

If true, then it sounds like your case is the exact one for which LNKLST 
UNALLOCATE and LNKLST ALLOCATE were created.
You are (I hope) enlarging an uncataloged-on-this-system SYS1.MIGLIB data 
set.
And the only problem would have been the running system's ENQ on the 
running system's SYS1.MIGLIB data set.
So you use LNKLST UNALLOCATE.
Then you do whatever you want with your uncataloged data set. 

There would have been no reason to stop LLA.

But if you are playing with LNKLST SETs then either you shouldn't be or 
your initial statement is not true.

There is no way to remove SYS1.MIGLIB from a LNKLST set. You would have 
had to IPL with a SYSLIB MIGLIB statement.

And while you appear to have lucked out in whatever you did, you put your 
system at risk while you were doing it.

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

[Elardus Engelbrecht]

Charles Mills wrote:

>What happens if an SMF exit modifies the SMF record? Do the next exit in the 
>chain, SYS1.MANx and/or the stream see the modified record, or is the exit 
>only modifying a "private copy" of the SMF record?

It should be able to do that provided the SMF exit is getting the address 
(fullword) of the SMF record in register 1. Each SMF record is passed to an 
installation exit (either IEFU83, IEFU84, or IEFU85) before it is written to 
the SMF data set. But there is one catch, Inside the SMF exit, you cannot use 
the SMFWTM or SMFEWTM macro to write to the SMF data set, because the exits are 
called by SMFWTM/SMFEWTM.

Of course, SMF records needed to be collected and then written out instead of 
being suppressed by the exits themselves.

Cheryl Watson and Frank Kyne once wrote in November 2014 this:

"An application would pass a record to SMF using the SMFWTM macro, and SMF 
would call IEFU83 with the record. The exit could choose to delete the record, 
modify it or perform some action based on the record’s contents. "

(From: 
http://enterprisesystemsmedia.com/article/smf-exits-and-the-life-of-a-job )


>It would seem to me to be an important point, and the documentation is pretty 
>much silent (or I am visually challenged). However, I tend to interpret "Word 
>1: The address of the record that SMF is to write" as implying that there is 
>only a single copy that will get passed on down the line.

Your interpretation is correct, but strangely just like you and Scott 
Ballentine, I also don't see it documented specifically that your SMF exits can 
modify a record all the way from one exit to other until it is finally written 
out to the SMF VSAM datasets.

I believe the reason is that due to security and integrity of the SMF records 
themselves, IBM is not talking much about it. 

For IEFACTRT, I see this note: 

"When the data for an SMF record exceeds 32,756 bytes in length, the system 
constructs one or more "continuation" or "additional" records to ensure that no 
individual record exceeds that length. The system invokes IEFACTRT once for the 
original record and once for each continuation record."

So, I believe SMF records can be changed many times until it is written out 
finally.


>I will submit an RCF once I get a definitive answer here.

Please do so.

Groete / Greetings
Elardus Engelbrecht

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

[Veryl Ellis]

Yeah, I thought of that also, but still had to contend with the ENQ / LNKLST 
issue.

Thanks,

S. Veryl Ellis 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
ITschak Mugzach
Sent: Wednesday, June 12, 2019 2:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

another option is to override SMP DDDEF in job JCL to the newly allocated & 
populated dataset. at end, you can do the renames, unallocation of lla, etc.

ITschak

On Tue, Jun 11, 2019 at 10:49 PM Carmen Vitullo  wrote:

> One of my first contracting jobs was working for state gov'mt, y2k, 
> and my first task was to apply maint to the current OS, the SMP/E 
> environment was pointing to a live sandbox system, I pointed this out 
> to my boss, and he said yeah, we do this all the time, :( so I 
> understand where David is coming from.
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Veryl Ellis" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Tuesday, June 11, 2019 2:42:57 PM
> Subject: Re: SYS1.MIGLIB and LNKLST
>
> Applying maintenance to a target SYSRES volume.
> I never apply maintenance to a running system.
>
> S. Veryl
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Jousma, David
> Sent: Tuesday, June 11, 2019 3:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYS1.MIGLIB and LNKLST
>
> Veryl,
>
>
> You are getting a lot of feedback that I consider a bit scary. Can you 
> clarify something? Are you trying to apply maintenance to your running 
> SYSRES? Or a copy of it, and are dealing with that type of enqueuer? 
> If the latter, then yes, allocate a .NEW version of MIGLIB, copy the 
> contents from the old to the new, and using appropriate tools, do the renames.
>
> If you are contemplating doing these activities on your running 
> system, well then, let me pop up a bowl of popcorn, and pour a 
> cocktail for this show.
>
> __
> ___
>
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, 
> MI
> 49546
> 616.653.8429 | fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Veryl Ellis
> Sent: Tuesday, June 11, 2019 2:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SYS1.MIGLIB and LNKLST
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> I'm applying maintenance to my target SYSRES and the target 
> SYS1.MIGLIB ran out of space (S/D37).
> Can anyone tell me how to get SYS1.MIGLIB out of the running Link List 
> concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB?
> The standard SETPROG LNKLST stuff to delete a DSN from the link list 
> doesn't work on SYS1.MIGLIB.
>
> Thanks for any assist.
>
>
>
> S. Veryl Ellis
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
>
> This e-mail transmission contains information that is confidential and 
> may be privileged. It is intended only for the addressee(s) named 
> above. If you receive this e-mail in error, please do not read, copy 
> or disseminate it in any manner. If you are not the intended 
> recipient, any disclosure, copying, distribution or use of the contents of 
> this information is prohibited.
> Please reply to the message immediately by informing the sender that 
> the message was misdirected. After replying, please erase it from your 
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> 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
>


--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for 
Legacy **|  *

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

Re: SYS1.MIGLIB and LNKLST

[Veryl Ellis]

That is what I ultimately did, once I was passed the enq / lnklst issue.

Thanks,

S. Veryl Ellis 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Wednesday, June 12, 2019 7:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

Big Thumbs up!   In that case, assuming you have access, you could have just 
allocated a larger .NEW version, copy old to new, and done the renames via ISPF 
3.4 with VOLSER, and bypassed the enqueuer warnings?   Would have saved a lot 
of fanagaling

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Veryl Ellis
Sent: Tuesday, June 11, 2019 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Applying maintenance to a target SYSRES volume.
I never apply maintenance to a running system.

S. Veryl 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Tuesday, June 11, 2019 3:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

Veryl,


You are getting a lot of feedback that I consider a bit scary.   Can you 
clarify something?   Are you trying to apply maintenance to your running 
SYSRES?  Or a copy of it, and are dealing with that type of enqueuer?   If the 
latter, then yes, allocate a .NEW version of MIGLIB, copy the contents from the 
old to the new, and using appropriate tools, do the renames.

If you are contemplating doing these activities on your running system, well 
then, let me pop up a bowl of popcorn, and pour a cocktail for this show.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Veryl Ellis
Sent: Tuesday, June 11, 2019 2:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SYS1.MIGLIB and LNKLST

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran out 
of space (S/D37).
Can anyone tell me how to get SYS1.MIGLIB out of the running Link List 
concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB?
The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't 
work on SYS1.MIGLIB.

Thanks for any assist.



S. Veryl Ellis


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is 

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

[Scott Ballentine]

The IEFU8x exits get the "live" record, so yes, any updates that the exit makes 
would get passed on down the line.

I thought this was documented, but I did a quick search and didn't find it 
either.  (There are some places that hint at it but I didn't find anything that 
spells it out.)

-Scott Ballentine, z/OS Development
 sbal...@us.ibm.com

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

DADSM/CVAF

[Buckton, T. (Theo)]

Hi,

How is the parameter CVAFDIR ACCESS=WRITE implemented? Any links to 
documentation explaining the implementation?

Regards

Nedbank Group Limited Internal Use Only


Nedbank disclaimer and confidentiality notice:

This email may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this email or all or some of the information contained therein, do not 
duplicate or redistribute it by any means. Please delete it and any attachments 
and notify the sender that you have received it in error. Unless specifically 
indicated, this email is neither an offer or a solicitation to buy or sell any 
securities, investment products or other financial product or service, nor is 
it an official confirmation of any transaction or an official statement of 
Nedbank. Any views or opinions presented are solely those of the author and do 
not necessarily represent those of Nedbank. Nedbank Ltd Reg No 1951/09/06.

The following link displays the names of the Nedbank Board of Directors and 
Company Secretary. [http://www.nedbank.co.za/terms/DirectorsNedbank.htm]

If you do not want to click on a link, please type the relevant address in your 
browser




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

Re: What (presumably SYSEVENT) function is equivalent to "E job,Q"

[Rob Scott]

WLM services macro : IWMRESET

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Wednesday, June 12, 2019 12:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What (presumably SYSEVENT) function is equivalent to "E job,Q"

What (presumably SYSEVENT) function is equivalent to "E job,Q"

I am trying to test something while the job is being quiesced. And I am not 
sure of the timing should I use MGCR(E).

--
Binyamin Dissen 
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dissensoftware.comdata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C02c7dca9db7d4936095a08d6ef25c0b5%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636959342774409730sdata=O0vtXmGnuIEE1VMrmcYgJ%2BECiWqCQf0cz4ueyrdsIv8%3Dreserved=0

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

[Jousma, David]

Big Thumbs up!   In that case, assuming you have access, you could have just 
allocated a larger .NEW version, copy old to new, and done the renames via ISPF 
3.4 with VOLSER, and bypassed the enqueuer warnings?   Would have saved a lot 
of fanagaling

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Veryl Ellis
Sent: Tuesday, June 11, 2019 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Applying maintenance to a target SYSRES volume.
I never apply maintenance to a running system.

S. Veryl 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Tuesday, June 11, 2019 3:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS1.MIGLIB and LNKLST

Veryl,


You are getting a lot of feedback that I consider a bit scary.   Can you 
clarify something?   Are you trying to apply maintenance to your running 
SYSRES?  Or a copy of it, and are dealing with that type of enqueuer?   If the 
latter, then yes, allocate a .NEW version of MIGLIB, copy the contents from the 
old to the new, and using appropriate tools, do the renames.

If you are contemplating doing these activities on your running system, well 
then, let me pop up a bowl of popcorn, and pour a cocktail for this show.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Veryl Ellis
Sent: Tuesday, June 11, 2019 2:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SYS1.MIGLIB and LNKLST

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran out 
of space (S/D37).
Can anyone tell me how to get SYS1.MIGLIB out of the running Link List 
concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB?
The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't 
work on SYS1.MIGLIB.

Thanks for any assist.



S. Veryl Ellis


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

What (presumably SYSEVENT) function is equivalent to "E job,Q"

[Binyamin Dissen]

What (presumably SYSEVENT) function is equivalent to "E job,Q"

I am trying to test something while the job is being quiesced. And I am not
sure of the timing should I use MGCR(E).

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

Re: Just how secure are mainframes? | Trevor Eddolls

[R.S.]

There were other ESMs.
I'm aware of at least two.
One was Deadbolt from JMenterprises (or so). One of Deadbolt developers 
is member of IBM-MAIN (maybe more, I know one).
The second product was PIES. It was polish product. I don't think it was 
in use outside of Poland.


--
Radoslaw Skorupka
Lodz, Poland







W dniu 2019-06-11 o 18:25, Bob Bridges pisze:

If that's what it stands for I should think those aren't just the big three but 
the ~only~ three.  At least, I've never heard of any others.  Which is odd, 
when you think about it; surely there's someone out there wanting to break into 
the market?  So says my capitalist assumptions.  But apparently not.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Nearly all men can stand adversity.  If you want to test a man's character, 
give him power.  -Abraham Lincoln */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Thursday, May 30, 2019 11:22

I have been under the impression it stands for External Security Manager, of which the 
"big 3" would be RACF, ACF2, Top Secret.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: Thursday, May 30, 2019 10:21 AM

I've seen the acronym ESM a few times in this thread.  I'll assume that means 
"Enterprise Security Management", and I'll guess it refers to security 
processes (not RACF), such as assigning userid's, making sure people have just the access 
they need, periodic audits, etc.

Am I even close?

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




==

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

[ITschak Mugzach]

another option is to override SMP DDDEF in job JCL to the newly allocated &
populated dataset. at end, you can do the renames, unallocation of lla,
etc.

ITschak

On Tue, Jun 11, 2019 at 10:49 PM Carmen Vitullo  wrote:

> One of my first contracting jobs was working for state gov'mt, y2k, and my
> first task was to apply maint to the current OS, the SMP/E environment was
> pointing to a live sandbox system, I pointed this out to my boss, and he
> said yeah, we do this all the time, :( so I understand where David is
> coming from.
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Veryl Ellis" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Tuesday, June 11, 2019 2:42:57 PM
> Subject: Re: SYS1.MIGLIB and LNKLST
>
> Applying maintenance to a target SYSRES volume.
> I never apply maintenance to a running system.
>
> S. Veryl
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Jousma, David
> Sent: Tuesday, June 11, 2019 3:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYS1.MIGLIB and LNKLST
>
> Veryl,
>
>
> You are getting a lot of feedback that I consider a bit scary. Can you
> clarify something? Are you trying to apply maintenance to your running
> SYSRES? Or a copy of it, and are dealing with that type of enqueuer? If the
> latter, then yes, allocate a .NEW version of MIGLIB, copy the contents from
> the old to the new, and using appropriate tools, do the renames.
>
> If you are contemplating doing these activities on your running system,
> well then, let me pop up a bowl of popcorn, and pour a cocktail for this
> show.
>
> _
>
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
> 49546
> 616.653.8429 | fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Veryl Ellis
> Sent: Tuesday, June 11, 2019 2:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SYS1.MIGLIB and LNKLST
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB
> ran out of space (S/D37).
> Can anyone tell me how to get SYS1.MIGLIB out of the running Link List
> concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB?
> The standard SETPROG LNKLST stuff to delete a DSN from the link list
> doesn't work on SYS1.MIGLIB.
>
> Thanks for any assist.
>
>
>
> S. Veryl Ellis
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
> EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
>
> This e-mail transmission contains information that is confidential and may
> be privileged. It is intended only for the addressee(s) named above. If you
> receive this e-mail in error, please do not read, copy or disseminate it in
> any manner. If you are not the intended recipient, any disclosure, copying,
> distribution or use of the contents of this information is prohibited.
> Please reply to the message immediately by informing the sender that the
> message was misdirected. After replying, please erase it from your computer
> system. Your assistance in correcting this error is appreciated.
>
> --
> 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
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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