IBM Mainframe and z/OS
Hello everyone, Does anyone know how I could gain hands-on experience on an IBM mainframe? This is a career path Id like to pursue - i.e. Websphere zOS consultant or CICS. I am currently a UoT student and was wondering how people gain experience -- r360design.ca -- r360design.ca
On 12/03/2017 10:33 PM, R360 Design INC via talk wrote:
Hello everyone,
Does anyone know how I could gain hands-on experience on an IBM mainframe? This is a career path Id like to pursue - i.e. Websphere zOS consultant or CICS. I am currently a UoT student and was wondering how people gain experience
Well, IBM systems run SUSE, if I'm not mistaken. You could start there for the software side. IIRC, IBM mainframes these days are simply massively multi-CPU., running Linux. I have a cousin, a nuclear physicist, who works with the big systems and I get the impression from him that it's largely the same as running a personal computer. I have no idea about Websphere zOS or CICS though. What does UoT have for big iron? I recall when I was at Ryerson, back in the '80s, they had an IBM mainframe.
On Sun, Dec 03, 2017 at 11:00:03PM -0500, James Knott via talk wrote:
Well, IBM systems run SUSE, if I'm not mistaken. You could start there for the software side. IIRC, IBM mainframes these days are simply massively multi-CPU., running Linux. I have a cousin, a nuclear physicist, who works with the big systems and I get the impression from him that it's largely the same as running a personal computer. I have no idea about Websphere zOS or CICS though. What does UoT have for big iron? I recall when I was at Ryerson, back in the '80s, they had an IBM mainframe.
No, they run zOS, and then in VMs you can run RHEL or SLES (or debian) if you want or one of the many other OSs that exist for it, or an emulator for a previous generation with whatever OS you want for that in the emulator going back to system/360 if you want. Not sure how many layers of emulation that would take, but it can be done. -- Len Sorensen
hey I thought I should let you know that "r360design.ca" doesn't work for me. Is that supposed to be a valid domain? David On Sun, Dec 3, 2017 at 10:33 PM, R360 Design INC via talk <talk@gtalug.org> wrote:
Hello everyone,
Does anyone know how I could gain hands-on experience on an IBM mainframe? This is a career path Id like to pursue - i.e. Websphere zOS consultant or CICS. I am currently a UoT student and was wondering how people gain experience
-- r360design.ca
-- r360design.ca
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Hello, You can join IBM partner world and get access to VMs running IBMs operating system for free. I used it a few years ago to test AIX and Active Directory integration https://www-356.ibm.com/partnerworld/wps/pub/systems/technical/hardware/linu... On Mon, Dec 4, 2017 at 12:44 AM David Thornton via talk <talk@gtalug.org> wrote:
hey I thought I should let you know that "r360design.ca" doesn't work for me.
Is that supposed to be a valid domain?
David
On Sun, Dec 3, 2017 at 10:33 PM, R360 Design INC via talk <talk@gtalug.org
wrote:
Hello everyone,
Does anyone know how I could gain hands-on experience on an IBM mainframe? This is a career path Id like to pursue - i.e. Websphere zOS consultant or CICS. I am currently a UoT student and was wondering how people gain experience
-- r360design.ca
-- r360design.ca
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
On Sun, Dec 03, 2017 at 10:33:20PM -0500, R360 Design INC via talk wrote:
Hello everyone,
Does anyone know how I could gain hands-on experience on an IBM mainframe? This is a career path Id like to pursue - i.e. Websphere zOS consultant or CICS. I am currently a UoT student and was wondering how people gain experience
I guess one could start playing around with http://www.hercules-390.org/ -- Len Sorensen
Greetings To R360,
From someone who worked as independent contract software engineer for 30 years, retiring early in the year 2002.
At that time major financial companies used large IBM mainframes extensively. They simply wouldn't trust anything else. The COBOL language often so disparaged by folks coming ftom the *nix world, was the robust application language backbone of much custom app code on IBM big iron. The IBM mainframes I worked in COBOL on had their own IBM proprietary operating systerms (e.g. MVS - multiple virtual systems). All was rock solid and performant. I did work for two large insurance companies. At one, the language was COBOL running on IBM's AIX *nix flavour on an IBM (RS-6000?) But as I understand, this COBOL application I worked on was was later migrated intact to an IBM mainframe running IBM's proprietary MVS OS The COBOL language has features making it a robust tool in the hands of "bricklayers" (programmers of varied skill and enthusiasm). The female U.S. Navy officer who invented COBOL knew what she was doing. I expect that there is still a large COBOL application code base (representing a large $ investment) in operation at these big companies. COBOL is a possible career path for someone young but who is also unafraid of jeers frm ignorant programmers from the net / *nix world. The old guard like me are all retired / ing in droves, and not enough new COBOL progammers are being produced by colleges and universities. There were (are?) some really great COBOL implementations out there. The name Micro Focus comes to mind. The MF COBOL on my Win XP PC proved to be rock solid and incredibly fast with a great debugger. * * * * * * You should research all this before making any commitment to a particular OS or application language. The advantage of starting your career with a big company (e.g. bank, insurance) is that they can manage their staff with a long-term view. They will invest in training you, and they provide a populaiton of competent staff to mentor you. I worked with many different programming languages over the years, and likely you will also. They are all just tools. Maybe that proprietary IBM OS layer I worked with has now all disappeared. But it would surprise mte to learn that our big banks are running their "inner jewels" type IT operations on open source LInux ... Regards,, Steve * * * Steve Petrie, P.Eng. Oakville, Ontario, Canada (905) 847-3253 apetrie@aspetrie.net ----- Original Message ----- From: R360 Design INC via talk To: talk@gtalug.org Sent: Sunday, December 03, 2017 10:33 PM Subject: [GTALUG] IBM Mainframe and z/OS Hello everyone, Does anyone know how I could gain hands-on experience on an IBM mainframe? This is a career path Id like to pursue - i.e. Websphere zOS consultant or CICS. I am currently a UoT student and was wondering how people gain experience -- r360design.ca -- r360design.ca ------------------------------------------------------------------------------ --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
On 12/04/2017 05:35 PM, Steve Petrie, P.Eng. via talk wrote:
The old guard like me are all retired / ing in droves, and not enough new COBOL progammers are being produced by colleges and universities. http://millennialmainframer.com/wp-content/uploads/2012/09/dilbertcobol1.jpg ;-)
When I was at American Airlines/Sabre, a goodly set of their crucial systems were running on TSO, on zSeries hardware (which tended to have other names at that time; 3090s and S/390s, I think; it was never clear to me what specific hardware I was ever connected to). There'd be a goodly mixture of the following technologies: - Lots of the software was written in COBOL - PL/1 was also used fairly heavily Storage would have a mixture mostly of three things: a) Raw storage, in the form of block-oriented files b) IMS databases c) DB2 databases The habit was to have code and storage pretty strictly disconnected; apps in PL/1 or COBOL would get attached to storage mostly via JCL scripts, and something that UNIX folk should find interesting about this is that many of the options of /usr/bin/dd correspond pretty directly to the shapes of commands in JCL. It's easy enough to find COBOL compilers to run on Linux; PL/1 is a mite more difficult. If you were to want to figure out how to write PL/1 code, I'd suggest looking into the SIMH Multics emulator; it runs a full PL/1 implementation (albeit in an MIT flavour that's a bit different from what IBM hawked). http://ringzero.wikidot.com/start I'm not sure that there are useful free implementations of equivalents to IMS or JCL. You'd not get a "free" implementation of DB2. I'm also not sure that "tooling around" with the bits of this that are available in 'gratis' form would make great preparation for using the real thing. The apps I got exposed to were all ones that integrated together the combination of (compiler + data storage + scripting) pretty tightly, and it doesn't seem to me that you can easily run enough "for free" to learn crucial lessons on how it works. Something crucial that would be missing would be database integration. The mapping of COBOL/PL/1 data structures onto SQL was a special sublanguage defined by IBM as extensions to those languages. That would also parallel that I'm not sure that playing with "libre" variants of APL would get you to a place where you'd be attractive to the (dwindling) shops that might still be deploying IBM APL2 or Dyalog APL software on mainframes. That said, if you did some "hacking away" with one of the J or K clones such as Kona (https://github.com/kevinlawler/kona.git), that might well be close enough to "real K" to be of interest to K shops (which do seem to exist). But J headed to ASCII; it's not EBCDIC.
On Dec 4, 2017 5:35 PM, "Steve Petrie, P.Eng. via talk" <talk@gtalug.org> wrote: *Greetings To R360,* From someone who worked as independent contract software engineer for 30 years, retiring early in the year 2002. At that time major financial companies used large IBM mainframes extensively. They simply wouldn't trust anything else. The COBOL language often so disparaged by folks coming ftom the *nix world, was the robust application language backbone of much custom app code on IBM big iron. The IBM mainframes I worked in COBOL on had their own IBM proprietary operating systerms (e.g. MVS - multiple virtual systems). All was rock solid and performant. I did work for two large insurance companies. At one, the language was COBOL running on IBM's AIX *nix flavour on an IBM (RS-6000?) But as I understand, this COBOL application I worked on was was later migrated intact to an IBM mainframe running IBM's proprietary MVS OS The COBOL language has features making it a robust tool in the hands of "bricklayers" (programmers of varied skill and enthusiasm). The female U.S. Navy officer who invented COBOL knew what she was doing. You must mean "Amazing Grace" Hopper. It's true she was in the wartime Naval Reserve, but prior to that she was a graduate of Yale and elsewhere in mathematics. Probably one of the most dedicated and inspired women of the traditional working man world of the day. Anecdotally, she was responsible for one very large hardware purchase for the Navy department. The hardware in question; bug screens for Windows .. ummm not the Microsoft kind. IIRC here's the quote from https://en.m.wikipedia.org/wiki/Grace_Hopper While she was working on a Mark II Computer at a US Navy research lab in Dahlgren, Virginia in 1947, her associates discovered a moth that was stuck in a relay; the moth impeded the operation of the relay. While neither Hopper nor her crew mentioned the phrase "debugging" in their logs, the case was held as an instance of literal "debugging." For many years, the term bug had been in use in engineering.[35][36] The remains of the moth can be found in the group's log book at the Smithsonian Institution's National Museum of American History in Washington, D.C. I think I read the exact stuff about the screen purchase in someone else's wartime memoir but the wiki covers her astounding career accomplishments in good detail. Her compiler, her proposed English language program which became COBOL and the proposition of distributed networks of small computers. All very hard sells at the time of the mindset of, computers do arithmetic. I expect that there is still a large COBOL application code base (representing a large $ investment) in operation at these big companies. COBOL is a possible career path for someone young but who is also unafraid of jeers frm ignorant programmers from the net / *nix world. The old guard like me are all retired / ing in droves, and not enough new COBOL progammers are being produced by colleges and universities. There were (are?) some really great COBOL implementations out there. The name Micro Focus comes to mind. The MF COBOL on my Win XP PC proved to be rock solid and incredibly fast with a great debugger. * * * * * * *You should research all this before making any commitment to a particular OS or application language.* The advantage of starting your career with a big company (e.g. bank, insurance) is that they can manage their staff with a long-term view. They will invest in training you, and they provide a populaiton of competent staff to mentor you. I worked with many different programming languages over the years, and likely you will also. They are all just tools. Maybe that proprietary IBM OS layer I worked with has now all disappeared. But it would surprise mte to learn that our big banks are running their "inner jewels" type IT operations on open source LInux *...* It's true there is a purpose for blinkered code in proprietary environments. Converting digigraphs and trigraphs back and forth is a kind of security by obscurity, but I kind of like the programmers sense of humor about it. https://en.m.wikipedia.org/wiki/EBCDIC Professor: "So the American government went to IBM to come up with an encryption standard, and they came up with—" Student: "EBCDIC!" Regards,, *Steve* ** * ** Steve Petrie, P.Eng*.* Oakville, Ontario, Canada (905) 847-3253 apetrie@aspetrie.net ----- Original Message ----- *From:* R360 Design INC via talk <talk@gtalug.org> *To:* talk@gtalug.org *Sent:* Sunday, December 03, 2017 10:33 PM *Subject:* [GTALUG] IBM Mainframe and z/OS Hello everyone, Does anyone know how I could gain hands-on experience on an IBM mainframe? This is a career path Id like to pursue - i.e. Websphere zOS consultant or CICS. I am currently a UoT student and was wondering how people gain experience -- r360design.ca -- r360design.ca ------------------------------ --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk Cheers, -- Russell
On 2017-12-09 08:10 AM, Russell via talk wrote:
Professor: "So the American government went to IBM to come up with an encryption standard, and they came up with—" Student: "EBCDIC!"
In jest, I know, but — unfair! If you start from the punched card for tallying numbers, then EBCDIC makes sense. BCD is a practical method of storing decimal numeric data, especially where financial transactions have to add up perfectly. EBCDIC was just a small alphabetical add-on to IBM's existing numeric tabulators. Many of the compromises/weirdnesses in EBCDIC's collation sequences can be traced back to mechanical limitations of IBM card punches of the 1940s to 1960s. The printing card punches contained a quite lovely device called a code plate that generated the printed dot-matrix letters. It's fully described here: http://www.masswerk.at/misc/card-punch-typography/ Yep, a bitmap font¹ defined in a postage-stamp sized chunk of metal. In 1949. Pretty neat, I have to say. Stewart ¹: Yes, Myles; before you ask, I went there: https://fontlibrary.org/en/font/keypunch029
On December 9, 2017 9:02:03 AM EST, "Stewart C. Russell via talk" <talk@gtalug.org> wrote:
On 2017-12-09 08:10 AM, Russell via talk wrote:
Professor: "So the American government went to IBM to come up with
an encryption standard, and they came up with—"
Student: "EBCDIC!"
In jest, I know, but — unfair!
If you start from the punched card for tallying numbers, then EBCDIC makes sense. BCD is a practical method of storing decimal numeric data, especially where financial transactions have to add up perfectly. EBCDIC was just a small alphabetical add-on to IBM's existing numeric tabulators.
Many of the compromises/weirdnesses in EBCDIC's collation sequences can be traced back to mechanical limitations of IBM card punches of the 1940s to 1960s. The printing card punches contained a quite lovely device called a code plate that generated the printed dot-matrix letters. It's fully described here:
Very interesting link. Also nice to know how little endian transport "return zero" errors we're being handled back in the day. "Moreover, the letter “O” and the number zero, which, while being produced by destinctive encodings, shared the same form on the 026, were altered for visual distinction." Most recently, after trying several kernel taints on my Intel gpu, which is having font rendering issues, I dumped my DSDT table and found namespace/pstate conflicts in returning zero as serialized data. Seven errors and a couple of hundred warnings. I tried Rawhide for better gpu drivers but no joy there. Steve was certainly right about one aspect of a corporate learning initiative. They will most likely have up to date accurate documentation and the best human mentorship they can afford.
Yep, a bitmap font¹ defined in a postage-stamp sized chunk of metal. In 1949. Pretty neat, I have to say.
Me too. Eighty years later, pinpoint engineering and manufacturing accuracy has put billions of Gladys Hoppers ideas on that same sized chunk. Well not just Gladys, but all the engineers and mathematicians who's work made this stuff affordable for me to hack around with. I think reading about the history of the engineering is half the fun. From my perspective that's the best part of the Internet. The other half is putting that knowledge to current use in a practical way. I bought an Nvidia card and untainted my kernels DRM. I'm going to dump DSDT again and I'll have more fun with serialized data. All the time I'll be swearing at systemd granularity requirements while secretly knowing I will have to figure it all out. With everyone else's help of course. :-)
Stewart
¹: Yes, Myles; before you ask, I went there: https://fontlibrary.org/en/font/keypunch029 --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
-- Russell
On 12/09/2017 10:30 AM, Russell via talk wrote:
Me too. Eighty years later, pinpoint engineering and manufacturing accuracy has put billions of Gladys Hoppers ideas on that same sized chunk. Well not just Gladys, but all the engineers and mathematicians who's work made this stuff affordable for me to hack around with.
Ummm... Grace Hopper. https://en.wikipedia.org/wiki/Grace_Hopper
| From: Russell via talk <talk@gtalug.org> | On December 9, 2017 9:02:03 AM EST, "Stewart C. Russell via talk" <talk@gtalug.org> wrote: | > http://www.masswerk.at/misc/card-punch-typography/ | | Very interesting link. Also nice to know how little endian transport | "return zero" errors we're being handled back in the day. Return zero? | Most recently, after trying several kernel taints What does that mean? As far as I understand, the kernel reports itself tainted if it observes any of a number of distateful things. Like loading proprietary kernel modules. The idea is that kernel maintainers will ignore problem reports from folks running such modules. | on my Intel gpu, which | is having font rendering issues, I dumped my DSDT table and found | namespace/pstate conflicts in returning zero as serialized data. I'm not sure what "returning zero as serialized data" means in this context. There are lots of buggy ACPI tables. If you are lucky, you can ignore them. You can disassemble ACPI tables and recompile them and get a surprising number of compiler warnings. I vaguely remember hearing the firmware developers generally use a Microsoft ACPI compiler but we Linux users use an Intel compiler, and it flags more errors (or at least different errors) than the Microsoft one. One of the common errors is ACPI routines falling off the end rather than returning a value. Does ACPI have anything to say about GPUs? | Seven | errors and a couple of hundred warnings. I tried Rawhide for better gpu | drivers but no joy there. Perhaps you need this kernel boot parameter: i915.alpha_support=1 Your kernel probably needs to be 4.13 or newer. See <https://www.phoronix.com/scan.php?page=article&item=coffee-uhd-graphics&num=1> (I speak with no experience.)
On December 9, 2017 1:58:58 PM EST, "D. Hugh Redelmeier via talk" <talk@gtalug.org> wrote:
| From: Russell via talk <talk@gtalug.org>
| On December 9, 2017 9:02:03 AM EST, "Stewart C. Russell via talk" <talk@gtalug.org> wrote:
| > http://www.masswerk.at/misc/card-punch-typography/ | | Very interesting link. Also nice to know how little endian transport | "return zero" errors we're being handled back in the day.
Return zero?
Sorry, a bit of a joke about transliterative errors. Wasn't the TLS heartbeat issue, in essence, a return zero error. The return handler expected "0" but got "" null and granted access as a permissive failover.
| Most recently, after trying several kernel taints
What does that mean? As far as I
understand, the kernel reports
itself tainted if it observes any of a number of distateful things. Like loading proprietary kernel modules. The idea is that kernel maintainers will ignore problem reports from folks running such modules.
I tried some recommendations, adding i915.alpha_support=1 and a few others on boot. I was eventually able to change display resolutions, but this triggered a kernel crash. The system recovered but I didn't even see the ABRT report until I updated F27. Now I'm at 4.13.16-302.fc27.x86_64. running Nvidia using their own driver. I've tainted the kernel by blacklisting Nouveau, which in fact appears to have provided me with more resolution choices. I may revert soon. I chose F27 for this build because I was very impressed with Gnome on Wayland on my HP-110. It handles display much better than Mint or Bunsen etc on it.
| on my Intel gpu, which | is having font rendering issues, I dumped my DSDT table and found | namespace/pstate conflicts in returning zero as serialized data.
I'm not sure what "returning zero as serialized data" means in this context.
There are lots of buggy ACPI tables. If you are lucky, you can ignore them.
You can disassemble ACPI tables and recompile them and get a surprising number of compiler warnings. I vaguely remember hearing the firmware developers generally use a Microsoft ACPI compiler but we Linux users use an Intel compiler, and it flags more errors (or at least different errors) than the Microsoft one.
One of the common errors is ACPI routines falling off the end rather than returning a value.
Does ACPI have anything to say about GPUs?
Not specifically, there are method, object and value references, which I'm currently trying to get an understanding of. Keeping pstate values stable and ordered, for finer grained control over reporting power management, seems to conflict with some methods. This warning, which looks to me like it's saying I'm getting 1 when I expect 0, is related to one ACPI error repeated seven times. This is where my base math skills fall down. Warning 4089. Is it a 0 object or a zero method? Line 4093 =length appears to exceed line 4091 =range maximum dsdt.dsl 180: Name (IOHB, 0x0290) Warning 4089 - ^ Object is not referenced 4088 DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 4089 0x00000000, // Granularity 4090 0x00000000, // Range Minimum 4091 0xDFFFFFFF, // Range Maximum 4092 0x00000000, // Translation Offset 4093 0xE0000000, // Length THE ERROR is 6074 dsdt.dsl 19786: Method (TBTD, 1, Serialized) Error 6074 - ^ Name already exists in scope (TBTD) Original name creation/declaration below: dsdt.dsl 164: External (TBTD, MethodObj) // 1 Arguments dsdt.dsl 19858: Method (TBTF, 1, Serialized) Error 6074 - ^ Name already exists in scope (TBTF) Original name creation/declaration below: dsdt.dsl 165: External (TBTF, MethodObj) // 1 Arguments dsdt.dsl 19979: Method (MMRP, 1, Serialized) Error 6074 - ^ Name already exists in scope (MMRP) Original name creation/declaration below: dsdt.dsl 124: External (MMRP, MethodObj) // 1 Arguments dsdt.dsl 19987: Method (MMTB, 1, Serialized) Error 6074 - ^ Name already exists in scope (MMTB) Original name creation/declaration below: dsdt.dsl 125: External (MMTB, MethodObj) // 1 Arguments dsdt.dsl 20009: Method (FFTB, 1, Serialized) Error 6074 - ^ Name already exists in scope (FFTB) Original name creation/declaration below: dsdt.dsl 113: External (FFTB, MethodObj) // 1 Arguments
| Seven | errors and a couple of hundred warnings. I tried Rawhide for better gpu | drivers but no joy there.
Perhaps you need this kernel boot parameter: i915.alpha_support=1 Your kernel probably needs to be 4.13 or newer.
See <https://www.phoronix.com/scan.php?page=article&item=coffee-uhd-graphics&num=1>
(I speak with no experience.)
I speak with many uneducated guesses as I try to stitch hardware together. When I was first overclocking, jumper by jumper, it struck me as odd that changing just a couple of jumpers on the motherboard could so drastically improve performance. On the other hand, getting a breakout lcd to report the clock speed changes accurately, required 42 jumpers to be precisely set or it wouldn't display data at all. If it isn't the trees, it's the forest. I sort of treat this mail list a little like a machete; it helps to cut away some of the undergrowth and keep stuff in perspective.
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
-- Russell
| From: Russell via talk <talk@gtalug.org> | On December 9, 2017 1:58:58 PM EST, "D. Hugh Redelmeier via talk" <talk@gtalug.org> wrote: | >| Most recently, after trying several kernel taints | > | >What does that mean? As far as I understand, the kernel reports | >itself tainted if it observes any of a number of distateful things. | >Like loading proprietary kernel modules. The idea is that kernel | >maintainers will ignore problem reports from folks running such | >modules. | | I tried some recommendations, adding i915.alpha_support=1 and a few | others on boot. I was eventually able to change display resolutions, but | this triggered a kernel crash. The system recovered but I didn't even | see the ABRT report until I updated F27. I still don't understand what you are calling "kernel taints". I recommended i915.alpha_support=1 because I remember that you got a Coffee Lake processor but forgot you got a discrete card. You are not using the Intel GPU, so don't use that parameter. I do hope it is harmless. | Now I'm at 4.13.16-302.fc27.x86_64. running Nvidia using their own | driver. I've tainted the kernel by blacklisting Nouveau, which in fact | appears to have provided me with more resolution choices. I may revert | soon. No, you have not tainted the kernel by blacklisting Nouveau. You've tainted it by loading the Nvidia module. That matches the meaning of tainting as I understand it and have explained. I too use the Nvidia drive, reluctantly. My X (or Wayland) craps out when I use Nouveau. This has been the case for some years, through many versions of Fedora. I'm not happy with this but am unwilling to spend the time required to provide a decent bug report. My most recent experience was better, but no cigar. I use a GTX 650 to drive an UltraHD TV set at 30Hz. I'm guessing that the latest crash was due to running of of display memory -- it happened when I ran restarted firefox with perhaps hundreds of tabs. I understand that Noveau isn't 100% capable on current Nvidia cards because Nvidia hasn't disclosed newer clocking/power-management features and they haven't made available the current firmware blob necessary. I don't think that these problems apply for my ancient card. Unfortunately, AMD cards aren't completely open either. For example, the method for getting sound on HDMI was undisclosed. That may have been fixed (someone reverse engineered a bit of that). But it is indicative of the gotchas. The best GPU player, generally, has been Intel. Probably because they are playing from behind. They did go through a bad patch where the drivers were unreliable but that was a few years ago. | I chose F27 for this build because I was very impressed with Gnome on | Wayland on my HP-110. It handles display much better than Mint or Bunsen | etc on it. The proprietary Nvidia driver precludes Wayland. Some day that may change but it is out of our control. | >| on my Intel gpu, which | >| is having font rendering issues, I dumped my DSDT table and found | >| namespace/pstate conflicts in returning zero as serialized data. | > | >I'm not sure what "returning zero as serialized data" means in this | >context. | > | >There are lots of buggy ACPI tables. If you are lucky, you can ignore | >them. | > | >You can disassemble ACPI tables and recompile them and get a surprising | >number of compiler warnings. I vaguely remember hearing the firmware | >developers generally use a Microsoft ACPI compiler but we Linux users | >use an Intel compiler, and it flags more errors (or at least different | >errors) than the Microsoft one. | > | >One of the common errors is ACPI routines falling off the end rather | >than returning a value. | > | >Does ACPI have anything to say about GPUs? | | Not specifically, there are method, object and value references, which | I'm currently trying to get an understanding of. Keeping pstate values | stable and ordered, for finer grained control over reporting power | management, seems to conflict with some methods. Keep separate problems separate, if possible. ACPI and your GPU problems are likely separate. If you are using the Intel GPU after all, then you must have removed your Nvidia card. At that point the kernel parameter I mentioned probably becomes relevant. | This warning, which looks to me like it's saying I'm getting 1 when I | expect 0, is related to one ACPI error repeated seven times. | | This is where my base math skills fall down. Warning 4089. Is it a 0 | object or a zero method? That doesn't seem like a "math skill" to me. That terminology just seems to cloud the problem solving. (Note to self: jokes while trying to disentangle a confused communication probably make things harder.) When in doubt, google error messages. But be prepared to be skeptical about the answers. You should also specify what is generating the diagnostics. The kernel? An ACPI compiler? It looks to me like the latter. If you are recompiling ACPI tables, I think that you are going in the wrong direction for solving GPU problems. If you think that the firmware is screwed up, look for a newer version. Self-help with ACPI tables is a desperation move (and potentially educational). The biggest ACPI issues are on notebooks. I get errors like the following on my desktop machine. From the kernel, on every boot. They are aparently due to a kernel bug. They don't seem to break anything. [ 3.018775] ACPI Error: Field [D128] at bit offset/length 128/1024 exceeds size of target Buffer (160 bits) (20170531/dsopcode-235) [ 3.018830] ACPI Error: Method parse/execution failed \HWMC, AE_AML_BUFFER_LIMIT (20170531/psparse-550) [ 3.018873] ACPI Error: Method parse/execution failed \_SB.WMID.WMAA, AE_AML_BUFFER_LIMIT (20170531/psparse-550) [ 3.018962] ACPI Error: Field [D128] at bit offset/length 128/1024 exceeds size of target Buffer (160 bits) (20170531/dsopcode-235) [ 3.019010] ACPI Error: Method parse/execution failed \HWMC, AE_AML_BUFFER_LIMIT (20170531/psparse-550) [ 3.019050] ACPI Error: Method parse/execution failed \_SB.WMID.WMAA, AE_AML_BUFFER_LIMIT (20170531/psparse-550) [ 3.019137] ACPI Error: Field [D128] at bit offset/length 128/1024 exceeds size of target Buffer (160 bits) (20170531/dsopcode-235) [ 3.019179] ACPI Error: Method parse/execution failed \HWMC, AE_AML_BUFFER_LIMIT (20170531/psparse-550) [ 3.019219] ACPI Error: Method parse/execution failed \_SB.WMID.WMAA, AE_AML_BUFFER_LIMIT (20170531/psparse-550) | Line 4093 =length appears to exceed line 4091 =range maximum ACPI is kind of an assembly language. Use your assembly-language intuition for dealing with these diagnostics. The messages are mostly clear but they refer to rules that you must find in the ACPI standards.
On December 10, 2017 12:38:27 AM EST, "D. Hugh Redelmeier via talk" <talk@gtalug.org> wrote:
| From: Russell via talk <talk@gtalug.org>
| On December 9, 2017 1:58:58 PM EST, "D. Hugh Redelmeier via talk" <talk@gtalug.org> wrote:
| >| Most recently, after trying several kernel taints | > | >What does that mean? As far as I understand, the kernel reports | >itself tainted if it observes any of a number of distateful things. | >Like loading proprietary kernel modules. The idea is that kernel | >maintainers will ignore problem reports from folks running such | >modules. | | I tried some recommendations, adding i915.alpha_support=1 and a few | others on boot. I was eventually able to change display resolutions, but | this triggered a kernel crash. The system recovered but I didn't even
| see the ABRT report until I updated F27.
I still don't understand what you are calling "kernel taints".
I recommended i915.alpha_support=1 because I remember that you got a Coffee Lake processor but forgot you got a discrete card. You are not using the Intel GPU, so don't use that parameter. I do hope it is harmless.
Thanks for taking the time to go over this with me. Actually, I didn't get the Nvidia 1050 Ti until a couple of days ago. The first thing I did on first boot after assembly was enable the alpha support for the Intel GPU. Then I dnf updated and saw that ABRT notifications, which pop up in the calendar widget, started displaying on login. Once I realized that DRM wasn't going to be easily available, even in Rawhide, I bought the Nvidia card and used their vendors install script. Excellent step by step instructions for Fedora Nvidia in/uninstall can be found here, if anyone else needs them. Recently updated to use systemd targets for use of the necessary telinit runlevels. https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/
| Now I'm at 4.13.16-302.fc27.x86_64. running Nvidia using their own | driver. I've tainted the kernel by blacklisting Nouveau, which in fact | appears to have provided me with more resolution choices. I may revert | soon.
I have just reverted to Nouveau. I guess I could have entered EDID data for the display resolutions which the Nvidia default config left out, but using the Nvidia driver somehow ran the card so that the cooling fan was running faster. It's vertical and the fan blades are a little unbalanced and so it seems to squeak a bit at higher speed. So far going back to Nouveau has at least stopped the squeaking.
No, you have not tainted the kernel by blacklisting Nouveau. You've tainted it by loading the Nvidia module. That matches the meaning of tainting as I understand it and have explained.
Thanks, I get that now.
I too use the Nvidia drive, reluctantly. My X (or Wayland) craps out when I use Nouveau. This has been the case for some years, through many versions of Fedora. I'm not happy with this but am unwilling to spend the time required to provide a decent bug report. My most recent experience was better, but no cigar. I use a GTX 650 to drive an UltraHD TV set at 30Hz. I'm guessing that the latest crash was due to running of of display memory -- it happened when I ran restarted firefox with perhaps hundreds of tabs.
I understand that Noveau isn't 100% capable on current Nvidia cards because Nvidia hasn't disclosed newer clocking/power-management features and they haven't made available the current firmware blob necessary. I don't think that these problems apply for my ancient card.
Unfortunately, AMD cards aren't completely open either. For example, the method for getting sound on HDMI was undisclosed. That may have been fixed (someone reverse engineered a bit of that). But it is indicative of the gotchas.
The best GPU player, generally, has been Intel. Probably because they are playing from behind. They did go through a bad patch where the drivers were unreliable but that was a few years ago.
| I chose F27 for this build because I was very impressed with Gnome on
| Wayland on my HP-110. It handles display much better than Mint or Bunsen | etc on it.
The proprietary Nvidia driver precludes Wayland. Some day that may change but it is out of our control.
| >| on my Intel gpu, which | >| is having font rendering issues, I dumped my DSDT table and found | >| namespace/pstate conflicts in returning zero as serialized data. | > | >I'm not sure what "returning zero as serialized data" means in this | >context. | > | >There are lots of buggy ACPI tables. If you are lucky, you can ignore | >them. | > | >You can disassemble ACPI tables and recompile them and get a surprising | >number of compiler warnings. I vaguely remember hearing the firmware | >developers generally use a Microsoft ACPI compiler but we Linux users | >use an Intel compiler, and it flags more errors (or at least different | >errors) than the Microsoft one. | > | >One of the common errors is ACPI routines falling off the end rather | >than returning a value. | > | >Does ACPI have anything to say about GPUs? | | Not specifically, there are method, object and value references, which | I'm currently trying to get an understanding of. Keeping pstate values | stable and ordered, for finer grained control over reporting power | management, seems to conflict with some methods.
Keep separate problems separate, if possible.
ACPI and your GPU problems are likely separate.
If you are using the Intel GPU after all, then you must have removed your Nvidia card. At that point the kernel parameter I mentioned probably becomes relevant.
| This warning, which looks to me like it's saying I'm getting 1 when I
| expect 0, is related to one ACPI error repeated seven times. | | This is where my base math skills fall down. Warning 4089. Is it a 0 | object or a zero method?
That doesn't seem like a "math skill" to me. That terminology just seems to cloud the problem solving. (Note to self: jokes while trying to disentangle a confused communication probably make things harder.)
When in doubt, google error messages. But be prepared to be skeptical about the answers.
You should also specify what is generating the diagnostics. The kernel? An ACPI compiler? It looks to me like the latter. If you are recompiling ACPI tables, I think that you are going in the wrong direction for solving GPU problems.
If you think that the firmware is screwed up, look for a newer version. Self-help with ACPI tables is a desperation move (and potentially educational). The biggest ACPI issues are on notebooks.
I get errors like the following on my desktop machine. From the kernel, on every boot. They are aparently due to a kernel bug. They don't seem to break anything.
[ 3.018775] ACPI Error: Field [D128] at bit offset/length 128/1024 exceeds size of target Buffer (160 bits) (20170531/dsopcode-235) [ 3.018830] ACPI Error: Method parse/execution failed \HWMC, AE_AML_BUFFER_LIMIT (20170531/psparse-550) [ 3.018873] ACPI Error: Method parse/execution failed \_SB.WMID.WMAA, AE_AML_BUFFER_LIMIT (20170531/psparse-550) [ 3.018962] ACPI Error: Field [D128] at bit offset/length 128/1024 exceeds size of target Buffer (160 bits) (20170531/dsopcode-235) [ 3.019010] ACPI Error: Method parse/execution failed \HWMC, AE_AML_BUFFER_LIMIT (20170531/psparse-550) [ 3.019050] ACPI Error: Method parse/execution failed \_SB.WMID.WMAA, AE_AML_BUFFER_LIMIT (20170531/psparse-550) [ 3.019137] ACPI Error: Field [D128] at bit offset/length 128/1024 exceeds size of target Buffer (160 bits) (20170531/dsopcode-235) [ 3.019179] ACPI Error: Method parse/execution failed \HWMC, AE_AML_BUFFER_LIMIT (20170531/psparse-550) [ 3.019219] ACPI Error: Method parse/execution failed \_SB.WMID.WMAA, AE_AML_BUFFER_LIMIT (20170531/psparse-550)
| Line 4093 =length appears to exceed line 4091 =range maximum
ACPI is kind of an assembly language. Use your assembly-language intuition for dealing with these diagnostics. The messages are mostly clear but they refer to rules that you must find in the ACPI standards.
Thanks for the support. One thing I noticed immediately after reverting to Nouveau was that ABRT now prompts me to join bugzilla and file a report. Before this it would tell me I had the option to email the maintainers privately. It seems that the AI approves of my kernel now. I've installed a hauppauge quad win TV tuner. I haven't watched TV in years, but it registered something like 20 OTA stations and even the credit card remote shows up on /dev/input/by-path (I remember your tip about that, from some audio stuff a few years ago) I installed KDE to check out plasma and kaffeine for the TV. Plasma generated an X crash report on KDE so I went back to Nouveau. The remote is crap. I can't even tell if it is powered on, so I can't really test lircd. A quick check of the log says no node at /sys/class/rc/rc* I did try a udev rule to link /dev/lirc0 to the input event node but no luck yet. So a new battery and more tinkering with stuff I'm a little more familiar with. Thanks,
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
-- Russell
| From: Stewart C. Russell via talk <talk@gtalug.org> | The printing card punches contained a quite lovely | device called a code plate that generated the printed dot-matrix | letters. It's fully described here: | | http://www.masswerk.at/misc/card-punch-typography/ Thanks. I never new how the dot matrix was stored. I did know (i.e. was told firmly) that you risked breaking an IBM 026 by duplicating a card with invalid hole combinations. You could turn off printing and that was thought to prevent the problem. Even then, duplicating a column with too many holes could screw things up to the extent that the duplicate wasn't and sometimes the card jammed. In my experience, an 026 keypunch sounded really bad when you punched a column with too many holes. Much safer to use an 029. (The 026 was introduced in 1949. The 029 was introduced in 1964, along with EBCDIC and the IBM/360. You can imagine how much nicer the 029 was. But neither had a backspace key. Or lower case letters.)
On 12/09/2017 01:23 PM, D. Hugh Redelmeier via talk wrote:
(The 026 was introduced in 1949. The 029 was introduced in 1964, along with EBCDIC and the IBM/360. You can imagine how much nicer the 029 was. But neither had a backspace key. Or lower case letters.)
Many years ago, I worked on the CN Rail "TRACS" system. This was used to keep track of all the cars in a freight train. The system had a Datapoint 2200¹ terminal with 2 cassette recorders, a local printer, card punch & reader and serial lines to remote sites and also the IBM main frame in Montreal. This terminal used ASCII internally as well as for the local printer, Hollerith to the card punch/reader, Baudot to the remote sites and EBCDIC to Montreal. 1) The Datapoint 2200 was the intended target for the Intel 8008 CPU, but went with a customer built CPU board, as the 8008 was too slow. However, it had the same instruction set as the 8008. We even had a BASIC interpreter for it. ;-) https://en.wikipedia.org/wiki/Datapoint_2200
On 2017-12-03 10:33 PM, R360 Design INC via talk wrote:
Hello everyone,
Does anyone know how I could gain hands-on experience on an IBM mainframe? This is a career path Id like to pursue - i.e. Websphere zOS consultant or CICS. I am currently a UoT student and was wondering how people gain experience
You may want to have a watch here (it does the rounds occasionally, I might have seen it on this list a while back even?) Title: Here's What Happens When an 18 Year Old Buys a Mainframe https://www.youtube.com/watch?v=45X4VP8CGtk Cheaper than a fruity modest spec'ed laptop.
On 2017-12-03 10:33 PM, R360 Design INC via talk wrote:
Hello everyone,
Does anyone know how I could gain hands-on experience on an IBM mainframe? This is a career path Id like to pursue - i.e. Websphere zOS consultant or CICS. I am currently a UoT student and was wondering how people gain experience
You might make a cold call on Lexis Nexis for a summer job, as they run both MVS and Linux. Drop me a line that I can pass on to a colleague there if you're interested. --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
participants (12)
-
Ansar Mohammed -
Christopher Browne -
D. Hugh Redelmeier -
David Collier-Brown -
David Thornton -
James Knott -
Jamon Camisso -
lsorense＠csclub.uwaterloo.ca -
R360 Design INC -
Russell -
Steve Petrie, P.Eng. -
Stewart C. Russell