Re: [External] : Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I actually traveled to Japan to work on an Amdahl machine installed there. We visited the factory where the base machines were built and then sent to Amdahl for their modifications. My time at Amdahl was fantastic. Best technology (PERIOD) and some of the best people I ever worked with. We pushed like crazy to have Fujitsu move from 31-bit to 64-bit and keep competing with the new CMOS machines. However, FJs fascination with high-end unix ended that dream. I left Amdahl/Fujitsu America after a small amount of time working on the unit stuff. Jon Nolting System Administrator Engineering IT jon.nolt...@oracle.com 425-295-1733 (Cell) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Monday, July 31, 2023 4:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] : Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives On Mon, 31 Jul 2023 16:29:22 -0400, Steve Thompson wrote: >Fujitsu did not "buy" Amdahl machines, Phil didn't say that Fujitsu bought Amdahl machines. He said that they bought Amdahl. This is true. >Fujitsu supplied Amdahl with their machines I worked for Amdahl too, from 1978 to 1984. I started as a field Systems Engineer, often finding and occasionally fixing bugs in MVS. When MVS abended on an Amdahl machine, IBM would take the position that it must be the hardware, unless the customer could reproduce it in an IBM machine.Then I cross-trained to hardware, then an SE Specialist. During that time frame, Fujitsu did not supply Amdahl with their machines. Amdahl designed and built their own machines. IIRC Amdahl designed the chips. I don't remember who fabricated the chips, but it might have been Fujitsu. Probably other components were supplied by Fujitsu as well. >with the MODs we (yeah, I worked for Amdahl >prior to 1990) asked for/needed, and then for instructions we >didn't have micro-store for, Micro-store? There was no micro-store on the 470 or 580 (5850,5860, 5870 and 5880) systems. All instructions were implemented entirely in hardware. On the 470 series, that caused Amdahl to be at a disadvantage when IBM added new instructions. Instead, Amdahl used software emulation for the new instructions. The first of these was MVS/SE Assist, an enhancement to the Program Interruption First-Level Interrupt Handler. It would detect the PIC 1 and emulate the instruction in software if it was something that it handled. The 580 had a radical new design. During a three month stint at headquarters, I worked with the 580 console project and I had my own, numbered and registered copy of the ALTA Principles of operation. Among other things, it defined a mechanism to permit another level of virtualization, allowing 4 Domains to be defined and mapping System storage to domain storage. Sometimes I wish I had "forgotten" to return it when I left... To manage it, there was a new state, System state, in addition to Problem and Supervisor state. System state registers registers for use only when in System state. Special System state instructions to do things like moving data between the normal registers and the system state registers. The design included 31 or 32 bit memory (I forget which) and a much improved channel subsystem. When 370/XA came out a year or two later, I looked in the XA POO for anything that didn't more or less fit in the ALTA design and didn't find anything. Macrocode ran in System state IIRC it was loaded into System storage by the console processor. The console on the 580 was a separate 370 processor on one MCC that ran the UTS flavor of Unix. That was my first exposure to Unix. Macrocode mapped System storage to domain storage and system channels to domain channels. All interruptions went through Macrocode. New instructions could be simulated by Macrocode >we used FAM (Fast Assist Mode) which >we then emulated instructions (part of MacroCode). > ... > >And I still think my time at Amdahl was the best job and >education in machine hardware I could have ever had for the short >time I was there. Same here. And the training was top notch. -- 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] : Flashcopy dataset example
We use something like this when the virtual address will changed. We also put these commands into execs flashcopy a246 0 end to b246 0 end flashcopy a246 0 end to b246 0 end label SGB246 Jon Nolting System Administrator Engineering IT jon.nolt...@oracle.com 425-295-1733 (Cell) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Friday, February 17, 2023 8:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] : Flashcopy dataset example Can anyone provide an example on how to use flashcopy to copy, or backup, an individual dataset? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] : Re: DISPLAY VTAM commands from TSO CONSOLE
I found with VTAM messages output, there were 2x messages that were provided.
The first provided the command accepted. The 2nd message, in this case, had 22
lines seen below in the REXX trace. I've always been forced to this 2x message
response for VTAM.
/* Rexx */
trace r
'consprof soldisplay(no) unsoldisplay(no)'
'console activate name(nolting)'
address console
"D NET,ID=TCP00015"
do loop = 1 to 2
x = getmsg('cmsg.','either',,,10)
if rc = 0 then
do i = 1 to cmsg.0
say '+++' cmsg.i
end
end
address tso
'console deactivate'
SDSF OUTPUT DISPLAY TSOBAT03 JOB35268 DSID 102 LINE 1 COLUMNS 02- 133
COMMAND INPUT ===>SCROLL ===> CSR
READY
%console1
4 *-* 'consprof soldisplay(no) unsoldisplay(no)'
>>> "consprof soldisplay(no) unsoldisplay(no)"
5 *-* 'console activate name(nolting)'
>>> "console activate name(nolting)"
6 *-* address console
8 *-* "D NET,ID=TCP00015"
>>> "D NET,ID=TCP00015"
9 *-* do loop = 1 to 2
>>> "1"
>>> "2"
10 *-* x = getmsg('cmsg.','either',,,10)
>>>"0"
11 *-* if rc = 0
>>>"1"
*-* then
12 *-* do i = 1 to cmsg.0
>>> "1"
>>> "1"
13 *-*say '+++' cmsg.i
>>> "+++ IST097I DISPLAY ACCEPTED"
+++ IST097I DISPLAY ACCEPTED
14 *-* end
12 *-* do i = 1 to cmsg.0
15 *-* end
9 *-* do loop = 1 to 2
10 *-* x = getmsg('cmsg.','either',,,10)
>>>"0"
11 *-* if rc = 0
>>>"1"
*-* then
12 *-* do i = 1 to cmsg.0
>>> "1"
>>> "22"
13 *-*say '+++' cmsg.i
>>> "+++ IST075I NAME = NETA.TCP00015, TYPE = APPL"
+++ IST075I NAME = NETA.TCP00015, TYPE = APPL
14 *-* end
Jon Nolting
System Administrator
Engineering IT
jon.nolt...@oracle.com
425-295-1733 (Cell)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Sims
Sent: Wednesday, May 5, 2021 1:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] : Re: DISPLAY VTAM commands from TSO CONSOLE
I've tried this (2 minute delay):
netcmd = 'DISPLAY NET,E,ID=' || vtamlu
if test = 'TEST' then say 'Command:' netcmd
"CONSOLE SYSCMD(" netcmd ") CART(VTAM)"
msg = getmsg(netresp.,'either','VTAM',,120)
And this:
"CONSOLE SYSCMD(" netcmd ") CART(VPSC0002)"
msg = getmsg(netresp.,'SOL',VPSC ,''X,120)
both with 'SOL' and 'either," no difference, only one line returned.
This exec issues three system commands, one to derive the VTAM LU from
VPS, the second, above, to derive the IP address from VTAM, and then the
third to display from TCPIP NETSTAT the status of the printer. It never
gets to command #3.
Thanks,
/Tom
On 5/5/2021 12:07 PM, Charles Mills wrote:
> Can you post your code with CART and a two-second delay?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Sims
> Sent: Wednesday, May 5, 2021 11:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DISPLAY VTAM commands from TSO CONSOLE
>
> Thanks, I've tried with/without CART, as well as waiting up to 2 minutes
> for responses, with no change in the dreary outcome.
>
> /Tom
>
> On 5/5/2021 11:16 AM, Seymour J Metz wrote:
>> Program in a delay.. I'd also suggest using a CART.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!GqivPVa7Brio!MOBXBK9b0ffHBqazXo-IYbec0z96Lc4feclihM09EMd6rW8_9LAjKieTVmEpTapWVQ$
>>
>>
>>
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
>> Tom Sims [trs...@att.net]
>> Sent: Wednesday, May 5, 2021 2:10 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: DISPLAY VTAM commands from TSO CONSOLE
>>
>> I am having difficulty obtaining predictable and repeatable results from
>> DISPLAY VTAM commands in TSO CONSOLE.
>>
>> In all cases, the first response is returned, e.g., for processing via
>> getmsg():
>>
>> 10:06:05.30 SYSTVPSC 0290 DISPLAY NET,ID=SYSTP011
>> 10:06:05.31 SYSTVPSC 0090 IST097I DISPLAY ACCEPTED
>>
>> All too often, though, the subsequent detail display is not, and
>> getmsg() returns, e.g., by msgresp.0 a number of lines=1 and nothing
>&g
Re: Unable to VARY ONLINE DASD after SAN power outage
This could be the storage unit went into R/O mode to protect the existing data. We’ve had that happen on similar old storage devices. See if you can check the storage HMC which might reflect the condition. We had to “fix” whatever caused this protective condition allowing R/W access. Good luck Sent from my iPhone > On Aug 2, 2020, at 10:08 AM, Christian Svensson > <022ad63487ef-dmarc-requ...@listserv.ua.edu> wrote: > > Hi, > > I have an old DS6800 running alongside my z114. Due to a power outage the > SAN was shut down uncleanly and > while it does not appear to indicate any failures in its logs or status > displays, I'm having issues trying to IPL my LPARs from it. > > To try to debug this issue I loaded a z/VM installation DVD and had a look > at the devices. > To reduce the number of potential error sources, I created a new CKD volume > at 03F1 in the DS6800. > When I try to vary this device online I get: > > vary online 03f1 > 12:59:33 HCPERP794E DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME > 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33 > HCPERP794E DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME > 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33 > HCPERP6306I DASD 03F1 AN EQUIPMENT CHECK WITH PERMANENT ERROR > 12:59:33 HCPERP6306I OCCURRED > 12:59:33 HCPERP6300I SENSE DATA FORMAT = 0F MSG CODE = 0C > 12:59:33 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = 63 > 12:59:33 HCPERP6302I SEEK ADDRESS = > 12:59:33 HCPERP6303I SENSE = 1090 F1FC 0800 0004 230002CB > 12:59:33 HCPERP6303I 0004F908 4082 0C00 > 12:59:33 HCPERP6304I IRB = 01C04417 7FF0B010 0210 0080 > 12:59:33 HCPERP6305I USERID = SYSTEM > 12:59:33 HCPERP2216I CHANNEL PATH ID = F5 > 12:59:33 HCPERP2220I PHYSICAL CHANNEL PATH ID = 011D12:59:33 HCPERP794E > DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME > 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33 > HCPERP794E DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME > 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33 > HCPERP6306I DASD 03F1 AN EQUIPMENT CHECK WITH PERMANENT ERROR > 12:59:33 HCPERP6306I OCCURRED > 12:59:33 HCPERP6300I SENSE DATA FORMAT = 0F MSG CODE = 0C > 12:59:33 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = 27 > 12:59:33 HCPERP6302I SEEK ADDRESS = > 12:59:33 HCPERP6303I SENSE = 1090 F1FC 0800 0004 230002CB > 12:59:33 HCPERP6303I 0004F908 4082 0C00 > 12:59:33 HCPERP6304I IRB = 00C04017 7FE95E50 0E00 0080 > 12:59:33 HCPERP6305I USERID = SYSTEM > 12:59:33 HCPERP2216I CHANNEL PATH ID = F5 > 12:59:33 HCPERP2220I PHYSICAL CHANNEL PATH ID = 011D > 12:59:33 HCPCRC8083I EREP record threshold has been exceeded for userid > OPEREREP. Currently 0006 records are enqueued. > 12:59:33 HCPCPN6277I Device 03F1 cannot be varied online because I/O errors > occurred. > 12:59:33 1 device(s) specified; 0 device(s) successfully varied online > Ready(06277); T=0.01/0.01 > > This error is presented on the few other devices I've tried to vary online. > > Any suggestions of things to try? Worst come to worst I'll power everything > off and do a cold boot. > This is all a hobbyist setup so no IBM maintenance contract on anything I'm > afraid :-). > > Thanks, > > -- > 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: pasearch ends with an error "papi.dll not found"
NP. I was using USS tcsh thus the syntax that didn't work for you. Jon Nolting System Administrator Engineering IT jon.nolt...@oracle.com 425-295-1733 (Cell) -Original Message- From: ITschak Mugzach [mailto:imugz...@gmail.com] Sent: Monday, April 6, 2020 11:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: pasearch ends with an error "papi.dll not found" I followed Jon solution. got setenv command not found. However, export LIBPATH= solved the problem. Tx Jon. ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM comming son * On Mon, Apr 6, 2020 at 9:48 PM Jon Nolting wrote: > I get this on z/OS 2.3. > > /u/tec1002# setenv LIBPATH /usr/lpp/tcpip/lib > /u/tec1002# pasearch -a Secure_Ftpd_Debug | head -10 > > TCP/IP pasearch CS V2R3 Image Name: TCPIP > Date: 04/06/2020Time: 11:45:09 > TTLS Instance Id: 1584209313 > > TTLS Action: grp_Production > Version:3 > Status: Active > Scope: Group > TTLSEnabled: On > SYSE23:/u/tec1002# > > > Jon Nolting > System Administrator > Engineering IT > > jon.nolt...@oracle.com > 425-295-1733 (Cell) > > -Original Message- > From: ITschak Mugzach [mailto:imugz...@gmail.com] > Sent: Monday, April 6, 2020 10:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: pasearch ends with an error "papi.dll not found" > > While querying PAGENT (pasearch -t) I get the following error msgs. > papi.dll is in search path and is APF authorized. Any idea? > > ITschak > > # pasearch -t > > CEE3501S The module papi.dll was not found. > > From entry point paInitPapi at compile unit offset +00A6 at > entry o > ffset +00A6 at address 1F840F96. > > Ý1¨ + Done(137) pasearch -t > > 16843856 Killed /bin/pasearch > > # > > ITschak Mugzach > *|** IronSphere Platform* *|* *Information Security Continuous Monitoring > for z/OS, x/Linux & IBM I **| z/VM comming son * > > -- > 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: pasearch ends with an error "papi.dll not found"
I get this on z/OS 2.3. /u/tec1002# setenv LIBPATH /usr/lpp/tcpip/lib /u/tec1002# pasearch -a Secure_Ftpd_Debug | head -10 TCP/IP pasearch CS V2R3 Image Name: TCPIP Date: 04/06/2020Time: 11:45:09 TTLS Instance Id: 1584209313 TTLS Action: grp_Production Version:3 Status: Active Scope: Group TTLSEnabled:On SYSE23:/u/tec1002# Jon Nolting System Administrator Engineering IT jon.nolt...@oracle.com 425-295-1733 (Cell) -Original Message- From: ITschak Mugzach [mailto:imugz...@gmail.com] Sent: Monday, April 6, 2020 10:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: pasearch ends with an error "papi.dll not found" While querying PAGENT (pasearch -t) I get the following error msgs. papi.dll is in search path and is APF authorized. Any idea? ITschak # pasearch -t CEE3501S The module papi.dll was not found. From entry point paInitPapi at compile unit offset +00A6 at entry o ffset +00A6 at address 1F840F96. Ý1¨ + Done(137) pasearch -t 16843856 Killed /bin/pasearch # ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM comming son * -- 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: Principles of Operation
While at Amdahl, I used PoO as well. Jon Nolting System Administrator Engineering IT jon.nolt...@oracle.com 425-295-1733 (Cell) -Original Message- From: ste...@copper.net [mailto:ste...@copper.net] Sent: Sunday, September 22, 2019 8:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Principles of Operation Back in college, it was referred to as the PoO. After the other postings about Amdahl v IBM, I have to laugh because the whole computer department in college was fiercely IBM oriented. And they felt that the IBM mainframe competitors were dishonest (theological problem with a church owned college). I prefer Pop, but I too worked at Amdahl (Macrocode) and I went with the flow. I’ve also worked for IBM. So it has been interesting. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how many OSes run on IBMz
As mentioned, I would also add CFCC which is a very specific OS as well as KVM Jon Nolting System Administrator Engineering IT jon.nolt...@oracle.com 425-295-1733 (Cell) -Original Message- From: John McKown [mailto:john.archie.mck...@gmail.com] Sent: Thursday, January 24, 2019 6:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: how many OSes run on IBMz On Thu, Jan 24, 2019 at 7:44 AM Parwez Hamid wrote: > All depends whether you are asking about 'current' Z systems or the > older ones. > I was thinking just current systems, not historical. And "main line" from IBM itself: z/OS, z/VSE, z/VM, z/TPF(?), z/Linux. I am thinking of currently supported OSes which will IPL "stand alone" in an LPAR, so that excludes OSes which only run as a guest in z/VM, such as CMS. > > You can add the following: > > KVM > Hitachi’s operating system, VOS > > -- I just burned 2000 calories! That's the last time I'll nap with brownies in the oven. 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: how many OSes run on IBMz
KVM? Jon Nolting System Administrator Engineering IT jon.nolt...@oracle.com 425-295-1733 (Cell) -Original Message- From: Gadi Ben-Avi [mailto:gad...@malam.com] Sent: Thursday, January 24, 2019 4:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: how many OSes run on IBMz You forgot z/VM -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Thursday, January 24, 2019 2:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: how many OSes run on IBMz This is mainly a curiosity question. I know of: z/OS, z/VSE, z/TPF, and z/Linux. Are there any others? OK, the real reason I'm asking is to be a bit weird in a game that I play. It is "No Man's Sky",which is a space exploration game. When you discover a new star system or planet, you can rename it. So I plan to find a star with "n" planets, where "n" is the number of OSes which run on the IBMz platform. I will name the star IBMz, and the planets after the OSes. If there are any moons around a planet, I will try to name them after some major subsystem which runs on the OS with that name, such as JES2 or POWER or RSCS. -- I just burned 2000 calories! That's the last time I'll nap with brownies in the oven. 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: File transfer Red Alert
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
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.
Re: File transfer Red Alert
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
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
