Re: z/OS Cross-memory server code walkthrough
On 2020-03-02 10:08 AM, Paul Gilmartin wrote: On Sun, 1 Mar 2020 08:11:19 -0600, Support, DUNNIT SYSTEMS LTD. wrote: OK, let me rephrase my question: I see that the files are most likely in EBCDIC and just need a binary transfer to z/OS. Is that correct? It's EBCDIC, but beware: the line breaks are x'25' rather than the perplexing x'15' that z/OS expects. It's not EBCDIC by the time it's pushed to Github! The working tree may have been EBCDIC but but Rockets git port will perform code page conversion using the settings in .gitattributes. IIRC, git-encoding is fixed at ISO8859-1 https://github.com/rscott-rocket/mxe/blob/master/.gitattributes Line endings are handled automatically or explicitly using configuration. https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings If so, I notice all the files have extension names on them, after the member name. Is there an easy way to transfer these to a PDS or do the extension names get in the way, due to 8-character member name conventions? Thanks again. Transfer the .zip in binary; unzip with "jar". The files will be extracted to z/OS UNIX directory which is friendly to extension names. HLASM ought to learn to deal with extensions. Most cross-assemblers can do so. The first 4 commands in README.md merely say "Copy". This is pretty vague. The x'25' linebreaks lead me to suspect the developers built and tested from an ASCII tree with a cross-assembler then converted to EBCDIC using a non-z tool that was unaware of the idiosyncratic z/OS line separator convention. -- 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: z/OS Cross-memory server code walkthrough
> the perplexing x'15' that z/OS expects. EBCDIC '15'X is NL, a perfectly reasonable end-of-line character. Eunix uses LF for that purpose, rather than CRLF, which is less reasonable. EBCDIC '0D'X is CR and '25'X is LF. I hate ASCII! > HLASM ought to learn to deal with extensions. In member names? -- 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: Sunday, March 1, 2020 9:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS Cross-memory server code walkthrough On Sun, 1 Mar 2020 08:11:19 -0600, Support, DUNNIT SYSTEMS LTD. wrote: >OK, let me rephrase my question: > >I see that the files are most likely in EBCDIC and just need a binary transfer >to z/OS. Is that correct? > It's EBCDIC, but beware: the line breaks are x'25' rather than the perplexing x'15' that z/OS expects. >If so, I notice all the files have extension names on them, after the member >name. Is there an easy way to transfer these to a PDS or do the extension >names get in the way, due to 8-character member name conventions? Thanks again. > Transfer the .zip in binary; unzip with "jar". The files will be extracted to z/OS UNIX directory which is friendly to extension names. HLASM ought to learn to deal with extensions. Most cross-assemblers can do so. The first 4 commands in README.md merely say "Copy". This is pretty vague. The x'25' linebreaks lead me to suspect the developers built and tested from an ASCII tree with a cross-assembler then converted to EBCDIC using a non-z tool that was unaware of the idiosyncratic z/OS line separator convention. -- 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: DF/EF andd DFP the IBM predecessor was Re: OT Boeing flight software
My first job as a system programmer was at a company that attempted to put DF/EF into production. It was quickly pulled out. And no, there was no test/QA environment. All they had was a 370/168, with 8MB of main storage. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Saturday, February 29, 2020 9:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DF/EF andd DFP the IBM predecessor was Re: OT Boeing flight software [External Email. Exercise caution when clicking links or opening attachments.] I don't recall any problems with DFP, but I counted myself blessed that I never installed DF/EF. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Clark Morris [cfmt...@uniserve.com] Sent: Friday, February 28, 2020 7:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DF/EF andd DFP the IBM predecessor was Re: OT Boeing flight software [Default] On 28 Feb 2020 07:24:20 -0800, in bit.listserv.ibm-main idfli...@gmail.com (scott Ford) wrote: >Mike, > >Reminds me of this whole Agile process that's being used. Incomplete >thinking, not like a lot of old timer Sysprogs, who had to think about >, installation, testing, implementation in production, impact on users >and backup. DF/EF comes to mind and Jamie Yates of IBM describing a situation of clients calling with a SEV 1 problem when they didn't have one because they would by the time they got a call back. After installing DFP, my feeling at the time that DFP stood for Damn Fragile Product, a sentiment at least some of my compatriots at SHARE agreed with. The PE chains were something else. Clark Morris > >Boeing sounds piecemeal .. > >Scott > >On Fri, Feb 28, 2020 at 6:42 AM Ray Pearce wrote: > >> Orlando Sentinel says: >> >> Unfortunately, our website is currently unavailable in most European >> countries. We are engaged on the issue and committed to looking at >> options that support our full range of digital offerings to the EU >> market. We continue to identify technical compliance solutions that >> will provide all readers with our award-winning journalism. >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Mike Schwab >> Sent: 28 February 2020 02:19 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: OT Boeing flight software >> >> >> https://www.orlandosentinel.com/space/os-bz-boeing-safety-commercial- >> crew-20200226-bgvthodnjzgmlc36hsxcaopahu-story.html >> >> Boeing didn't perform full end-to-end test of its astronaut capsule >> before troubled mission, 'surprising' NASA safety panel. >> >> Critically, the panel learned early this month that Boeing did not >> perform a full, end-to-end integrated test of Starliner in a Systems >> Integration Lab with ULA's Atlas V rocket. The test typically shows >> how all the software systems during each component of the mission >> would have responded with each other through every maneuver - and it >> could potentially have caught the issues Boeing later experienced in >> the mission. >> >> "It's pretty exhaustive. You gotta do that," said Christopher >> Saindon, a former member who ended his tenure on the panel in mid-February. >> "That was somewhat surprising to us on the panel. There were >> certainly gaps in the test protocol." >> >> >> It was software that ultimately did fail Boeing when it flew >> Starliner on a Dec. 20 mission intended to dock with the >> International Space Station. The capsule's internal clock was 11 >> hours ahead, causing it to miss critical maneuvers and fly into the >> incorrect orbit. Then, communication issues potentially caused by >> cell towers in the area blocked Boeing from sending a command to >> rectify the orbit. Starliner, the company determined, wasn't going to >> be able to reach the space station. >> >> But in the process of bringing it back down and re-checking its >> software, the company caught yet another issue that could have caused >> Starliner to collide with its service module when the two separated >> prior to the capsule's return to Earth. Teams were able to correct >> the issue before to the capsule's return on Dec. 22, but the >> multitude of problems have led NASA to call for a full >> re-verification of Boeing's software - a process that will take >> analyzing about a million lines of code. >> >> Software issues are also plaguing another arm of Boeing, which is >> dealing with the fall out of problems with its 737 Max airplanes that >> led to the deaths of 346 people and has grounded the planes. >> >> >> -- >> Mike A Schwab, Springfield IL USA >> Where do Forest Rangers go to get away from it all? >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the
Re: z/OS Cross-memory server code walkthrough
On Sun, 1 Mar 2020 08:11:19 -0600, Support, DUNNIT SYSTEMS LTD. wrote: >OK, let me rephrase my question: > >I see that the files are most likely in EBCDIC and just need a binary transfer >to z/OS. Is that correct? > It's EBCDIC, but beware: the line breaks are x'25' rather than the perplexing x'15' that z/OS expects. >If so, I notice all the files have extension names on them, after the member >name. Is there an easy way to transfer these to a PDS or do the extension >names get in the way, due to 8-character member name conventions? Thanks again. > Transfer the .zip in binary; unzip with "jar". The files will be extracted to z/OS UNIX directory which is friendly to extension names. HLASM ought to learn to deal with extensions. Most cross-assemblers can do so. The first 4 commands in README.md merely say "Copy". This is pretty vague. The x'25' linebreaks lead me to suspect the developers built and tested from an ASCII tree with a cross-assembler then converted to EBCDIC using a non-z tool that was unaware of the idiosyncratic z/OS line separator convention. -- 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 Cross-memory server code walkthrough
Sorry. I used your question to ask my own. I would zip the repo up Binary transfer it to z/os Unzip it The convert fro utf8 to 1047 Matt Hogstrom +1 (919) 656-0564 > On Mar 1, 2020, at 09:11, Support, DUNNIT SYSTEMS LTD. > wrote: > > OK, let me rephrase my question: > > I see that the files are most likely in EBCDIC and just need a binary > transfer to z/OS. Is that correct? > > If so, I notice all the files have extension names on them, after the member > name. Is there an easy way to transfer these to a PDS or do the extension > names get in the way, due to 8-character member name conventions? Thanks > again. > > -- > 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: Phones (was -- OT)
Sounds like when I lived and worked in Lausanne , Switzerland. PTT bills for the month were very expense. Felt like you had to mortgage a house to pay for it. It was the International calls that were expense. On Sat, Feb 29, 2020 at 8:39 PM Wayne Bickerdike wrote: > Gil, > > I was working in Indonesia and the only way to call home was from the > Wartel (Warung Telekomunikasi) ie Phone shop. > > They allocate a phone booth and you give them the number to dial. It has an > electronic display showing the rolling cost. It was around $5 a minute back > in 1993. My boss gave me a Telstra phone card and the 1800 number overseas > needed an account number which was # delimited followed by a # delimited > pin number. That's why the sneaky mofos disabled the # key, however, tone > diallers still worked. > > > > On Sun, Mar 1, 2020 at 8:27 AM Paul Gilmartin < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > On Sun, 1 Mar 2020 08:00:44 +1100, Wayne Bickerdike wrote: > > >... > > >I have had to resort to tone dialers in Indonesia to use a phone > > >card because they disable the # key . Their phone systems were largely > > >owned by kleptocrats who realised that phone cards would bypass their > > >exorbitant phone call charges. > > > > > In the U.S. there existed services one could call via a (free) 800 > > number (no #, IIRC); enter a card number, then target number > > to bypass exorbitant AT charges. AT retaliated by reversing > > DC polarity after initial connection so tone generator wouldn't > > work. FCC prohibited disabling those third party services. AT > > acquiesced by agreeing to install bridge rectifiers on request, > > *only* in Western Electric (AT partner) phones. Customers with > > third-party hardware were left to seek relief from their vendors. > > Kleptocrats. Think of 1959 consent decree. > > > > -- gil > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > Wayne V. Bickerdike > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Interesting IBM chip collection
Thanks! A home museum! On 2/29/2020 11:54 PM, Andrew Armstrong wrote: Have a look at: https://youtu.be/C0upso-RGF8 ...I didn't realise (had no way of knowing really) that the IBM multi chip modules were so colorful. -- 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 Cross-memory server code walkthrough
Rob, Thanks for sharing the code. I didn’t see a license file in the repo and at least in the source files I checked there was no copyright or license. Did you intend this to be a BSD / Apache style license ? Who owns the copyright, I assume you or is it owned by Rocket? Just curious if I wanted to pick up some of the code for use so that I understand the IP and Copyright requirements. Matt Hogstrom PGP key 0F143BC1 > On Mar 1, 2020, at 07:56, Support, DUNNIT SYSTEMS LTD. > wrote: > > Hi Rob, > > I see that the code is up on GITHUB: > > https://github.com/rscott-rocket/mxe > > I am brand new to GITHUB. Is there a link which tells me what format the > files contained in the downloaded ZIP file are in and/or what to use to > transfer them to z/OS? > > Thanks for your contribution and your assistance. > > -- > 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 Cross-memory server code walkthrough
OK, let me rephrase my question: I see that the files are most likely in EBCDIC and just need a binary transfer to z/OS. Is that correct? If so, I notice all the files have extension names on them, after the member name. Is there an easy way to transfer these to a PDS or do the extension names get in the way, due to 8-character member name conventions? Thanks again. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS Cross-memory server code walkthrough
Hi Rob, I see that the code is up on GITHUB: https://github.com/rscott-rocket/mxe I am brand new to GITHUB. Is there a link which tells me what format the files contained in the downloaded ZIP file are in and/or what to use to transfer them to z/OS? Thanks for your contribution and your assistance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
