"Can you use HTTPS with RECEIVE ORDER? Or is this FTPS only?" Although my previous post suggested using FTP to pull the year's-worth HOLDDATA file and re-RECEIVE it to all global zones, we employ RECEIVE ORDER to pull actual PTF data. We do this with HTTPS because we cannot use FTPS. (Long story.) So yes, I can verify that this works.
. . 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 Mark Pace Sent: Tuesday, March 05, 2019 8:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SMPE Internet Service Retrieval: TRANSFERONLY I'm still using the old way of FTPing the HOLDDATA every week. And I use HTTPS to download maintenance from SHOPZ. Can you use HTTPS with RECEIVE ORDER? Or is this FTPS only? On Tue, Mar 5, 2019 at 9:32 AM Kurt Quackenbush <ku...@us.ibm.com> wrote: > On 3/4/2019 4:33 PM, Smith, Sean M wrote: > > "Have you tried the TRANSFERONLY once, followed by RECEIVE FROMNTS > > for each CSI?" > > > > My job is automated and as such I would need to capture the > > execution of the first step to get the order number to dynamically > > create the second step with the RECEIVE FROMNTS ORDER(xxxxxx) > > Sort'a. You'd have to scrape the output from the RECEIVE ORDER to > capture the generated subdirectory name, then do the following for the > other global zones: > > RECEIVE FROMNTS('ORD00001-05March2019-08.57.58') > > > Hence my question about redirecting or managing a referback. The > > process makes sense it just doesn't seem to lend itself to any sort > > of automation and with 22 GLOBAL CSI's to order and receive into it > > is ripe for transmission or wait time outs. > > This may be blasphemous, but have you considered using a single, or > maybe fewer, global zones? Maybe even just for your daily receive of > the HOLDDATA and running all of your reports. More global zones are > not always necessary or helpful. > > Kurt Quackenbush -- IBM, SMP/E Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
