Re: File transfer Red Alert

[Peter Hunkeler]

​>Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you 
can do a BINary download to a PC, then do a BINary upload to z/OS if you 
first do a "QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".​ 




Just for the records, above QUOTE command has the values wrong. Correct is: 
4160.


And to improve performance, use BLKSIZE=29120, and RECFM=FBS. 

-- 
Peter Hunkeler 

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Mike Hochee]

Yes, definitely something like that... AMAPTFLE.  It was mentioned in this 
NaSPA article as an SMP predecessor... 
http://www.naspa.net/magazine/2005/0705/T0507009.pdf   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard Adam
Sent: Thursday, May 24, 2018 12:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

I personally used SMP in 1975 on a S/360 running MFT.

Sent from my iPhone

On May 23, 2018, at 8:29 PM, Edward Gould  wrote:

>> On May 23, 2018, at 2:13 PM, Gerhard Adam  wrote:
>> 
>> SMP was available in MVT and MFT.  It did not begin with MVS
> 
> I beg to differ. But I was new to the job and our senior sysprog did maint 
> with another IBM program (which I do not remember but it was NOT SMP but 
> something like iebptfle or something like that.
> Someone else, please confirm.
> 
> Ed
> 
> 
> --
> 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: Old School Maintenance Philosophy -- Never ACCEPT?

[Ed Jaffe]

On 5/23/2018 9:30 AM, Jesse 1 Robinson wrote:

Open any IBM doc on SMP(/E) ever published and you will find the same canonical 
procedure:

--RECEIVE
--APPLY
--ACCEPT (maybe hold off on this a while, but resolve to do it eventually)


FWIW, I always do it this way:
--ACCEPT
--RECEIVE
--APPLY

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Gerhard Adam]

I personally used SMP in 1975 on a S/360 running MFT.

Sent from my iPhone

On May 23, 2018, at 8:29 PM, Edward Gould  wrote:

>> On May 23, 2018, at 2:13 PM, Gerhard Adam  wrote:
>> 
>> SMP was available in MVT and MFT.  It did not begin with MVS
> 
> I beg to differ. But I was new to the job and our senior sysprog did maint 
> with another IBM program (which I do not remember but it was NOT SMP but 
> something like iebptfle or something like that.
> Someone else, please confirm.
> 
> Ed
> 
> 
> --
> 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: GETMAIN LOC=32

[Ed Jaffe]

On 5/11/2018 2:24 PM, Bernd Oppolzer wrote:

For example: I'm not really familiar with the new 64 bit instruction,
but there must be an instruction similar to MVCL, involving two
64 bit address registers and two length registers.


Yes. It's called MVCL.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Edward Gould]

> On May 23, 2018, at 2:13 PM, Gerhard Adam  wrote:
> 
> SMP was available in MVT and MFT.  It did not begin with MVS

I beg to differ. But I was new to the job and our senior sysprog did maint with 
another IBM program (which I do not remember but it was NOT SMP but something 
like iebptfle or something like that.
Someone else, please confirm.

Ed


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

Re: Fwd: [TSO-REXX] Sdsf rexx

[Ed Jaffe]

On 5/8/2018 12:50 PM, Jake Anderson wrote:

Lizette,

We are using EJES. I think it has its own rexx interface.

So finding a way to know the destination based on first character of a
Jobname.


Listing the destination for each job whose name starts with $ is trivial 
in (E)JES. You don't even need a REXX. This simple batch job will create 
a report in a SYSOUT data set showing job name, job id, owner, and 
destination:


//LIST$    JOB 1,JAFFE,CLASS=A,MSGCLASS=T,NOTIFY=
//EJES EXEC PGM=EJESLNK
//EJESOUT  DD DUMMY,RECFM=VB,LRECL=84,BLKSIZE=88
//EJESEXT  DD SYSOUT=*
//EJESIN   DD *
 PRESET;JNAME $*;STATUS;SHOW JNAME JID OWNER PRTDEST;UPDATE
 EXTRACT FIRST LAST
//

The report looks like this in my environment:

STATUS - 3040S- 0X- 9W- 0H- 0T- 0 Records -- Row 
1 to 9

JobName  JobID    Owner    PrtDest
   -
$EDSQ001 S0007202 SYSOPER  LOCAL
$EDSQ002 S0007204 SYSOPER  LOCAL
$EDSQ003 S0007206 SYSOPER  LOCAL
$EDSQ004 S0007208 SYSOPER  LOCAL
$EDSQ005 S0008532 SYSOPER  LOCAL
$EDSQ006 S0008534 SYSOPER  LOCAL
$EDSQ007 S0008536 SYSOPER  LOCAL
$EDSQ008 S0008538 SYSOPER  LOCAL
$MASCOMM S001 SYSOPER  LOCAL

If you want to use REXX instead, you could author something like this:

/* REXX */
  rc=ejesrexx("EXECAPI * 'PRESET;JNAME $*;STATUS' (prefix _ term")
  say "JobName  JobId    Owner    PrtDest"
  do i=1 to _Lines
    say LEFT(_TCData.__JNAME.i,8) LEFT(_TCData.__JID.i,8) ,
    LEFT(_TCData.__OWNER.i,8) _TCData.__PRTDEST.i
  end

Executing this under my TSO userid yields the following:

JobName  JobId    Owner    PrtDest
$EDSQ001 S0007202 SYSOPER  LOCAL
$EDSQ002 S0007204 SYSOPER  LOCAL
$EDSQ003 S0007206 SYSOPER  LOCAL
$EDSQ004 S0007208 SYSOPER  LOCAL
$EDSQ005 S0008532 SYSOPER  LOCAL
$EDSQ006 S0008534 SYSOPER  LOCAL
$EDSQ007 S0008536 SYSOPER  LOCAL
$EDSQ008 S0008538 SYSOPER  LOCAL
$MASCOMM S001 SYSOPER  LOCAL
***
If you have additional questions, please contact Phoenix Software 
Technical Support via supp...@phoenixsoftware.com.


Thanks,

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Jesse 1 Robinson]

Pre-E SMP consisted entirely of PDS--PO because PDSE had not been invented yet. 
It was, as someone pointed out, a sort of elaborate RYO data base. In those 
days of molasses-inspired SLED, clunky CPUs, limited expensive central memory, 
and a far less sophisticated MVS than we enjoy today, a 'standard' SMP install 
could take forever. Hours. Days. Longer even than the MTTF of the 
infrastructure itself. 

So SMP provided an alternative run mode. I forget the terminology, but it 
entailed reading entire PDS directories into memory, updating data in memory as 
required, then writing entire directories back out in one massive operation. 
The result was a far shorter elapsed time than the standard mode. Unless. 
Unless something went wrong, especially during the write-out phase. Could be a 
program failure; DASD error; power hiccup, spilled cup of coffee. At that point 
the entire SMP data base was trashed. So you restored the whole SMP environment 
and started over.

With or without ACCEPT, modern SMP/E is a miracle.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Wednesday, May 23, 2018 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: [External] Old School Maintenance Philosophy -- Never 
ACCEPT?

>SMP/E for z/OS  IBM User's Guide SA23-2277-30
... appears to say otherwise:

No. Read what I actually wrote. The configuration information for an SMP4 or 
earlier environment is in multiple data sets, of which the CDS is only one. The 
CDS is the equivalent of a target zone, not of the entire CSI, and the manual 
you cited does not claim otherwise.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, May 23, 2018 3:19 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

On Wed, 23 May 2018 18:55:21 +, Seymour J Metz wrote:

>The CDS may have been an equivalent to a target zone, but not to the entire 
>CSI. You won't get very far without a PTS and ACDS.
>
SMP/E for z/OS  IBM User's Guide SA23-2277-30 ... appears to say otherwise:

The consolidated software inventory (CSI)
The CSI data sets contain all the information SMP/E needs to
track the distribution and target libraries. As the card catalog
contains a card for each book in the library, the CSI contains
an entry for each element in its libraries. The CSI entries
contain the element name, type, history, how the element was
introduced into the system, and a pointer to the element in the
distribution and target libraries.*The*CSI*does*not*contain*the
*element*itself*, but rather a description of the element it
represents
[emphasis added]

This seems to use "CSI" to refer to the VSAM data sets, but not to PDSes that 
contain actual elements.

-- gil


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

Re: File transfer Red Alert

[Pew, Curtis G]

On May 23, 2018, at 1:56 PM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> And other firewalls block .zip instead (or also).  After all, a .zip might 
> contain
> anything, including executable code.  Some firewalls have a whitelist.  And I
> dealt recently with one that blocked a .eml (Forward as Attachment).
> 
> MIME-encode it; strip headers; name it *.txt. or wrap it as *.pdf.  But don't
> rely on a filename as defense against malware.  See: "steganography".

Yes. I wasn’t trying to suggest that such firewalls are a good idea, or that 
renaming to .zip is a good way to get around them. I just was guessing that 
someone tried to get the .jar file and was blocked, then they complained to the 
vendor, and someone at the vendor said, “Well, a .jar file is really a .zip 
file too, so let’s name it that and let them rename it.”


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: File transfer Red Alert

[Jesse 1 Robinson]

I don't run SFTP personally so I don't have an example, but it's our corporate 
standard for inter-platform data transfer. It can definitely run in batch.

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Wednesday, May 23, 2018 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: File transfer Red Alert

AFAIK, yes (no examples available).

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Wednesday, May 23, 2018 3:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

Can I run sftp as a batch job as I can regular ftp?

On Wed, May 23, 2018 at 2:56 PM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 23 May 2018 16:57:18 +, Pew, Curtis G  wrote:
> >>
> >> Why didn't the supplier, as a courtesy to the customer, deliver the
> file with
> >> the needed extension and save that step?
> >
> >This is just a guess, but maybe some firewalls or other policy 
> >enforcing
> software block .jar files but allow .zip files. If you have a Java VM 
> on your system, .jar files contain executable code and in some 
> circumstances might be executed inadvertently.
> >
> And other firewalls block .zip instead (or also).  After all, a .zip 
> might contain anything, including executable code.  Some firewalls 
> have a whitelist.
> And I
> dealt recently with one that blocked a .eml (Forward as Attachment).
>
> MIME-encode it; strip headers; name it *.txt. or wrap it as *.pdf.
> But don't rely on a filename as defense against malware.  See:
> "steganography".
>
> -- gil


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

Re: File transfer Red Alert

[Allan Staller]

AFAIK, yes (no examples available).

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Wednesday, May 23, 2018 3:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

Can I run sftp as a batch job as I can regular ftp?

On Wed, May 23, 2018 at 2:56 PM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 23 May 2018 16:57:18 +, Pew, Curtis G  wrote:
> >>
> >> Why didn't the supplier, as a courtesy to the customer, deliver the
> file with
> >> the needed extension and save that step?
> >
> >This is just a guess, but maybe some firewalls or other policy
> >enforcing
> software block .jar files but allow .zip files. If you have a Java VM
> on your system, .jar files contain executable code and in some
> circumstances might be executed inadvertently.
> >
> And other firewalls block .zip instead (or also).  After all, a .zip
> might contain anything, including executable code.  Some firewalls
> have a whitelist.
> And I
> dealt recently with one that blocked a .eml (Forward as Attachment).
>
> MIME-encode it; strip headers; name it *.txt. or wrap it as *.pdf.
> But don't rely on a filename as defense against malware.  See:
> "steganography".
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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: File transfer Red Alert

[Mark Pace]

Can I run sftp as a batch job as I can regular ftp?

On Wed, May 23, 2018 at 2:56 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 23 May 2018 16:57:18 +, Pew, Curtis G  wrote:
> >>
> >> Why didn't the supplier, as a courtesy to the customer, deliver the
> file with
> >> the needed extension and save that step?
> >
> >This is just a guess, but maybe some firewalls or other policy enforcing
> software block .jar files but allow .zip files. If you have a Java VM on
> your system, .jar files contain executable code and in some circumstances
> might be executed inadvertently.
> >
> And other firewalls block .zip instead (or also).  After all, a .zip might
> contain
> anything, including executable code.  Some firewalls have a whitelist.
> And I
> dealt recently with one that blocked a .eml (Forward as Attachment).
>
> MIME-encode it; strip headers; name it *.txt. or wrap it as *.pdf.  But
> don't
> rely on a filename as defense against malware.  See: "steganography".
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Seymour J Metz]

>SMP/E for z/OS  IBM User's Guide SA23-2277-30
... appears to say otherwise:

No. Read what I actually wrote. The configuration information for an SMP4 or 
earlier environment is in multiple data sets, of which the CDS is only one. The 
CDS is the equivalent of a target zone, not of the entire CSI, and the manual 
you cited does not claim otherwise.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, May 23, 2018 3:19 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

On Wed, 23 May 2018 18:55:21 +, Seymour J Metz wrote:

>The CDS may have been an equivalent to a target zone, but not to the entire 
>CSI. You won't get very far without a PTS and ACDS.
>
SMP/E for z/OS  IBM User's Guide SA23-2277-30
... appears to say otherwise:

The consolidated software inventory (CSI)
The CSI data sets contain all the information SMP/E needs to
track the distribution and target libraries. As the card catalog
contains a card for each book in the library, the CSI contains
an entry for each element in its libraries. The CSI entries
contain the element name, type, history, how the element was
introduced into the system, and a pointer to the element in the
distribution and target libraries.*The*CSI*does*not*contain*the
*element*itself*, but rather a description of the element it
represents
[emphasis added]

This seems to use "CSI" to refer to the VSAM data sets, but not to PDSes that
contain actual elements.

-- 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: Old School Maintenance Philosophy -- Never ACCEPT?

[Tom Marchant]

On Wed, 23 May 2018 09:55:04 -0700, Gerhard Adam wrote:

>Why bother?  Do a RESTORE GROUP CHECK and get that information.

No, GROUP doesn't work that way with RESTORE.


assume you have applied two PTFs, and one defines the other as the 
prerequisite. When you select the prerequisite and specify the GROUP 
operand, SMP/E also tries to restore the other PTF. On the other hand, 
if you select the SYSMOD that specifies the prerequisite, SMP/E 
restores that particular SYSMOD only if the prerequisite has been 
accepted.


-- 
Tom Marchant

>> On May 23, 2018, at 9:08 AM, Tom Marchant 
>> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> If I want to restore PTF A and RESTORE CHECK tells me that it can't 
>> RESTORE it because PTFs B, C, and D have not been ACCEPTed, I can 
>> run ACCEPT CHECK on B, C, and D. That should give me a list of all the 
>> PTFs that also need to be RESTOREd in order to RESTORE A.

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Paul Gilmartin]

On Wed, 23 May 2018 18:55:21 +, Seymour J Metz wrote:

>The CDS may have been an equivalent to a target zone, but not to the entire 
>CSI. You won't get very far without a PTS and ACDS.
>
SMP/E for z/OS  IBM User's Guide SA23-2277-30
... appears to say otherwise:

The consolidated software inventory (CSI)
The CSI data sets contain all the information SMP/E needs to
track the distribution and target libraries. As the card catalog
contains a card for each book in the library, the CSI contains
an entry for each element in its libraries. The CSI entries
contain the element name, type, history, how the element was
introduced into the system, and a pointer to the element in the
distribution and target libraries.*The*CSI*does*not*contain*the
*element*itself*, but rather a description of the element it 
represents
[emphasis added]

This seems to use "CSI" to refer to the VSAM data sets, but not to PDSes that
contain actual elements.

-- gil

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Gerhard Adam]

If I remember, the PTS still held the sysmods and the ACDS was for the 
distribution "zone" equivalent.

Sent from my iPhone

> On May 23, 2018, at 11:55 AM, Seymour J Metz  wrote:
> 
> The CDS may have been an equivalent to a target zone, but not to the entire 
> CSI. You won't get very far without a PTS and ACDS.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Nims,Alva John (Al) 
> Sent: Wednesday, May 23, 2018 2:50 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
> 
> Yes, that was my mistake, I should have said the predecessor to the CSI was 
> the CDS, a PDS data set with that funny character in the member name.
> 
> Al Nims
> Systems Admin/Programmer III
> UF Information Technology
> East Campus
> P.O. Box 112050
> Gainesville, FL. 32611
> (e) ajn...@ufl.edu
> (p) (352) 273-1298
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Wednesday, May 23, 2018 2:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
> 
>> On Wed, 23 May 2018 11:05:29 -0700, Gerhard Adam wrote:
>> 
>> I think the reference may have been to the older SMP CDS which played
>> the role of the current CSI
>> 
> The rumor I heard (I wasn't there) is that, prior to VSAM, SMP used a PDS 
> directory as a makeshift data base.  Names of members (which needn't actually 
> exist) were limited to 7 bytes in order that the eighth could be used for 
> flags.
> 
> -- 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: How to get BPX loadhfs (BPX1LOD) to load module into writable memory?

[Thomas David Rivers]

Peter Relson wrote:

I believe that the rules for whether BPX1LOD brings a module into writable 
memory are the same as for whether the LOAD service does.
It primarily has to do with the module attributes (is it reentrant?) and 
the APF authorization of the job step.


Peter Relson
z/OS Core Technology Design
 

Just to follow-up... If I add  -Wl,REUS=NONE to the link step (the c99 
command)

for building the HFS load module - that seems to mark the module
appropriately so that it is loaded into writable memory.

  - 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: File transfer Red Alert

[Paul Gilmartin]

On Wed, 23 May 2018 16:57:18 +, Pew, Curtis G  wrote:
>> 
>> Why didn't the supplier, as a courtesy to the customer, deliver the file with
>> the needed extension and save that step?
>
>This is just a guess, but maybe some firewalls or other policy enforcing 
>software block .jar files but allow .zip files. If you have a Java VM on your 
>system, .jar files contain executable code and in some circumstances might be 
>executed inadvertently.
> 
And other firewalls block .zip instead (or also).  After all, a .zip might 
contain
anything, including executable code.  Some firewalls have a whitelist.  And I
dealt recently with one that blocked a .eml (Forward as Attachment).

MIME-encode it; strip headers; name it *.txt. or wrap it as *.pdf.  But don't
rely on a filename as defense against malware.  See: "steganography".

-- gil

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Seymour J Metz]

The CDS may have been an equivalent to a target zone, but not to the entire 
CSI. You won't get very far without a PTS and ACDS.


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


From: IBM Mainframe Discussion List  on behalf of 
Nims,Alva John (Al) 
Sent: Wednesday, May 23, 2018 2:50 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

Yes, that was my mistake, I should have said the predecessor to the CSI was the 
CDS, a PDS data set with that funny character in the member name.

Al Nims
Systems Admin/Programmer III
UF Information Technology
East Campus
P.O. Box 112050
Gainesville, FL. 32611
(e) ajn...@ufl.edu
(p) (352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, May 23, 2018 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

On Wed, 23 May 2018 11:05:29 -0700, Gerhard Adam wrote:

>I think the reference may have been to the older SMP CDS which played
>the role of the current CSI
>
The rumor I heard (I wasn't there) is that, prior to VSAM, SMP used a PDS 
directory as a makeshift data base.  Names of members (which needn't actually 
exist) were limited to 7 bytes in order that the eighth could be used for flags.

-- 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] Old School Maintenance Philosophy -- Never ACCEPT?

[Edward Gould]

> On May 23, 2018, at 9:08 AM, David L. Craig  wrote:
> 
>> 
>> Not sure how long ago eons was, but I started in the
>> mid-80s on MVS/SP and at my first SMP/E (and I believe
>> only) class, I was taught the APPLY / run for a while /
>> ACCEPT usage - except for USERMODs or APARs that hadn't
>> had a published PTF yet.
> 
> I learned to use SMP back on MVT (am I the only one still
> here that can truthfully make that statement?) and while
> it's been a while since I last used SMP/E, I do not recall
> ever encountering a no ACCEPT policy for any IBM MRM.
> But people aren't mentioning policy for archiving snapshots
> of target and DLIB volumes and restoring therefrom--much
> faster than reAPPLYing LOTS of maintenance.  That also
> requires tracking the target/DLIB volume snapshot
> associations, which are not necessarily based upon the
> dates of the snapshots.

AFAIK smp (e)  did not exist during mvs 2.0 3.0(shakes on this one) and it came 
out with 3.7 (?)
Before smp there was tremendous and I do mean tremendous working by having to 
manually to the co, prerec's by hand. It was drudge work that needed a high 
amount of concentration and immersion.
I did it once and couldn’t handle the long hours needed. We printed a 
spreadsheet and it helped a little but still took copious amounts of time.
SMP was a godsend to sysprogs. I would venture to say that  MVS would have 
ended up in the dust pile for computer history without SMP. Yes it was 
cumbersome and the PDS’s needed and large number of directories was a real 
pain. VSAM saved SMP as well.
Ed

 


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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Nims,Alva John (Al)]

Yes, that was my mistake, I should have said the predecessor to the CSI was the 
CDS, a PDS data set with that funny character in the member name.

Al Nims
Systems Admin/Programmer III
UF Information Technology
East Campus 
P.O. Box 112050
Gainesville, FL. 32611
(e) ajn...@ufl.edu 
(p) (352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, May 23, 2018 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

On Wed, 23 May 2018 11:05:29 -0700, Gerhard Adam wrote:

>I think the reference may have been to the older SMP CDS which played 
>the role of the current CSI
> 
The rumor I heard (I wasn't there) is that, prior to VSAM, SMP used a PDS 
directory as a makeshift data base.  Names of members (which needn't actually 
exist) were limited to 7 bytes in order that the eighth could be used for flags.

-- 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] Old School Maintenance Philosophy -- Never ACCEPT?

[Paul Gilmartin]

On Wed, 23 May 2018 11:05:29 -0700, Gerhard Adam wrote:

>I think the reference may have been to the older SMP CDS which played the role 
>of the current CSI
> 
The rumor I heard (I wasn't there) is that, prior to VSAM, SMP used a PDS 
directory
as a makeshift data base.  Names of members (which needn't actually exist) were
limited to 7 bytes in order that the eighth could be used for flags.

-- gil

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

Re: Old School Maintenance Philosophy -- Never ACCEPT?

[Edward Gould]

> On May 22, 2018, at 3:28 PM, Ed Jaffe  wrote:
> 
> z/OS Sysprogs,
> 
> ISTR a maintenance philosophy from "eons" ago where PTFs would be applied but 
> never accepted.
> 
> What was the rationale for this? Does anyone still use this philosophy? If 
> so, why?
> 
> Thanks,
> 
> -- 

Ed,

Long ago and far away we never accepted maintenance as we wanted to be able to 
back fixes off, This was after the DFP fiasco (mega PTF tape).
We were not loathe to change the philosophy but Management seem to cut the 
number of sysprogs so we started to not accept PTF’s (unless there was a need).
Management kept cutting and the acting got delayed and delayed and then 
forgotten. I won’t say it was because of management 100 percent but 95 percent.

Ed

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Carmen Vitullo]

:) so nice to be called a newbe @60, I started out working for Sear ETO in 1977 
as an operator :( 
so yep, very green 


Carmen Vitullo 

- Original Message -

From: "Seymour J Metz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 1:04:09 PM 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

ObNewbie That was before MVSCP. 


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

 
From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo  
Sent: Wednesday, May 23, 2018 1:10 PM 
To: IBM-MAIN@listserv.ua.edu 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

Ah yes, the SYSTEM GEN - MVSCP 


Carmen Vitullo 

- Original Message - 

From: "Seymour J Metz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 11:54:31 AM 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

War stories, yes, but I worked on OS/360 and OS/2 SVS before there was an SMP, 
and that was far worse. 


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

 
From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo  
Sent: Wednesday, May 23, 2018 10:15 AM 
To: IBM-MAIN@listserv.ua.edu 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

I'm so glad I did not have to use/work with SMP, I've heard the war stories and 
I think the backup everyone philosophy came from the old SMP V4 days and at the 
site I worked at, SMP/E I was still taught the standard of backing up all SMP/E 
datasets, target and DLIBS prior to any apply, it has saved my A$$ a couple 
times 



Carmen Vitullo 

- Original Message - 

From: "David L. Craig"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 9:08:45 AM 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

On 18May23:1247+, Pommier, Rex wrote: 
> 
> Not sure how long ago eons was, but I started in the 
> mid-80s on MVS/SP and at my first SMP/E (and I believe 
> only) class, I was taught the APPLY / run for a while / 
> ACCEPT usage - except for USERMODs or APARs that hadn't 
> had a published PTF yet. 

I learned to use SMP back on MVT (am I the only one still 
here that can truthfully make that statement?) and while 
it's been a while since I last used SMP/E, I do not recall 
ever encountering a no ACCEPT policy for any IBM MRM. 
But people aren't mentioning policy for archiving snapshots 
of target and DLIB volumes and restoring therefrom--much 
faster than reAPPLYing LOTS of maintenance. That also 
requires tracking the target/DLIB volume snapshot 
associations, which are not necessarily based upon the 
dates of the snapshots. 
-- 
 
May the LORD God bless you exceedingly abundantly! 

Dave_Craig__ 
"So the universe is not quite as you thought it was. 
You'd better rearrange your beliefs, then. 
Because you certainly can't rearrange the universe." 
__--from_Nightfall_by_Asimov/Silverberg_ 

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


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

Re: Replaceing IEBGENER

[Paul Gilmartin]

On Wed, 23 May 2018 17:41:43 +, Jesse 1 Robinson wrote:

>Sorry for a war story on Wednesday, but it's too good to suppress. We 
>implemented the ICEGENER strategy at a former shop in the 80s. What could go 
>wrong? Seems that some (of course critical) application was creating a 
>sequential file in which the actual number of blocks was calculated. File was 
>created on DASD and IEBGENERed to tape. The JCL that created the tape file did 
>not code BLKSIZE; just depended on IEBGENER's habit of copying input DCB to 
>output. You've all seen the warning message.
>
>File was later read in by another program that expected the original number of 
>blocks. But ICEGENER had already stepped in to help out by reblocking the file 
>to SDB. Good for tape usage; fatal for the program that expected a set number 
>of blocks. 30 years later I still shake my head over that one.  
> 
IIRC, IEBGENER proper went through similar gyrations at the inception of SDB.
It first switched from copying DCB to relying on SDB, then introduced a PARM
option to select the old benavior, and still later made the classical behavior 
the
default.

I just RTFM.  It has become dreadfully complicated.  It depends on
PARM={INPUT|YES|SMALL|LARGE|NO}.  (Is PARM='' supported?
(The doc doesn't say that.)  And on the setting of COPYSDB in
SYS1.PARMLIB.COPYSDB(DEVSUPxx).  And on SMS options.  It
doesn't make it clear in view of all this newfangled stuff what the
individual applications programmer can do to guarantee replicating
BLKSIZE from SYSUT1 to SYSUT2.

Hiwever, I dislike any design that depends on blocking factors.  A
better design of your program would have been to depend on a
particular number of records rather than a particular number of
blocks.  Think QSAM, not BSAM.

-- gil

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

Re: z/OS 2.3 - sftp

[Mark Pace]

Thank you, Kirk and Susan.

On Wed, May 23, 2018 at 12:04 PM, Susan Shumway  wrote:

> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com
> .ibm.zos.v2r3.foto100/sftp.htm
>
> -Sue Shumway
>
> On 05/23/18 11:48 AM, Mark Pace wrote:
>
>> Can someone tell me where the sftp command is documented in z/OS 2.3?
>>
>> I've looked in the 8 Unix System Services manuals.
>>
>>
> --
> Sue Shumway
> z/OS Product Documentation Lead
> IBM Poughkeepsie
> chale...@us.ibm.com
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: VTL as 3490 vs 3590

[Seymour J Metz]

What, z/VM doesn't have 1052-7 support? GD


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


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Tuesday, May 22, 2018 4:03 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: VTL as 3490 vs 3590

W dniu 2018-05-22 o 19:41, Seymour J Metz pisze:
> 3210 and 3215 are local non-SNA devices; there is no telnet equivalent.

3215?
Is it the $#$@% mode which is widely present in z/VM?
I hate set conmode or how it was...

BTW: 3215 support is optional feature of OSA-ICC. Quite new feature...
It seem someone need it.

--
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
http://secure-web.cisco.com/1pJSsN96Rikm63Vj5LHNJ-SX67nA5WLPX1cFtkzwpzuCmhax-mMFO5H2fDvYC4xh4oIYDL5cB8IVWjgwODziC_0K74cEJvhsYVRkREg1w93hmI_41FHIxGyMjecX8qGmFS6VPcRmCHZ3A6gibeQnW71w3kYSJBVMnOlyBzoJN3klvFNbm5ayGzRHGwzPz8fK1-mo1XuY_aJ8vSlMopPzGkNrVzp-hEOY78HkWvyLjWvVLONgDdOeTF-tmltqzyINXBz6Y6qwVKK4ioYk4udkiqc2igfT5A1ooW4ylJFC7p-EvbA1rTXjYZqgdtEFRU0Ggoe8F_GjWl2cshh4M5B7Dnv_o01Fjcv4M_F0TNJfK-XE7540xsM5N4O-DnvQ003WPdr5X7gArRLEpXTAKDyW1wybJRvRa71E6KODxZkp0ifVZXoebipTf115ln8QWFpVn/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 
025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


--
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: Old School Maintenance Philosophy -- Never ACCEPT?

[Seymour J Metz]

>ISTR a maintenance philosophy from "eons" ago where PTFs would be
>applied but never accepted.

It's not my dog.

> What was the rationale for this?

Urban legends? 4 roses?

>Does anyone still use this philosophy?

If so, I don't want to know. The only case where it might make sense was for 
JES2 back when the consistently had packaging errors in their service.

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


From: IBM Mainframe Discussion List  on behalf of Ed 
Jaffe 
Sent: Tuesday, May 22, 2018 4:28 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Old School Maintenance Philosophy -- Never ACCEPT?

z/OS Sysprogs,

ISTR a maintenance philosophy from "eons" ago where PTFs would be
applied but never accepted.

What was the rationale for this? Does anyone still use this philosophy?
If so, why?

Thanks,

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://secure-web.cisco.com/1fsB4sUhPWP49AqaQ7Z_q84p-TXhvVzfBjsIXmwRuTGM4kZ23CdeDfT_aGviLMajJ7mWHOP_ULS4KAhrlje2S7HdZhbAF6w2-3NKDNZMLPNkIT8hGbc_gk7rgf4XhGNS1tDN_p_Suu80ToiJ9MNWWdzv8B173amuMCcfpHJEAFQXeBWM7CXqxOfegtKa6UtYm4IlIAgxFcdW4EVzcXUI4OYT4VuZY101nCpDkYHr4xy0JINdkp-on2vFI6F1A7HEIGF5fALbPyXsVon5MugosmP2_UzAzCn0QTYmpS4hd9gPdKtrfsQ_IlC00TtcOInh6QSVTls86YQD94xsXxupgza6OIRV_0PwulPbwHeivfqJbUJlCEC4D-OuM4W4S6ShEaedY336qvMsqKDweufrJEMMVVYo-EzBqdpnYOjfxla94eGQoH1FjdPxxG2HImS1g/http%3A%2F%2Fwww.phoenixsoftware.com%2F

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
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] Old School Maintenance Philosophy -- Never ACCEPT?

[Seymour J Metz]

No. The equivalent of the CSI was multiple data sets, starting with the PTS, 
CDS and ACDS.


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


From: IBM Mainframe Discussion List  on behalf of 
Gerhard Adam 
Sent: Wednesday, May 23, 2018 2:05 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

I think the reference may have been to the older SMP CDS which played the role 
of the current CSI

Sent from my iPhone

> On May 23, 2018, at 11:03 AM, Seymour J Metz  wrote:
>
> The PTS, among others, was a PDS. SMP used very strange member names. There 
> was no CSI, no zones.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Carmen Vitullo 
> Sent: Wednesday, May 23, 2018 1:11 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
>
> CSI not VSAM ?
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Alva John Nims (Al)" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Wednesday, May 23, 2018 12:00:11 PM
> Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
>
> " I learned to use SMP back on MVT (am I the only one still here that can 
> truthfully make that statement?)" Answer: No, yes I remember SMP back before 
> the "e" was added on, the CSI was a PDS! And not a PDSe!
>
> I do not follow the 'Never ACCEPT" process.
>
> Al Nims
> Systems Admin/Programmer III
> UF Information Technology
> East Campus
> P.O. Box 112050
> Gainesville, FL. 32611
> (e) ajn...@ufl.edu
> (p) (352) 273-1298
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of David L. Craig
> Sent: Wednesday, May 23, 2018 10:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
>
>> On 18May23:1247+, Pommier, Rex wrote:
>>
>> Not sure how long ago eons was, but I started in the mid-80s on MVS/SP
>> and at my first SMP/E (and I believe
>> only) class, I was taught the APPLY / run for a while / ACCEPT usage -
>> except for USERMODs or APARs that hadn't had a published PTF yet.
>
> I learned to use SMP back on MVT (am I the only one still here that can 
> truthfully make that statement?) and while it's been a while since I last 
> used SMP/E, I do not recall ever encountering a no ACCEPT policy for any IBM 
> MRM.
> But people aren't mentioning policy for archiving snapshots of target and 
> DLIB volumes and restoring therefrom--much faster than reAPPLYing LOTS of 
> maintenance. That also requires tracking the target/DLIB volume snapshot 
> associations, which are not necessarily based upon the dates of the snapshots.
> --
> 
> May the LORD God bless you exceedingly abundantly!
>
> Dave_Craig__
> "So the universe is not quite as you thought it was.
> You'd better rearrange your beliefs, then.
> Because you certainly can't rearrange the universe."
> __--from_Nightfall_by_Asimov/Silverberg_
>
> --
> 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

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Gerhard Adam]

I think the reference may have been to the older SMP CDS which played the role 
of the current CSI

Sent from my iPhone

> On May 23, 2018, at 11:03 AM, Seymour J Metz  wrote:
> 
> The PTS, among others, was a PDS. SMP used very strange member names. There 
> was no CSI, no zones.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Carmen Vitullo 
> Sent: Wednesday, May 23, 2018 1:11 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
> 
> CSI not VSAM ?
> 
> 
> Carmen Vitullo
> 
> - Original Message -
> 
> From: "Alva John Nims (Al)" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Wednesday, May 23, 2018 12:00:11 PM
> Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
> 
> " I learned to use SMP back on MVT (am I the only one still here that can 
> truthfully make that statement?)" Answer: No, yes I remember SMP back before 
> the "e" was added on, the CSI was a PDS! And not a PDSe!
> 
> I do not follow the 'Never ACCEPT" process.
> 
> Al Nims
> Systems Admin/Programmer III
> UF Information Technology
> East Campus
> P.O. Box 112050
> Gainesville, FL. 32611
> (e) ajn...@ufl.edu
> (p) (352) 273-1298
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of David L. Craig
> Sent: Wednesday, May 23, 2018 10:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
> 
>> On 18May23:1247+, Pommier, Rex wrote:
>> 
>> Not sure how long ago eons was, but I started in the mid-80s on MVS/SP
>> and at my first SMP/E (and I believe
>> only) class, I was taught the APPLY / run for a while / ACCEPT usage -
>> except for USERMODs or APARs that hadn't had a published PTF yet.
> 
> I learned to use SMP back on MVT (am I the only one still here that can 
> truthfully make that statement?) and while it's been a while since I last 
> used SMP/E, I do not recall ever encountering a no ACCEPT policy for any IBM 
> MRM.
> But people aren't mentioning policy for archiving snapshots of target and 
> DLIB volumes and restoring therefrom--much faster than reAPPLYing LOTS of 
> maintenance. That also requires tracking the target/DLIB volume snapshot 
> associations, which are not necessarily based upon the dates of the snapshots.
> --
> 
> May the LORD God bless you exceedingly abundantly!
> 
> Dave_Craig__
> "So the universe is not quite as you thought it was.
> You'd better rearrange your beliefs, then.
> Because you certainly can't rearrange the universe."
> __--from_Nightfall_by_Asimov/Silverberg_
> 
> --
> 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: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Seymour J Metz]

ObNewbie That was before MVSCP.


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


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, May 23, 2018 1:10 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

Ah yes, the SYSTEM GEN - MVSCP


Carmen Vitullo

- Original Message -

From: "Seymour J Metz" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, May 23, 2018 11:54:31 AM
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

War stories, yes, but I worked on OS/360 and OS/2 SVS before there was an SMP, 
and that was far worse.


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


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, May 23, 2018 10:15 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

I'm so glad I did not have to use/work with SMP, I've heard the war stories and 
I think the backup everyone philosophy came from the old SMP V4 days and at the 
site I worked at, SMP/E I was still taught the standard of backing up all SMP/E 
datasets, target and DLIBS prior to any apply, it has saved my A$$ a couple 
times



Carmen Vitullo

- Original Message -

From: "David L. Craig" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, May 23, 2018 9:08:45 AM
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

On 18May23:1247+, Pommier, Rex wrote:
>
> Not sure how long ago eons was, but I started in the
> mid-80s on MVS/SP and at my first SMP/E (and I believe
> only) class, I was taught the APPLY / run for a while /
> ACCEPT usage - except for USERMODs or APARs that hadn't
> had a published PTF yet.

I learned to use SMP back on MVT (am I the only one still
here that can truthfully make that statement?) and while
it's been a while since I last used SMP/E, I do not recall
ever encountering a no ACCEPT policy for any IBM MRM.
But people aren't mentioning policy for archiving snapshots
of target and DLIB volumes and restoring therefrom--much
faster than reAPPLYing LOTS of maintenance. That also
requires tracking the target/DLIB volume snapshot
associations, which are not necessarily based upon the
dates of the snapshots.
--

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
You'd better rearrange your beliefs, then.
Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

--
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: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Seymour J Metz]

The PTS, among others, was a PDS. SMP used very strange member names. There was 
no CSI, no zones.


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


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, May 23, 2018 1:11 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

CSI not VSAM ?


Carmen Vitullo

- Original Message -

From: "Alva John Nims (Al)" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, May 23, 2018 12:00:11 PM
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

" I learned to use SMP back on MVT (am I the only one still here that can 
truthfully make that statement?)" Answer: No, yes I remember SMP back before 
the "e" was added on, the CSI was a PDS! And not a PDSe!

I do not follow the 'Never ACCEPT" process.

Al Nims
Systems Admin/Programmer III
UF Information Technology
East Campus
P.O. Box 112050
Gainesville, FL. 32611
(e) ajn...@ufl.edu
(p) (352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David L. Craig
Sent: Wednesday, May 23, 2018 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

On 18May23:1247+, Pommier, Rex wrote:
>
> Not sure how long ago eons was, but I started in the mid-80s on MVS/SP
> and at my first SMP/E (and I believe
> only) class, I was taught the APPLY / run for a while / ACCEPT usage -
> except for USERMODs or APARs that hadn't had a published PTF yet.

I learned to use SMP back on MVT (am I the only one still here that can 
truthfully make that statement?) and while it's been a while since I last used 
SMP/E, I do not recall ever encountering a no ACCEPT policy for any IBM MRM.
But people aren't mentioning policy for archiving snapshots of target and DLIB 
volumes and restoring therefrom--much faster than reAPPLYing LOTS of 
maintenance. That also requires tracking the target/DLIB volume snapshot 
associations, which are not necessarily based upon the dates of the snapshots.
--

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
You'd better rearrange your beliefs, then.
Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

--
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: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Seymour J Metz]

SMP3? I remember the original SMP, and the chaotic days before it.


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


From: IBM Mainframe Discussion List  on behalf of 
Bill Hitefield 
Sent: Wednesday, May 23, 2018 1:23 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

In my SysProg days (70s - 80s), I would ACCEPT maintenance, but only after we 
had run it for a while. PUT maintenance was relegated to weekends. I would 
backup the full environment before running the ACCEPT (saved my bacon a few 
times).



PS: Anybody else remember fighting with SMP v3? We were so happy when SMP v4 
came out. 



Bill Hitefield



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gerhard Adam
Sent: Wednesday, May 23, 2018 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?



I also don't recall a "never ACCEPT" policy.  That would be silly because it 
becomes a "never RESTORE" policy.



Sent from my iPhone



> On May 23, 2018, at 7:08 AM, David L. Craig 
> > wrote:

>

>> On 18May23:1247+, Pommier, Rex wrote:

>>

>> Not sure how long ago eons was, but I started in the mid-80s on

>> MVS/SP and at my first SMP/E (and I believe

>> only) class, I was taught the APPLY / run for a while / ACCEPT usage

>> - except for USERMODs or APARs that hadn't had a published PTF yet.

>

> I learned to use SMP back on MVT (am I the only one still here that

> can truthfully make that statement?) and while it's been a while since

> I last used SMP/E, I do not recall ever encountering a no ACCEPT

> policy for any IBM MRM.

> But people aren't mentioning policy for archiving snapshots of target

> and DLIB volumes and restoring therefrom--much faster than reAPPLYing

> LOTS of maintenance.  That also requires tracking the target/DLIB

> volume snapshot associations, which are not necessarily based upon the

> dates of the snapshots.

> --

> 

> May the LORD God bless you exceedingly abundantly!

>

> Dave_Craig__

> "So the universe is not quite as you thought it was.

> You'd better rearrange your beliefs, then.

> Because you certainly can't rearrange the universe."

> __--from_Nightfall_by_Asimov/Silverberg_

>

> --

> 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: Replaceing IEBGENER

[Rugen, Len]

My similar war story, DOS/VS job would fail with system error that blocks read 
from tape didn't match label block count; OK, that is a hardware error, dropped 
block.  After much cleaning and attempts at repair we would still get it.  
Programmer came in one day and said they had fixed it themselves and were mad 
that they had to do it.  Their fix?  Switch to NL tape  



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

Re: File transfer Red Alert

[Jon Nolting]

Makes sense.  That is what I am playing with using OpenSSH sftp or Dovetailed.  
Will using DDDUD meet the earlier requirement for uploads using on PDUU.  If 
so, the I can focus on that?

-Original Message-
From: Jousma, David [mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu] 
Sent: Wednesday, May 23, 2018 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

No, what I am saying is to ditch pduu in favor of ibmsdduu.   There are config 
options to specify a http proxy.   The only caveat I've seen is that the files 
to be uploaded have to be in zfs filesystem 
first.https://urldefense.proofpoint.com/v2/url?u=https-3A__www-2D05.ibm.com_de_support_ecurep_send-5Fjava-2Dtool.html=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=MQsKeOxcIGeiq-qoJzO2oVgUmKB65Wchl7khwwU0Ijk=cL1-pOr7jhx_2fNj4XUty3cpdglFeecEXpNDNYHBXlg=fqD79nYnkIg2jz9wHYkzsSJYcxWUnrjWYUL6cdDU28A=_Dave
 JousmaManager Mainframe Engineering, Assistant Vice 
Presidentdavid.jousma@53.com1830 East Paris, Grand Rapids, MI  49546 MD RSCB2Hp 
616.653.8429f 616.653.2717-Original Message-From: IBM Mainframe 
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jon NoltingSent: 
Wednesday, May 23, 2018 1:41 PMTo: ibm-m...@listserv.ua.EDUSubject: Re: File 
transfer Red Alert**CAUTION EXTERNAL EMAILDO NOT open attachments or click 
on links from unknown senders or unexpected emails**Yes, but PDUU does not 
support Java only the FTP client.  Are you hearing that PDUU is going to use 
something other than the FTP client.  That is what I am hearing from the 
PMR.-Original Message-From: Jousma, David 
[mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu]Sent: Wednesday, May 23, 
2018 10:38 AMTo: ibm-m...@listserv.ua.EDUSubject: Re: File transfer Red 
AlertJon, the newer JAVA utility does document that they support HTTP 
proxy._Dave 
JousmaManager Mainframe Engineering, Assistant Vice President 
david.jousma@53.com1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 
616.653.8429 f 616.653.2717-Original Message-From: IBM Mainframe 
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jon NoltingSent: 
Wednesday, May 23, 2018 1:24 PMTo: ibm-m...@listserv.ua.EDUSubject: Re: File 
transfer Red Alert**CAUTION EXTERNAL EMAILDO NOT open attachments or click 
on links from unknown senders or unexpected emails**In the PMR I opened, PDUU 
(AMAPDUPL) does not use the capability that SMP/E for downloads.  I am talking 
with them about potentially using some variant of USS sftp as their client 
interface to that we can continue using the PDUU tool.As of now, I have to 
upload SVCDUMPs, etc from WinSCP after downloading them to Windows after they 
are TERSE'd.IBM, please don't make the requirement for upload of PDUU only as 
your process doesn't work for HTTP proxies. Service request number 47544 
004 000 -- AMAPDUPL does not support HTTP proxy-Original Message-From: 
Jousma, David [mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu]Sent: 
Wednesday, May 23, 2018 10:19 AMTo: ibm-m...@listserv.ua.EDUSubject: Re: File 
transfer Red AlertSkip, I was going to bring that up too.  We've also got RFN 
working through our HTTPS proxy just fine.   I would like to believe that IBM 
would make something similar available, but not holding my breath either.I 
think that’s why I gave up on PDUU as 
well._Dave 
JousmaManager Mainframe Engineering, Assistant Vice President 
david.jousma@53.com1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 
616.653.8429 f 616.653.2717-Original Message-From: IBM Mainframe 
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 
RobinsonSent: Wednesday, May 23, 2018 1:14 PMTo: 
ibm-m...@listserv.ua.EDUSubject: Re: File transfer Red Alert**CAUTION EXTERNAL 
EMAILDO NOT open attachments or click on links from unknown senders or 
unexpected emails**This is the same road we traversed a few years back when 
RECEIVE FROM NETWORK stopped working with vanilla FTP. We are not technically 
capable of running FTPS directly from z/OS to IBM because we depend on an 
appliance (BlueCoat) to 'punch through' the standard firewall. BlueCoat does 
not--and I'm told never will--support TLS syntax. Fortunately HTTPS was made 
available for RFN, so we've maintained business as usual. I see no mention of 
HTTPS in the current change. This looks like a road with No Outlet.  ..J.O.Skip 
RobinsonSouthern California Edison CompanyElectric Dragon Team PaddlerSHARE MVS 
Program Co-Manager323-715-0595 Mobile626-543-6132 Office ⇐=== 
newrobin...@sce.com-Original Message-From: IBM Mainframe Discussion 
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis GSent: 
Wednesday, May 23, 2018 9:57 AMTo: ibm-m...@listserv.ua.EDUSubject: 
(External):Re: 

Re: File transfer Red Alert

[Jousma, David]

No, what I am saying is to ditch pduu in favor of ibmsdduu.   There are config 
options to specify a http proxy.   The only caveat I've seen is that the files 
to be uploaded have to be in zfs filesystem first.

https://www-05.ibm.com/de/support/ecurep/send_java-tool.html



_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Nolting
Sent: Wednesday, May 23, 2018 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

**CAUTION EXTERNAL EMAIL**

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

Yes, but PDUU does not support Java only the FTP client.  Are you hearing that 
PDUU is going to use something other than the FTP client.  That is what I am 
hearing from the PMR.

-Original Message-
From: Jousma, David [mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, May 23, 2018 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

Jon, the newer JAVA utility does document that they support HTTP proxy.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Nolting
Sent: Wednesday, May 23, 2018 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

**CAUTION EXTERNAL EMAIL**

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

In the PMR I opened, PDUU (AMAPDUPL) does not use the capability that SMP/E for 
downloads.  I am talking with them about potentially using some variant of USS 
sftp as their client interface to that we can continue using the PDUU tool.

As of now, I have to upload SVCDUMPs, etc from WinSCP after downloading them to 
Windows after they are TERSE'd.

IBM, please don't make the requirement for upload of PDUU only as your process 
doesn't work for HTTP proxies.

Service request number 47544 004 000 -- AMAPDUPL does not support HTTP 
proxy

-Original Message-
From: Jousma, David [mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, May 23, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

Skip, I was going to bring that up too.  We've also got RFN working through our 
HTTPS proxy just fine.   I would like to believe that IBM would make something 
similar available, but not holding my breath either.

I think that’s why I gave up on PDUU as well.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, May 23, 2018 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

**CAUTION EXTERNAL EMAIL**

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

This is the same road we traversed a few years back when RECEIVE FROM NETWORK 
stopped working with vanilla FTP. We are not technically capable of running 
FTPS directly from z/OS to IBM because we depend on an appliance (BlueCoat) to 
'punch through' the standard firewall. BlueCoat does not--and I'm told never 
will--support TLS syntax. 

Fortunately HTTPS was made available for RFN, so we've maintained business as 
usual. I see no mention of HTTPS in the current change. This looks like a road 
with No Outlet.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pew, Curtis G
Sent: Wednesday, May 23, 2018 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: File transfer Red Alert

On May 23, 2018, at 10:07 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Why didn't the supplier, as a courtesy to the customer, deliver the 
> file with the needed extension and save that step?

This is just a guess, but maybe some firewalls or other policy enforcing 
software block .jar files but allow .zip files. If you have a Java VM on your 
system, .jar files contain executable code and in some circumstances might be 
executed inadvertently.


--
Pew, Curtis G
curtis@austin.utexas.edu
ITS 

Re: Replaceing IEBGENER

[Jesse 1 Robinson]

Sorry for a war story on Wednesday, but it's too good to suppress. We 
implemented the ICEGENER strategy at a former shop in the 80s. What could go 
wrong? Seems that some (of course critical) application was creating a 
sequential file in which the actual number of blocks was calculated. File was 
created on DASD and IEBGENERed to tape. The JCL that created the tape file did 
not code BLKSIZE; just depended on IEBGENER's habit of copying input DCB to 
output. You've all seen the warning message.

File was later read in by another program that expected the original number of 
blocks. But ICEGENER had already stepped in to help out by reblocking the file 
to SDB. Good for tape usage; fatal for the program that expected a set number 
of blocks. 30 years later I still shake my head over that one.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Wednesday, May 23, 2018 10:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Replaceing IEBGENER

I don't agree. It's simple to refer directly to the program that you want. 
Adding an IEBGENER alias to ICEGENER runs the risk of someone hitting a subtle 
incompatibility at 0'dark hundred in a job that was never tested with ICEGENER.


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


From: IBM Mainframe Discussion List  on behalf of 
Brian Westerman 
Sent: Wednesday, May 23, 2018 2:24 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Replaceing IEBGENER

If you have DFSort or Syncsort then replacing IEBGENER with ICEGENER or 
SYNCGENR is not only simple, but you would be silly not to do so and save the 
resources.  FASTGENR is also very good, but I don't think (in my opinion) that 
it's worth the extra cost since you already paid for either SYNCGENR or 
ICEGENER.

Brian


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

Re: File transfer Red Alert

[Jon Nolting]

Yes, but PDUU does not support Java only the FTP client.  Are you hearing that 
PDUU is going to use something other than the FTP client.  That is what I am 
hearing from the PMR.

-Original Message-
From: Jousma, David [mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu] 
Sent: Wednesday, May 23, 2018 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

Jon, the newer JAVA utility does document that they support HTTP proxy.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Nolting
Sent: Wednesday, May 23, 2018 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

**CAUTION EXTERNAL EMAIL**

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

In the PMR I opened, PDUU (AMAPDUPL) does not use the capability that SMP/E for 
downloads.  I am talking with them about potentially using some variant of USS 
sftp as their client interface to that we can continue using the PDUU tool.

As of now, I have to upload SVCDUMPs, etc from WinSCP after downloading them to 
Windows after they are TERSE'd.

IBM, please don't make the requirement for upload of PDUU only as your process 
doesn't work for HTTP proxies.

Service request number 47544 004 000 -- AMAPDUPL does not support HTTP 
proxy

-Original Message-
From: Jousma, David [mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, May 23, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

Skip, I was going to bring that up too.  We've also got RFN working through our 
HTTPS proxy just fine.   I would like to believe that IBM would make something 
similar available, but not holding my breath either.

I think that’s why I gave up on PDUU as well.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, May 23, 2018 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

**CAUTION EXTERNAL EMAIL**

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

This is the same road we traversed a few years back when RECEIVE FROM NETWORK 
stopped working with vanilla FTP. We are not technically capable of running 
FTPS directly from z/OS to IBM because we depend on an appliance (BlueCoat) to 
'punch through' the standard firewall. BlueCoat does not--and I'm told never 
will--support TLS syntax. 

Fortunately HTTPS was made available for RFN, so we've maintained business as 
usual. I see no mention of HTTPS in the current change. This looks like a road 
with No Outlet.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pew, Curtis G
Sent: Wednesday, May 23, 2018 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: File transfer Red Alert

On May 23, 2018, at 10:07 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Why didn't the supplier, as a courtesy to the customer, deliver the 
> file with the needed extension and save that step?

This is just a guess, but maybe some firewalls or other policy enforcing 
software block .jar files but allow .zip files. If you have a Java VM on your 
system, .jar files contain executable code and in some circumstances might be 
executed inadvertently.


--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

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

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

Re: File transfer Red Alert

[Jousma, David]

Jon, the newer JAVA utility does document that they support HTTP proxy.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Nolting
Sent: Wednesday, May 23, 2018 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

**CAUTION EXTERNAL EMAIL**

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

In the PMR I opened, PDUU (AMAPDUPL) does not use the capability that SMP/E for 
downloads.  I am talking with them about potentially using some variant of USS 
sftp as their client interface to that we can continue using the PDUU tool.

As of now, I have to upload SVCDUMPs, etc from WinSCP after downloading them to 
Windows after they are TERSE'd.

IBM, please don't make the requirement for upload of PDUU only as your process 
doesn't work for HTTP proxies.

Service request number 47544 004 000 -- AMAPDUPL does not support HTTP 
proxy

-Original Message-
From: Jousma, David [mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, May 23, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

Skip, I was going to bring that up too.  We've also got RFN working through our 
HTTPS proxy just fine.   I would like to believe that IBM would make something 
similar available, but not holding my breath either.

I think that’s why I gave up on PDUU as well.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, May 23, 2018 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

**CAUTION EXTERNAL EMAIL**

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

This is the same road we traversed a few years back when RECEIVE FROM NETWORK 
stopped working with vanilla FTP. We are not technically capable of running 
FTPS directly from z/OS to IBM because we depend on an appliance (BlueCoat) to 
'punch through' the standard firewall. BlueCoat does not--and I'm told never 
will--support TLS syntax. 

Fortunately HTTPS was made available for RFN, so we've maintained business as 
usual. I see no mention of HTTPS in the current change. This looks like a road 
with No Outlet.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pew, Curtis G
Sent: Wednesday, May 23, 2018 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: File transfer Red Alert

On May 23, 2018, at 10:07 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Why didn't the supplier, as a courtesy to the customer, deliver the 
> file with the needed extension and save that step?

This is just a guess, but maybe some firewalls or other policy enforcing 
software block .jar files but allow .zip files. If you have a Java VM on your 
system, .jar files contain executable code and in some circumstances might be 
executed inadvertently.


--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

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

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


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

--
For 

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Gerhard Adam]

Sorry, but the CSI was never a PDS and still isn't.  I suspect you're thinking 
of the PTS

Sent from my iPhone

> On May 23, 2018, at 10:00 AM, Nims,Alva John (Al)  wrote:
> 
> " I learned to use SMP back on MVT (am I the only one still here that can 
> truthfully make that statement?)" Answer: No, yes I remember SMP back before 
> the "e" was added on, the CSI was a PDS! And not a PDSe!
> 
> I do not follow the 'Never ACCEPT" process.
> 
> Al Nims
> Systems Admin/Programmer III
> UF Information Technology
> East Campus 
> P.O. Box 112050
> Gainesville, FL. 32611
> (e) ajn...@ufl.edu 
> (p) (352) 273-1298
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of David L. Craig
> Sent: Wednesday, May 23, 2018 10:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
> 
>> On 18May23:1247+, Pommier, Rex wrote:
>> 
>> Not sure how long ago eons was, but I started in the mid-80s on MVS/SP 
>> and at my first SMP/E (and I believe
>> only) class, I was taught the APPLY / run for a while / ACCEPT usage - 
>> except for USERMODs or APARs that hadn't had a published PTF yet.
> 
> I learned to use SMP back on MVT (am I the only one still here that can 
> truthfully make that statement?) and while it's been a while since I last 
> used SMP/E, I do not recall ever encountering a no ACCEPT policy for any IBM 
> MRM.
> But people aren't mentioning policy for archiving snapshots of target and 
> DLIB volumes and restoring therefrom--much faster than reAPPLYing LOTS of 
> maintenance.  That also requires tracking the target/DLIB volume snapshot 
> associations, which are not necessarily based upon the dates of the snapshots.
> --
> 
> May the LORD God bless you exceedingly abundantly!
> 
> Dave_Craig__
> "So the universe is not quite as you thought it was.
> You'd better rearrange your beliefs, then.
> Because you certainly can't rearrange the universe."
> __--from_Nightfall_by_Asimov/Silverberg_
> 
> --
> 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] Old School Maintenance Philosophy -- Never ACCEPT?

[David Purdy]

I indeed remember SMP v4, especially v4.13 that ironically had bugs.  Circa 
1978/79 and very ugly.  Our PSR lived onsite for days.

David



On Wednesday, May 23, 2018 Bill Hitefield  
wrote:
In my SysProg days (70s - 80s), I would ACCEPT maintenance, but only after we 
had run it for a while. PUT maintenance was relegated to weekends. I would 
backup the full environment before running the ACCEPT (saved my bacon a few 
times).



PS: Anybody else remember fighting with SMP v3? We were so happy when SMP v4 
came out. 



Bill Hitefield



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gerhard Adam
Sent: Wednesday, May 23, 2018 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?



I also don't recall a "never ACCEPT" policy. That would be silly because it 
becomes a "never RESTORE" policy.



Sent from my iPhone



> 

On May 23, 2018, at 7:08 AM, David L. Craig 
> wrote:

>

>> On 18May23:1247+, Pommier, Rex wrote:

>>

>> Not sure how long ago eons was, but I started in the mid-80s on

>> MVS/SP and at my first SMP/E (and I believe

>> only) class, I was taught the APPLY / run for a while / ACCEPT usage

>> - except for USERMODs or APARs that hadn't had a published PTF yet.

>

> I learned to use SMP back on MVT (am I the only one still here that

> can truthfully make that statement?) and while it's been a while since

> I last used SMP/E, I do not recall ever encountering a no ACCEPT

> policy for any IBM MRM.

> But people aren't mentioning policy for archiving snapshots of target

> and DLIB volumes and restoring therefrom--much faster than reAPPLYing

> LOTS of maintenance. That also requires tracking the target/DLIB

> volume snapshot associations, which are not necessarily based upon the

> dates of the snapshots.

> --

> 

> May the LORD God bless you exceedingly abundantly!

>

> Dave_Craig__

> "So the universe is not quite as you thought it was.

> You'd better rearrange your beliefs, then.

> Because you certainly can't rearrange the universe."

> __--from_Nightfall_by_Asimov/Silverberg_

>

> --

> 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: File transfer Red Alert

[Jon Nolting]

In the PMR I opened, PDUU (AMAPDUPL) does not use the capability that SMP/E for 
downloads.  I am talking with them about potentially using some variant of USS 
sftp as their client interface to that we can continue using the PDUU tool.

As of now, I have to upload SVCDUMPs, etc from WinSCP after downloading them to 
Windows after they are TERSE'd.

IBM, please don't make the requirement for upload of PDUU only as your process 
doesn't work for HTTP proxies.

Service request number 47544 004 000 -- AMAPDUPL does not support HTTP 
proxy

-Original Message-
From: Jousma, David [mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu] 
Sent: Wednesday, May 23, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

Skip, I was going to bring that up too.  We've also got RFN working through our 
HTTPS proxy just fine.   I would like to believe that IBM would make something 
similar available, but not holding my breath either.

I think that’s why I gave up on PDUU as well.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, May 23, 2018 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

**CAUTION EXTERNAL EMAIL**

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

This is the same road we traversed a few years back when RECEIVE FROM NETWORK 
stopped working with vanilla FTP. We are not technically capable of running 
FTPS directly from z/OS to IBM because we depend on an appliance (BlueCoat) to 
'punch through' the standard firewall. BlueCoat does not--and I'm told never 
will--support TLS syntax. 

Fortunately HTTPS was made available for RFN, so we've maintained business as 
usual. I see no mention of HTTPS in the current change. This looks like a road 
with No Outlet.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pew, Curtis G
Sent: Wednesday, May 23, 2018 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: File transfer Red Alert

On May 23, 2018, at 10:07 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Why didn't the supplier, as a courtesy to the customer, deliver the 
> file with the needed extension and save that step?

This is just a guess, but maybe some firewalls or other policy enforcing 
software block .jar files but allow .zip files. If you have a Java VM on your 
system, .jar files contain executable code and in some circumstances might be 
executed inadvertently.


--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

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

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


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

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

Re: File transfer Red Alert

[Jon Nolting]

This is interesting as our network folks just implemented a HTTP proxy which 
totally negates AMAPDUPL because it uses a FTP client.  I have a PRM open and 
are looking at OpenSSH sftp or potentially Dovetailed Tech SFTP to be to access 
datasets from USS.

It has introduced a nightmare for uploading diagnostic information.  We can't 
use PDUU and need an alternative from IBM until they can support something 
other than the FTP client.

-Original Message-
From: Don Poitras [mailto:sas...@sas.com] 
Sent: Wednesday, May 23, 2018 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

In article 
<4ee2851a2279b94cb70cd69b1741060901f61c1...@s1flokydce2kx05.dm0001.info53.com> 
you wrote:
> Thanks John.   
> >A .jar file _is_ a .zip file, but with some specified contents, such as a 
> >"manifest". The JAVA "jar" command can create a file which a standard 
> >"unzip" >utility can expand. It can also extract files from a standard zip 
> >file. That is, it can act as a regular zip command. But a true .jar file 
> >must have the .jar >extension and have the proper contents to be used by the 
> >java executable.
> For us "dummies" though, uploading the file as-is isn???t enough.  It has to 
> be renamed to .jar for the supplied JCL to work correctly.
> >Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you can 
> >do a BINary download to a PC, then do a BINary upload to z/OS if you first 
> >do a >"QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".
> This is precisely what I am trying to avoid.  I want to transmit my diags 
> directly from z/OS.  
> Playing with this some more, and I think it was already mentioned here is 
> that AMATERSE does not allow SYSUT1 or SYSUT2 to be PATH statements either.
> _
> Dave Jousma

On my last PMR, I was told to use PDUU to send in the dump. It does the tersing 
and encrypting under the covers and can be run as JCL.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_SSLTBW-5F2.3.0_com.ibm.zos.v2r3.ieav100_pftp.htm=DwIBAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=MQsKeOxcIGeiq-qoJzO2oVgUmKB65Wchl7khwwU0Ijk=UMyheIR7fDrGICq9zHTpZTRadsfPQ50RXthlyngpS6E=NLv03oyPMBugFqGvVijTQEpz2t2Mrg7ciZp3npwF08s=

There's this note about the types of files that are _not_ supported:

---
PDUU does not support the following types of input data sets:
 Large block interface (LBI) (no BLKSIZE value).
 VSAM and direct (DSORG=DA) data sets
 Data sets with keys (KEYLEN)
 z/OS UNIX files
 Concatenated data sets of any type
---

--
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
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] Old School Maintenance Philosophy -- Never ACCEPT?

[Bill Hitefield]

In my SysProg days (70s - 80s), I would ACCEPT maintenance, but only after we 
had run it for a while. PUT maintenance was relegated to weekends. I would 
backup the full environment before running the ACCEPT (saved my bacon a few 
times).



PS: Anybody else remember fighting with SMP v3? We were so happy when SMP v4 
came out. 



Bill Hitefield



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gerhard Adam
Sent: Wednesday, May 23, 2018 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?



I also don't recall a "never ACCEPT" policy.  That would be silly because it 
becomes a "never RESTORE" policy.



Sent from my iPhone



> On May 23, 2018, at 7:08 AM, David L. Craig 
> > wrote:

>

>> On 18May23:1247+, Pommier, Rex wrote:

>>

>> Not sure how long ago eons was, but I started in the mid-80s on

>> MVS/SP and at my first SMP/E (and I believe

>> only) class, I was taught the APPLY / run for a while / ACCEPT usage

>> - except for USERMODs or APARs that hadn't had a published PTF yet.

>

> I learned to use SMP back on MVT (am I the only one still here that

> can truthfully make that statement?) and while it's been a while since

> I last used SMP/E, I do not recall ever encountering a no ACCEPT

> policy for any IBM MRM.

> But people aren't mentioning policy for archiving snapshots of target

> and DLIB volumes and restoring therefrom--much faster than reAPPLYing

> LOTS of maintenance.  That also requires tracking the target/DLIB

> volume snapshot associations, which are not necessarily based upon the

> dates of the snapshots.

> --

> 

> May the LORD God bless you exceedingly abundantly!

>

> Dave_Craig__

> "So the universe is not quite as you thought it was.

> You'd better rearrange your beliefs, then.

> Because you certainly can't rearrange the universe."

> __--from_Nightfall_by_Asimov/Silverberg_

>

> --

> 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: File transfer Red Alert

[Jousma, David]

Skip, I was going to bring that up too.  We've also got RFN working through our 
HTTPS proxy just fine.   I would like to believe that IBM would make something 
similar available, but not holding my breath either.

I think that’s why I gave up on PDUU as well.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, May 23, 2018 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

**CAUTION EXTERNAL EMAIL**

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

This is the same road we traversed a few years back when RECEIVE FROM NETWORK 
stopped working with vanilla FTP. We are not technically capable of running 
FTPS directly from z/OS to IBM because we depend on an appliance (BlueCoat) to 
'punch through' the standard firewall. BlueCoat does not--and I'm told never 
will--support TLS syntax. 

Fortunately HTTPS was made available for RFN, so we've maintained business as 
usual. I see no mention of HTTPS in the current change. This looks like a road 
with No Outlet.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pew, Curtis G
Sent: Wednesday, May 23, 2018 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: File transfer Red Alert

On May 23, 2018, at 10:07 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Why didn't the supplier, as a courtesy to the customer, deliver the 
> file with the needed extension and save that step?

This is just a guess, but maybe some firewalls or other policy enforcing 
software block .jar files but allow .zip files. If you have a Java VM on your 
system, .jar files contain executable code and in some circumstances might be 
executed inadvertently.


--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

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

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


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

Re: Replaceing IEBGENER

[Seymour J Metz]

I don't agree. It's simple to refer directly to the program that you want. 
Adding an IEBGENER alias to ICEGENER runs the risk of someone hitting a subtle 
incompatibility at 0'dark hundred in a job that was never tested with ICEGENER.


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


From: IBM Mainframe Discussion List  on behalf of 
Brian Westerman 
Sent: Wednesday, May 23, 2018 2:24 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Replaceing IEBGENER

If you have DFSort or Syncsort then replacing IEBGENER with ICEGENER or 
SYNCGENR is not only simple, but you would be silly not to do so and save the 
resources.  FASTGENR is also very good, but I don't think (in my opinion) that 
it's worth the extra cost since you already paid for either SYNCGENR or 
ICEGENER.

Brian

--
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: File transfer Red Alert

[Jesse 1 Robinson]

This is the same road we traversed a few years back when RECEIVE FROM NETWORK 
stopped working with vanilla FTP. We are not technically capable of running 
FTPS directly from z/OS to IBM because we depend on an appliance (BlueCoat) to 
'punch through' the standard firewall. BlueCoat does not--and I'm told never 
will--support TLS syntax. 

Fortunately HTTPS was made available for RFN, so we've maintained business as 
usual. I see no mention of HTTPS in the current change. This looks like a road 
with No Outlet.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pew, Curtis G
Sent: Wednesday, May 23, 2018 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: File transfer Red Alert

On May 23, 2018, at 10:07 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Why didn't the supplier, as a courtesy to the customer, deliver the 
> file with the needed extension and save that step?

This is just a guess, but maybe some firewalls or other policy enforcing 
software block .jar files but allow .zip files. If you have a Java VM on your 
system, .jar files contain executable code and in some circumstances might be 
executed inadvertently.


--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Carmen Vitullo]

CSI not VSAM ? 


Carmen Vitullo 

- Original Message -

From: "Alva John Nims (Al)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 12:00:11 PM 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

" I learned to use SMP back on MVT (am I the only one still here that can 
truthfully make that statement?)" Answer: No, yes I remember SMP back before 
the "e" was added on, the CSI was a PDS! And not a PDSe! 

I do not follow the 'Never ACCEPT" process. 

Al Nims 
Systems Admin/Programmer III 
UF Information Technology 
East Campus 
P.O. Box 112050 
Gainesville, FL. 32611 
(e) ajn...@ufl.edu 
(p) (352) 273-1298 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David L. Craig 
Sent: Wednesday, May 23, 2018 10:09 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

On 18May23:1247+, Pommier, Rex wrote: 
> 
> Not sure how long ago eons was, but I started in the mid-80s on MVS/SP 
> and at my first SMP/E (and I believe 
> only) class, I was taught the APPLY / run for a while / ACCEPT usage - 
> except for USERMODs or APARs that hadn't had a published PTF yet. 

I learned to use SMP back on MVT (am I the only one still here that can 
truthfully make that statement?) and while it's been a while since I last used 
SMP/E, I do not recall ever encountering a no ACCEPT policy for any IBM MRM. 
But people aren't mentioning policy for archiving snapshots of target and DLIB 
volumes and restoring therefrom--much faster than reAPPLYing LOTS of 
maintenance. That also requires tracking the target/DLIB volume snapshot 
associations, which are not necessarily based upon the dates of the snapshots. 
-- 
 
May the LORD God bless you exceedingly abundantly! 

Dave_Craig__ 
"So the universe is not quite as you thought it was. 
You'd better rearrange your beliefs, then. 
Because you certainly can't rearrange the universe." 
__--from_Nightfall_by_Asimov/Silverberg_ 

-- 
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: File transfer Red Alert

[Jousma, David]

And that is perfectly valid point.  They just need to call that out on the 
webpage then.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pew, Curtis G
Sent: Wednesday, May 23, 2018 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

**CAUTION EXTERNAL EMAIL**

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

On May 23, 2018, at 10:07 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Why didn't the supplier, as a courtesy to the customer, deliver the 
> file with the needed extension and save that step?

This is just a guess, but maybe some firewalls or other policy enforcing 
software block .jar files but allow .zip files. If you have a Java VM on your 
system, .jar files contain executable code and in some circumstances might be 
executed inadvertently.


--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services

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

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


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

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Carmen Vitullo]

Ah yes, the SYSTEM GEN - MVSCP 


Carmen Vitullo 

- Original Message -

From: "Seymour J Metz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 11:54:31 AM 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

War stories, yes, but I worked on OS/360 and OS/2 SVS before there was an SMP, 
and that was far worse. 


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

 
From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo  
Sent: Wednesday, May 23, 2018 10:15 AM 
To: IBM-MAIN@listserv.ua.edu 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

I'm so glad I did not have to use/work with SMP, I've heard the war stories and 
I think the backup everyone philosophy came from the old SMP V4 days and at the 
site I worked at, SMP/E I was still taught the standard of backing up all SMP/E 
datasets, target and DLIBS prior to any apply, it has saved my A$$ a couple 
times 



Carmen Vitullo 

- Original Message - 

From: "David L. Craig"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 9:08:45 AM 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

On 18May23:1247+, Pommier, Rex wrote: 
> 
> Not sure how long ago eons was, but I started in the 
> mid-80s on MVS/SP and at my first SMP/E (and I believe 
> only) class, I was taught the APPLY / run for a while / 
> ACCEPT usage - except for USERMODs or APARs that hadn't 
> had a published PTF yet. 

I learned to use SMP back on MVT (am I the only one still 
here that can truthfully make that statement?) and while 
it's been a while since I last used SMP/E, I do not recall 
ever encountering a no ACCEPT policy for any IBM MRM. 
But people aren't mentioning policy for archiving snapshots 
of target and DLIB volumes and restoring therefrom--much 
faster than reAPPLYing LOTS of maintenance. That also 
requires tracking the target/DLIB volume snapshot 
associations, which are not necessarily based upon the 
dates of the snapshots. 
-- 
 
May the LORD God bless you exceedingly abundantly! 

Dave_Craig__ 
"So the universe is not quite as you thought it was. 
You'd better rearrange your beliefs, then. 
Because you certainly can't rearrange the universe." 
__--from_Nightfall_by_Asimov/Silverberg_ 

-- 
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: Old School Maintenance Philosophy -- Never ACCEPT?

[Seymour J Metz]

Never accept what? The advice to never accept an APAR or USERMOD is sound. The 
advice never to accept a PTF - it's not my dog.


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


From: IBM Mainframe Discussion List  on behalf of 
Allan Staller 
Sent: Wednesday, May 23, 2018 8:49 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Old School Maintenance Philosophy -- Never ACCEPT?

"never accept" because there might be "bad" maintenance in the stream.

If you have been running on the "new maintenance" for xx months, what can be 
"bad"?
I agree w/Tom Conley. It was wrong then (even if well intended). It is still 
wrong.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, May 22, 2018 5:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Old School Maintenance Philosophy -- Never ACCEPT?

On 5/22/2018 1:49 PM, Allan Staller wrote:
> I haven't used that philosophy in 30+ years.

What was the rationale 30+ years ago?

Do you remember why things were being done that way?

Thanks,

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1UQ7-7D9XBwR1qCx3aiNIShyb0c2RaZdkHhbVCRk2rp9c4x0rSKhLU1Hz5Xj0ahaYKuYDUShzYIJjtR2Gj0dHQ0ZnIgtMS4d0hXUKfpGp78VydHJ75f5MUY8LFbMprU1dpfSdqekPOr9NxxC2bTRwKTVMaMyKCZqam4gfwEx3g7zVZP2a_WVJpjOpDlowCJaLnZ5M-J2xit4_C0rX9Nf6eztGVQIbF_yTpLZP_JuM0AidsuNbTlt8x4LRUCbshs3p-4t0MBfGOkxRRld1dLTr-ltKWWV7Jqd4NaAMTUzx6rLJofMXZhB4ED2XlOzLXFYJCez_6kij4kk5HbtrxEFu_RC6b7fpWN0FAtf81eZcCQHuTUMHEXZLoxVHrKbH3lNx1CfLpuaavO8lqupc0dYfGmllZFfiplx9NIb9kJGV1L-RnwQ0d3Tn5YxZCwmanE5n/https%3A%2F%2Fapac01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fwww.phoenixsoftware.com%252F%26data%3D02%257C01%257Callan.staller%2540HCL.COM%257C0a9bd16e74284d053ffe08d5c03411e4%257C189de737c93a4f5a8b686f4ca9941912%257C0%257C0%257C636626252258061200%26sdata%3DRplEGhGyPWTc5cVIUJkB6EAo3h2uTX8R9ErgpA0OyfA%253D%26reserved%3D0

This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise received 
this email message in error, any use, dissemination, distribution, review, 
storage or copying of this e-mail message and the information contained therein 
is strictly prohibited. If you are not an intended recipient, please contact 
the sender by reply e-mail and destroy all copies of this email message and do 
not otherwise utilize or retain this email message or any or all of the 
information contained therein. Although this email message and any attachments 
or appended messages are believed to be free of any virus or other defect that 
might affect any computer system into which it is received and opened, it is 
the responsibility of the recipient to ensure that it is virus free and no 
responsibility is accepted by the sender for any loss or damage arising in any 
way from its opening or use.

--
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] Old School Maintenance Philosophy -- Never ACCEPT?

[Nims,Alva John (Al)]

" I learned to use SMP back on MVT (am I the only one still here that can 
truthfully make that statement?)" Answer: No, yes I remember SMP back before 
the "e" was added on, the CSI was a PDS! And not a PDSe!

I do not follow the 'Never ACCEPT" process.

Al Nims
Systems Admin/Programmer III
UF Information Technology
East Campus 
P.O. Box 112050
Gainesville, FL. 32611
(e) ajn...@ufl.edu 
(p) (352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David L. Craig
Sent: Wednesday, May 23, 2018 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

On 18May23:1247+, Pommier, Rex wrote:
> 
> Not sure how long ago eons was, but I started in the mid-80s on MVS/SP 
> and at my first SMP/E (and I believe
> only) class, I was taught the APPLY / run for a while / ACCEPT usage - 
> except for USERMODs or APARs that hadn't had a published PTF yet.

I learned to use SMP back on MVT (am I the only one still here that can 
truthfully make that statement?) and while it's been a while since I last used 
SMP/E, I do not recall ever encountering a no ACCEPT policy for any IBM MRM.
But people aren't mentioning policy for archiving snapshots of target and DLIB 
volumes and restoring therefrom--much faster than reAPPLYing LOTS of 
maintenance.  That also requires tracking the target/DLIB volume snapshot 
associations, which are not necessarily based upon the dates of the snapshots.
--

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

--
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: File transfer Red Alert

[Pew, Curtis G]

On May 23, 2018, at 10:07 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Why didn't the supplier, as a courtesy to the customer, deliver the file with
> the needed extension and save that step?

This is just a guess, but maybe some firewalls or other policy enforcing 
software block .jar files but allow .zip files. If you have a Java VM on your 
system, .jar files contain executable code and in some circumstances might be 
executed inadvertently.


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services

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

Re: Old School Maintenance Philosophy -- Never ACCEPT?

[Tom Marchant]

On Wed, 23 May 2018 11:08:32 -0500, Tom Marchant wrote:

>On Wed, 23 May 2018 10:07:16 -0400, John Eells wrote:
>
>>As others have pointed out, it makes RESTORE a lot harder if you never
>>ACCEPT PTFs.
>
>I haven't had the need to do this yet, but I have an idea that I think will 
>make it much easier.
>
>If I want to restore PTF A and RESTORE CHECK tells me that it can't 
>RESTORE it because PTFs B, C, and D have not been ACCEPTed, I can 
>run ACCEPT CHECK on B, C, and D. That should give me a list of all the 
>PTFs that also need to be RESTOREd in order to RESTORE A.

I meant to say ACCEPT CHECK GROUP on B, C, and D.

-- 
Tom Marchant

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

Re: Old School Maintenance Philosophy -- Never ACCEPT?

[Gerhard Adam]

Why bother?  Do a RESTORE GROUP CHECK and get that information.

Sent from my iPhone

> On May 23, 2018, at 9:08 AM, Tom Marchant 
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> On Wed, 23 May 2018 10:07:16 -0400, John Eells wrote:
>> 
>> As others have pointed out, it makes RESTORE a lot harder if you never
>> ACCEPT PTFs.
> 
> I haven't had the need to do this yet, but I have an idea that I think will 
> make it much easier.
> 
> If I want to restore PTF A and RESTORE CHECK tells me that it can't 
> RESTORE it because PTFs B, C, and D have not been ACCEPTed, I can 
> run ACCEPT CHECK on B, C, and D. That should give me a list of all the 
> PTFs that also need to be RESTOREd in order to RESTORE A.
> 
> -- 
> 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: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Seymour J Metz]

War stories, yes, but I worked on OS/360 and OS/2 SVS before there was an SMP, 
and that was far worse.


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


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, May 23, 2018 10:15 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

I'm so glad I did not have to use/work with SMP, I've heard the war stories and 
I think the backup everyone philosophy came from the old SMP V4 days and at the 
site I worked at, SMP/E I was still taught the standard of backing up all SMP/E 
datasets, target and DLIBS prior to any apply, it has saved my A$$ a couple 
times



Carmen Vitullo

- Original Message -

From: "David L. Craig" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, May 23, 2018 9:08:45 AM
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

On 18May23:1247+, Pommier, Rex wrote:
>
> Not sure how long ago eons was, but I started in the
> mid-80s on MVS/SP and at my first SMP/E (and I believe
> only) class, I was taught the APPLY / run for a while /
> ACCEPT usage - except for USERMODs or APARs that hadn't
> had a published PTF yet.

I learned to use SMP back on MVT (am I the only one still
here that can truthfully make that statement?) and while
it's been a while since I last used SMP/E, I do not recall
ever encountering a no ACCEPT policy for any IBM MRM.
But people aren't mentioning policy for archiving snapshots
of target and DLIB volumes and restoring therefrom--much
faster than reAPPLYing LOTS of maintenance. That also
requires tracking the target/DLIB volume snapshot
associations, which are not necessarily based upon the
dates of the snapshots.
--

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
You'd better rearrange your beliefs, then.
Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

--
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: File transfer Red Alert

[Jousma, David]

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, May 23, 2018 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

>Why didn't the supplier, as a courtesy to the customer, deliver the file with 
>the needed extension and save that step?

Bingo.  That’s why I mentioned it.  Seemed like an error on the webpage.

>>>Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you can 
>>>do a BINary download to a PC, then do a BINary upload to z/OS if you first 
>>>do a >>"QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".
>>
>>This is precisely what I am trying to avoid.  I want to transmit my diags 
>>directly from z/OS.  
>> 
>Is there an obstacle to that?  Don't the same commands work on z/OS FTP?
>Or even shortcut with options on the BINARY command?

No obstacle, and yes they do work.  The java utility does encryption, which is 
a new requirement.  Looks like I still have to get FTPs or HTTP_PROXY working.  
FTPs is a problem here as IBM requires a range of ports for passive TLS 
transfers.  Something my security folks are balking at.   IBM used to use just 
one port, which they were ok with.

I kinda had set this all aside for a bit until this alert came out, as I was 
still using anonymous FTP to testcase.boulder.ibm.com on standard FTP port.   
Sounds like tomorrow that ends.   I don’t want to have to resort to browser 
based uploads if I can help it.


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


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

Re: File transfer Red Alert

[Don Poitras]

In article 
<4ee2851a2279b94cb70cd69b1741060901f61c1...@s1flokydce2kx05.dm0001.info53.com> 
you wrote:
> Thanks John.   
> >A .jar file _is_ a .zip file, but with some specified contents, such as a 
> >"manifest". The JAVA "jar" command can create a file which a standard 
> >"unzip" >utility can expand. It can also extract files from a standard zip 
> >file. That is, it can act as a regular zip command. But a true .jar file 
> >must have the .jar >extension and have the proper contents to be used by the 
> >java executable.
> For us "dummies" though, uploading the file as-is isn???t enough.  It has to 
> be renamed to .jar for the supplied JCL to work correctly.
> >Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you can 
> >do a BINary download to a PC, then do a BINary upload to z/OS if you first 
> >do a >"QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".
> This is precisely what I am trying to avoid.  I want to transmit my diags 
> directly from z/OS.  
> Playing with this some more, and I think it was already mentioned here is 
> that AMATERSE does not allow SYSUT1 or SYSUT2 to be PATH statements either.
> _
> Dave Jousma

On my last PMR, I was told to use PDUU to send in the dump. It does
the tersing and encrypting under the covers and can be run as JCL.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieav100/pftp.htm

There's this note about the types of files that are _not_ supported:

---
PDUU does not support the following types of input data sets:
 Large block interface (LBI) (no BLKSIZE value).
 VSAM and direct (DSORG=DA) data sets
 Data sets with keys (KEYLEN)
 z/OS UNIX files
 Concatenated data sets of any type
---

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Old School Maintenance Philosophy -- Never ACCEPT?

[Jesse 1 Robinson]

I would go so far as to assert that there was never a 'no-ACCEPT policy', only 
an ad hoc practice advocated by what I always thought were outliers. Open any 
IBM doc on SMP(/E) ever published and you will find the same canonical 
procedure:

--RECEIVE  
--APPLY  
--ACCEPT (maybe hold off on this a while, but resolve to do it eventually)   

Having never given no-ACCEPT serious consideration, I can't speak for its 
motivation. I suspect that it was a combination of (misguided) RESTORE concerns 
and a sense that ACCEPT represents wasted cycles--CPU and bioware. Some may 
have believed that the whole DLIB environment entailed unnecessary DASD space. 
When DASD became radically cheaper--and people became more expensive--no-ACCEPT 
may have looked like a penny saved. I personally think that's false economy. 
ACCEPT, besides stuffing a lot of data into distribution libraries, also 
performs SMP/E cleanup. Until ACCEPT, RECEIVEd sysmods remain in the PTS, which 
grows insidiously like the Blob over the life of each FMID. Likewise TLIBs, 
which hold the verbatim content of all sysmods, are not deleted until ACCEPT 
(if then--it's optional). 

Having said all that, I suspect that there are still Never ACCEPTers out there 
who are unlikely to change their ways. I'm guessing that OP Ed Jaffe is looking 
at this issue from the perspective a software supplier. It's hard to imagine 
that the owners of SMP/E will ever alter the recommended procedure.

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard Adam
Sent: Wednesday, May 23, 2018 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: [External] Old School Maintenance Philosophy -- Never 
ACCEPT?

I also don't recall a "never ACCEPT" policy.  That would be silly because it 
becomes a "never RESTORE" policy.

Sent from my iPhone

> On May 23, 2018, at 7:08 AM, David L. Craig  wrote:
> 
>> On 18May23:1247+, Pommier, Rex wrote:
>> 
>> Not sure how long ago eons was, but I started in the mid-80s on 
>> MVS/SP and at my first SMP/E (and I believe
>> only) class, I was taught the APPLY / run for a while / ACCEPT usage 
>> - except for USERMODs or APARs that hadn't had a published PTF yet.
> 
> I learned to use SMP back on MVT (am I the only one still here that 
> can truthfully make that statement?) and while it's been a while since 
> I last used SMP/E, I do not recall ever encountering a no ACCEPT 
> policy for any IBM MRM.
> But people aren't mentioning policy for archiving snapshots of target 
> and DLIB volumes and restoring therefrom--much faster than reAPPLYing 
> LOTS of maintenance.  That also requires tracking the target/DLIB 
> volume snapshot associations, which are not necessarily based upon the 
> dates of the snapshots.
> --
> 
> May the LORD God bless you exceedingly abundantly!


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

Re: VTL as 3490 vs 3590

[Ken Bloom]

You make some good points.  Here are a few more things to consider.

Most vendors use .AWS format so there is compatibility at that level and that’s 
useful.  We have conversion utilities that allow us to replace another vendors 
VTL with the 5990.   As a wise person once said "indecision is the key to 
flexibility" which is why we also have the capability to limit volume size.  We 
actually have 1 customer that is runningit hurts to say it 3480 (which we 
also emulate) and we limit the volume size there for him. We find that most 
sites for whatever reason use 3490 with no max volume size even though we 
provide the capability to do other emulation and limit size.  Some sites do 
stack tapes and others put 1 dataset on a tape even though it’s a very small 
data set.  With VTL there is no wasted space so small datasets on a tape is not 
an issue.  
I believe that HSM will limit writing a tape to 97% (default value) of the 
specified tape type, so having unlimited volume size does not really affect 
anything.

Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc 
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, May 23, 2018 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTL as 3490 vs 3590

W dniu 2018-05-23 o 17:39, Mike Baldwin pisze:
[...]
 > Thanks for reading this far! Did I kill the thread?
No! Not at all.

 > A couple of the largest VTL vendors only support 3490
Well, can we enumerate the VTL vendors? IMHO all of them would be happy 
to see its name on the list, while it's still no advertisement.
Let me begin:
IBM TS7700 - does it support 3590 emulation? What volume sizes available?
VISARA Vi-5990 - according to Ken's informaton it does support 3590 
emulation, any volume size.
STK/Oracle VSM - only 3490?
EMC DLm - ???
what else?


Another thread:
Assuming maximum virtual volume size does NOT depend on emulation type 
(which is a case for VISARA) - what is an advantage of having 3590 over 
3490? And the opposite - what's wrong with 3590 emulation?

Compatibility: since both emulated 3490 and emulated 3590 are VIRTUAL 
and exist only inside VTL what problems could happen with "incompatible" 
drives? IMHO VISARA 150GB virtual volume is incompatible with Oracle VSM 
virtual volume despite of emulation type, however in any case it is 
perfectly possible to move data from one tape system to another. The 
largest (actual) volume size matter.


Optimal maximum volume size for HSM:
There are some limitations in HSM which do not allow to backup very 
large datasets because maximum number of tapes used for dump is limited 
to 254 (it was 40 in the past!). That clearly say the small volume size 
could pain.
What about upper values? Is it good or bad to have huge volumes? I'm 
using 4/12TB volumes (real TS1140) and see nothing wrong with it. Of 
course I cannot make the volume smaller4 times (yes, I know there are 
sport cartridges, but I have normal ones).
Getting back to VTLs - what would be wrong in using (potential) 12TB 
virtual volumes for HSM?
I do not insist on 12TB, but I'm trying to understand what the optimal 
value is and why.



Regards
-- 
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 

Re: VTL as 3490 vs 3590

[R.S.]

W dniu 2018-05-23 o 17:39, Mike Baldwin pisze:
[...]
> Thanks for reading this far! Did I kill the thread?
No! Not at all.

> A couple of the largest VTL vendors only support 3490
Well, can we enumerate the VTL vendors? IMHO all of them would be happy 
to see its name on the list, while it's still no advertisement.

Let me begin:
IBM TS7700 - does it support 3590 emulation? What volume sizes available?
VISARA Vi-5990 - according to Ken's informaton it does support 3590 
emulation, any volume size.

STK/Oracle VSM - only 3490?
EMC DLm - ???
what else?


Another thread:
Assuming maximum virtual volume size does NOT depend on emulation type 
(which is a case for VISARA) - what is an advantage of having 3590 over 
3490? And the opposite - what's wrong with 3590 emulation?


Compatibility: since both emulated 3490 and emulated 3590 are VIRTUAL 
and exist only inside VTL what problems could happen with "incompatible" 
drives? IMHO VISARA 150GB virtual volume is incompatible with Oracle VSM 
virtual volume despite of emulation type, however in any case it is 
perfectly possible to move data from one tape system to another. The 
largest (actual) volume size matter.



Optimal maximum volume size for HSM:
There are some limitations in HSM which do not allow to backup very 
large datasets because maximum number of tapes used for dump is limited 
to 254 (it was 40 in the past!). That clearly say the small volume size 
could pain.
What about upper values? Is it good or bad to have huge volumes? I'm 
using 4/12TB volumes (real TS1140) and see nothing wrong with it. Of 
course I cannot make the volume smaller4 times (yes, I know there are 
sport cartridges, but I have normal ones).
Getting back to VTLs - what would be wrong in using (potential) 12TB 
virtual volumes for HSM?
I do not insist on 12TB, but I'm trying to understand what the optimal 
value is and why.




Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: Old School Maintenance Philosophy -- Never ACCEPT?

[Tom Marchant]

On Wed, 23 May 2018 10:07:16 -0400, John Eells wrote:

>As others have pointed out, it makes RESTORE a lot harder if you never
>ACCEPT PTFs.

I haven't had the need to do this yet, but I have an idea that I think will 
make it much easier.

If I want to restore PTF A and RESTORE CHECK tells me that it can't 
RESTORE it because PTFs B, C, and D have not been ACCEPTed, I can 
run ACCEPT CHECK on B, C, and D. That should give me a list of all the 
PTFs that also need to be RESTOREd in order to RESTORE A.

-- 
Tom Marchant

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

Re: z/OS 2.3 - sftp

[Susan Shumway]

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.foto100/sftp.htm

-Sue Shumway

On 05/23/18 11:48 AM, Mark Pace wrote:

Can someone tell me where the sftp command is documented in z/OS 2.3?

I've looked in the 8 Unix System Services manuals.



--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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

Re: z/OS 2.3 - sftp

[Kirk Wolf]

Sorry, that was the wrong link.
Try:
https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc276806?OpenDocument

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, May 23, 2018 at 11:01 AM, Kirk Wolf  wrote:

> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.
> 0/com.ibm.zos.v2r3.e0za100/ch1openssh.htm
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> On Wed, May 23, 2018 at 10:49 AM, Mark Pace 
> wrote:
>
>> Can someone tell me where the sftp command is documented in z/OS 2.3?
>>
>> I've looked in the 8 Unix System Services manuals.
>>
>> --
>> The postings on this site are my own and don’t necessarily represent
>> Mainline’s positions or opinions
>>
>> Mark D Pace
>> Senior Systems Engineer
>> Mainline Information Systems
>>
>> --
>> 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: z/OS 2.3 - sftp

[Kirk Wolf]

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0za100/ch1openssh.htm

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, May 23, 2018 at 10:49 AM, Mark Pace  wrote:

> Can someone tell me where the sftp command is documented in z/OS 2.3?
>
> I've looked in the 8 Unix System Services manuals.
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> 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

AW: AW: IP printing from JES2?

[Michael Knigge]

Thanks for clarification... sorry I've missed the sarcasm - no native speaker 
;-)


Mit freundlichen Grüßen

Michael Knigge
Software Engineer

SET GmbH
Lister Straße 15
30163 Hannover

phone: +49 511 39780-23
fax: +49 511 39780-65

www.set.de
michael.kni...@set.de

Handelsregister: HRB52778 Amtsgericht Hannover
Geschäftsführer: Till Dammermann, Dr. Bernd Huber

Weitere Informationen finden Sie auf unserer Homepage...
-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Dana Mitchell
Gesendet: Mittwoch, 23. Mai 2018 15:01
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: AW: IP printing from JES2?

Sorry for my sarcasm,

On Wed, 23 May 2018 06:49:08 +, Michael Knigge  
wrote:

>"Priced attractively" means that it is part of Communications Server (which is 
>part of z/OS) but is not "free"? There is an additional fee?
>

Correct, no additional fee.  Part of CS

thanks
Dana




>Thank you,
>Michael
>
>
>Mit freundlichen Grüßen
>

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

z/OS 2.3 - sftp

[Mark Pace]

Can someone tell me where the sftp command is documented in z/OS 2.3?

I've looked in the 8 Unix System Services manuals.

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: VTL as 3490 vs 3590

[Ken Bloom]

Yes, that was a typo.  We allow 3490 or 3590, but as I said, most define as 
3490 and we have only had 1 customer do 3590.  The 3590 customer is 
international and he does stack data sets on each tape.   We are backing up 
over 1000 tapes per night at that site. 

Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


> On May 23, 2018, at 11:39 AM, Mike Baldwin  wrote:
> 
> Hi Tony,
> 
> Wow, long Friday thread!
> Tony, our observation is that customers who choose a VTL that supports 3590 
> logical device type usually choose to exploit 3590.
> A couple of the largest VTL vendors only support 3490, so they have a choice 
> of one, and it does not seem to be a priority to add 3590 emulation.  I hope 
> that changes, but it's possible that if you change to one of those vendors in 
> future, you could be changing from 3590 back to 3490!
> 
> "All VTLs should be defined as 3490s  because that is what everybody does."
> 
> Not really, but if choosing 3590 it would be prudent to ensure that the 
> recovery site also supports 3590.
> 
> "if we have an issue with the VTL we can just swap the fiber and continue 
> running on real 3590s"
> 
> I don't hear of this practice.  I think redundancy is usually built into the 
> network (grid) configuration (multiple VTL's).
> If doing this, I hope you at least have real TS11x0's (less obsolete than 
> real 3590), and enough of them!
> 
> "only define them as 3590 if the customer has a "desire" to define 3490."
> 
> I hope that's a typo, Ken!  ;-)
> 
> "you can define the virtual-volumes in Gigabytes of capacity."
> 
> Yes, these days customers are defining their logical volumes on new libraries 
> at values like 25 GiB, 32 GB, 40 GB
> (regardless of the 3490/3590 question).
> When we migrate, that greatly reduces the number of multi-volume datasets and 
> volume chains.
> Also, we have seen in larger shops a lot of time can be spent on tape 
> management house-keeping
> and synchronisation of the library with tape management.  (Think millions of 
> those smaller volumes).
> Consolidation to fewer, larger logical volumes can save storage management 
> time.
> 
> "If you stack lots of very small files, you run into a problem with the 
> Block-ID not being large enough."
> 
> We don't see customers needing to stack many files on logical volumes (I 
> would define many as thousands).
> And,
> 
>>> Depending on how the data is accessed, having more blocks on an emulated
>>> tape than can be addressed by blkid, may not be a problem. Or, perhaps the
>>> emulation uses newer blkid format, and as long as mvs does not manipulate
>>> them, they likely work ok.
>>> Mike Wood
> 
> "it might be better to use 3590 as a base so that there are few virtual tapes 
> changed [sic]
> together. The plus of this is easier tape management."
> 
> This benefit (volume chain length) can be achieved with logical volume size, 
> regardless of 3490/3590 choice.  I.e., choose higher capacity -> fewer 
> volumes.
> 
> "I don't agree...with the sites that don't specify a limit to the tape size."
> 
> In z/OS storage management, we like limits, don't we?  I think it's a good 
> safety catch
> that other platforms lack.  
> 
> "there is no file size limit."
> 
> Yes, for practical purposes, there may seem to be no limit, but usually there 
> is a limit to the
> size of a file in the back-end (Unix) filesystem.  These days, a cartridge 
> may contain
> 20 TB; the SL standard allows over 2 PB per dataset (and 65535 datasets per 
> volume!)
> 
> "VTS is still able to use TS1150 (what about TS1155???), but it is 
> backend of the VTS, not frontend.
> Previously I had a choice: use native drives or buy VTS add-on. Now we  have 
> only VTS."
> 
> "for investment protection
> IBM United States Hardware Announcement 117-038...
> The TS1155 Tape drive is not compatible with IBM TS7700 or Enterprise Tape 
> Control Unit environments...
> Native data rate of 360 MBps...
> TS1155 Tape Drive Model 55F is supported in a wide range of environments, 
> including IBM Power Systems, IBM System i, IBM System p, IBM System x, and 
> other servers running AIX, Linux, Oracle Solaris, and Microsoft Windows"
> 
> (No mention of z/OS, mainframe, or FICON)
> 
> I imagine the (millennial?) reader gets the message that for the newest, 
> fastest, highest capacity
> tape subsystem, hooray I can use it with my Windows servers.  It should not 
> even cross my mind
> that mainframes still exist, let alone have unique I/O strengths.
> IMHO this fuels the daily eyebrows raising "There are still mainframes?"  
> ("There are still tapes?")
> <\rant>
> 
> "IBM has waited some period of time before certifying z/OS use of that new 
> tape
> drive/tape media/density. I suspect that's because IBM is just being that 
> extra bit careful"
> 
> I'm not sure about that, but unlike the following there was no mention of a 
> plan for TS7700:
> "IBM plans to 

Re: VTL as 3490 vs 3590

[Mike Baldwin]

Hi Tony,

Wow, long Friday thread!
Tony, our observation is that customers who choose a VTL that supports 3590 
logical device type usually choose to exploit 3590.
A couple of the largest VTL vendors only support 3490, so they have a choice of 
one, and it does not seem to be a priority to add 3590 emulation.  I hope that 
changes, but it's possible that if you change to one of those vendors in 
future, you could be changing from 3590 back to 3490!

"All VTLs should be defined as 3490s  because that is what everybody does."

Not really, but if choosing 3590 it would be prudent to ensure that the 
recovery site also supports 3590.

"if we have an issue with the VTL we can just swap the fiber and continue 
running on real 3590s"

I don't hear of this practice.  I think redundancy is usually built into the 
network (grid) configuration (multiple VTL's).
If doing this, I hope you at least have real TS11x0's (less obsolete than real 
3590), and enough of them!

"only define them as 3590 if the customer has a "desire" to define 3490."

I hope that's a typo, Ken!  ;-)

"you can define the virtual-volumes in Gigabytes of capacity."

Yes, these days customers are defining their logical volumes on new libraries 
at values like 25 GiB, 32 GB, 40 GB
(regardless of the 3490/3590 question).
When we migrate, that greatly reduces the number of multi-volume datasets and 
volume chains.
Also, we have seen in larger shops a lot of time can be spent on tape 
management house-keeping
and synchronisation of the library with tape management.  (Think millions of 
those smaller volumes).
Consolidation to fewer, larger logical volumes can save storage management time.

"If you stack lots of very small files, you run into a problem with the 
Block-ID not being large enough."

We don't see customers needing to stack many files on logical volumes (I would 
define many as thousands).
And,

>> Depending on how the data is accessed, having more blocks on an emulated
>> tape than can be addressed by blkid, may not be a problem. Or, perhaps the
>> emulation uses newer blkid format, and as long as mvs does not manipulate
>> them, they likely work ok.
>> Mike Wood

"it might be better to use 3590 as a base so that there are few virtual tapes 
changed [sic]
together. The plus of this is easier tape management."

This benefit (volume chain length) can be achieved with logical volume size, 
regardless of 3490/3590 choice.  I.e., choose higher capacity -> fewer volumes.

"I don't agree...with the sites that don't specify a limit to the tape size."

In z/OS storage management, we like limits, don't we?  I think it's a good 
safety catch
that other platforms lack.  

"there is no file size limit."

Yes, for practical purposes, there may seem to be no limit, but usually there 
is a limit to the
size of a file in the back-end (Unix) filesystem.  These days, a cartridge may 
contain
20 TB; the SL standard allows over 2 PB per dataset (and 65535 datasets per 
volume!)

"VTS is still able to use TS1150 (what about TS1155???), but it is 
backend of the VTS, not frontend.
Previously I had a choice: use native drives or buy VTS add-on. Now we  have 
only VTS."

"for investment protection
IBM United States Hardware Announcement 117-038...
The TS1155 Tape drive is not compatible with IBM TS7700 or Enterprise Tape 
Control Unit environments...
Native data rate of 360 MBps...
TS1155 Tape Drive Model 55F is supported in a wide range of environments, 
including IBM Power Systems, IBM System i, IBM System p, IBM System x, and 
other servers running AIX, Linux, Oracle Solaris, and Microsoft Windows"

(No mention of z/OS, mainframe, or FICON)

I imagine the (millennial?) reader gets the message that for the newest, 
fastest, highest capacity
tape subsystem, hooray I can use it with my Windows servers.  It should not 
even cross my mind
that mainframes still exist, let alone have unique I/O strengths.
IMHO this fuels the daily eyebrows raising "There are still mainframes?"  
("There are still tapes?")
<\rant>

"IBM has waited some period of time before certifying z/OS use of that new tape
drive/tape media/density. I suspect that's because IBM is just being that extra 
bit careful"

I'm not sure about that, but unlike the following there was no mention of a 
plan for TS7700:
"IBM plans to extend support for the TS1155 Tape Drive Model 55F to the IBM 
Spectrum Archive family of products."
Maybe we need to read between the lines?

"The auditors are ok with old tapes that most likely will 
never need to be read...Management has chosen 'deniability'."

That is disturbing.

"There is absolutely no limitation on continuing to use
physical tape media for your organization's data storage needs."

See above, TS1155 not supported with mainframe.  (Except maybe LinuxONE?)

"You do need a tape controller for physical tape. That's always been true"

Technically yes, although some (non-IBM) drives include a built-in controller.
Timothy, thank you for contributing that IBM 

Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory?

[Thomas David Rivers]

Peter Relson wrote:

I believe that the rules for whether BPX1LOD brings a module into writable 
memory are the same as for whether the LOAD service does.
It primarily has to do with the module attributes (is it reentrant?) and 
the APF authorization of the job step.


Peter Relson
z/OS Core Technology Design

 



Ah - but what if, although the module might be marked RENT,
I'd _really_ like it to loaded into writable storage without re-linking
it?

No way to do that?

  - Dave R. -

--
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: Replaceing IEBGENER

[John Eells]

Paul Gilmartin wrote:

On Wed, 23 May 2018 10:17:48 -0400, John Eells wrote:


Vernooij, Kees - KLM , ITOPT1 wrote:

Because IT creates the alias IBMGENER to the old IEBGENER and so it knows how 
to invoke it.



Quite some time ago, DFSMSdfp started to ship an IEBGENR alias of
IEBGENER so that DFSORT could call it when ICEGENER encountered IEBGENER
control statements.


Thanks for saving customers a couple installation steps and for moving to a
uniform configuration across sites.


You're welcome, of course, but this is pretty old news.  If I recall 
correctly, this was in the early OS/390 timeframe.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: File transfer Red Alert

[Paul Gilmartin]

On Wed, 23 May 2018 13:00:22 +, Jousma, David wrote:
>
>>A .jar file _is_ a .zip file, but with some specified contents, such as a 
>>"manifest". The JAVA "jar" command can create a file which a standard "unzip" 
>>>utility can expand. It can also extract files from a standard zip file. That 
>>is, it can act as a regular zip command. But a true .jar file must have the 
>>.jar >extension and have the proper contents to be used by the java 
>>executable.
>
>For us "dummies" though, uploading the file as-is isn’t enough.  It has to be 
>renamed to .jar for the supplied JCL to work correctly.
> 
Why didn't the supplier, as a courtesy to the customer, deliver the file with
the needed extension and save that step?

>>Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you can 
>>do a BINary download to a PC, then do a BINary upload to z/OS if you first do 
>>a >"QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".
>
>This is precisely what I am trying to avoid.  I want to transmit my diags 
>directly from z/OS.  
> 
Is there an obstacle to that?  Don't the same commands work on z/OS FTP?
Or even shortcut with options on the BINARY command?

>Playing with this some more, and I think it was alrea y mentioned here is that 
>AMATERSE does not allow SYSUT1 or SYSUT2 to be PATH statements either.
>
Here, the AMATERSE designers were obsessive.  QSAM and BSAM handle PATH
just file.  Let them do their job.  In fact, UNPACK works if SYSUT1 is a 
concatenation
of an empty Classic data set and a PATH.

There is, however, good reason not to support PATH for the unpacked operand.
That's what pax is for.  AMATERSE should, however, allow (schematically):
pax -w | AMATERSE PACK
and:
AMATERSE UNPACK | pax -r

-- gil

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Gerhard Adam]

I also don't recall a "never ACCEPT" policy.  That would be silly because it 
becomes a "never RESTORE" policy.

Sent from my iPhone

> On May 23, 2018, at 7:08 AM, David L. Craig  wrote:
> 
>> On 18May23:1247+, Pommier, Rex wrote:
>> 
>> Not sure how long ago eons was, but I started in the
>> mid-80s on MVS/SP and at my first SMP/E (and I believe
>> only) class, I was taught the APPLY / run for a while /
>> ACCEPT usage - except for USERMODs or APARs that hadn't
>> had a published PTF yet.
> 
> I learned to use SMP back on MVT (am I the only one still
> here that can truthfully make that statement?) and while
> it's been a while since I last used SMP/E, I do not recall
> ever encountering a no ACCEPT policy for any IBM MRM.
> But people aren't mentioning policy for archiving snapshots
> of target and DLIB volumes and restoring therefrom--much
> faster than reAPPLYing LOTS of maintenance.  That also
> requires tracking the target/DLIB volume snapshot
> associations, which are not necessarily based upon the
> dates of the snapshots.
> -- 
> 
> May the LORD God bless you exceedingly abundantly!
> 
> Dave_Craig__
> "So the universe is not quite as you thought it was.
> You'd better rearrange your beliefs, then.
> Because you certainly can't rearrange the universe."
> __--from_Nightfall_by_Asimov/Silverberg_
> 
> --
> 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: Replaceing IEBGENER

[Paul Gilmartin]

On Wed, 23 May 2018 10:17:48 -0400, John Eells wrote:

>Vernooij, Kees - KLM , ITOPT1 wrote:
>> Because IT creates the alias IBMGENER to the old IEBGENER and so it knows 
>> how to invoke it.
>
>
>Quite some time ago, DFSMSdfp started to ship an IEBGENR alias of
>IEBGENER so that DFSORT could call it when ICEGENER encountered IEBGENER
>control statements.
>
Thanks for saving customers a couple installation steps and for moving to a
uniform configuration across sites.

-- gil

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

Re: File transfer Red Alert

[Carmen Vitullo]

this doc is pretty good on how to get the cert and upload to your z/OS system 


https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim3000/obtuc.htm
 


doing this we were able to schedule the receive of holddata weekly using a 
scheduling package. 




Carmen Vitullo 

- Original Message -

From: "Carmen Vitullo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 9:22:46 AM 
Subject: Re: File transfer Red Alert 

I'll hunt around I do have some JCL to receive HOLDDATA weekly, but something 
like this may work, if you receive the keyring for SMP/E from the IBM site, 
there's doc on the site, they add the keyring to your security package and use 
some JCL like this... I think this is still valid 





SET BDY(GLOBAL). 
RECEIVE SYSMODS HOLDDATA 
ORDER( /* Place an order for service */ 
ORDERSERVER(ORDRSRVR) /* Specify the ORDERSERVER DDNAME. */ 
CLIENT(MYCLIENT) /* Specify the CLIENT DDNAME. */ 
FORTGTZONES(ZOST111) /* For this target zone */ 
) 
. /* DELETEPKG. */ 
//ORDRSRVR DD * 
https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/; 
keyring="TSO-USERID/zOSring" 
certificate="SMPE Client Certificate"> 
 
/* 
//MYCLIENT DD * 
 
 

Carmen Vitullo 

- Original Message - 

From: "Robert B. Richards"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 9:12:28 AM 
Subject: Re: File transfer Red Alert 

Speaking of file transfer, does anyone have JCL to get HOLDDATA "securely"? 

I was using: 

//FTPHOLDD EXEC PGM=FTP,REGION=2M,PARM='(EXIT' 
//SYSPRINT DD SYSOUT=* 
//OUTPUT DD SYSOUT=* 
//INPUT DD * 
dispby-112.boulder.ibm.com 
anonymous 
myemailaddress 
cd /s390/holddata 
locsite lrecl=80 blksize=0 recfm=fb cyl primary=15 
get full.txt 'SYSxxx.SMPE.ENHANCED.HOLDDATA' (repl 
quit 

I now need to make this a secure FTP. What changes to I need in the above? 

Bob 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown 
Sent: Wednesday, May 23, 2018 8:45 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: File transfer Red Alert 

On Wed, May 23, 2018 at 7:25 AM Jousma, David < 
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: 

> Does anyone find this funny? Comes today, with compliance date of 
> tomorrow. 
> 
> Anyway, I'm playing with the JAVA version of the utility. First off, 
> I'll point out that the download link for the .jar file downloads the file 
> as a .zip file. 


​A .jar file _is_ a .zip file, but with some specified contents, such as a 
"manifest". The JAVA "jar" command can create a file which a standard 
"unzip" utility can expand. It can also extract files from a standard zip 
file. That is, it can act as a regular zip command. But a true .jar file 
must have the .jar extension and have the proper contents to be used by the 
java executable.​ 



> After uploading to my sandbox, I had to rename it to .jar. Initial test 
> is successful, the only issue I have is that by default it wants to look 
> into filesystem for the files to upload. I'm not smart enough, but is 
> there syntax to have it pull traditional MVS dataset? If not how would I 
> copy an SVC dump into my filesystem without losing the necessary 
> attributesdoc says TERSE ahead of time is not necessary. 
> 

​Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you 
can do a BINary download to a PC, then do a BINary upload to z/OS if you 
first do a "QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".​ 



> 
> //BPXS1 EXEC PGM=BPXBATCH,REGION=256M 
> //STDOUT DD SYSOUT=* 
> //STDERR DD SYSOUT=* 
> //*** use the current java environment 
> //STDENV DD * 
> PATH=/bin:/usr/sbin:/opt/fitb/java/Jre:. 
> //STDPARM DD * 
> SH java -classpath /home/myhome/ibmsdduu.jar ibmsdduu.cmd 
> -threads=4 -encrypt -compress 
> -server=testcase.boulder.ibm.com 
> -pmr -id=0.000.000 
> /test.txt 
> /* 
> _ 
> Dave Jousma 
> Manager Mainframe Engineering, Assistant Vice President 
> david.jou...@53.com 
> 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H 
> p 616.653.8429 
> f 616.653.2717 
> 

-- 
Once a government places vague notions of public safety and security above 
the preservation of freedom, a general loss of liberty is sure to follow. 

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book) 


Maranatha! <>< 
John McKown 

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

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


-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 

Re: File transfer Red Alert

[Carmen Vitullo]

I'll hunt around I do have some JCL to receive HOLDDATA weekly, but something 
like this may work, if you receive the keyring for SMP/E from the IBM site, 
there's doc on the site, they add the keyring to your security package and use 
some JCL like this... I think this is still valid 





SET BDY(GLOBAL). 
RECEIVE SYSMODS HOLDDATA 
ORDER( /* Place an order for service */ 
ORDERSERVER(ORDRSRVR) /* Specify the ORDERSERVER DDNAME. */ 
CLIENT(MYCLIENT) /* Specify the CLIENT DDNAME. */ 
FORTGTZONES(ZOST111) /* For this target zone */ 
) 
. /* DELETEPKG. */ 
//ORDRSRVR DD * 
https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/; 
keyring="TSO-USERID/zOSring" 
certificate="SMPE Client Certificate"> 
 
/* 
//MYCLIENT DD * 
 
 

Carmen Vitullo 

- Original Message -

From: "Robert B. Richards"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 9:12:28 AM 
Subject: Re: File transfer Red Alert 

Speaking of file transfer, does anyone have JCL to get HOLDDATA "securely"? 

I was using: 

//FTPHOLDD EXEC PGM=FTP,REGION=2M,PARM='(EXIT' 
//SYSPRINT DD SYSOUT=* 
//OUTPUT DD SYSOUT=* 
//INPUT DD * 
dispby-112.boulder.ibm.com 
anonymous 
myemailaddress 
cd /s390/holddata 
locsite lrecl=80 blksize=0 recfm=fb cyl primary=15 
get full.txt 'SYSxxx.SMPE.ENHANCED.HOLDDATA' (repl 
quit 

I now need to make this a secure FTP. What changes to I need in the above? 

Bob 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown 
Sent: Wednesday, May 23, 2018 8:45 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: File transfer Red Alert 

On Wed, May 23, 2018 at 7:25 AM Jousma, David < 
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: 

> Does anyone find this funny? Comes today, with compliance date of 
> tomorrow. 
> 
> Anyway, I'm playing with the JAVA version of the utility. First off, 
> I'll point out that the download link for the .jar file downloads the file 
> as a .zip file. 


​A .jar file _is_ a .zip file, but with some specified contents, such as a 
"manifest". The JAVA "jar" command can create a file which a standard 
"unzip" utility can expand. It can also extract files from a standard zip 
file. That is, it can act as a regular zip command. But a true .jar file 
must have the .jar extension and have the proper contents to be used by the 
java executable.​ 



> After uploading to my sandbox, I had to rename it to .jar. Initial test 
> is successful, the only issue I have is that by default it wants to look 
> into filesystem for the files to upload. I'm not smart enough, but is 
> there syntax to have it pull traditional MVS dataset? If not how would I 
> copy an SVC dump into my filesystem without losing the necessary 
> attributesdoc says TERSE ahead of time is not necessary. 
> 

​Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you 
can do a BINary download to a PC, then do a BINary upload to z/OS if you 
first do a "QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".​ 



> 
> //BPXS1 EXEC PGM=BPXBATCH,REGION=256M 
> //STDOUT DD SYSOUT=* 
> //STDERR DD SYSOUT=* 
> //*** use the current java environment 
> //STDENV DD * 
> PATH=/bin:/usr/sbin:/opt/fitb/java/Jre:. 
> //STDPARM DD * 
> SH java -classpath /home/myhome/ibmsdduu.jar ibmsdduu.cmd 
> -threads=4 -encrypt -compress 
> -server=testcase.boulder.ibm.com 
> -pmr -id=0.000.000 
> /test.txt 
> /* 
> _ 
> Dave Jousma 
> Manager Mainframe Engineering, Assistant Vice President 
> david.jou...@53.com 
> 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H 
> p 616.653.8429 
> f 616.653.2717 
> 

-- 
Once a government places vague notions of public safety and security above 
the preservation of freedom, a general loss of liberty is sure to follow. 

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book) 


Maranatha! <>< 
John McKown 

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

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


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

Re: Replaceing IEBGENER

[John Eells]

Vernooij, Kees - KLM , ITOPT1 wrote:

Because IT creates the alias IBMGENER to the old IEBGENER and so it knows how 
to invoke it.



Quite some time ago, DFSMSdfp started to ship an IEBGENR alias of 
IEBGENER so that DFSORT could call it when ICEGENER encountered IEBGENER 
control statements.


The sample job in SYS1.SICESAMP(ICEGAREC) has an SMP/E USERMOD that 
creates a copy of ICEGENER in the SICELPA data set, with aliases of 
IEBGENER and SORTGENR.  When the USERMOD is applied and SICELPA is in 
the LPA list (as it should be if you are using DFSORT) the IEBGENER 
alias of ICEGENER is found before the copy of IEBGENER in LINKLIB.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[Carmen Vitullo]

I'm so glad I did not have to use/work with SMP, I've heard the war stories and 
I think the backup everyone philosophy came from the old SMP V4 days and at the 
site I worked at, SMP/E I was still taught the standard of backing up all SMP/E 
datasets, target and DLIBS prior to any apply, it has saved my A$$ a couple 
times 



Carmen Vitullo 

- Original Message -

From: "David L. Craig"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 9:08:45 AM 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

On 18May23:1247+, Pommier, Rex wrote: 
> 
> Not sure how long ago eons was, but I started in the 
> mid-80s on MVS/SP and at my first SMP/E (and I believe 
> only) class, I was taught the APPLY / run for a while / 
> ACCEPT usage - except for USERMODs or APARs that hadn't 
> had a published PTF yet. 

I learned to use SMP back on MVT (am I the only one still 
here that can truthfully make that statement?) and while 
it's been a while since I last used SMP/E, I do not recall 
ever encountering a no ACCEPT policy for any IBM MRM. 
But people aren't mentioning policy for archiving snapshots 
of target and DLIB volumes and restoring therefrom--much 
faster than reAPPLYing LOTS of maintenance. That also 
requires tracking the target/DLIB volume snapshot 
associations, which are not necessarily based upon the 
dates of the snapshots. 
-- 
 
May the LORD God bless you exceedingly abundantly! 

Dave_Craig__ 
"So the universe is not quite as you thought it was. 
You'd better rearrange your beliefs, then. 
Because you certainly can't rearrange the universe." 
__--from_Nightfall_by_Asimov/Silverberg_ 

-- 
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: File transfer Red Alert

[Richards, Robert B.]

Speaking of file transfer, does anyone have JCL to get HOLDDATA "securely"?

I was using:

//FTPHOLDD EXEC PGM=FTP,REGION=2M,PARM='(EXIT'   
//SYSPRINT DD  SYSOUT=*  
//OUTPUT   DD  SYSOUT=*  
//INPUTDD  * 
 dispby-112.boulder.ibm.com  
 anonymous   
 myemailaddress 
 cd /s390/holddata   
 locsite lrecl=80 blksize=0 recfm=fb cyl primary=15  
 get full.txt 'SYSxxx.SMPE.ENHANCED.HOLDDATA' (repl
 quit

I now need to make this a secure FTP.  What changes to I need in the above?

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, May 23, 2018 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer Red Alert

On Wed, May 23, 2018 at 7:25 AM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Does anyone find this funny?   Comes today, with compliance date of
> tomorrow.
>
> Anyway, I'm playing with the JAVA version of the utility.   First off,
> I'll point out that the download link for the .jar file downloads the file
> as a .zip file.


​A .jar file _is_ a .zip file, but with some specified contents, such as a
"manifest". The JAVA "jar" command can create a file which a standard
"unzip" utility can expand. It can also extract files from a standard zip
file. That is, it can act as a regular zip command. But a true .jar file
must have the .jar extension and have the proper contents to be used by the
java executable.​



>  After uploading to my sandbox, I had to rename it to .jar.  Initial test
> is successful, the only issue I have is that by default it wants to look
> into filesystem for the files to upload.   I'm not smart enough, but is
> there syntax to have it pull traditional MVS dataset?  If not how would I
> copy an SVC dump into my filesystem without losing the necessary
> attributesdoc says TERSE ahead of time is not necessary.
>

​Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you
can do a BINary download to a PC, then do a BINary upload to z/OS if you
first do a "QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".​



>
> //BPXS1 EXEC PGM=BPXBATCH,REGION=256M
> //STDOUT DD SYSOUT=*
> //STDERR DD SYSOUT=*
> //*** use the current java environment
> //STDENV DD *
> PATH=/bin:/usr/sbin:/opt/fitb/java/Jre:.
> //STDPARM DD *
> SH java -classpath /home/myhome/ibmsdduu.jar ibmsdduu.cmd
> -threads=4 -encrypt -compress
> -server=testcase.boulder.ibm.com
> -pmr -id=0.000.000
> /test.txt
> /*
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>

-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

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

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

[David L. Craig]

On 18May23:1247+, Pommier, Rex wrote:
> 
> Not sure how long ago eons was, but I started in the
> mid-80s on MVS/SP and at my first SMP/E (and I believe
> only) class, I was taught the APPLY / run for a while /
> ACCEPT usage - except for USERMODs or APARs that hadn't
> had a published PTF yet.

I learned to use SMP back on MVT (am I the only one still
here that can truthfully make that statement?) and while
it's been a while since I last used SMP/E, I do not recall
ever encountering a no ACCEPT policy for any IBM MRM.
But people aren't mentioning policy for archiving snapshots
of target and DLIB volumes and restoring therefrom--much
faster than reAPPLYing LOTS of maintenance.  That also
requires tracking the target/DLIB volume snapshot
associations, which are not necessarily based upon the
dates of the snapshots.
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

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

Re: Old School Maintenance Philosophy -- Never ACCEPT?

[John Eells]

As others have pointed out, it makes RESTORE a lot harder if you never 
ACCEPT PTFs.


Why?  To RESTORE, SMP/E requires the needed levels of the parts to be in 
the DLIBs.


Here is a simple example.  Suppose you have Part A, and the DLIB level 
of Part A is 001.  You have installed six PTFs that replace Part A, so 
now the target level of Part A is, in this example, 007.  There's a 
problem with the last PTF, and either the PE fix is not available or 
perhaps you're not comfortable with its age.  So, you want to take off 
just the last PTF that replaced Part A.  But, SMP/E does not have level 
006 of part A in the DLIB, it has level 001.  So, you must either back 
off all six PTFs to back off the last one, and then put five of them 
back, *or* ACCEPT the first five before backing off the sixth.  In the 
first case, SMP/E restores Part A back to level 001, and then updates it 
to 006.  In the second (after the ACCEPT for the first five PTFs), it 
simply restores Part A to level 006.


Now, think about what happens with PTFs that PRE and IF other PTFs, and 
those that ship overlapping multiples of some parts.  This stuff can get 
really complicated to untangle, fast.  The RESTORE process tends to be 
iterative, and can be quite time-consuming, if you never or rarely run 
ACCEPT.  So most thoughtful people, after seeing how this all works, 
decide how far forward to ACCEPT, and when, and do it as a matter of 
course to keep the plate of sticky spaghetti down to a manageable level 
of complexity in case they have to RESTORE a PTF later on.


I hate stories that start with "when *I* did that," but I'll tell one 
anyway.  We used to ACCEPT all non-PE PTFs ahead of each preventive 
service cycle, which seemed to keep it under control reasonably well 
because we did it quarterly (which is now pretty much the current 
recommendation, as it happens).  If you do it less often, the amount of 
applied but not accepted service will be greater, and the chains to be 
resolved before RESTORE will be correspondingly more complex.  You might 
want to ACCEPT by PTF age (PUT) in that case, for example.


Other people have other strategies, but you should think about the 
complexity of RESTORE preparation and the time it will take if you have 
to RESTORE a PTF to resolve a severe problem.  Also, not running ACCEPT 
on some regular basis makes your SMPPTS data sets grow forever, though 
this is a far smaller concern today than it was historically.


This is the current state of SMP/E RESTORE processing.  The requirement 
to "Please, *please* just let me take off this PTF and anything that 
PREs or IFs it without having to figure this stuff all out" is, believe 
me, *very* well understood.  In other words, more RFEs won't hurt, but 
neither will they help much.



Ed Jaffe wrote:

z/OS Sysprogs,

ISTR a maintenance philosophy from "eons" ago where PTFs would be 
applied but never accepted.


What was the rationale for this? Does anyone still use this philosophy? 
If so, why?


Thanks,




--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: [External] Re: VTL as 3490 vs 3590

[Pommier, Rex]

I've been following this thread with some interest.  We currently have a TS7720 
without tape behind it and a TS3584 with C06 "dumb" controllers as Timothy 
calls them.  Due to the impending demise of support for the C06 and the 
unavailability of C07 controllers we have decided to swing the 3584 behind the 
7720.  Today when I perform system backups, I send 1 copy to the VTS for ease 
of recovery for the "something happened to my dataset" and the other copy 
directly to the 3592 tapes in the 3584.  This set of backups is transported 
offsite for actual disaster recovery. So here are my questions.  

I was under the impression that the physical tape on the back end of a TS77xx 
box basically acted as a cache extension where the physical tapes were managed 
by the TS77xx controllers.  Can I force, for example, a set of system backups 
to get sent immediately to the passthru tapes as well as the virtual tapes on 
the TS7720 itself so I can send a set of physicals offsite like I do today?  

In the case of backups that need to go offsite, what manages the physical tapes 
in the 3584 - is it still my tape management system on the mainframe or is it 
some kind of tape management in the 7720?

Can I use other physical tapes in the 3584 as extra space for "throwaway" data 
in the 7720 if I'm running low on cache (physical disk) in the VTS?  

If I'm using some physicals as just cache extension what manages these tapes?  
Does the 7720 or is this still z/OS TMS?  What handles recycling of these 
tapes?  

Thanks,

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, May 22, 2018 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: VTL as 3490 vs 3590

W dniu 2018-05-22 o 08:04, Timothy Sipples pisze:
> Radoslaw Skorupka wrote:
>> It is really nice sales pitch, but *technically* IBM it is no longer
>> possible to write directly to a tape volume from z/OS.
> First of all, it's not a sales pitch. I don't do sales pitches very well.
>
> Second, it's also no longer possible to "write directly" to disk drives.
> *All* mainframe-attached storage -- flash/SSD, disk, and now tape -- is
> highly virtualized, with intelligent controllers equipped with caches.
>
> Why is this progress a problem? And it's a very long arc of progress, not
> at all sudden. As I've carefully and accurately documented, there was
> nearly 19 years of product overlap as IBM tape made the transition to
> virtualized-physical.
>
> Finally, "ask your friendly IBM representative" about IBM TS1155/TS4500
> attachment to your IBM TS7700. I have no inside information on that, but I
> do pay some attention to IBM's past practices.

I was talking to IBMer storage salesmen last week or so. They still 
offer TS1150, not 1155.

Regarding the sales pitch: can I insert physical cart into TS7700? Let's 
imagine I want to write the tape in shop A and read it in shop B.
Yes, I know about grid or even ftp, but I want to send physical medium. 
Just because. Can I?
Or still available ServerPac on a tape. Can it be read on TS7700?

Regards
-- 
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 

Re: AW: IP printing from JES2?

[Dana Mitchell]

Sorry for my sarcasm, 

On Wed, 23 May 2018 06:49:08 +, Michael Knigge  
wrote:

>"Priced attractively" means that it is part of Communications Server (which is 
>part of z/OS) but is not "free"? There is an additional fee?
>

Correct, no additional fee.  Part of CS

thanks
Dana




>Thank you,
>Michael
>
>
>Mit freundlichen Grüßen
>

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

Re: File transfer Red Alert

[Jousma, David]

Thanks John.   

>A .jar file _is_ a .zip file, but with some specified contents, such as a 
>"manifest". The JAVA "jar" command can create a file which a standard "unzip" 
>>utility can expand. It can also extract files from a standard zip file. That 
>is, it can act as a regular zip command. But a true .jar file must have the 
>.jar >extension and have the proper contents to be used by the java executable.

For us "dummies" though, uploading the file as-is isn’t enough.  It has to be 
renamed to .jar for the supplied JCL to work correctly.

>Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you can 
>do a BINary download to a PC, then do a BINary upload to z/OS if you first do 
>a >"QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".

This is precisely what I am trying to avoid.  I want to transmit my diags 
directly from z/OS.  

Playing with this some more, and I think it was already mentioned here is that 
AMATERSE does not allow SYSUT1 or SYSUT2 to be PATH statements either.
_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


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


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

Re: IP printing from JES2?

[Allan Staller]

AFAIK, no additional fee.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Michael Knigge
Sent: Wednesday, May 23, 2018 1:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: IP printing from JES2?

"Priced attractively" means that it is part of Communications Server (which is 
part of z/OS) but is not "free"? There is an additional fee?

Thank you,
Michael


Mit freundlichen Grüßen

Michael Knigge
Software Engineer

SET GmbH
Lister Straße 15
30163 Hannover

phone: +49 511 39780-23
fax: +49 511 39780-65

https://apac01.safelinks.protection.outlook.com/?url=www.set.de=02%7C01%7Callan.staller%40HCL.COM%7C22545d22d48d4f61f1f808d5c079558d%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636626549749073485=SjKnZcDv%2FXHDIO1%2BiJhLnfwSX02ijr12Apsoi%2FKX2To%3D=0
michael.kni...@set.de

Handelsregister: HRB52778 Amtsgericht Hannover
Geschäftsführer: Till Dammermann, Dr. Bernd Huber

Weitere Informationen finden Sie auf unserer Homepage...
-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Dana Mitchell
Gesendet: Dienstag, 22. Mai 2018 18:29
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: IP printing from JES2?

We have been using NPF for quite a while.  Setup is sort of non-intuitave, but 
we have a very small number of printers,  once setup it just works and doesn't 
need much attention.  Priced attractively.

Dana

On Tue, 22 May 2018 10:07:42 -0400, Tony Thigpen  wrote:

>We are going to look at IP NETWORK PRINT FACILITY since it is part of
>Communications Server.
>
>Tony Thigpen
>

--
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 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: File transfer Red Alert

[Allan Staller]

"//DD:DDNAME" or something similar?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, May 23, 2018 7:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: File transfer Red Alert

Does anyone find this funny?   Comes today, with compliance date of tomorrow.

Anyway, I'm playing with the JAVA version of the utility.   First off, I'll 
point out that the download link for the .jar file downloads the file as a .zip 
file.   After uploading to my sandbox, I had to rename it to .jar.  Initial 
test is successful, the only issue I have is that by default it wants to look 
into filesystem for the files to upload.   I'm not smart enough, but is there 
syntax to have it pull traditional MVS dataset?  If not how would I copy an SVC 
dump into my filesystem without losing the necessary attributesdoc says 
TERSE ahead of time is not necessary.

//BPXS1 EXEC PGM=BPXBATCH,REGION=256M
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//*** use the current java environment
//STDENV DD *
PATH=/bin:/usr/sbin:/opt/fitb/java/Jre:.
//STDPARM DD *
SH java -classpath /home/myhome/ibmsdduu.jar ibmsdduu.cmd
-threads=4 -encrypt -compress
-server=testcase.boulder.ibm.com
-pmr -id=0.000.000
/test.txt
/*
_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

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




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::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] Old School Maintenance Philosophy -- Never ACCEPT?

[Carmen Vitullo]

Agree, my SMP/E class I took (Amdal) in the early 80's taught us the same, plus 
it was suggested we run the accept process (only sysmods(PTF) ) prior to 
applying of new maint. 
that philosophy right or wrong has worked great for me. 


NEVER ACCEPT USERMODS OR APARS - 


Carmen Vitullo 

- Original Message -

From: "Rex Pommier"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 23, 2018 7:47:15 AM 
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

Ed, 

Not sure how long ago eons was, but I started in the mid-80s on MVS/SP and at 
my first SMP/E (and I believe only) class, I was taught the APPLY / run for a 
while / ACCEPT usage - except for USERMODs or APARs that hadn't had a published 
PTF yet. 

Rex 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe 
Sent: Tuesday, May 22, 2018 3:28 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [External] Old School Maintenance Philosophy -- Never ACCEPT? 

z/OS Sysprogs, 

ISTR a maintenance philosophy from "eons" ago where PTFs would be 
applied but never accepted. 

What was the rationale for this? Does anyone still use this philosophy? 
If so, why? 

Thanks, 

-- 
Phoenix Software International 
Edward E. Jaffe 
831 Parkview Drive North 
El Segundo, CA 90245 
http://www.phoenixsoftware.com/ 

 
This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise 
received this email message in error, any use, dissemination, distribution, 
review, storage or copying of this e-mail message and the information 
contained therein is strictly prohibited. If you are not an intended 
recipient, please contact the sender by reply e-mail and destroy all copies 
of this email message and do not otherwise utilize or retain this email 
message or any or all of the information contained therein. Although this 
email message and any attachments or appended messages are believed to be 
free of any virus or other defect that might affect any computer system into 
which it is received and opened, it is the responsibility of the recipient 
to ensure that it is virus free and no responsibility is accepted by the 
sender for any loss or damage arising in any way from its opening or use. 

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


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

Re: Old School Maintenance Philosophy -- Never ACCEPT?

[Allan Staller]

"never accept" because there might be "bad" maintenance in the stream.

If you have been running on the "new maintenance" for xx months, what can be 
"bad"?
I agree w/Tom Conley. It was wrong then (even if well intended). It is still 
wrong.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, May 22, 2018 5:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Old School Maintenance Philosophy -- Never ACCEPT?

On 5/22/2018 1:49 PM, Allan Staller wrote:
> I haven't used that philosophy in 30+ years.

What was the rationale 30+ years ago?

Do you remember why things were being done that way?

Thanks,

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.phoenixsoftware.com%2F=02%7C01%7Callan.staller%40HCL.COM%7C0a9bd16e74284d053ffe08d5c03411e4%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636626252258061200=RplEGhGyPWTc5cVIUJkB6EAo3h2uTX8R9ErgpA0OyfA%3D=0

This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise received 
this email message in error, any use, dissemination, distribution, review, 
storage or copying of this e-mail message and the information contained therein 
is strictly prohibited. If you are not an intended recipient, please contact 
the sender by reply e-mail and destroy all copies of this email message and do 
not otherwise utilize or retain this email message or any or all of the 
information contained therein. Although this email message and any attachments 
or appended messages are believed to be free of any virus or other defect that 
might affect any computer system into which it is received and opened, it is 
the responsibility of the recipient to ensure that it is virus free and no 
responsibility is accepted by the sender for any loss or damage arising in any 
way from its opening or use.

--
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] Old School Maintenance Philosophy -- Never ACCEPT?

[Pommier, Rex]

Ed,

Not sure how long ago eons was, but I started in the mid-80s on MVS/SP and at 
my first SMP/E (and I believe only) class, I was taught the APPLY / run for a 
while / ACCEPT usage - except for USERMODs or APARs that hadn't had a published 
PTF yet.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, May 22, 2018 3:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Old School Maintenance Philosophy -- Never ACCEPT?

z/OS Sysprogs,

ISTR a maintenance philosophy from "eons" ago where PTFs would be 
applied but never accepted.

What was the rationale for this? Does anyone still use this philosophy? 
If so, why?

Thanks,

-- 
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
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: File transfer Red Alert

[John McKown]

On Wed, May 23, 2018 at 7:25 AM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Does anyone find this funny?   Comes today, with compliance date of
> tomorrow.
>
> Anyway, I'm playing with the JAVA version of the utility.   First off,
> I'll point out that the download link for the .jar file downloads the file
> as a .zip file.


​A .jar file _is_ a .zip file, but with some specified contents, such as a
"manifest". The JAVA "jar" command can create a file which a standard
"unzip" utility can expand. It can also extract files from a standard zip
file. That is, it can act as a regular zip command. But a true .jar file
must have the .jar extension and have the proper contents to be used by the
java executable.​



>  After uploading to my sandbox, I had to rename it to .jar.  Initial test
> is successful, the only issue I have is that by default it wants to look
> into filesystem for the files to upload.   I'm not smart enough, but is
> there syntax to have it pull traditional MVS dataset?  If not how would I
> copy an SVC dump into my filesystem without losing the necessary
> attributesdoc says TERSE ahead of time is not necessary.
>

​Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you
can do a BINary download to a PC, then do a BINary upload to z/OS if you
first do a "QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".​



>
> //BPXS1 EXEC PGM=BPXBATCH,REGION=256M
> //STDOUT DD SYSOUT=*
> //STDERR DD SYSOUT=*
> //*** use the current java environment
> //STDENV DD *
> PATH=/bin:/usr/sbin:/opt/fitb/java/Jre:.
> //STDPARM DD *
> SH java -classpath /home/myhome/ibmsdduu.jar ibmsdduu.cmd
> -threads=4 -encrypt -compress
> -server=testcase.boulder.ibm.com
> -pmr -id=0.000.000
> /test.txt
> /*
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>

-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


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: [External] Re: Old School Maintenance Philosophy -- Never ACCEPT?

[Pommier, Rex]

Or you restore A and B and reapply A.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 22, 2018 6:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Old School Maintenance Philosophy -- Never ACCEPT?

On Tue, 22 May 2018 16:51:01 -0400, Tom Conley wrote:

>On 5/22/2018 4:26 PM, Ed Jaffe wrote:
>>
>> ISTR a maintenance philosophy from "eons" ago where PTFs would be
>> applied but never accepted.
>>
>> What was the rationale for this? Does anyone still use this philosophy?
>> If so, why?
>
>There is no rationale.  It was wrong then, and it's wrong now.  It
>kneecaps the most valuable feature of SMP/E - RESTORE!  Unless, of
>course, you like RESTOREing the entire FMID.
>
OTOH, doing ACCEPT kneecaps the possibility of a RESTORE to a point
earlier than that ACCEPT.  SMP/E strikes me as a half-hearted design.
A better design would permit RESTORE to any prior service level provided
the necessary elements remain in the GLOBAL zone.

Suppose you have two suspect PTFs,  A and B.  In order to tentatively
RESTORE B you must ACCEPT A.  If RESTORE B doesn't solve the problem
there's no posibility to RESTORE A.

I believe VMSES/E does better.  It has no analogue of ACCEPT.  VMFREMOV
simply re-installs needed components from the DELTA disk, the analog of
the GLOBAL zone.

-- gil

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

File transfer Red Alert

[Jousma, David]

Does anyone find this funny?   Comes today, with compliance date of tomorrow.

Anyway, I'm playing with the JAVA version of the utility.   First off, I'll 
point out that the download link for the .jar file downloads the file as a .zip 
file.   After uploading to my sandbox, I had to rename it to .jar.  Initial 
test is successful, the only issue I have is that by default it wants to look 
into filesystem for the files to upload.   I'm not smart enough, but is there 
syntax to have it pull traditional MVS dataset?  If not how would I copy an SVC 
dump into my filesystem without losing the necessary attributesdoc says 
TERSE ahead of time is not necessary.

//BPXS1 EXEC PGM=BPXBATCH,REGION=256M
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//*** use the current java environment
//STDENV DD *
PATH=/bin:/usr/sbin:/opt/fitb/java/Jre:.
//STDPARM DD *
SH java -classpath /home/myhome/ibmsdduu.jar ibmsdduu.cmd
-threads=4 -encrypt -compress
-server=testcase.boulder.ibm.com
-pmr -id=0.000.000
/test.txt
/*
_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

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




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

Re: VTL as 3490 vs 3590

[R.S.]

W dniu 2018-05-23 o 08:19, Brian Westerman pisze:

Except that now you can merely transmit the data to any other server to have it 
offsite.  Having gone through all of the various gyrations over the years of 
trying to come up with ways to get the tapes off site, from paying a company to 
cart them away to the caves to transmitting tape-to-tape at another location, 
trasmitting the data from the back end to another server is (in my opinion) 
much easier.

Yes ...and no.
For regular process yes. Assuming you have to send huge amount of data 
to "foreign" company  - it can be easier to send (encrypted) cart. Last, 
but not least - installation material is an example when we do not care 
to much about data secrecy, but "external media" is something we like.
Of course my example was just to show we lost some functionality with 
lack of support of native tapes.


Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory?

[Peter Relson]

I believe that the rules for whether BPX1LOD brings a module into writable 
memory are the same as for whether the LOAD service does.
It primarily has to do with the module attributes (is it reentrant?) and 
the APF authorization of the job step.

Peter Relson
z/OS Core Technology Design


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

Re: VTL as 3490 vs 3590

[Brian Fraser]

And safer, especially in areas where there are regulators that get very
cranky if a tape goes missing during transit.

On Wed, May 23, 2018 at 2:19 PM, Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> Except that now you can merely transmit the data to any other server to
> have it offsite.  Having gone through all of the various gyrations over the
> years of trying to come up with ways to get the tapes off site, from paying
> a company to cart them away to the caves to transmitting tape-to-tape at
> another location, trasmitting the data from the back end to another server
> is (in my opinion) much easier.
>
> Brian
>
> --
> 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: VTL as 3490 vs 3590

[Parwez Hamid]

3215 support is a FUNCTION of CHPID = OSC and has been around since 2008. It 
requires the OSA-1000BASE-T feature and main users are z/TPF customers.

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

Re: Replaceing IEBGENER

[Gadi Ben-Avi]

FastGener does other things besides just replacing IEBGENER.
It's a system we inherited, so at this stage we do not have a choice.

Gadi


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Wednesday, May 23, 2018 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Replaceing IEBGENER

Thank you for the explanation. I googled FASTGENER (not FASTGENR) and did not 
find proper link ;-)

Another question: Gadi, you wrote you have DFSort - does it make any sens to 
purchase another GENER when you have ICEGENER?
Is FASTGENR better than ICEGENER?

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-05-23 o 06:27, Gadi Ben-Avi pisze:
> FastGener is from SEA (https://seasoft.com/)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> R.S.
> Sent: Tuesday, May 22, 2018 10:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Replaceing IEBGENER
>
> Just curious: which company delivers FASTGENER?
>
> I know ICEGENER (IBM) and SYNCGENER (Syncsort), but don't know FASTGENER.
> Are ther more "GENERS"?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> ==
>
>
>


==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


--
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: VTL as 3490 vs 3590

[R.S.]

"...and my car has 4 beautiful wheels including spare one"
(sales pitch in tire workshop)

--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: Replaceing IEBGENER

[R.S.]

Thank you for the explanation. I googled FASTGENER (not FASTGENR) and 
did not find proper link ;-)


Another question: Gadi, you wrote you have DFSort - does it make any 
sens to purchase another GENER when you have ICEGENER?

Is FASTGENR better than ICEGENER?

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-05-23 o 06:27, Gadi Ben-Avi pisze:

FastGener is from SEA (https://seasoft.com/)


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Tuesday, May 22, 2018 10:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Replaceing IEBGENER

Just curious: which company delivers FASTGENER?

I know ICEGENER (IBM) and SYNCGENER (Syncsort), but don't know FASTGENER.
Are ther more "GENERS"?

--
Radoslaw Skorupka
Lodz, Poland




==






==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

AW: IP printing from JES2?

[Michael Knigge]

"Priced attractively" means that it is part of Communications Server (which is 
part of z/OS) but is not "free"? There is an additional fee?

Thank you,
Michael


Mit freundlichen Grüßen

Michael Knigge
Software Engineer

SET GmbH
Lister Straße 15
30163 Hannover

phone: +49 511 39780-23
fax: +49 511 39780-65

www.set.de
michael.kni...@set.de

Handelsregister: HRB52778 Amtsgericht Hannover
Geschäftsführer: Till Dammermann, Dr. Bernd Huber

Weitere Informationen finden Sie auf unserer Homepage...
-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Dana Mitchell
Gesendet: Dienstag, 22. Mai 2018 18:29
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: IP printing from JES2?

We have been using NPF for quite a while.  Setup is sort of non-intuitave, but 
we have a very small number of printers,  once setup it just works and doesn't 
need much attention.  Priced attractively.

Dana

On Tue, 22 May 2018 10:07:42 -0400, Tony Thigpen  wrote:

>We are going to look at IP NETWORK PRINT FACILITY since it is part of
>Communications Server.
>
>Tony Thigpen
>

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