Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread Donald Russell
Thank you all for the suggestions on compressing  my data.  I’ve got a lot
of reading/following up to do. :-)

Cheers,
Don



On Sun, Jun 30, 2019 at 12:51 David Mingee  wrote:

> Hello,  You can consider adding the command  MODE C  before the PUT
> command in your FTP.  This will compress the file during transmit only.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Donald Russell
> Sent: Sunday, June 30, 2019 3:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Using bpxbatch to compress an MVS dataset
>
> I sincerely appreciate people’s feedback on this subject but the problem
> I’m trying to solve is how to compress the file, not whether compression is
> needed. The decision to compress was made based on frequency of use,
> bandwidth between source and destination and difference in file
> size/transmission time, the value of that benefit etc.
>
> Currently I use pkzip to create a gzip file. If I can accomplish this with
> bpxbatch then I may be able to cancel the pkzip license. The other aspect
> is I’d like to run this on an mvs system that doesn’t have non-ibm products
> on it so bpxbatch may be available whereas pkzip is not.
>
> Don
>
>
>
> On Sun, Jun 30, 2019 at 10:51 Thomas Kern <
> 0041d919e708-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Another consideration is how many times the compressed file would be
> > transferred. We used to host lots of documents on our mainframe to be
> > served out on a website. When the transfer load became noticeable on
> > the performance reports, we started compressing the most common
> documents.
> > The transfer load dropped dramatically and Management decided to
> > compress all documents before loading them into the website.
> >
> >
> > /Tom Kern
> >
> > On 06/30/2019 12:45, Donald Russell wrote:
> > > I???m not considering the cost of compression  in relation to the
> > transfer
> > > savings because the size of the files is huge (several million lines
> > > of
> > > text) that compress really well. Pkzip/gzip seems to get well over
> > > 80% compression. Then yes, after the mvs job step runs, the ftp
> > > target is in another city or even continent, and the ftp traffic is
> > > encrypted inflight using ftps.
> > >
> > > My goal is to to compress the text file prior to ftp.
> > >
> > > Can bpxbatch programs like tar read/write from/to dd names, or fully
> > > qualified dataset names instead of Unix-like file paths?
> > >
> > > Don
> > >
> > >
> > > On Sun, Jun 30, 2019 at 09:19 Steve Thompson 
> wrote:
> > >
> > >> If this file is being sent inside your firewall, the time and CPU
> > >> cycles will cost more than the ftp. This is based on experiences
> > >> using MFT products. (Basically what Gadi said).
> > >>
> > >> We found in testing that compressing was really only useful with
> > >> small pipes. Of course, there is a ratio between number of bytes to
> > >> transfer
> > and
> > >> bandwidth in determining the effectiveness of the compression (and
> > >> compression method).
> > >>
> > >> Now, if this is confidential data, and is going outside of your
> > firewall,
> > >> you have to consider encryption. Compress first, then encrypt,
> > >> because encrypted data is generally uncompressable.
> > >>
> > >> HTH
> > >> Steve Thompson
> > >>
> > >> Sent from my iPhone ??? small keyboarf, fat fungrs, stupd spell
> manglr.
> > >> Expct mistaks
> > >>
> > >>
> > >>> On Jun 30, 2019, at 12:05 PM, Gadi Ben-Avi  wrote:
> > >>>
> > >>> If both systems are on the same physical computer, it might not be
> > worth
> > >> it.
> > >>> The time and cpu cycles it would take to compress and uncompress
> > >>> might
> > >> take longer than transferring the un compressed file.
> > >>>
> > >>>
> > >>> -Original Message-
> > >>> From: IBM Mainframe Discussion List  On
> > >> Behalf Of Donald Russell
> > >>> Sent: Sunday, June 30, 2019 6:58 PM
> > >>> To: IBM-MAIN@LISTSERV.UA.EDU
> > >>> Subject: Using bpxbatch to compress an MVS dataset
> > >>>
> > >>> I have a batch process in zOS 2.1 (soon to be 2.3) that creates a
> > >>> large
> > >> text file I want to FTP to a zLinux system.
> > >>> How can I use bpxbatch tar or compress (or ?) to create a smaller
> > >>> file
> > I
> > >> can ftp instead instead of the original file? I don???t want to use
> > pkzip
> > >> unless that???s the only choice. Terse is no good because Linux
> > >> can???t
> > unterse
> > >> it.
> > >>> Is there a way to specify a DD name for the input and output
> > >>> files,
> > >> similar to how FTP allows put/get //DD:
> > >>> Part two... the text in the file is EBCDIC, but Linux wants ASCII.
> > >>> I
> > >> don???t see an option to do the conversion.
> > >>> I???ll have to check tr, but maybe there???s a way to use more
> > traditional
> > >> Unix syntax like
> > >>> cat //dd:in | tr ... | tar -cv //dd:out
> > >>>
> > >>> Cheers,
> > >>> Don
> > >>>
> > >>> --
> > >>>  For IBM-MAIN 

Re: listcat with only dsn

2019-07-01 Thread David Spiegel
OK, but, what if you want to use masking characters in the DSNAME (a la 
3.4)?

On 2019-07-01 19:57, Sri h Kolusu wrote:
 I need to generate a listcat with only the dsn. like in 3.4 but I
>> want it in a dataset with ONLY the dsn.
> Elaine,
>
> If your intention is to just get list of all datasets for a particular HLQ,
> then it is quite simple. Run LISTCAT via TSO and then strip off the
> unwanted data.
>
> Something like this
>
> //  EXPORT SYMLIST=*
> // SET HLQ='ELAINE'
> //*
> //*
> //* ISSUE LISTCAT ON LEVEL FOR THE USERID**
> //*
> //STEP0100 EXEC PGM=IKJEFT01
> //SYSTSPRT DD DSN=&,DISP=(,PASS),SPACE=(CYL,(5,5),RLSE),
> //DCB=(LRECL=80,RECFM=FB,BLKSIZE=0)
> //SYSTSIN  DD *,SYMBOLS=JCLONLY
>LISTCAT LEVEL('') NAME
> //*
> //*
> //* STRIP OFF THE HEADERS AND CATALOG INFO FROM THE LISTCAT  **
> //* OUTPUT AND CREATE LIST OF THE DATASETS FOR THE USER  **
> //*
> //STEP0200 EXEC PGM=SORT
> //SYSOUT   DD SYSOUT=*
> //SORTIN   DD DISP=(OLD,PASS),DSN=&
> //SORTOUT  DD SYSOUT=*
> //SYSINDD *
>OPTION COPY
>OMIT COND=(01,05,CH,EQ,C'READY',OR,
>   01,03,CH,EQ,C'END',OR,
>   06,06,CH,EQ,C'IN-CAT',OR,
>   03,08,CH,EQ,C'LISTCAT ')
>
>INREC BUILD=(17,44)
> //*
>
>
> Thanks,
> Kolusu
>
>
> --
> 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: Best way to alert customer to pending license expiration?

2019-07-01 Thread Mike Schwab
How about message identifier xxxRENEW, where the xxx is the (IBM
registered) company / product MSG prefix?  This would be in addition to
existing messages. Then the site automation notifies their software license
manager.

On Mon, Jul 1, 2019, 15:43 Charles Mills  wrote:

> THANK YOU ALL for taking the time to provide your input. The management
> decision is to keep it simple and put out a vanilla WTO that will be
> distinct and easy to automate.
>
> Let me do one e-mail in response to your many, many helpful details:
>
> > IMHO the best way is a WTO that is easy to catch in the customer's
> automation software.
>
> Thank you @Shmuel. I agree that is the approach.
>
> > Wouldn't it be nice if there were a multi-ISV convention for format of
> expiration alerts?
>
> Vendor collaboration on anything license-related alarms the anti-trust
> lawyers.
>
> > Or even for messages requiring human attention?
>
> I think one person's "needs human attention" is another person's "ho-hum."
>
> > The customer has a responsibility to manage their own system.
> > The fact that many do not (completely) is not really something you can
> solve.
>
> Agreed. But I still keep trying. :-( There is no software feature that
> substitutes for management. I keep forgetting that.
>
> > I don't know why the sales team can't keep track of what they've sold
>
> Neither do I, but I'm a programmer, not a psychologist or a VP of Sales.
> In my experience they at least DO not, not reliably.
>
> > And to be totally crazy maybe the salesperson could actually visit the
> customer.
>
> That train has largely left the station. That is a HUGE, HUGE cost that
> would have to be passed on to you-know-who. And customers do not want to
> take the time to have someone in their offices. I miss the days when -- as
> the technical, non-sales CEO of my old company -- I could call someone up
> and say "hey, I'm going to be in Pittsburgh next month, can I take you to
> lunch?" and they would be delighted. Nowadays they would not pick up the
> phone. I really miss those days.
>
> > From my experience over the past few decades on the customer side there
> is no
> > full proof means to inform the customer of an expiring license.
>
> Sadly, I fear you are right.
>
> > My software emails the customer a notice once a day,
>
> I like it, but not going to go there at this time. Will keep that in mind.
>
> > You're assuming that the target machine has the technical connectivity
> to "call home,"
> > or, that if it doesn't, the operators and managers of the target machine
> would agree to
> > such connectivity and configure it. I don't think you can make those
> assumptions.
>
> Agreed. In spades.
>
> > So if I can tell the software - when you hit 30 days, then produce
> > a message to syslog and set the RC to 08 - but only if this tool is
> run.
>
> I like it. I want to keep this in mind.
>
> > The WTO would go to someone to low in the pecking order to make this
> worthwhile.
>
> Agreed.
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Re: listcat with only dsn

2019-07-01 Thread Sri h Kolusu
>>> I need to generate a listcat with only the dsn. like in 3.4 but I
> want it in a dataset with ONLY the dsn.

Elaine,

If your intention is to just get list of all datasets for a particular HLQ,
then it is quite simple. Run LISTCAT via TSO and then strip off the
unwanted data.

Something like this

//  EXPORT SYMLIST=*
// SET HLQ='ELAINE'
//*
//*
//* ISSUE LISTCAT ON LEVEL FOR THE USERID**
//*
//STEP0100 EXEC PGM=IKJEFT01
//SYSTSPRT DD DSN=&,DISP=(,PASS),SPACE=(CYL,(5,5),RLSE),
//DCB=(LRECL=80,RECFM=FB,BLKSIZE=0)
//SYSTSIN  DD *,SYMBOLS=JCLONLY
  LISTCAT LEVEL('') NAME
//*
//*
//* STRIP OFF THE HEADERS AND CATALOG INFO FROM THE LISTCAT  **
//* OUTPUT AND CREATE LIST OF THE DATASETS FOR THE USER  **
//*
//STEP0200 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DISP=(OLD,PASS),DSN=&
//SORTOUT  DD SYSOUT=*
//SYSINDD *
  OPTION COPY
  OMIT COND=(01,05,CH,EQ,C'READY',OR,
 01,03,CH,EQ,C'END',OR,
 06,06,CH,EQ,C'IN-CAT',OR,
 03,08,CH,EQ,C'LISTCAT ')

  INREC BUILD=(17,44)
//*


Thanks,
Kolusu


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


Re: WTO for message that will require explicit deletion?

2019-07-01 Thread Charles Mills
Thanks all for your help. I have given up on this direction. The effort is
possibly ill-advised, but in any event I am under-knowledgeable, have no
real console to test with or observe, and find the documentation less than
sufficient to this task.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, June 30, 2019 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO for message that will require explicit deletion?

@Peter, thanks.

Frankly, the documentation of the more esoteric aspects of WTO seems
haphazard to this observer. I think WTO's clarity of documentation suffers
from the various things that have been layered on over the years such as
MCS. As I wrote in the OP, the idea that DESC=3 requires an explicit delete
comes from this in the doc: "If the task can determine when the operator has
performed the action, the task should issue a DOM macro to delete the
message." That is not logically the same as the statement "the message will
hang out until it is explicitly deleted" but for better or worse that is
what I inferred.

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


Re: listcat with only dsn

2019-07-01 Thread Kirk Wolf
FYI, Co:Z includes a z/OS Unix "catsearch" shell command, which can print
just the DSN or also an ISPF 3.4-like listing.
https://dovetail.com/docs/dspipes/dsp-ref_catsearch.html
Co:Z is free to use under our Community License.



On Mon, Jul 1, 2019 at 5:50 PM Mark Zelden  wrote:

> On Fri, 28 Jun 2019 19:10:45 -0500, Mark Zelden  wrote:
>
> >using "NAME" produces two lines (one that includes that catalog).  Once
> you know that catalog
> >adding "CAT(blahblah)" to the LISTCAT will give one line per dataset name.
> >
> >A better option is my version of IGGCSI00 - CATSRCH.  It can be used with
> a panel or
> >just by itself -"TSO CATSRCH dsn.pattern.** .   However, the output
> goes in a browse
> >temp data set so you have to use TSO ISRDDN (or the DDLIST line command)
> to edit the data set
> >or save it some place from there.
> >
> >The best option may be to use this simple CLIST (not on my web site /
> CBT).  You can
> >pass the DSN level to it (default is your userid).  I call it
> "DSLISTSV".  It will save the list
> >as a single data set per line in "userid.SAVE.DATASETS".
> >
>
> 
>
> >Should I add this to my CBT file?  If I do, I would also add "MEMLISTSV":
> >
>
> No one said yes, but I added them to CBT file 434 and my web site anyway.
>
> BTW, sometime in the last 24 hours I hit over 700,000 visitors on my web
> site!
> Thanks for your support!  :-)
>
>
> Regards,
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> ITIL v3 Foundation Certified
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://search390.techtarget.com/ateExperts/
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread Kirk Wolf
- Java's java.util.zip package (and the jar command) will use zEDC.

- z/OS OpenSSH - see the "zEDCCompression" option.

- I'm not sure about IBM pax, seems unlikely since it was not documented.

- It appears that Rocket's gzip port does support zEDC.





On Mon, Jul 1, 2019 at 11:31 AM Mark Jacobs <
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> Does that use the zEDC compression feature if's available on your system?
>
> Mark Jacobs
>
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, July 1, 2019 11:51 AM, Kirk Wolf 
> wrote:
>
> > jar is zip compatible.
> > https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jarGuide.html
> >
> > Also the Java sdk has an API to read/write zip / deflate files.
> >
> > There is a JZOS sample program that shows how to create a zip archive
> using
> > z/OS data sets as input / output.
> >
> > https://github.com/zsystems/java-samples/blob/master/ZipDatasets.java
> >
> > On Sun, Jun 30, 2019 at 3:46 PM Paul Gilmartin <
> > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > On Sun, 30 Jun 2019 20:34:19 +, Denis wrote:
> > >
> > > > I wonder if the jar command of the Java SDK in z/OS creates gzip
> > > > compatible jar files, which in Windows can be extracted/used by
> renaming
> > > > Form .jar to .ZIP.I cannot remember if the jar compression uses
> ziip.Any
> > > > file type can be added to a jar, but I have not tried dd names.
> > >
> > > I believe jar uses zip deflate. I've used it to unpack zipped files
> from
> > > cbttape.org.
> > > I believe jar isn't fussy about filenames -- you can bypass the rename.
> > > Jar syntax is most similar to tar.
> > > -- gil
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> 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: GIM40101E PTF already applied

2019-07-01 Thread Jesse 1 Robinson
I cannot see any reason for running a real APPLY that does not look exactly 
like the immediately preceding APPLY CHECK. Whatever you may learn from the 
CHECK should not alter your APPLY process. That's why CHECK exists. If you 
rerun CHECK to look exactly like the problematic APPLY, you will see squirrely 
messages there too. 

I always recommend to people some like this.

   APPLY [some set of selection criteria]   CHECK
   ...
   APPLY [same set of selection criteria]  /* CHECK */

In other words, just comment out the CHECK. Editing the APPLY in any other way 
is just begging for trouble.

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Monday, July 1, 2019 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: GIM40101E PTF already applied

On Mon, 1 Jul 2019 12:43:43 -0500, Elaine Beal wrote:

>I am running an apply check and get messages because PTFs required as co or 
>pre-req are already applied.
>do I have to individually exclude these ptf's? It looks like aypassapplycheck 
>is good only on accept.

GIM40101E? That message doesn't say "already applied". It says:

command PROCESSING FAILED FOR SYSMOD sysmod EVEN THOUGH IT  
WAS SPECIFIED ON THE SELECT OPERAND. sysmod IS NOT IN THE   
zonetype ZONE.  

Explanation:

command   an SMP/E command  
sysmodSYSMOD ID 
zonetype  zone type 

The indicated SYSMOD was specified on the SELECT operand but
the SYSMOD is not available for SMP/E to process.   

System Action:  SYSMOD processing stops.

--
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: listcat with only dsn

2019-07-01 Thread Mark Zelden
On Fri, 28 Jun 2019 19:10:45 -0500, Mark Zelden  wrote:

>using "NAME" produces two lines (one that includes that catalog).  Once you 
>know that catalog
>adding "CAT(blahblah)" to the LISTCAT will give one line per dataset name.
>
>A better option is my version of IGGCSI00 - CATSRCH.  It can be used with a 
>panel or
>just by itself -"TSO CATSRCH dsn.pattern.** .   However, the output goes 
>in a browse
>temp data set so you have to use TSO ISRDDN (or the DDLIST line command) to 
>edit the data set
>or save it some place from there.
>
>The best option may be to use this simple CLIST (not on my web site / CBT).  
>You can
>pass the DSN level to it (default is your userid).  I call it "DSLISTSV".  It 
>will save the list
>as a single data set per line in "userid.SAVE.DATASETS".  
>



>Should I add this to my CBT file?  If I do, I would also add "MEMLISTSV":
>

No one said yes, but I added them to CBT file 434 and my web site anyway. 

BTW, sometime in the last 24 hours I hit over 700,000 visitors on my web site! 
Thanks for your support!  :-) 


Regards,

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


Re: GIM40101E PTF already applied

2019-07-01 Thread Tom Marchant
On Mon, 1 Jul 2019 12:43:43 -0500, Elaine Beal wrote:

>I am running an apply check and get messages because PTFs required as co or 
>pre-req are already applied.
>do I have to individually exclude these ptf's? It looks like aypassapplycheck 
>is good only on accept.

GIM40101E? That message doesn't say "already applied". It says:

command PROCESSING FAILED FOR SYSMOD sysmod EVEN THOUGH IT  
WAS SPECIFIED ON THE SELECT OPERAND. sysmod IS NOT IN THE   
zonetype ZONE.  

Explanation:

command   an SMP/E command  
sysmodSYSMOD ID 
zonetype  zone type 

The indicated SYSMOD was specified on the SELECT operand but
the SYSMOD is not available for SMP/E to process.   

System Action:  SYSMOD processing stops.

-- 
Tom Marchant

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


Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Pommier, Rex
Hi Tom,

Thanks for correcting my terminology.  I wasn't confusing SMPTLIBs and target 
libraries.  I was confusing SMPTLIBs and RELFILEs.  I had it in my head that 
the RELFILEs were the critters created by the RECEIVE and subsequently used by 
the APPY and ACCEPT, rather than your correct thinking that RELFILEs populate 
the SMPTLIBs at RECEIVE.  I was using TLIBs as an abbreviation for TargetLIBs, 
as in the TLIB=target, DLIB=distribution sense.   I now know, bad form due to 
SMPTLIBs.  

I stand corrected, due to my bad use of abbreviations.

The SMPTLIBs are used in ACCEPT processing (as well as APPLY).  The 
distribution libraries are populated/updated from the SMPTLIBs, not the target 
libraries.

Thanks for the correction.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Monday, July 1, 2019 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

On Mon, 1 Jul 2019 18:29:57 +, Pommier, Rex wrote:

>I don't see how SMP/E can use the TLIBs to populate the DLIBs.  What 
>would it copy across to the DLIB if, like in the OP's case, he wants to 
>ACCEPT the base code but there have been multiple PTFs installed to the 
>TLIBs,

Are you confusing SMPTLIBs with Target libraries? TLIB refers to SMPTLIB data 
sets.
APPLY never updates SMPTLIB data sets.
It reads them when applying the SYSMOD that is packaged in RELFILE format is 
applied or when accepting such a SYSMOD.

>Whereas, the SMPMCS and
>RELFILES would have the original code shipped with the functions and PTFs.  

The SMPMCS and RELFILES are only used during RECEIVE processing.

--
Tom Marchant

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


Re: GIM40101E PTF already applied

2019-07-01 Thread Paul Gilmartin
On Mon, 1 Jul 2019 15:50:42 -0500, Elaine Beal wrote:
>
>I have tried both ways.
>
>originally
>
>SET  BOUNDARY (MVST100) .
>APPLY
> SOURCEID(RSU*)
> GROUPEXTEND
> BYPASS(HOLDSYSTEM)
> CHECK
>
>then I tried SELECTing PTFS with the same issue.
>which makes sense, if they're applied, they're applied:)
> 
I was asking a question, not making a suggestion.  Don't SELECT PTFs that
are already APPLYed.

If SOURCEID is too stupid to ignore APPLYed PTFs, it should be fixed.

-- gil


>Elaine
>
>--
>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: GIM40101E PTF already applied

2019-07-01 Thread Tom Marchant
On Mon, 1 Jul 2019 12:43:43 -0500, Elaine Beal wrote:

>I am running an apply check and get messages because PTFs required as co or 
>pre-req are already applied.
>do I have to individually exclude these ptf's? It looks like aypassapplycheck 
>is good only on accept.

I find this to be helpful in understanding the SYSMOD selection process.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.gim1000/gim118.htm

(There is a similar figure for ACCEPT)

Notice that it starts with SYSMODS that have not yet been applied, and narrows 
down the selection.

Then there is number 4 on this page, where it talks about GROUP and GROUPEXTEND:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.gim1000/appprcs.htm

Notice that each item in the list specifies "Any SYSMOD not already applied".

I would not be able to determine what happened without seeing more of your 
output in SMPOUT. In particular I would like to see every (complete) message 
for one of the SYSMODS that seems to have been incorrectly selected.

I do have one thought, though. Do these SYSMODS have a RESTORE ERROR?

-- 
Tom Marchant

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


Re: Best way to alert customer to pending license expiration?

2019-07-01 Thread Mark Jacobs
Can I make a suggestion? Add the method you'll be using to the contract, 
explaining what's being done, how it's being done, and what happens in the 
customer lets the license expire. That way there are no fingers being pointed 
back at your company due to their failure to handle it correctly.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Monday, July 1, 2019 4:43 PM, Charles Mills  wrote:

> THANK YOU ALL for taking the time to provide your input. The management 
> decision is to keep it simple and put out a vanilla WTO that will be distinct 
> and easy to automate.
>
> Let me do one e-mail in response to your many, many helpful details:
>
> > IMHO the best way is a WTO that is easy to catch in the customer's 
> > automation software.
>
> Thank you @Shmuel. I agree that is the approach.
>
> > Wouldn't it be nice if there were a multi-ISV convention for format of 
> > expiration alerts?
>
> Vendor collaboration on anything license-related alarms the anti-trust 
> lawyers.
>
> > Or even for messages requiring human attention?
>
> I think one person's "needs human attention" is another person's "ho-hum."
>
> > The customer has a responsibility to manage their own system.
> > The fact that many do not (completely) is not really something you can 
> > solve.
>
> Agreed. But I still keep trying. :-( There is no software feature that 
> substitutes for management. I keep forgetting that.
>
> > I don't know why the sales team can't keep track of what they've sold
>
> Neither do I, but I'm a programmer, not a psychologist or a VP of Sales. In 
> my experience they at least DO not, not reliably.
>
> > And to be totally crazy maybe the salesperson could actually visit the 
> > customer.
>
> That train has largely left the station. That is a HUGE, HUGE cost that would 
> have to be passed on to you-know-who. And customers do not want to take the 
> time to have someone in their offices. I miss the days when -- as the 
> technical, non-sales CEO of my old company -- I could call someone up and say 
> "hey, I'm going to be in Pittsburgh next month, can I take you to lunch?" and 
> they would be delighted. Nowadays they would not pick up the phone. I really 
> miss those days.
>
> > From my experience over the past few decades on the customer side there is 
> > no
> > full proof means to inform the customer of an expiring license.
>
> Sadly, I fear you are right.
>
> > My software emails the customer a notice once a day,
>
> I like it, but not going to go there at this time. Will keep that in mind.
>
> > You're assuming that the target machine has the technical connectivity to 
> > "call home,"
> > or, that if it doesn't, the operators and managers of the target machine 
> > would agree to
> > such connectivity and configure it. I don't think you can make those 
> > assumptions.
>
> Agreed. In spades.
>
> > So if I can tell the software - when you hit 30 days, then produce
> > a message to syslog and set the RC to 08 - but only if this tool is run.
>
> I like it. I want to keep this in mind.
>
> > The WTO would go to someone to low in the pecking order to make this 
> > worthwhile.
>
> Agreed.
>
> Charles
>
> ---
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: Best way to alert customer to pending license expiration?

2019-07-01 Thread Lizette Koehler
Charles, one other option some vendor products provide is an MVS Command I can 
issue, and trap with automation, that would let me know expiration when I want 
it.  Rather than running a stand alone program

F tool-stc-name,STATUS

That would provide status of tool and license key


Lizette



> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Charles Mills
> Sent: Monday, July 01, 2019 1:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Best way to alert customer to pending license expiration?
> 
> THANK YOU ALL for taking the time to provide your input. The management
> decision is to keep it simple and put out a vanilla WTO that will be distinct
> and easy to automate.
> 
> Let me do one e-mail in response to your many, many helpful details:
> 
> > IMHO the best way is a WTO that is easy to catch in the customer's
> automation software.
> 
> Thank you @Shmuel. I agree that is the approach.
> 
> > Wouldn't it be nice if there were a multi-ISV convention for format of
> expiration alerts?
> 
> Vendor collaboration on anything license-related alarms the anti-trust
> lawyers.
> 
> > Or even for messages requiring human attention?
> 
> I think one person's "needs human attention" is another person's "ho-hum."
> 
> > The customer has a responsibility to manage their own system.
> > The fact that many do not (completely) is not really something you can
> solve.
> 
> Agreed. But I still keep trying. :-( There is no software feature that
> substitutes for management. I keep forgetting that.
> 
> > I don't know why the sales team can't keep track of what they've sold
> 
> Neither do I, but I'm a programmer, not a psychologist or a VP of Sales. In
> my experience they at least DO not, not reliably.
> 
> > And to be totally crazy maybe the salesperson could actually visit the
> customer.
> 
> That train has largely left the station. That is a HUGE, HUGE cost that would
> have to be passed on to you-know-who. And customers do not want to take the
> time to have someone in their offices. I miss the days when -- as the
> technical, non-sales CEO of my old company -- I could call someone up and say
> "hey, I'm going to be in Pittsburgh next month, can I take you to lunch?" and
> they would be delighted. Nowadays they would not pick up the phone. I really
> miss those days.
> 
> > From my experience over the past few decades on the customer side
> > there is no full proof means to inform the customer of an expiring license.
> 
> Sadly, I fear you are right.
> 
> > My software emails the customer a notice once a day,
> 
> I like it, but not going to go there at this time. Will keep that in mind.
> 
> > You're assuming that the target machine has the technical connectivity to
> "call home,"
> > or, that if it doesn't, the operators and managers of the target
> > machine would agree to such connectivity and configure it. I don't think
> you can make those assumptions.
> 
> Agreed. In spades.
> 
> > So if I can tell the software - when you hit 30 days, then produce a
> > message to syslog and set the RC to 08 - but only if this tool is run.
> 
> I like it. I want to keep this in mind.
> 
> > The WTO would go to someone to low in the pecking order to make this
> worthwhile.
> 
> Agreed.
> 
> Charles
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: GIM40101E PTF already applied

2019-07-01 Thread Elaine Beal
Gil-

I have tried both ways.

originally

SET  BOUNDARY (MVST100) .
APPLY
 SOURCEID(RSU*)
 GROUPEXTEND
 BYPASS(HOLDSYSTEM)
 CHECK

then I tried SELECTing PTFS with the same issue.
which makes sense, if they're applied, they're applied:)

Elaine

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


Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Tom Marchant
On Mon, 1 Jul 2019 18:29:57 +, Pommier, Rex wrote:

>I don't see how SMP/E can use the TLIBs to populate the DLIBs.  What would it 
>copy 
>across to the DLIB if, like in the OP's case, he wants to ACCEPT the base code 
>but there 
>have been multiple PTFs installed to the TLIBs, 

Are you confusing SMPTLIBs with Target libraries? TLIB refers to SMPTLIB data 
sets.
APPLY never updates SMPTLIB data sets.
It reads them when applying the SYSMOD that is packaged in RELFILE format is 
applied or when accepting such a SYSMOD.

>Whereas, the SMPMCS and 
>RELFILES would have the original code shipped with the functions and PTFs.  

The SMPMCS and RELFILES are only used during RECEIVE processing.

-- 
Tom Marchant

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


Re: Best way to alert customer to pending license expiration?

2019-07-01 Thread Charles Mills
THANK YOU ALL for taking the time to provide your input. The management 
decision is to keep it simple and put out a vanilla WTO that will be distinct 
and easy to automate.

Let me do one e-mail in response to your many, many helpful details:

> IMHO the best way is a WTO that is easy to catch in the customer's automation 
> software.

Thank you @Shmuel. I agree that is the approach.

> Wouldn't it be nice if there were a multi-ISV convention for format of 
> expiration alerts?

Vendor collaboration on anything license-related alarms the anti-trust lawyers.

> Or even for messages requiring human attention?

I think one person's "needs human attention" is another person's "ho-hum."

> The customer has a responsibility to manage their own system.  
> The fact that many do not (completely) is not really something you can solve.

Agreed. But I still keep trying. :-( There is no software feature that 
substitutes for management. I keep forgetting that.

> I don't know why the sales team can't keep track of what they've sold

Neither do I, but I'm a programmer, not a psychologist or a VP of Sales. In my 
experience they at least DO not, not reliably.

> And to be totally crazy maybe the salesperson could actually visit the 
> customer.

That train has largely left the station. That is a HUGE, HUGE cost that would 
have to be passed on to you-know-who. And customers do not want to take the 
time to have someone in their offices. I miss the days when -- as the 
technical, non-sales CEO of my old company -- I could call someone up and say 
"hey, I'm going to be in Pittsburgh next month, can I take you to lunch?" and 
they would be delighted. Nowadays they would not pick up the phone. I really 
miss those days.

> From my experience over the past few decades on the customer side there is no 
> full proof means to inform the customer of an expiring license.

Sadly, I fear you are right.

> My software emails the customer a notice once a day,

I like it, but not going to go there at this time. Will keep that in mind.

> You're assuming that the target machine has the technical connectivity to 
> "call home," 
> or, that if it doesn't, the operators and managers of the target machine 
> would agree to 
> such connectivity and configure it. I don't think you can make those 
> assumptions.

Agreed. In spades. 

> So if I can tell the software - when you hit 30 days, then produce 
> a message to syslog and set the RC to 08 - but only if this tool is run.  

I like it. I want to keep this in mind. 

> The WTO would go to someone to low in the pecking order to make this 
> worthwhile.  

Agreed.

Charles

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


Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Tom Marchant
There seems to be some confusion in this thread about RELFILEs and SMPTLIB data 
sets.

RELFILEs are used only during RECEIVE processing and are not used after that.

SMPTLIB data sets are created during RECEIVE processing and are used for both 
APPLY and ACCEPT.

Neither are used by the running product. That is what the target libraries are 
for.

In this modern age of RERCEIVE ORDER, RECEIVE FROMNETWORK, et al, the RELFILEs 
are contained in the Unix directory.

In the old days, when running an ordinary RECEIVE, the RELFILEs were in MVS 
data sets with a low level qualifier of Fn. RFPREFIX is used to construct the 
data set names that will be read during RECEIVE processing. DSPREFIX is used to 
construct the data set names of the SMPTLIB data sets created during RECEIVE 
processing.

I suspect that the confusion comes from the fact that both the RELFILEs and the 
SMPTLIB data sets have an LLQ on Fn. (Actually there can be more than one "n" 
in the dsname for more than 9 RELFILEs and SMPTLIB data sets.)

The SMPTLIB data sets are deleted during REJECT processing, whether explicitly 
with a REJECT command or implicitly when performing an ACCEPT with the PURGE 
global option specified, or a RESTORE with the REJECT global option specified.

-- 
Tom Marchant

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


Re: STORAGE OBTAIN doc inconsistency?

2019-07-01 Thread Charles Mills
You're right, of course. Not to start a religious war, but even on a big-endian 
machine, it seems to me to make sense to number the bits from LSB to MSB. Bit n 
then represents 2^n -- in an 8-, 16-, 32-, 64- or 128-bit integer. What could 
be more logical?

Not going to happen of course.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Monday, July 1, 2019 6:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STORAGE OBTAIN doc inconsistency?

The notation that would be clearest is to number the bits from right to
left.  However, that may well cause other logical problems on a big-endian
architecture. And obviously, such a change would be ludicrous at this point.

I don't think there's any way to support the old 32-bit numbering that
would solve anything.  Fixing a few mistakes now & then should be fine.

sas


On Thu, Jun 27, 2019 at 7:49 AM Peter Relson  wrote:

> I (to some extent "unfortunately") expect such inconsistency across the
> suite of books (imagine if we still supported both ESA/390 and z
> Architectures as options -- what "notation" would we use)? The effort to
> change every 32-bit-register bit reference to its "appropriate"
> 64-bit-register bit reference is likely to be more than anyone is willing
> to commit to (no matter how good an idea it is)..
>
> But surely we should expect to be consistent for a given macro.
>
> Perhaps someone can suggest a notation that would make it clear "this is a
> bit reference that applies to a 64-bit register". Using "the words" can
> make it clear but is cumbersome. "Bits 32.24-31" (vs "Bits 24-31 of the
> 32-bit register"), "Bits 64.15-23" (vs "bits 15-23 of the 64-bit
> register"), "Control Register 2.64.0-31" (vs "64-bit Control register 2
> bits 0-31"). Not pretty. (Obviously if the numeric range includes a value
> >= 32, there is no ambiguity, so once converted the cases Charles pointed
> out will be clear enough without additional clarification.)
>
> 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
>


-- 
sas

--
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: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Allan Staller
I bow to your superior research skills. Agreed.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Agreed completely with your last 2 statements.  The RELFILES aren't used in the 
running system, only for installation.  Accepting base functions immediately is 
a good thing.  :-)

I don't see how SMP/E can use the TLIBs to populate the DLIBs.  What would it 
copy across to the DLIB if, like in the OP's case, he wants to ACCEPT the base 
code but there have been multiple PTFs installed to the TLIBs, most likely some 
being PTFs on top of PTFs and maybe an APAR and/or USERMOD installed.  Whereas, 
the SMPMCS and RELFILES would have the original code shipped with the functions 
and PTFs.  

I found this snippet in the SMP/E commands manual under ACCEPT which indicates 
that if the software was shipped in RELFILE format, that's where SMP/E goes to 
do the accepts.


If the module is packaged in a link library (LKLIB) or a relative file 
(RELFILE),SMP/E copies the module to the distribution library. Any aliases 
specified for such a module must exist in the LKLIB or relative file in order 
to be copied.


I am pretty sure he won't be able to ACCEPT DB2 11 unless/until he can find the 
missing RELFILES.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

That is why I asked Kurt Q.  to jump in (in another post, not tracked below).
I *think* the DLIBs are built from the TLIBs, but I am not sure.

If this is the case, then  no problem will occur. 

If the RELFILES *are* needed for the accept, then the OP has a problem, he can 
*never* run a ACCEPT for the current software. 
The rollout process is calling for some RELFILES that no longer exist. For a 
fair amount of work (I do not believe it is worth the effort) the RELFILES 
could be recreated from the TLIBS. 

I can pretty much guarantee that the RELFILES *ARE NOT* used  by the running 
system, so dummy RELFILES can be supplied to satisfy the requirements of the 
rollout process.


Moral of the story. ACCEPT the base functions immediately after successful 
APPLY.  




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Allan,

Are you sure the RELFILES aren't needed for the ACCEPT?  In my old brain, I'm 
thinking that ACCEPT copies modules etc from the RELFILES.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 10:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Perhaps that will solve the OP's problem.
Run the accept w/NOPURGE and then manually delete the RELFILES.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

There is definitely an option to not delete the RELFILES.  PURGE/NOPURGE does 
this - part of the cleanup options.  One purpose of this is if you are using a 
single SMP/E GLOBAL zone with multiple target and multiple distribution zones 
managed by it.  You can use the NOPURGE to ACCEPT SYSMODS into the first DLIB 
zones then change to PURGE to accept into the last DLIB.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

ACCEPT will absolutely clean up the relfiles. I do not recall if there is an 
SMPE configuration option to override this.

If DB2 V12 is installed in the same SMPE environment as DB2 V11, I expect 
problems.
The SMPE MCS for DB2V12 FMIDs most likely contains ++DELETE statements for 
DB2V11 FMIDS.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Bill,

Presuming your DB2 12 install will be going into its own SMP/E environment and 
new target/distribution libraries, as soon as you have a successful base APPLY, 
you should be able to accept them.  As a new install of a new release, what 
reason would you have to try to do a RESTORE?   Doing this may clean up the 
RELFILES as well, depending on how your options are set.  Obviously that is not 
the case of maintenance.  For maintenance on the DB2 12, I 

Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Pommier, Rex
Agreed completely with your last 2 statements.  The RELFILES aren't used in the 
running system, only for installation.  Accepting base functions immediately is 
a good thing.  :-)

I don't see how SMP/E can use the TLIBs to populate the DLIBs.  What would it 
copy across to the DLIB if, like in the OP's case, he wants to ACCEPT the base 
code but there have been multiple PTFs installed to the TLIBs, most likely some 
being PTFs on top of PTFs and maybe an APAR and/or USERMOD installed.  Whereas, 
the SMPMCS and RELFILES would have the original code shipped with the functions 
and PTFs.  

I found this snippet in the SMP/E commands manual under ACCEPT which indicates 
that if the software was shipped in RELFILE format, that's where SMP/E goes to 
do the accepts.


If the module is packaged in a link library (LKLIB) or a relative file 
(RELFILE),SMP/E copies the module to the distribution library. Any aliases 
specified for such a module must exist in the LKLIB or relative file in order 
to be copied.


I am pretty sure he won't be able to ACCEPT DB2 11 unless/until he can find the 
missing RELFILES.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

That is why I asked Kurt Q.  to jump in (in another post, not tracked below).
I *think* the DLIBs are built from the TLIBs, but I am not sure.

If this is the case, then  no problem will occur. 

If the RELFILES *are* needed for the accept, then the OP has a problem, he can 
*never* run a ACCEPT for the current software. 
The rollout process is calling for some RELFILES that no longer exist. For a 
fair amount of work (I do not believe it is worth the effort) the RELFILES 
could be recreated from the TLIBS. 

I can pretty much guarantee that the RELFILES *ARE NOT* used  by the running 
system, so dummy RELFILES can be supplied to satisfy the requirements of the 
rollout process.


Moral of the story. ACCEPT the base functions immediately after successful 
APPLY.  




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Allan,

Are you sure the RELFILES aren't needed for the ACCEPT?  In my old brain, I'm 
thinking that ACCEPT copies modules etc from the RELFILES.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 10:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Perhaps that will solve the OP's problem.
Run the accept w/NOPURGE and then manually delete the RELFILES.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

There is definitely an option to not delete the RELFILES.  PURGE/NOPURGE does 
this - part of the cleanup options.  One purpose of this is if you are using a 
single SMP/E GLOBAL zone with multiple target and multiple distribution zones 
managed by it.  You can use the NOPURGE to ACCEPT SYSMODS into the first DLIB 
zones then change to PURGE to accept into the last DLIB.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

ACCEPT will absolutely clean up the relfiles. I do not recall if there is an 
SMPE configuration option to override this.

If DB2 V12 is installed in the same SMPE environment as DB2 V11, I expect 
problems.
The SMPE MCS for DB2V12 FMIDs most likely contains ++DELETE statements for 
DB2V11 FMIDS.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Bill,

Presuming your DB2 12 install will be going into its own SMP/E environment and 
new target/distribution libraries, as soon as you have a successful base APPLY, 
you should be able to accept them.  As a new install of a new release, what 
reason would you have to try to do a RESTORE?   Doing this may clean up the 
RELFILES as well, depending on how your options are set.  Obviously that is not 
the case of maintenance.  For maintenance on the DB2 12, I would do similar as 
Alan mentioned.  APPLY maintenance, then let it sit for weeks/months and then 
ACCEPT the PTFs - or wait for the ACCEPT until right before your next APPLY 
cycle.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli

Re: GIM40101E PTF already applied

2019-07-01 Thread Elaine Beal
sorry wrong job, previous one was trying to do some of the individual PTFs 
having an issue

SET  BOUNDARY (MVST100) .
APPLY
 SOURCEID(RSU*)
 GROUPEXTEND
 BYPASS(HOLDSYSTEM)
 CHECK



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


Re: GIM40101E PTF already applied

2019-07-01 Thread Elaine Beal
sorry, I should have mentioned. applying RSU

  SET  BOUNDARY (MVST100) .
  APPLY
   SELECT(UA93140 UA78422   UA83116   UA92976)
   GROUPEXTEND
   BYPASS(HOLDSYSTEM)
   CHECK

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


Re: Boeing's 737 Max Software Outsourced to $9-an-Hour Engineers

2019-07-01 Thread Dan at Poodles
These were not software engineers.  They were software mechanics.  Nothing
more, nothing less.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, July 1, 2019 11:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Boeing's 737 Max Software Outsourced to $9-an-Hour Engineers

> On first read, this seems to have been outsourced to programmers in India

"In offices across from Seattle's Boeing Field, recent college graduates
employed by the Indian software developer HCL Technologies Ltd. occupied
several rows of desks, said Mark Rabin, a former Boeing software engineer
who worked in a flight-test group that supported the Max."


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


From: IBM Mainframe Discussion List  on behalf of
Jeffrey Holst <02366bf64af9-dmarc-requ...@listserv.ua.edu>
Sent: Monday, July 1, 2019 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Boeing's 737 Max Software Outsourced to $9-an-Hour Engineers

On first read, this seems to have been outsourced to programmers in India,
so H1B visa rules would not apply.

Jeff Holst

On Sun, 30 Jun 2019 20:46:26 +, Seymour J Metz  wrote:

>So much for paying prevailing wages to H1B visa holders. this should be in
court, but I won't hold my breathe.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on 
>behalf of Mark Regan 
>Sent: Saturday, June 29, 2019 5:56 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Fwd: Boeing's 737 Max Software Outsourced to $9-an-Hour 
>Engineers
>
>While not mainframe related, many may relate to this kind of experience.
>
>
>https://finance.yahoo.com/news/boeings-737-max-software-outsourced-2046
>57048.html
>
>Regards,
>
>Mark Regan, K8MTR
>CTO1, USNR-Retired
>Nationwide Ins, Retired
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

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


Re: GIM40101E PTF already applied

2019-07-01 Thread Paul Gilmartin
On Mon, 1 Jul 2019 12:43:43 -0500, Elaine Beal wrote:

>I am running an apply check and get messages because PTFs required as co or 
>pre-req are already applied.
>do I have to individually exclude these ptf's? It looks like aypassapplycheck 
>is good only on accept.
> 
That shouldn't happen.  Are you explicitly SELECTing the co- or pre-reqs?

-- gil

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


Re: GIM40101E PTF already applied

2019-07-01 Thread Michael Brennan
On your INCLUDE statement you should not have any PTFS that are already APPLIED.

Michael Brennan



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elaine Beal
Sent: Monday, July 1, 2019 12:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: GIM40101E PTF already applied

I am running an apply check and get messages because PTFs required as co or 
pre-req are already applied.
do I have to individually exclude these ptf's? It looks like aypassapplycheck 
is good only on accept.

Thanks,
Elaine

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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


GIM40101E PTF already applied

2019-07-01 Thread Elaine Beal
I am running an apply check and get messages because PTFs required as co or 
pre-req are already applied.
do I have to individually exclude these ptf's? It looks like aypassapplycheck 
is good only on accept.

Thanks,
Elaine

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


Re: How to allow a user HFS to be mounted on different LPAR's at different times?

2019-07-01 Thread Allan Staller
1) change the auto mount convention to include a system symbols (e.g. 
) and rename all *.*.USER.ZFS as needed.
2) Investigate OMVS SYSPLEX sharing. One file will be used for all 
participating images.

See the USS Planning Guide for details.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Monday, July 1, 2019 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to allow a user HFS to be mounted on different LPAR's at different 
times?

Cross posted to IBM-MAIN and the MVS-OE lists.

We seem to be using HFS containers for the "/u/userid" directories at this 
location.  Not my choice, nor am I likely to be able to change it.  Bureaucracy 
rules.

If I submit a batch job from LPAR A that uses Unix System Services facilities 
(e.g., execute the /bin/awk program using BPXBATSL) and the job runs on LPAR B 
and then I try to submit and execute the exact same batch job on LPAR A then I 
get a message about "can't mount user HFS on system" and an ERRNO code that 
seems to indicate an EBUSY condition.  When this happens, I also cannot access 
my "/u/userid" directory under ISPF 3.17 from LPAR A, and I get the same sort 
of message and ERRNO condition from ISPF.

I have taken to restricting my Unix batch jobs to un on just one LPAR to 
prevent this error (which is unrecoverable for me until the next weekend IPL).  
As a result I do not have the specific message or ERRNO value to present to you 
for analysis.

Is there anything I can communicate to our sysprog team to allow me to run the 
same Unix System Services batch job on different LPAR's at different times and 
still retain the ability to access my "/u/userid" directory from the submitting 
LPAR without these mount errors?

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
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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


Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Allan Staller
That is why I asked Kurt Q.  to jump in (in another post, not tracked below).
I *think* the DLIBs are built from the TLIBs, but I am not sure.

If this is the case, then  no problem will occur. 

If the RELFILES *are* needed for the accept, then the OP has a problem, he can 
*never* run a ACCEPT for the current software. 
The rollout process is calling for some RELFILES that no longer exist. For a 
fair amount of work (I do not believe it is worth the effort) the RELFILES 
could be recreated from the TLIBS. 

I can pretty much guarantee that the RELFILES *ARE NOT* used  by the running 
system, so dummy RELFILES can be supplied to satisfy the requirements of the 
rollout process.


Moral of the story. ACCEPT the base functions immediately after successful 
APPLY.  




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Allan,

Are you sure the RELFILES aren't needed for the ACCEPT?  In my old brain, I'm 
thinking that ACCEPT copies modules etc from the RELFILES.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 10:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Perhaps that will solve the OP's problem.
Run the accept w/NOPURGE and then manually delete the RELFILES.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

There is definitely an option to not delete the RELFILES.  PURGE/NOPURGE does 
this - part of the cleanup options.  One purpose of this is if you are using a 
single SMP/E GLOBAL zone with multiple target and multiple distribution zones 
managed by it.  You can use the NOPURGE to ACCEPT SYSMODS into the first DLIB 
zones then change to PURGE to accept into the last DLIB.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

ACCEPT will absolutely clean up the relfiles. I do not recall if there is an 
SMPE configuration option to override this.

If DB2 V12 is installed in the same SMPE environment as DB2 V11, I expect 
problems.
The SMPE MCS for DB2V12 FMIDs most likely contains ++DELETE statements for 
DB2V11 FMIDS.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Bill,

Presuming your DB2 12 install will be going into its own SMP/E environment and 
new target/distribution libraries, as soon as you have a successful base APPLY, 
you should be able to accept them.  As a new install of a new release, what 
reason would you have to try to do a RESTORE?   Doing this may clean up the 
RELFILES as well, depending on how your options are set.  Obviously that is not 
the case of maintenance.  For maintenance on the DB2 12, I would do similar as 
Alan mentioned.  APPLY maintenance, then let it sit for weeks/months and then 
ACCEPT the PTFs - or wait for the ACCEPT until right before your next APPLY 
cycle.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: zOSMF software validation looking for *.F files

Thinking forward to my v12 Db2 migration, at what point is it advisable to 
accept the base? As soon as I have my first system successfully migrated? Or 
right before the first maintenance Apply?
thanks
Bill

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 

Re: LOAD/LINK exit

2019-07-01 Thread Thomas David Rivers

Peter Relson wrote:

BPX ptrace...Does that mean performance is not an issue in that case? 
   



That seems like a logical conclusion.

When the system is running in a privileged state, just about the only safe 
way to give control to non-privileged work running as an exit or extention 
under that same task is via SYNCH. That is not going to perform well. 
Returning to the user in their state is a different case.


Peter Relson
z/OS Core Technology Design

 


Oh - hmm - it would be nice to have a non-supervisor-state
thingy that did this - similar to what is available via PTRACE.

But - "would be nice" doesn't make for a good business case :-)

   - Dave Rivers -


--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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


Re: Best way to alert customer to pending license expiration?

2019-07-01 Thread Paul Gilmartin
On Mon, 1 Jul 2019 17:16:04 +, Seymour J Metz wrote:

>IMHO the best way is a WTO that is easy to catch in the customer's automation 
>software. Getting the administrative staff to pony up in a timely fashion is a 
>much harder problem )-:
> 
Wouldn't it be nice if there were a multi-ISV convention for format
of expiration alerts?  Or even for messages requiring human attention?

-- gil

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


Re: [MVS-OE] How to allow a user HFS to be mounted on different LPAR's at different times?

2019-07-01 Thread Paul Gilmartin
> On 2019-07-01, at 10:51:59, Farley, Peter x23353 wrote:
> 
> Cross posted to IBM-MAIN and the MVS-OE lists.
> ...
> Is there anything I can communicate to our sysprog team to allow me to run 
> the same Unix System Services batch job on different LPAR's at different 
> times and still retain the ability to access my "/u/userid" directory from 
> the submitting LPAR without these mount errors?
>  
NFS?  We found it useful, even before HFS sharing existed.

— gil

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


Re: Best way to alert customer to pending license expiration?

2019-07-01 Thread Seymour J Metz
IMHO the best way is a WTO that is easy to catch in the customer's automation 
software. Getting the administrative staff to pony up in a timely fashion is a 
much harder problem )-:


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


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Sunday, June 30, 2019 6:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way to alert customer to pending license expiration?

Okay, I am "dropping up one level" from my question about persistent WTO
messages. The REAL question is "what would be the best way to tell a
customer that their license is fairly close to expiration?"

Please, may I ask that we not digress into whether license enforcement is a
good idea. That's a valid discussion but it's not this thread. I'm a
contractor on this and it's not my decision. I also happen to think that
software vendors need to get paid and not every customer ponies up
spontaneously. FWIW, there is no CPUID checking in the product, just certain
usage restrictions and an expiration date.

It's a batch product. It's not a huge big deal product, so there is no
"CA-1" that is devoted to license management.

What would be the best way to get the right peoples' attention to let them
know that the license is fairly close to expiration? Let me tell you from
experience three things that do not work well:

- An I message in SYSPRINT with no elevated return code. Put simply, nobody
notices or cares. (Until the product expires, and then all heck breaks
loose.)
- A W message in SYSPRINT with a return code of 4. All heck breaks loose at
that point, because everyone seems to use JCL that checks for a zero return
code, and you break their batch processes with a 4. You might as well return
16 as return 4.
- Having vendor sales management keep track of whether a new license has
been sent, and managing it that way. (1) "A license has been sent" is not
the same thing as "someone actually installed the license"; and (2) not
every sales person is a genius at getting paperwork right.

I was considering some sort of WTO that would require manual attention -- or
at least console automation simulated attention -- but that may not be a
great possibility.

So ... what have you seen that has worked well in your opinion?

Thanks,
Charles

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

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


Re: How to allow a user HFS to be mounted on different LPAR's at different times?

2019-07-01 Thread John McKown
On Mon, Jul 1, 2019 at 11:52 AM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> Cross posted to IBM-MAIN and the MVS-OE lists.
>
> We seem to be using HFS containers for the "/u/userid" directories at this
> location.  Not my choice, nor am I likely to be able to change it.
> Bureaucracy rules.
>
> If I submit a batch job from LPAR A that uses Unix System Services
> facilities (e.g., execute the /bin/awk program using BPXBATSL) and the job
> runs on LPAR B and then I try to submit and execute the exact same batch
> job on LPAR A then I get a message about "can't mount user HFS on system"
> and an ERRNO code that seems to indicate an EBUSY condition.  When this
> happens, I also cannot access my "/u/userid" directory under ISPF 3.17 from
> LPAR A, and I get the same sort of message and ERRNO condition from ISPF.
>
> I have taken to restricting my Unix batch jobs to un on just one LPAR to
> prevent this error (which is unrecoverable for me until the next weekend
> IPL).  As a result I do not have the specific message or ERRNO value to
> present to you for analysis.
>
> Is there anything I can communicate to our sysprog team to allow me to run
> the same Unix System Services batch job on different LPAR's at different
> times and still retain the ability to access my "/u/userid" directory from
> the submitting LPAR without these mount errors?
>

Only if the systems are in the same SYSPLEX and you have enabled UNIX
sysplex sharing.
ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb200/uxsys.htm

[quote]

By establishing the shared file system environment, sysplex users can
access data throughout the file hierarchy from any system in the sysplex.
The best way to describe the benefit of this function is by comparing what
was the file system sharing capability prior to the introduction of shared
file system support with the capability that exists now. Consider a sysplex
that consists of two systems, SY1 and SY2:

   - Users logged onto SY1 can write to the directories on SY1. For users
   on SY1 to make a change to file systems mounted on SY2's /u directory,
   they would have to log onto SY2.
   - The system programmer who makes configuration changes for the sysplex
   needs to change the entries in the /etc file systems for SY1 and SY2. To
   make the changes for both systems, the system programmer must log onto each
   system.

With shared file system support, all file systems that are mounted by a
system participating in a shared file system are available to all
participating systems. In other words, once a file system is mounted by a
participating system, that file system is accessible by any other
participating system. It is not possible to mount a file system so that it
is restricted to just one of those systems. Consider a sysplex that
consists of two systems, SY1 and SY2:

   - A user logged onto any system can make changes to file systems mounted
   on /u, and those changes are visible to all systems.
   - The system programmer who manages maintenance for the sysplex can
   change entries in both /etc file systems from either system.

The term participating group is used to identify those systems that belong
to the same SYSBPX XCF sysplex group and have followed the required
installation and migration activities to participate in a shared file
system.

There is also greater availability of data in case of system outage, and a
greater flexibility for data placement and the ability for a single
BPXPRMxx member to define all the file systems in the sysplex.

[/quote]




>
> Peter
> --
>
>
-- 
Money is the root of all evil.
Evil is the root of all money.
With that in mind, money is made by the government ...


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: Boeing's 737 Max Software Outsourced to $9-an-Hour Engineers

2019-07-01 Thread Seymour J Metz
> On first read, this seems to have been outsourced to programmers in India

"In offices across from Seattle’s Boeing Field, recent college graduates 
employed by the Indian software developer HCL Technologies Ltd. occupied 
several rows of desks, said Mark Rabin, a former Boeing software engineer who 
worked in a flight-test group that supported the Max."


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


From: IBM Mainframe Discussion List  on behalf of 
Jeffrey Holst <02366bf64af9-dmarc-requ...@listserv.ua.edu>
Sent: Monday, July 1, 2019 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Boeing's 737 Max Software Outsourced to $9-an-Hour Engineers

On first read, this seems to have been outsourced to programmers in India, so 
H1B visa rules would not apply.

Jeff Holst

On Sun, 30 Jun 2019 20:46:26 +, Seymour J Metz  wrote:

>So much for paying prevailing wages to H1B visa holders. this should be in 
>court, but I won't hold my breathe.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Mark Regan 
>Sent: Saturday, June 29, 2019 5:56 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Fwd: Boeing's 737 Max Software Outsourced to $9-an-Hour Engineers
>
>While not mainframe related, many may relate to this kind of experience.
>
>
>https://finance.yahoo.com/news/boeings-737-max-software-outsourced-204657048.html
>
>Regards,
>
>Mark Regan, K8MTR
>CTO1, USNR-Retired
>Nationwide Ins, Retired
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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


Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Seymour J Metz
Did you try to receive the function again?


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


From: IBM Mainframe Discussion List  on behalf of 
Bill Giannelli 
Sent: Monday, July 1, 2019 10:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF software validation looking for *.F files

So at this point if I want to accept the base, I would need to have recalled 
the RELFILES (or *.F*)? Some of them I can not get recalled and am getting 
"locate errors".
thanks
Bill

--
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: STORAGE OBTAIN doc inconsistency?

2019-07-01 Thread scott Ford
Steve,

Absolutely, clarification always helps.

Scott

On Mon, Jul 1, 2019 at 9:41 AM Steve Smith  wrote:

> The notation that would be clearest is to number the bits from right to
> left.  However, that may well cause other logical problems on a big-endian
> architecture. And obviously, such a change would be ludicrous at this
> point.
>
> I don't think there's any way to support the old 32-bit numbering that
> would solve anything.  Fixing a few mistakes now & then should be fine.
>
> sas
>
>
> On Thu, Jun 27, 2019 at 7:49 AM Peter Relson  wrote:
>
> > I (to some extent "unfortunately") expect such inconsistency across the
> > suite of books (imagine if we still supported both ESA/390 and z
> > Architectures as options -- what "notation" would we use)? The effort to
> > change every 32-bit-register bit reference to its "appropriate"
> > 64-bit-register bit reference is likely to be more than anyone is willing
> > to commit to (no matter how good an idea it is)..
> >
> > But surely we should expect to be consistent for a given macro.
> >
> > Perhaps someone can suggest a notation that would make it clear "this is
> a
> > bit reference that applies to a 64-bit register". Using "the words" can
> > make it clear but is cumbersome. "Bits 32.24-31" (vs "Bits 24-31 of the
> > 32-bit register"), "Bits 64.15-23" (vs "bits 15-23 of the 64-bit
> > register"), "Control Register 2.64.0-31" (vs "64-bit Control register 2
> > bits 0-31"). Not pretty. (Obviously if the numeric range includes a value
> > >= 32, there is no ambiguity, so once converted the cases Charles pointed
> > out will be clear enough without additional clarification.)
> >
> > 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
> >
>
>
> --
> sas
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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


How to allow a user HFS to be mounted on different LPAR's at different times?

2019-07-01 Thread Farley, Peter x23353
Cross posted to IBM-MAIN and the MVS-OE lists.

We seem to be using HFS containers for the "/u/userid" directories at this 
location.  Not my choice, nor am I likely to be able to change it.  Bureaucracy 
rules.

If I submit a batch job from LPAR A that uses Unix System Services facilities 
(e.g., execute the /bin/awk program using BPXBATSL) and the job runs on LPAR B 
and then I try to submit and execute the exact same batch job on LPAR A then I 
get a message about "can't mount user HFS on system" and an ERRNO code that 
seems to indicate an EBUSY condition.  When this happens, I also cannot access 
my "/u/userid" directory under ISPF 3.17 from LPAR A, and I get the same sort 
of message and ERRNO condition from ISPF.

I have taken to restricting my Unix batch jobs to un on just one LPAR to 
prevent this error (which is unrecoverable for me until the next weekend IPL).  
As a result I do not have the specific message or ERRNO value to present to you 
for analysis.

Is there anything I can communicate to our sysprog team to allow me to run the 
same Unix System Services batch job on different LPAR's at different times and 
still retain the ability to access my "/u/userid" directory from the submitting 
LPAR without these mount errors?

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: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread Mark Jacobs
Does that use the zEDC compression feature if's available on your system?

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Monday, July 1, 2019 11:51 AM, Kirk Wolf  wrote:

> jar is zip compatible.
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jarGuide.html
>
> Also the Java sdk has an API to read/write zip / deflate files.
>
> There is a JZOS sample program that shows how to create a zip archive using
> z/OS data sets as input / output.
>
> https://github.com/zsystems/java-samples/blob/master/ZipDatasets.java
>
> On Sun, Jun 30, 2019 at 3:46 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Sun, 30 Jun 2019 20:34:19 +, Denis wrote:
> >
> > > I wonder if the jar command of the Java SDK in z/OS creates gzip
> > > compatible jar files, which in Windows can be extracted/used by renaming
> > > Form .jar to .ZIP.I cannot remember if the jar compression uses ziip.Any
> > > file type can be added to a jar, but I have not tried dd names.
> >
> > I believe jar uses zip deflate. I've used it to unpack zipped files from
> > cbttape.org.
> > I believe jar isn't fussy about filenames -- you can bypass the rename.
> > Jar syntax is most similar to tar.
> > -- gil
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Pommier, Rex
Allan,

Are you sure the RELFILES aren't needed for the ACCEPT?  In my old brain, I'm 
thinking that ACCEPT copies modules etc from the RELFILES.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 10:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Perhaps that will solve the OP's problem.
Run the accept w/NOPURGE and then manually delete the RELFILES.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

There is definitely an option to not delete the RELFILES.  PURGE/NOPURGE does 
this - part of the cleanup options.  One purpose of this is if you are using a 
single SMP/E GLOBAL zone with multiple target and multiple distribution zones 
managed by it.  You can use the NOPURGE to ACCEPT SYSMODS into the first DLIB 
zones then change to PURGE to accept into the last DLIB.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

ACCEPT will absolutely clean up the relfiles. I do not recall if there is an 
SMPE configuration option to override this.

If DB2 V12 is installed in the same SMPE environment as DB2 V11, I expect 
problems.
The SMPE MCS for DB2V12 FMIDs most likely contains ++DELETE statements for 
DB2V11 FMIDS.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Bill,

Presuming your DB2 12 install will be going into its own SMP/E environment and 
new target/distribution libraries, as soon as you have a successful base APPLY, 
you should be able to accept them.  As a new install of a new release, what 
reason would you have to try to do a RESTORE?   Doing this may clean up the 
RELFILES as well, depending on how your options are set.  Obviously that is not 
the case of maintenance.  For maintenance on the DB2 12, I would do similar as 
Alan mentioned.  APPLY maintenance, then let it sit for weeks/months and then 
ACCEPT the PTFs - or wait for the ACCEPT until right before your next APPLY 
cycle.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: zOSMF software validation looking for *.F files

Thinking forward to my v12 Db2 migration, at what point is it advisable to 
accept the base? As soon as I have my first system successfully migrated? Or 
right before the first maintenance Apply?
thanks
Bill

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, 

Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread Kirk Wolf
jar is zip compatible.
https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jarGuide.html

Also the Java sdk has an API to read/write zip / deflate files.

There is a JZOS sample program that shows how to create a zip archive using
z/OS data sets as input / output.

https://github.com/zsystems/java-samples/blob/master/ZipDatasets.java

On Sun, Jun 30, 2019 at 3:46 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 30 Jun 2019 20:34:19 +, Denis wrote:
>
> >I wonder if the jar command of the Java SDK in z/OS creates gzip
> compatible jar files, which in Windows can be extracted/used by renaming
> Form .jar to .ZIP.I cannot remember if the jar compression uses ziip.Any
> file type can be added to a jar, but I have not tried dd names.
> >
> I believe jar uses zip deflate.  I've used it to unpack zipped files from
> cbttape.org.
> I believe jar isn't fussy about filenames -- you can bypass the rename.
> Jar syntax is most similar to tar.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Allan Staller
Perhaps that will solve the OP's problem.
Run the accept w/NOPURGE and then manually delete the RELFILES.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

There is definitely an option to not delete the RELFILES.  PURGE/NOPURGE does 
this - part of the cleanup options.  One purpose of this is if you are using a 
single SMP/E GLOBAL zone with multiple target and multiple distribution zones 
managed by it.  You can use the NOPURGE to ACCEPT SYSMODS into the first DLIB 
zones then change to PURGE to accept into the last DLIB.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

ACCEPT will absolutely clean up the relfiles. I do not recall if there is an 
SMPE configuration option to override this.

If DB2 V12 is installed in the same SMPE environment as DB2 V11, I expect 
problems.
The SMPE MCS for DB2V12 FMIDs most likely contains ++DELETE statements for 
DB2V11 FMIDS.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Bill,

Presuming your DB2 12 install will be going into its own SMP/E environment and 
new target/distribution libraries, as soon as you have a successful base APPLY, 
you should be able to accept them.  As a new install of a new release, what 
reason would you have to try to do a RESTORE?   Doing this may clean up the 
RELFILES as well, depending on how your options are set.  Obviously that is not 
the case of maintenance.  For maintenance on the DB2 12, I would do similar as 
Alan mentioned.  APPLY maintenance, then let it sit for weeks/months and then 
ACCEPT the PTFs - or wait for the ACCEPT until right before your next APPLY 
cycle.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: zOSMF software validation looking for *.F files

Thinking forward to my v12 Db2 migration, at what point is it advisable to 
accept the base? As soon as I have my first system successfully migrated? Or 
right before the first maintenance Apply?
thanks
Bill

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.

Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Pommier, Rex
There is definitely an option to not delete the RELFILES.  PURGE/NOPURGE does 
this - part of the cleanup options.  One purpose of this is if you are using a 
single SMP/E GLOBAL zone with multiple target and multiple distribution zones 
managed by it.  You can use the NOPURGE to ACCEPT SYSMODS into the first DLIB 
zones then change to PURGE to accept into the last DLIB.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, July 1, 2019 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

ACCEPT will absolutely clean up the relfiles. I do not recall if there is an 
SMPE configuration option to override this.

If DB2 V12 is installed in the same SMPE environment as DB2 V11, I expect 
problems.
The SMPE MCS for DB2V12 FMIDs most likely contains ++DELETE statements for 
DB2V11 FMIDS.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Bill,

Presuming your DB2 12 install will be going into its own SMP/E environment and 
new target/distribution libraries, as soon as you have a successful base APPLY, 
you should be able to accept them.  As a new install of a new release, what 
reason would you have to try to do a RESTORE?   Doing this may clean up the 
RELFILES as well, depending on how your options are set.  Obviously that is not 
the case of maintenance.  For maintenance on the DB2 12, I would do similar as 
Alan mentioned.  APPLY maintenance, then let it sit for weeks/months and then 
ACCEPT the PTFs - or wait for the ACCEPT until right before your next APPLY 
cycle.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: zOSMF software validation looking for *.F files

Thinking forward to my v12 Db2 migration, at what point is it advisable to 
accept the base? As soon as I have my first system successfully migrated? Or 
right before the first maintenance Apply?
thanks
Bill

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--

Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread Kirk Wolf
1. If you use the z/OS pax of z/OS with a portable archive format, the file
will be compatible with linux tar.  LZ compression is supported.  For
example, "pax -x ustar" specifies the compatible USTART format, which is
the default.

2. The pax -f  with pax can be a z/OS dataset (//'hlq.my.dsn'  or
//dd:myDD reference).
Unfortunately the component file that you are adding/compressing into
the archive can not be a dataset/DD
Your question doesn't say which case you have.

3. You can use BPXBATCH to run pax, although using a DD reference requires
BPXBATSL.  It's trickier, but it can be done.

Here's an example of using COZBATCH (an improved BPXBATCH utility,
available free under our Community License):

//  EXPORT SYMLIST=(INDSN,FN)
//  SET INDSN=TCPIP.ETC.SERVICES
//  SET FN='myfile.txt'
//*
//SHELL EXEC PGM=COZBATCH
//ARCHIVE   DD DSN=&,DISP=(NEW,PASS),
// DCB=(RECFM=U,BLKSIZE=27998),
// SPACE=(CYL,(10,10))
//STDIN DD *
# The following is just input to a z/OS Unix login shell running in batch

# We copy/convert the INDSN through a named pipe so that pax can use it
#  as a component file name that we choose
mkfifo $JES_FN # JES_xxx environment variables are mapped from JES
symbols
trap 'rm -rf -f $JES_FN' EXIT
fromdsn -t ISO8859-1 -l crlf $JES_INDSN > $JES_FN   &

pax -wvz -f //DD:ARCHIVE  $JES_FN
//
(as you can see, this example uses fromdsn to do codepage and line
terminator conversion on the input file)

4. Since you are dealing with one file, IMO it is simpler to just use gzip
on z/OS (the Rocket port).

//  EXPORT SYMLIST=(INDSN)
//  SET INDSN=TCPIP.ETC.SERVICES
//*
//GZIP EXEC PGM=COZBATCH
//GZ   DD DSN=&,DISP=(NEW,PASS),
// DCB=(RECFM=U,BLKSIZE=2799
// SPACE=(CYL,(1,1))
//STDINDD *
set -o pipecurrent
fromdsn -t ISO8859-1 -l crlf $JES_INDSN | \
  gzip -v -c | \
  todsn -b //DD:GZ
//

Either one of these steps could be followed by an FTP step using the passed
temporary archive/gz data set.

5. FWIW, if you use SFTP (z/OS OpenSSH) instead of FTP or FTP+TLS, you can
automatically do LZ compression/decompression on the file as it is
transferred.   Co:Z SFTP also supports z/OS data sets and codepage / format
conversions.

Kirk Wolf
http://dovetail.com

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


Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread Paul Gilmartin
On Mon, 1 Jul 2019 10:16:24 -0500, John McKown wrote:
>
>You can run something like the following in BPXBATCH:
>
>//PS001   EXEC PGM=BPXBATCH,REGION=0M
>//*PARM='SH printenv '
>//STDOUT   DD SYSOUT=*
>//STDERR   DD SYSOUT=*
>//STDINDD DUMMY
>//STDPARM  DD *
>SH cp -T "//'INPUT.DSN'" /dev/fd1 | compress >|input.dsn.Z
>/*
>
>If you need this to be put back into a z/OS dataset it is a bit more
>cumberson.
> 
But why?  aren't FTP and SFTP quite UNIX-savvy?

>SH cp -T "//'INPUT.DSN'" /dev/fd1 |
>   compress |
>   cp -B "-W seqparms='blksize=23779,recfm=u,space=(cyl,(1,1))'"
>   "//'INPUT.DSN.Z'"
> 
It might be easier to preallocate the output data set with a JCL DD statement.

If you omit the secondary space, Sx37 is guaranteed, regardless of primary
size.  (Or, you can supply the idiosyncratic NORLSE option.)
(I hate MVS!)

Wouldn't BLKSIZE=0 or BLKSIZE=32760 be preferable?  (Or might this
result in one block per track if the access method doesn't use track
balances?)

>Important note on the above. All the lines, without line end characters,
>are concatenated into a single line and presented to BPXPARM as a long
>PARM=. That means that you DO NOT use any shell continuation characters
>because it is only one line. Also you DO NOT put in any comments because it
>is all one line so that everything after the first # will be a comment.
>And, if you want to have multiple commands, you MUST terminate each
>command, except possibly the last, with a semi-colon.
>
Or if your editor like ISPF allows hex input, separate statements with 0x15.

-- gil

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


Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread David Spiegel
NOPURGE

On 2019-07-01 11:34, Allan Staller wrote:
> ACCEPT will absolutely clean up the relfiles. I do not recall if there is an 
> SMPE configuration option to override this.
>
> If DB2 V12 is installed in the same SMPE environment as DB2 V11, I expect 
> problems.
> The SMPE MCS for DB2V12 FMIDs most likely contains ++DELETE statements for 
> DB2V11 FMIDS.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Pommier, Rex
> Sent: Monday, July 1, 2019 10:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: zOSMF software validation looking for *.F files
>
> Bill,
>
> Presuming your DB2 12 install will be going into its own SMP/E environment 
> and new target/distribution libraries, as soon as you have a successful base 
> APPLY, you should be able to accept them.  As a new install of a new release, 
> what reason would you have to try to do a RESTORE?   Doing this may clean up 
> the RELFILES as well, depending on how your options are set.  Obviously that 
> is not the case of maintenance.  For maintenance on the DB2 12, I would do 
> similar as Alan mentioned.  APPLY maintenance, then let it sit for 
> weeks/months and then ACCEPT the PTFs - or wait for the ACCEPT until right 
> before your next APPLY cycle.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Bill Giannelli
> Sent: Monday, July 1, 2019 9:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: zOSMF software validation looking for *.F files
>
> Thinking forward to my v12 Db2 migration, at what point is it advisable to 
> accept the base? As soon as I have my first system successfully migrated? Or 
> right before the first maintenance Apply?
> thanks
> Bill
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged.  If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful.  If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format.  Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> --
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
> --
>
> --
> 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: Best way to alert customer to pending license expiration?

2019-07-01 Thread David Purdy
We had a similar story in the late '70s deciding between two non-IBM database 
products.  The winner sent a similar "marketing rep" to the CIO, and the deal 
closed the next week.Really wished IDMS was the winner, but our strong 
recommendations were for naught. 
David


-Original Message-
From: David Spiegel 
To: IBM-MAIN 
Sent: Mon, Jul 1, 2019 09:33 AM
Subject: Re: Best way to alert customer to pending license expiration?


This reminds me of a story ... (I say that a lot, just ask my kids)
In the '90s, I worked for a multi-national food company. (I did in the 
'80s too, but, that was a different company).
A certain mainframe software company would always send provocatively 
dressed women to visit when it was time to renew contracts and/or to 
sell new software leases.
Years later they denied having this practice and to bolster (or, should 
I say buttress (pun intended)) their argument, they claimed they could 
prove it was false because
their company had some female vice presidents. (They were saying in 
essence that they don't objectify women.) Of course, both could have 
been true (i.e. that there
were female higher-ups AND that they objectified women.) I was LOLing 
when I read this ridiculous article.

On 2019-07-01 08:53, Carl Swanson wrote:
> Another method would send a bill and maybe make a phone call. And to be 
> totally crazy maybe the salesperson could actually visit the customer.
> Just saying electronic is not always the only method and may not be the best.
>
> Carl Swanson
> carl.swan...@dell.com
> Advisory Systems Engineer Mainframe Practice
> Mobile: 215-688-1459
> Sent from iPhone misspellings likely
>
>
>> On Jul 1, 2019, at 8:22 AM, Lionel B Dyck  wrote:
>>
>>  From my experience over the past few decades on the customer side there is
>> no full proof means to inform the customer of an expiring license.
>>
>> Highlighted console messages work if you have live operators who actually
>> look at a console. They also work for the Sysprogs who look at system action
>> messages assuming that they actually read the messages and don't assume that
>> someone else is doing something about it.
>>
>> Messages in a batch job can be useful, again only if the application owner
>> looks at the generated messages and then reports them.
>>
>> Messages in reports are useful as the report user may report that
>> information - then again they may assume that someone is already working the
>> license issue.
>>
>> Lastly just because the messages are there and someone has alerted the
>> appropriate parties does not mean that the product won't expire as I have
>> rarely found any of the places I've worked where the licenses get renewed on
>> time - my experience is that 99% (perhaps higher) do expire and fall into
>> either a grace period or the Sysprog scrambles to get a temporary extension
>> from the vendor.
>>
>> My $0.01 on the topic
>>
>> Lionel B. Dyck <
>> Website: 
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.lbdsoftware.com=02%7C01%7C%7C200bb77b7dc446ba7a8d08d6fe232a22%7C84df9e7fe9f640afb435%7C1%7C0%7C636975824340116566=QrKTqXsnBr0rmuE92qE25S%2FeGLvI07v7fu55qUNbXeE%3D=0
>>
>> "Worry more about your character than your reputation.  Character is what
>> you are, reputation merely what others think you are." - John Wooden
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>


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

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


Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Allan Staller
ACCEPT will absolutely clean up the relfiles. I do not recall if there is an 
SMPE configuration option to override this.

If DB2 V12 is installed in the same SMPE environment as DB2 V11, I expect 
problems.
The SMPE MCS for DB2V12 FMIDs most likely contains ++DELETE statements for 
DB2V11 FMIDS.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, July 1, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: zOSMF software validation looking for *.F files

Bill,

Presuming your DB2 12 install will be going into its own SMP/E environment and 
new target/distribution libraries, as soon as you have a successful base APPLY, 
you should be able to accept them.  As a new install of a new release, what 
reason would you have to try to do a RESTORE?   Doing this may clean up the 
RELFILES as well, depending on how your options are set.  Obviously that is not 
the case of maintenance.  For maintenance on the DB2 12, I would do similar as 
Alan mentioned.  APPLY maintenance, then let it sit for weeks/months and then 
ACCEPT the PTFs - or wait for the ACCEPT until right before your next APPLY 
cycle.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: zOSMF software validation looking for *.F files

Thinking forward to my v12 Db2 migration, at what point is it advisable to 
accept the base? As soon as I have my first system successfully migrated? Or 
right before the first maintenance Apply?
thanks
Bill

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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


Re: [External] Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Pommier, Rex
Bill,

Presuming your DB2 12 install will be going into its own SMP/E environment and 
new target/distribution libraries, as soon as you have a successful base APPLY, 
you should be able to accept them.  As a new install of a new release, what 
reason would you have to try to do a RESTORE?   Doing this may clean up the 
RELFILES as well, depending on how your options are set.  Obviously that is not 
the case of maintenance.  For maintenance on the DB2 12, I would do similar as 
Alan mentioned.  APPLY maintenance, then let it sit for weeks/months and then 
ACCEPT the PTFs - or wait for the ACCEPT until right before your next APPLY 
cycle.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: zOSMF software validation looking for *.F files

Thinking forward to my v12 Db2 migration, at what point is it advisable to 
accept the base? As soon as I have my first system successfully migrated? Or 
right before the first maintenance Apply?
thanks
Bill

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread John McKown
On Mon, Jul 1, 2019 at 10:16 AM John McKown 
wrote:

> On Sun, Jun 30, 2019 at 2:21 PM Donald Russell 
> wrote:
>
>> I sincerely appreciate people’s feedback on this subject but the problem
>> I’m trying to solve is how to compress the file, not whether compression
>> is
>> needed. The decision to compress was made based on frequency of use,
>> bandwidth between source and destination and difference in file
>> size/transmission time, the value of that benefit etc.
>>
>> Currently I use pkzip to create a gzip file. If I can accomplish this with
>> bpxbatch then I may be able to cancel the pkzip license. The other aspect
>> is I’d like to run this on an mvs system that doesn’t have non-ibm
>> products
>> on it so bpxbatch may be available whereas pkzip is not.
>>
>
> z/OS does not come with a UNIX compression product, other than the
> "laughable" compress program. But I just tried it with the following
> results:
>
> jesysmsg.lst600  File xx
>  2019/05/23 06:54:06 988920 --s- nl1
> jesysmsg.lst.Z  644  File xx
>  2019/07/01 09:41:27 179231 --s-   1
>
> You can run something like the following in BPXBATCH:
>
> //PS001   EXEC PGM=BPXBATCH,REGION=0M
> //*PARM='SH printenv '
> //STDOUT   DD SYSOUT=*
> //STDERR   DD SYSOUT=*
> //STDINDD DUMMY
> //STDPARM  DD *
> SH cp -T "//'INPUT.DSN'" /dev/fd1 | compress >|input.dsn.Z
> /*
>
> If you need this to be put back into a z/OS dataset it is a bit more
> cumberson.
>
> SH cp -T "//'INPUT.DSN'" /dev/fd1 |
>compress |
>cp -B "-W seqparms='blksize=23779,recfm=u,space=(cyl,(1,1))'"
>"//'INPUT.DSN.Z'"
>

Made a stupid mistake in the above

SH cp -T "//'INPUT.DSN'" /dev/fd1 |
   compress |
   cp -B "-W seqparms='blksize=23779,recfm=u,space=(cyl,(1,1))'"
  /dev/fd0
  "//'INPUT.DSN.Z'"




>
> Important note on the above. All the lines, without line end characters,
> are concatenated into a single line and presented to BPXPARM as a long
> PARM=. That means that you DO NOT use any shell continuation characters
> because it is only one line. Also you DO NOT put in any comments because it
> is all one line so that everything after the first # will be a comment.
> And, if you want to have multiple commands, you MUST terminate each
> command, except possibly the last, with a semi-colon.
>
>
>
>>
>> Don
>>
>>
> --
> Money is the root of all evil.
> Evil is the root of all money.
> With that in mind, money is made by the government ...
>
>
> Maranatha! <><
> John McKown
>


-- 
Money is the root of all evil.
Evil is the root of all money.
With that in mind, money is made by the government ...


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: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread John McKown
On Sun, Jun 30, 2019 at 2:21 PM Donald Russell 
wrote:

> I sincerely appreciate people’s feedback on this subject but the problem
> I’m trying to solve is how to compress the file, not whether compression is
> needed. The decision to compress was made based on frequency of use,
> bandwidth between source and destination and difference in file
> size/transmission time, the value of that benefit etc.
>
> Currently I use pkzip to create a gzip file. If I can accomplish this with
> bpxbatch then I may be able to cancel the pkzip license. The other aspect
> is I’d like to run this on an mvs system that doesn’t have non-ibm products
> on it so bpxbatch may be available whereas pkzip is not.
>

z/OS does not come with a UNIX compression product, other than the
"laughable" compress program. But I just tried it with the following
results:

jesysmsg.lst600  File xx
 2019/05/23 06:54:06 988920 --s- nl1
jesysmsg.lst.Z  644  File xx
 2019/07/01 09:41:27 179231 --s-   1

You can run something like the following in BPXBATCH:

//PS001   EXEC PGM=BPXBATCH,REGION=0M
//*PARM='SH printenv '
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//STDINDD DUMMY
//STDPARM  DD *
SH cp -T "//'INPUT.DSN'" /dev/fd1 | compress >|input.dsn.Z
/*

If you need this to be put back into a z/OS dataset it is a bit more
cumberson.

SH cp -T "//'INPUT.DSN'" /dev/fd1 |
   compress |
   cp -B "-W seqparms='blksize=23779,recfm=u,space=(cyl,(1,1))'"
   "//'INPUT.DSN.Z'"

Important note on the above. All the lines, without line end characters,
are concatenated into a single line and presented to BPXPARM as a long
PARM=. That means that you DO NOT use any shell continuation characters
because it is only one line. Also you DO NOT put in any comments because it
is all one line so that everything after the first # will be a comment.
And, if you want to have multiple commands, you MUST terminate each
command, except possibly the last, with a semi-colon.



>
> Don
>
>
-- 
Money is the root of all evil.
Evil is the root of all money.
With that in mind, money is made by the government ...


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: Best way to alert customer to pending license expiration?

2019-07-01 Thread Phil Smith III
ObAnecdote: many years ago, a sysprog friend goes into the data center for 
something, notices a message on the (VM) operator's console: 

[BACKUPPRODUCTNAME] will expire in 15 days!

 

He points to it, politely asking a question that no doubt included several 
four-letter words. Operator's response: "It always says that".

 

Um, no, just for the last couple of weeks.

 

As Steve Smith (no [known] relation) notes, you can't fix this kind of 
incompetence.


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


Re: Copying portions of a huge data set

2019-07-01 Thread Ron Hawkins
I would have thought SAS is your friend.


RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: Thursday, 27 June 2019 07:44
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Copying portions of a huge data set

As I said earlier, I can 'browse forward' in the corrupted file to identify the 
beginning of each 'good' segment (syslog) and the beginning of each 'bad' 
segment (user job). Pointing to some random spot in the file may not tell me 
much about where I am at the moment. 

Ironically the bad segments (user output) all seem to end this way:

ICE052I 0 END OF DFSORT  

I see that as just a coincidence of what the user is doing. I wouldn't try to 
count on that for a general case. It turns out we can prevent this problem in 
the future by turning off access to a RACF resource in JES2 Exit 6. That should 
have been done many years ago. 

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Ward Able, Grant
Sent: Wednesday, June 26, 2019 3:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Copying portions of a huge data set

This may be simplistic, but using REXX & EXECIO, as long as you can identify 
the errant data easily enough, you should be able to get this done fairly 
easily. Maybe not as quick as REPRO, but without much hassle. 




Regards – Grant.

In theory, there's no difference between theory and practice. In practice, 
there is.

There is no such thing as the Cloud. It is just somebody else’s computer.

If you don't have time to do it right, when will you have the time to do it 
over? - John Wooden




DTCC Internal (Green)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: 25 June 2019 23:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Copying portions of a huge data set

ATTENTION! This email originated outside of DTCC; exercise caution.

With 22,807,898 lines in the file, it took a lot of 'inspection' to understand 
why our log print program was getting S0C7. The intrusive user junk always 
starts with 'J E S 2  J O B  L O G'. OTOH every true syslog record seems to 
have an alpha character in position 1 that can be found with "f p'@' 1 word". 
Hence the relevant line numbers can be found easily with alternating ISPF 
browse commands. But very hard to turn into a simple algorithm.

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jerry Whitteridge
Sent: Tuesday, June 25, 2019 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Copying portions of a huge data set

Can you only identify the bad data by the line numbers or is there a keyword in 
the log entries that you can include/exclude by ?

Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
06/25/2019 01:07:12 PM:

> From: Jesse 1 Robinson 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/25/2019 01:08 PM
> Subject: [EXTERNAL] Copying portions of a huge data set Sent by: IBM 
> Mainframe Discussion List 
>
> We have a file that contains one month's worth of syslog/operlog data.
> Unfortunately a user's job output has infiltrated this file at random 
> points by inappropriate use of MSGCLASS. I want to copy the good data 
> (log stuff) to another file and leave the errant user stuff behind. It 
> seems simple, but I can't seem to tweak a utility like REPRO (with 
> SKIP and COUNT) to do what I want. I've browsed the file and 
> identified by line number where each good data starts/ends and where 
> the bad data starts/ends, like this:
>
> 01 - log
> 932964 - job
> 933148 - log
> 0001539016 - job
> ...
> 0022175585 - job
> 0022176053 - EOD log
>
> The output file should contain just the 'log' data. Suggestions?
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.com
>
>
> --
> 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: zOSMF software validation looking for *.F files

2019-07-01 Thread Allan Staller
Immediately after the successful apply  of the FMID's

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF software validation looking for *.F files

Thinking forward to my v12 Db2 migration, at what point is it advisable to 
accept the base? As soon as I have my first system successfully migrated? Or 
right before the first maintenance Apply?
thanks
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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


Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Bill Giannelli
Thinking forward to my v12 Db2 migration, at what point is it advisable to 
accept the base? As soon as I have my first system successfully migrated? Or 
right before the first maintenance Apply?
thanks
Bill

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


Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Allan Staller
IIRC, the RELFILEs are not used in the accept process. You can just allocate 
them if they are lost.

Kurt Q, Can you comment?

HTH,

-Original Message-
From: Allan Staller
Sent: Monday, July 1, 2019 8:59 AM
To: IBM Mainframe Discussion List 
Subject: RE: zOSMF software validation looking for *.F files

You should be able to accept the base functions with a minimum of additional 
maintenance.

In my shop, I would:
Accept the base functions and any required maintenance. ACCEPT CHECK S(FMID1, 
FMID2,..). Resolve any error holds. This will of course require that the 
.F* files be recalled.
Accept the "prior maintenance level"
Install new maintenance

Accepts should be run on a regular (but not urgent) basis.
My typical timing on ACCEPT, is just prior to the next round of maintenance.
I.e. install maintenance, wait for whatever period (expected to be several 
months or more). Accept current maintenance.
Wash rinse repeat.

HTH.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF software validation looking for *.F files

Thank you for the response! Sorry for being vague. I believe you have the 
answer in that I never accepted the Base for my v11 Db2. I have applied 
maintenance a few times now since migrating to v11. At this point would I be 
able to accept the v11 base only? If si how do I specify that?
thanks
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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


Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Allan Staller
You might get a RC8 from the accept related to deleting the files. Otherwise 
you should be OK.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF software validation looking for *.F files

So at this point if I want to accept the base, I would need to have recalled 
the RELFILES (or *.F*)? Some of them I can not get recalled and am getting 
"locate errors".
thanks
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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


Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Bill Giannelli
So at this point if I want to accept the base, I would need to have recalled 
the RELFILES (or *.F*)? Some of them I can not get recalled and am getting 
"locate errors".
thanks
Bill

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


Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Allan Staller
You should be able to accept the base functions with a minimum of additional 
maintenance.

In my shop, I would:
Accept the base functions and any required maintenance. ACCEPT CHECK S(FMID1, 
FMID2,..). Resolve any error holds. This will of course require that the 
.F* files be recalled.
Accept the "prior maintenance level"
Install new maintenance

Accepts should be run on a regular (but not urgent) basis.
My typical timing on ACCEPT, is just prior to the next round of maintenance.
I.e. install maintenance, wait for whatever period (expected to be several 
months or more). Accept current maintenance.
Wash rinse repeat.

HTH.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF software validation looking for *.F files

Thank you for the response! Sorry for being vague. I believe you have the 
answer in that I never accepted the Base for my v11 Db2. I have applied 
maintenance a few times now since migrating to v11. At this point would I be 
able to accept the v11 base only? If si how do I specify that?
thanks
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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


Re: Boeing's 737 Max Software Outsourced to $9-an-Hour Engineers

2019-07-01 Thread Jeffrey Holst
On first read, this seems to have been outsourced to programmers in India, so 
H1B visa rules would not apply. 

Jeff Holst

On Sun, 30 Jun 2019 20:46:26 +, Seymour J Metz  wrote:

>So much for paying prevailing wages to H1B visa holders. this should be in 
>court, but I won't hold my breathe.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Mark Regan 
>Sent: Saturday, June 29, 2019 5:56 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Fwd: Boeing's 737 Max Software Outsourced to $9-an-Hour Engineers
>
>While not mainframe related, many may relate to this kind of experience.
>
>
>https://finance.yahoo.com/news/boeings-737-max-software-outsourced-204657048.html
>
>Regards,
>
>Mark Regan, K8MTR
>CTO1, USNR-Retired
>Nationwide Ins, Retired
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Bill Giannelli
Thank you for the response! Sorry for being vague. I believe you have the 
answer in that I never accepted the Base for my v11 Db2. I have applied 
maintenance a few times now since migrating to v11. At this point would I be 
able to accept the v11 base only? If si how do I specify that?
thanks
Bill

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


Re: STORAGE OBTAIN doc inconsistency?

2019-07-01 Thread Steve Smith
The notation that would be clearest is to number the bits from right to
left.  However, that may well cause other logical problems on a big-endian
architecture. And obviously, such a change would be ludicrous at this point.

I don't think there's any way to support the old 32-bit numbering that
would solve anything.  Fixing a few mistakes now & then should be fine.

sas


On Thu, Jun 27, 2019 at 7:49 AM Peter Relson  wrote:

> I (to some extent "unfortunately") expect such inconsistency across the
> suite of books (imagine if we still supported both ESA/390 and z
> Architectures as options -- what "notation" would we use)? The effort to
> change every 32-bit-register bit reference to its "appropriate"
> 64-bit-register bit reference is likely to be more than anyone is willing
> to commit to (no matter how good an idea it is)..
>
> But surely we should expect to be consistent for a given macro.
>
> Perhaps someone can suggest a notation that would make it clear "this is a
> bit reference that applies to a 64-bit register". Using "the words" can
> make it clear but is cumbersome. "Bits 32.24-31" (vs "Bits 24-31 of the
> 32-bit register"), "Bits 64.15-23" (vs "bits 15-23 of the 64-bit
> register"), "Control Register 2.64.0-31" (vs "64-bit Control register 2
> bits 0-31"). Not pretty. (Obviously if the numeric range includes a value
> >= 32, there is no ambiguity, so once converted the cases Charles pointed
> out will be clear enough without additional clarification.)
>
> 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
>


-- 
sas

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


Re: SMPE APPLY CHECK CC 04

2019-07-01 Thread David Spiegel
It generates a CC=4 ONLY when at least one HOLD is BYPASSed.

On 2019-07-01 08:51, Allan Staller wrote:
> Perfectly acceptable. IIRC BYPASS(HOLDSYS(.)) automatically generates a 
> CC4
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Bill Giannelli
> Sent: Sunday, June 30, 2019 4:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMPE APPLY CHECK CC 04
>
> I downloaded Db2 maintenance without superseded sysmods. I am running a SMPE 
> APPLY CHECK with BYPASS and am getting a CC 04. Various messages say 
> "conditions were not satisfied  for sysmod XX". As long as I take care of 
> the HOLDDATA requirements I bypassed, can I accept the CC 04 and not try to 
> get a CC 00? Can I proceed to APPLY without check?
> thanks
> Bill
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> --
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
> --
>
> --
> 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: Best way to alert customer to pending license expiration?

2019-07-01 Thread David Spiegel
This reminds me of a story ... (I say that a lot, just ask my kids)
In the '90s, I worked for a multi-national food company. (I did in the 
'80s too, but, that was a different company).
A certain mainframe software company would always send provocatively 
dressed women to visit when it was time to renew contracts and/or to 
sell new software leases.
Years later they denied having this practice and to bolster (or, should 
I say buttress (pun intended)) their argument, they claimed they could 
prove it was false because
their company had some female vice presidents. (They were saying in 
essence that they don't objectify women.) Of course, both could have 
been true (i.e. that there
were female higher-ups AND that they objectified women.) I was LOLing 
when I read this ridiculous article.

On 2019-07-01 08:53, Carl Swanson wrote:
> Another method would send a bill and maybe make a phone call. And to be 
> totally crazy maybe the salesperson could actually visit the customer.
> Just saying electronic is not always the only method and may not be the best.
>
> Carl Swanson
> carl.swan...@dell.com
> Advisory Systems Engineer Mainframe Practice
> Mobile: 215-688-1459
> Sent from iPhone misspellings likely
>
>
>> On Jul 1, 2019, at 8:22 AM, Lionel B Dyck  wrote:
>>
>>  From my experience over the past few decades on the customer side there is
>> no full proof means to inform the customer of an expiring license.
>>
>> Highlighted console messages work if you have live operators who actually
>> look at a console. They also work for the Sysprogs who look at system action
>> messages assuming that they actually read the messages and don't assume that
>> someone else is doing something about it.
>>
>> Messages in a batch job can be useful, again only if the application owner
>> looks at the generated messages and then reports them.
>>
>> Messages in reports are useful as the report user may report that
>> information - then again they may assume that someone is already working the
>> license issue.
>>
>> Lastly just because the messages are there and someone has alerted the
>> appropriate parties does not mean that the product won't expire as I have
>> rarely found any of the places I've worked where the licenses get renewed on
>> time - my experience is that 99% (perhaps higher) do expire and fall into
>> either a grace period or the Sysprog scrambles to get a temporary extension
>> from the vendor.
>>
>> My $0.01 on the topic
>>
>> Lionel B. Dyck <
>> Website: 
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.lbdsoftware.comdata=02%7C01%7C%7C200bb77b7dc446ba7a8d08d6fe232a22%7C84df9e7fe9f640afb435%7C1%7C0%7C636975824340116566sdata=QrKTqXsnBr0rmuE92qE25S%2FeGLvI07v7fu55qUNbXeE%3Dreserved=0
>>
>> "Worry more about your character than your reputation.  Character is what
>> you are, reputation merely what others think you are." - John Wooden
> --
> 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: Best way to alert customer to pending license expiration?

2019-07-01 Thread Lionel B Dyck
Steve - that is a great reply.  Carl's suggestion for the sales rep to call 
and/or visit is spot on. 


Lionel B. Dyck <
Website: http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Smith
Sent: Monday, July 1, 2019 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way to alert customer to pending license expiration?

The customer has a responsibility to manage their own system.  The fact that 
many do not (completely) is not really something you can solve.

For many reasons, people have been trying all kinds of ways to force people to 
read their so-very-important message.  You cannot, and it would be a violation 
of humanity if you could.  All you can do is provide the information in a way 
that is reasonably easy to discover.

And basically repeating what Carl Swanson said: On the vendor side, I don't 
know why the sales team can't keep track of what they've sold, and follow up 
with customers before their license expires.  I think I'd set up automatic 
renewals, if possible, myself.

sas


On Mon, Jul 1, 2019 at 8:53 AM Carl Swanson < 
0252c152a1b5-dmarc-requ...@listserv.ua.edu> wrote:

> Another method would send a bill and maybe make a phone call. And to 
> be totally crazy maybe the salesperson could actually visit the customer.
> Just saying electronic is not always the only method and may not be 
> the best.
>
> Carl Swanson
> carl.swan...@dell.com
> Advisory Systems Engineer Mainframe Practice
> Mobile: 215-688-1459
> Sent from iPhone misspellings likely

--
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: Best way to alert customer to pending license expiration?

2019-07-01 Thread Steve Smith
The customer has a responsibility to manage their own system.  The fact
that many do not (completely) is not really something you can solve.

For many reasons, people have been trying all kinds of ways to force people
to read their so-very-important message.  You cannot, and it would be a
violation of humanity if you could.  All you can do is provide the
information in a way that is reasonably easy to discover.

And basically repeating what Carl Swanson said: On the vendor side, I don't
know why the sales team can't keep track of what they've sold, and follow
up with customers before their license expires.  I think I'd set up
automatic renewals, if possible, myself.

sas


On Mon, Jul 1, 2019 at 8:53 AM Carl Swanson <
0252c152a1b5-dmarc-requ...@listserv.ua.edu> wrote:

> Another method would send a bill and maybe make a phone call. And to be
> totally crazy maybe the salesperson could actually visit the customer.
> Just saying electronic is not always the only method and may not be the
> best.
>
> Carl Swanson
> carl.swan...@dell.com
> Advisory Systems Engineer Mainframe Practice
> Mobile: 215-688-1459
> Sent from iPhone misspellings likely

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


Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Allan Staller
*.F1 seems to match the convention for SMP RELFILES. Perhaps you need to run an 
accept of  the base function, which will clean up the RELFILES.
Not a lot to go on from the info provided.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, July 1, 2019 5:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF software validation looking for *.F files

Hello,
I am stumbling through zOSMF and am in Software management trying to do 
"software validation". zOSMF is attempting to access the original software 
files (*.F1, etc). Most of these files are migrated on my system and some are 
not able to be recalled. Why does zOSMF need to read these files?
thanks
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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


Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread Allan Staller
AMATERSE should provide what you want for a "classic" or "unix" file.
Of course this is only useful if the remote site is also z/OS.

AFAIK tar, pax,  in Unix System Services are compatible with their non-z/OS 
counterparts,
If support for "classic" files in not available, there are OGET, OPUT commands 
on z/OS to bridge the gap between z/OS and Open Systems.

HTH,



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Donald Russell
Sent: Sunday, June 30, 2019 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using bpxbatch to compress an MVS dataset

I’m not considering the cost of compression  in relation to the transfer 
savings because the size of the files is huge (several million lines of
text) that compress really well. Pkzip/gzip seems to get well over 80% 
compression. Then yes, after the mvs job step runs, the ftp target is in 
another city or even continent, and the ftp traffic is encrypted inflight using 
ftps.

My goal is to to compress the text file prior to ftp.

Can bpxbatch programs like tar read/write from/to dd names, or fully qualified 
dataset names instead of Unix-like file paths?

Don


On Sun, Jun 30, 2019 at 09:19 Steve Thompson  wrote:

> If this file is being sent inside your firewall, the time and CPU
> cycles will cost more than the ftp. This is based on experiences using
> MFT products. (Basically what Gadi said).
>
> We found in testing that compressing was really only useful with small
> pipes. Of course, there is a ratio between number of bytes to transfer
> and bandwidth in determining the effectiveness of the compression (and
> compression method).
>
> Now, if this is confidential data, and is going outside of your
> firewall, you have to consider encryption. Compress first, then
> encrypt, because encrypted data is generally uncompressable.
>
> HTH
> Steve Thompson
>
> Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr.
> Expct mistaks
>
>
> > On Jun 30, 2019, at 12:05 PM, Gadi Ben-Avi  wrote:
> >
> > If both systems are on the same physical computer, it might not be
> > worth
> it.
> > The time and cpu cycles it would take to compress and uncompress
> > might
> take longer than transferring the un compressed file.
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of Donald Russell
> > Sent: Sunday, June 30, 2019 6:58 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Using bpxbatch to compress an MVS dataset
> >
> > I have a batch process in zOS 2.1 (soon to be 2.3) that creates a
> > large
> text file I want to FTP to a zLinux system.
> >
> > How can I use bpxbatch tar or compress (or ?) to create a smaller
> > file I
> can ftp instead instead of the original file? I don’t want to use
> pkzip unless that’s the only choice. Terse is no good because Linux
> can’t unterse it.
> >
> > Is there a way to specify a DD name for the input and output files,
> similar to how FTP allows put/get //DD:
> >
> > Part two... the text in the file is EBCDIC, but Linux wants ASCII. I
> don’t see an option to do the conversion.
> >
> > I’ll have to check tr, but maybe there’s a way to use more
> > traditional
> Unix syntax like
> >
> > cat //dd:in | tr ... | tar -cv //dd:out
> >
> > Cheers,
> > Don
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not 

Re: Best way to alert customer to pending license expiration?

2019-07-01 Thread Carl Swanson
Another method would send a bill and maybe make a phone call. And to be totally 
crazy maybe the salesperson could actually visit the customer.
Just saying electronic is not always the only method and may not be the best.

Carl Swanson
carl.swan...@dell.com
Advisory Systems Engineer Mainframe Practice 
Mobile: 215-688-1459
Sent from iPhone misspellings likely


> On Jul 1, 2019, at 8:22 AM, Lionel B Dyck  wrote:
> 
> From my experience over the past few decades on the customer side there is
> no full proof means to inform the customer of an expiring license.
> 
> Highlighted console messages work if you have live operators who actually
> look at a console. They also work for the Sysprogs who look at system action
> messages assuming that they actually read the messages and don't assume that
> someone else is doing something about it.
> 
> Messages in a batch job can be useful, again only if the application owner
> looks at the generated messages and then reports them.
> 
> Messages in reports are useful as the report user may report that
> information - then again they may assume that someone is already working the
> license issue.
> 
> Lastly just because the messages are there and someone has alerted the
> appropriate parties does not mean that the product won't expire as I have
> rarely found any of the places I've worked where the licenses get renewed on
> time - my experience is that 99% (perhaps higher) do expire and fall into
> either a grace period or the Sysprog scrambles to get a temporary extension
> from the vendor.
> 
> My $0.01 on the topic
> 
> Lionel B. Dyck <
> Website: http://www.lbdsoftware.com
> 
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden

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


Re: SMPE APPLY CHECK CC 04

2019-07-01 Thread Allan Staller
Perfectly acceptable. IIRC BYPASS(HOLDSYS(.)) automatically generates a CC4

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Sunday, June 30, 2019 4:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE APPLY CHECK CC 04

I downloaded Db2 maintenance without superseded sysmods. I am running a SMPE 
APPLY CHECK with BYPASS and am getting a CC 04. Various messages say 
"conditions were not satisfied  for sysmod XX". As long as I take care of 
the HOLDDATA requirements I bypassed, can I accept the CC 04 and not try to get 
a CC 00? Can I proceed to APPLY without check?
thanks
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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


Re: STORAGE OBTAIN doc inconsistency?

2019-07-01 Thread scott Ford
Peter,

I always liked to see the macro, with the options and then examples.
Maybe because I am a visual learner, but this is easier for me..
Just a thought...

Scott

On Thu, Jun 27, 2019 at 7:49 AM Peter Relson  wrote:

> I (to some extent "unfortunately") expect such inconsistency across the
> suite of books (imagine if we still supported both ESA/390 and z
> Architectures as options -- what "notation" would we use)? The effort to
> change every 32-bit-register bit reference to its "appropriate"
> 64-bit-register bit reference is likely to be more than anyone is willing
> to commit to (no matter how good an idea it is)..
>
> But surely we should expect to be consistent for a given macro.
>
> Perhaps someone can suggest a notation that would make it clear "this is a
> bit reference that applies to a 64-bit register". Using "the words" can
> make it clear but is cumbersome. "Bits 32.24-31" (vs "Bits 24-31 of the
> 32-bit register"), "Bits 64.15-23" (vs "bits 15-23 of the 64-bit
> register"), "Control Register 2.64.0-31" (vs "64-bit Control register 2
> bits 0-31"). Not pretty. (Obviously if the numeric range includes a value
> >= 32, there is no ambiguity, so once converted the cases Charles pointed
> out will be clear enough without additional clarification.)
>
> 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
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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


Re: zOSMF software validation looking for *.F files

2019-07-01 Thread Kurt Quackenbush

On 7/1/2019 6:29 AM, Bill Giannelli wrote:

Hello, I am stumbling through zOSMF and am in Software management
trying to do "software validation". zOSMF is attempting to access the
original software files (*.F1, etc). Most of these files are migrated
on my system and some are not able to be recalled. Why does zOSMF
need to read these files?


Sounds like you are using the Software Instance -> Maintenance
Reports -> Software Instance Validation action.  One of the checks 
performed by this report processing is to ensure the data sets 
referenced by your SMP/E global, target, and dlib zones actually exist. 
 This includes the SMPTLIB data sets supplied by FUNCTION SYSMODs 
received in the global zone (data sets whose names are of the form *.F1).


If a data set is migrated and cannot be recalled, then the validation 
report will tell you this.  What you choose to do with this information 
is up to you.  For example, if you have no plans ever to APPLY or ACCEPT 
the FUNCTION SYSMOD that supplied the subject SMPTLIB data set, then I 
suppose you can ignore the error.


Kurt Quackenbush -- IBM, SMP/E and z/OSMF Software Management
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: Best way to alert customer to pending license expiration?

2019-07-01 Thread Lionel B Dyck
>From my experience over the past few decades on the customer side there is
no full proof means to inform the customer of an expiring license.

Highlighted console messages work if you have live operators who actually
look at a console. They also work for the Sysprogs who look at system action
messages assuming that they actually read the messages and don't assume that
someone else is doing something about it.

Messages in a batch job can be useful, again only if the application owner
looks at the generated messages and then reports them.

Messages in reports are useful as the report user may report that
information - then again they may assume that someone is already working the
license issue.

Lastly just because the messages are there and someone has alerted the
appropriate parties does not mean that the product won't expire as I have
rarely found any of the places I've worked where the licenses get renewed on
time - my experience is that 99% (perhaps higher) do expire and fall into
either a grace period or the Sysprog scrambles to get a temporary extension
from the vendor.

My $0.01 on the topic

Lionel B. Dyck <
Website: http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

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


Re: Best way to alert customer to pending license expiration?

2019-07-01 Thread Tony Thigpen
My software emails the customer a notice once a day, if the customer 
adds the correct email to the configuration.


Tony Thigpen

Charles Mills wrote on 6/30/19 6:40 PM:

Okay, I am "dropping up one level" from my question about persistent WTO
messages. The REAL question is "what would be the best way to tell a
customer that their license is fairly close to expiration?"

Please, may I ask that we not digress into whether license enforcement is a
good idea. That's a valid discussion but it's not this thread. I'm a
contractor on this and it's not my decision. I also happen to think that
software vendors need to get paid and not every customer ponies up
spontaneously. FWIW, there is no CPUID checking in the product, just certain
usage restrictions and an expiration date.

It's a batch product. It's not a huge big deal product, so there is no
"CA-1" that is devoted to license management.

What would be the best way to get the right peoples' attention to let them
know that the license is fairly close to expiration? Let me tell you from
experience three things that do not work well:

- An I message in SYSPRINT with no elevated return code. Put simply, nobody
notices or cares. (Until the product expires, and then all heck breaks
loose.)
- A W message in SYSPRINT with a return code of 4. All heck breaks loose at
that point, because everyone seems to use JCL that checks for a zero return
code, and you break their batch processes with a 4. You might as well return
16 as return 4.
- Having vendor sales management keep track of whether a new license has
been sent, and managing it that way. (1) "A license has been sent" is not
the same thing as "someone actually installed the license"; and (2) not
every sales person is a genius at getting paperwork right.

I was considering some sort of WTO that would require manual attention -- or
at least console automation simulated attention -- but that may not be a
great possibility.

So ... what have you seen that has worked well in your opinion?

Thanks,
Charles

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




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


Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread Scott Chapman
On Sun, 30 Jun 2019 15:46:17 -0500, Paul Gilmartin  wrote:

>On Sun, 30 Jun 2019 20:34:19 +, Denis wrote:
>
>>I wonder if the jar command of the Java SDK in z/OS creates gzip compatible 
>>jar files, which in Windows can be extracted/used by renaming Form .jar to 
>>.ZIP.I cannot remember if the jar compression uses ziip.Any file type can be 
>>added to a jar, but I have not tried dd names.
>> 
>I believe jar uses zip deflate.  I've used it to unpack zipped files from 
>cbttape.org.
>I believe jar isn't fussy about filenames -- you can bypass the rename.
>Jar syntax is most similar to tar.

I've used jar to zip up files and transfer them to/from the mainframe. Do need 
to handle ASCII/EBCDIC translations on one side or another. My recollection is 
that it does run on at least partially on the zIIP. Command is something like:
jar -cfM mydata.jar maydata.txt

The "M" option says don't produce the manifest file, which you don't need if 
the goal is just to zip up the data. 

The zip file API in Java is not that difficult to use and combined with the 
JZOS library, it's not hard to write a little utility that will read/write from 
DDs instead of file system files. I did so at my past job, but alas the source 
for that was left with the previous employer. 

Scott Chapman

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


Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread Sean Gleann
Hi Donald
The URL in my original response to you appears to have been garbled by some
sort of 'protection' thingy.
I don't know how to work around that, but here's an attempt:
h t t p : / / g r o u p s . y a h o o . c o m / g r o u p / h e r c u l e s
- 3 9 0
just remove the spaces to get the correct link back.

Regards
Sean

On Mon, 1 Jul 2019 at 11:18, David Spiegel  wrote:

> Hi Seann,
> In which Group would I find TERSE.ZIP?
>
> Thanks and regards,
> David
>
> On 2019-07-01 06:05, Sean Gleann wrote:
> > Donald: From your initial query... "Terse is no good because Linux can’t
> > unterse it."
> > FWIW there is a TERSE application available from the old Hercules days
> that
> > includes implementations for Windows, DOS, MAC and Linux.
> > I tried it out on windows and found it worked tolerably well for handling
> > TERSEd data moving in both directions, but I can't speak for the Linux
> > implementation.
> > If you can login to yahoo groups
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroups.yahoo.com%2Fgroup%2Fhercules-390data=02%7C01%7C%7C90d8eaf26b1547e8f6d908d6fe0bd459%7C84df9e7fe9f640afb435%7C1%7C0%7C636975724126831910sdata=tYjKfYK%2FmO7rXFzgo8oU2oCX5dUF%2FHMQmukNZl90lKY%3Dreserved=0
> > and go to 'files', you should be able to find the TERSE.ZIP distribution
> > file.
> >
> > Regards
> > Sean.
> >
> >
> >
> > On Sun, 30 Jun 2019 at 22:24, Lizette Koehler 
> > wrote:
> >
> >> If this is a batch process to FTP to another platform, and it can handle
> >> tar or jar etc...
> >>
> >> Then you can certainly do that.
> >>
> >> If the other platform can use TRSMAIN output, that is part of z/OS
> >>
> >> So for your issue, you just need a first step to send the file to USS
> and
> >> pax or tar it.
> >>
> >> Then ftp to the other platform.  Once received there - you should be
> able
> >> to reverse the process
> >>
> >>
> >> There is some interesting information here
> >>
> >>
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-01.ibm.com%2Fsupport%2Fdocview.wss%3Fuid%3Disg1OA5data=02%7C01%7C%7C90d8eaf26b1547e8f6d908d6fe0bd459%7C84df9e7fe9f640afb435%7C1%7C0%7C636975724126831910sdata=HOwbwkzsXj%2BDlFJhl6yegpytyIiHHLa90AUmwmBtD2Y%3Dreserved=0
> >>
> >>
> >>
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.bpxa500%2Fmvsds.htmdata=02%7C01%7C%7C90d8eaf26b1547e8f6d908d6fe0bd459%7C84df9e7fe9f640afb435%7C1%7C0%7C636975724126831910sdata=eR61kd6UsyJuUucHmVjO6xVWOZH046s3ICvIpAmIQko%3Dreserved=0
> >>
> >>
> >> I have not done this myself, but I know it should be possible to do.
> >>
> >> Lizette
> >>
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List  On
> >> Behalf Of
> >>> Donald Russell
> >>> Sent: Sunday, June 30, 2019 8:58 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Using bpxbatch to compress an MVS dataset
> >>>
> >>> I have a batch process in zOS 2.1 (soon to be 2.3) that creates a large
> >> text
> >>> file I want to FTP to a zLinux system.
> >>>
> >>> How can I use bpxbatch tar or compress (or ?) to create a smaller file
> I
> >> can
> >>> ftp instead instead of the original file? I don’t want to use pkzip
> >> unless
> >>> that’s the only choice. Terse is no good because Linux can’t unterse
> it.
> >>>
> >>> Is there a way to specify a DD name for the input and output files,
> >> similar
> >>> to how FTP allows put/get //DD:
> >>>
> >>> Part two... the text in the file is EBCDIC, but Linux wants ASCII. I
> >> don’t
> >>> see an option to do the conversion.
> >>>
> >>> I’ll have to check tr, but maybe there’s a way to use more traditional
> >> Unix
> >>> syntax like
> >>>
> >>> cat //dd:in | tr ... | tar -cv //dd:out
> >>>
> >>> Cheers,
> >>> Don
> >>>
> >>> --
> >>> For IBM-MAIN subscribe / signoff / archive access instructions, send
> >> email to
> >>> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > .
> >
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


zOSMF software validation looking for *.F files

2019-07-01 Thread Bill Giannelli
Hello,
I am stumbling through zOSMF and am in Software management trying to do 
"software validation". zOSMF is attempting to access the original software 
files (*.F1, etc). Most of these files are migrated on my system and some are 
not able to be recalled. Why does zOSMF need to read these files?
thanks
Bill

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


Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread David Spiegel
Hi Seann,
In which Group would I find TERSE.ZIP?

Thanks and regards,
David

On 2019-07-01 06:05, Sean Gleann wrote:
> Donald: From your initial query... "Terse is no good because Linux can’t
> unterse it."
> FWIW there is a TERSE application available from the old Hercules days that
> includes implementations for Windows, DOS, MAC and Linux.
> I tried it out on windows and found it worked tolerably well for handling
> TERSEd data moving in both directions, but I can't speak for the Linux
> implementation.
> If you can login to yahoo groups 
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroups.yahoo.com%2Fgroup%2Fhercules-390data=02%7C01%7C%7C90d8eaf26b1547e8f6d908d6fe0bd459%7C84df9e7fe9f640afb435%7C1%7C0%7C636975724126831910sdata=tYjKfYK%2FmO7rXFzgo8oU2oCX5dUF%2FHMQmukNZl90lKY%3Dreserved=0
> and go to 'files', you should be able to find the TERSE.ZIP distribution
> file.
>
> Regards
> Sean.
>
>
>
> On Sun, 30 Jun 2019 at 22:24, Lizette Koehler 
> wrote:
>
>> If this is a batch process to FTP to another platform, and it can handle
>> tar or jar etc...
>>
>> Then you can certainly do that.
>>
>> If the other platform can use TRSMAIN output, that is part of z/OS
>>
>> So for your issue, you just need a first step to send the file to USS and
>> pax or tar it.
>>
>> Then ftp to the other platform.  Once received there - you should be able
>> to reverse the process
>>
>>
>> There is some interesting information here
>>
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-01.ibm.com%2Fsupport%2Fdocview.wss%3Fuid%3Disg1OA5data=02%7C01%7C%7C90d8eaf26b1547e8f6d908d6fe0bd459%7C84df9e7fe9f640afb435%7C1%7C0%7C636975724126831910sdata=HOwbwkzsXj%2BDlFJhl6yegpytyIiHHLa90AUmwmBtD2Y%3Dreserved=0
>>
>>
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.bpxa500%2Fmvsds.htmdata=02%7C01%7C%7C90d8eaf26b1547e8f6d908d6fe0bd459%7C84df9e7fe9f640afb435%7C1%7C0%7C636975724126831910sdata=eR61kd6UsyJuUucHmVjO6xVWOZH046s3ICvIpAmIQko%3Dreserved=0
>>
>>
>> I have not done this myself, but I know it should be possible to do.
>>
>> Lizette
>>
>>
>>
>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On
>> Behalf Of
>>> Donald Russell
>>> Sent: Sunday, June 30, 2019 8:58 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Using bpxbatch to compress an MVS dataset
>>>
>>> I have a batch process in zOS 2.1 (soon to be 2.3) that creates a large
>> text
>>> file I want to FTP to a zLinux system.
>>>
>>> How can I use bpxbatch tar or compress (or ?) to create a smaller file I
>> can
>>> ftp instead instead of the original file? I don’t want to use pkzip
>> unless
>>> that’s the only choice. Terse is no good because Linux can’t unterse it.
>>>
>>> Is there a way to specify a DD name for the input and output files,
>> similar
>>> to how FTP allows put/get //DD:
>>>
>>> Part two... the text in the file is EBCDIC, but Linux wants ASCII. I
>> don’t
>>> see an option to do the conversion.
>>>
>>> I’ll have to check tr, but maybe there’s a way to use more traditional
>> Unix
>>> syntax like
>>>
>>> cat //dd:in | tr ... | tar -cv //dd:out
>>>
>>> Cheers,
>>> Don
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>> email to
>>> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>


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


Re: Using bpxbatch to compress an MVS dataset

2019-07-01 Thread Sean Gleann
Donald: From your initial query... "Terse is no good because Linux can’t
unterse it."
FWIW there is a TERSE application available from the old Hercules days that
includes implementations for Windows, DOS, MAC and Linux.
I tried it out on windows and found it worked tolerably well for handling
TERSEd data moving in both directions, but I can't speak for the Linux
implementation.
If you can login to yahoo groups http://groups.yahoo.com/group/hercules-390
and go to 'files', you should be able to find the TERSE.ZIP distribution
file.

Regards
Sean.



On Sun, 30 Jun 2019 at 22:24, Lizette Koehler 
wrote:

> If this is a batch process to FTP to another platform, and it can handle
> tar or jar etc...
>
> Then you can certainly do that.
>
> If the other platform can use TRSMAIN output, that is part of z/OS
>
> So for your issue, you just need a first step to send the file to USS and
> pax or tar it.
>
> Then ftp to the other platform.  Once received there - you should be able
> to reverse the process
>
>
> There is some interesting information here
>
> https://www-01.ibm.com/support/docview.wss?uid=isg1OA5
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa500/mvsds.htm
>
>
> I have not done this myself, but I know it should be possible to do.
>
> Lizette
>
>
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of
> > Donald Russell
> > Sent: Sunday, June 30, 2019 8:58 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Using bpxbatch to compress an MVS dataset
> >
> > I have a batch process in zOS 2.1 (soon to be 2.3) that creates a large
> text
> > file I want to FTP to a zLinux system.
> >
> > How can I use bpxbatch tar or compress (or ?) to create a smaller file I
> can
> > ftp instead instead of the original file? I don’t want to use pkzip
> unless
> > that’s the only choice. Terse is no good because Linux can’t unterse it.
> >
> > Is there a way to specify a DD name for the input and output files,
> similar
> > to how FTP allows put/get //DD:
> >
> > Part two... the text in the file is EBCDIC, but Linux wants ASCII. I
> don’t
> > see an option to do the conversion.
> >
> > I’ll have to check tr, but maybe there’s a way to use more traditional
> Unix
> > syntax like
> >
> > cat //dd:in | tr ... | tar -cv //dd:out
> >
> > Cheers,
> > Don
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to
> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Re: Best way to alert customer to pending license expiration?

2019-07-01 Thread Timothy Sipples
Clark Morris wrote:
>I suggest a call home module that notifies the vendor a product
>is actually installed and the date of installation.

You're assuming that the target machine has the technical connectivity to
"call home," or, that if it doesn't, the operators and managers of the
target machine would agree to such connectivity and configure it. I don't
think you can make those assumptions.

Or, you (the vendor, not you Clark) assume that your customer must
allow your software at least temporary technical connectivity to "call
home" for its initial license activation and for license renewals, which
could be one-time events annually. Only an authorized administrator would
be able to trigger an outbound call home attempt. The product would never
attempt to call home on its own, and there will be no inbound attempts from
the vendor. (Example: "FETCH LICENSE https://license.vendor.com.;) If the
vendor's backend system doesn't receive and reply to a license
activation/renewal in timely fashion, and if the customer hasn't explicitly
terminated their license, then a license violation is presumed.

There will likely be some loss of sales with this sort of technical
arrangement, and you'll have to be prepared for the greater support burden,
up front -- before your software has had the chance to demonstrate its
worth. There will customers who will have logical, sensible reasons they
cannot conduct business this way. However, perhaps the loss of sales will
be commercially acceptable. Or, for such customers, you could provide
alternate arrangements, such as a license server instance that they can run
and update within their environment, a server (multi-arch Docker
container?) that would support FETCH LICENSE https://license.customer.com
(for example).

Yes, the product could still generate its warning messages that might be
ignored.

For a batch-oriented program conceivably you could have warning messages
that eventually "graduate" into an invocation pause after a grace period --
perhaps even with a one-time resettable grace period; for example, the
administrator can add +35 days to the grace period on a one-time basis.
(Why 35? That's longer than one month, and months can be quite important in
both batch and procurement cycles.) However, once the license expires
without renewal, and after the grace period (extended or not), the program
would wait some escalating time interval before proceeding, with that time
interval preferably capped at something reasonable but painful (or painful
but reasonable). Or it would throttle to some number of records per minute
(for example). Or some of both. These "wait states" would presumably
trigger a "Hey, this product is running slower" complaint.

For the record, I do not like any of these ideas -- yuck! And whatever you
do (if you do), it should be fully disclosed up front (before sale),
carefully documented, and thoroughly tested.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
E-Mail: sipp...@sg.ibm.com

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