Re: MP3000 disk array woes
MIne's actually a P30, as well, though it's supposedly identical at the functional level to an H30. On Fri, Aug 16, 2024 at 6:11 AM W Mainframe < 01304632a58d-dmarc-requ...@listserv.ua.edu> wrote: > Jay,I have one P30 (a development version of H30), my array showed same > problem (channel issues). It is only able to run my IBM OS in EMIO mode. > Did you tried this?The support people to this hardware is not > easy..Unfortunately my power supply does not work anymore, both units... > :(Dan > > > Sent from Yahoo Mail for iPhone > > > On Friday, August 16, 2024, 12:20 AM, Jay Maynard < > 05997213d6c2-dmarc-requ...@listserv.ua.edu> wrote: > > I've been gifted a MP3000 model H30 with six 18 GB drives on top of the 9 > GB OS/2 drives. The machine appears to run, but I'm having trouble with the > disk array: it shows no configured volumes in the logical storage system > and the options to add more are greyed out. The disk box contents display > shows one drive of the 6 as being bad. > > I'd like to resurrect the array before wiping it, but if I have to delete > the contents, so be it. I can't even seem to do that, though. > > Looking for someone who understands these machines to get with me and > figure things out. This is probably going to get too deep in the weeds for > IBM-main, with an obsolete system, so contact me direct, please. > > Thanks! > -- > Jay Maynard > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3270 programming
The TN3270/TN3270E protocols were actually invented outside of IBM. But they're just an envelope for the 3270 data stream. I can tn3270 from a 3279-S3G attached to a 3174 over Token Ring to a P/390 and do charts with GDDM. On Fri, Aug 16, 2024 at 8:14 AM Lennie Bradshaw wrote: > Seymour, > That is interesting. I was unaware the protocol had been externalised from > IBM. I guess this absolves them of the responsibility of providing > documentation as well. > > Phil asked what was the original posters requirement. Well years ago (in > the late 1970s) I wrote some program for TSO using 3270 protocols. This was > in the days before ISPF and before the extended attribute support was > available. I have been involved in such programs rarely since then, but > have maintained some knowledge of the protocol. I have somewhere a "Green > Book" which has all the tables and so on, but I have mislaid it. I had to > make some changes to a VTAM USS table recently and was looking for the > specifications for the control strings I could use. As I couldn't find my > Green Book, I looked online and could not see where IBM had this documented. > Hence my questions. > > The website that Sebastian found was really useful. > > Many thanks to all who contributed. I will try and butt out now. > Lennie > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Seymour J Metz > Sent: 16 August 2024 12:56 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 3270 programming > > I would start with RFC 2355, TN3270 Enhancements < > https://datatracker.ietf.org/doc/rfc2355/> > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > > From: IBM Mainframe Discussion List on behalf > of Mike Schwab <05962a42dc49-dmarc-requ...@listserv.ua.edu> > Sent: Thursday, August 15, 2024 11:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 3270 programming > > > https://www.ibm.com/docs/en/zos-basic-skills?topic=terminal-3270-data-stream > Specifically listed but no link, > > On Thu, Aug 15, 2024 at 7:45 PM Tom Brennan > wrote: > > > > I don't think TN3270/TN3270E protocols are related to this manual. > > They're basically just a layer used to pass the binary 3270 data > > stream back and forth. > > > > But Lennie has a good point. I have a printed copy -05 from 1990 and > > it's pretty beat up. I seem to remember it on an IBM doc site until > > (guessing) 2005 or so, then it was suddenly gone. Maybe someone made > > a mistake in removing it, because it's certainly required for anybody > > who wants to code their own 3720 screens, or simply wants to know how > > things work. > > > > On 8/15/2024 5:33 PM, Ken Bloom wrote: > > > 3270 is supported via tn3270 and tn3270E. That’s the protocol > supported by IBM OSA or Visara CCA3074 etc. You can probably find some > old coax manuals for native 3270. > > > > > > Ken > > > > > > > > > Kenneth A. Bloom > > > CEO > > > Avenir Technologies Inc > > > /d/b/a Visara International > > > 203-984-2235 > > > bl...@visara.com<mailto:bl...@visara.com> > > > http://www.visara.com/<http://www.visara.com/> > > > > > > > > > On Aug 15, 2024, at 8:22 PM, Lennie Bradshaw < > lennie-brads...@outlook.com> wrote: > > > > > > So if the protocol is still supported, and still used, and still a > valid programming interface, why is there no *current* manual available > from IBM documenting it? > > > > > > Lennie > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On > > > Behalf Of Jay Maynard > > > Sent: 15 August 2024 23:02 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: 3270 programming > > > > > > I think IBM still supports 3270 access, if not the 3270s themselves. > > > > > > But if the data stream hasn't changed since the -7 manual was > published, there's no need for an update... > > > > > > On Thu, Aug 15, 2024 at 4:54 PM Paul Gilmartin < > 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > On Thu, 15 Aug 2024 15:16:15 -0500, Mike Schwab wrote: > > > > > > There have been no updates. > > > > > > Does IBM continue to support the device? If not, there's little > > > bu
MP3000 disk array woes
I've been gifted a MP3000 model H30 with six 18 GB drives on top of the 9 GB OS/2 drives. The machine appears to run, but I'm having trouble with the disk array: it shows no configured volumes in the logical storage system and the options to add more are greyed out. The disk box contents display shows one drive of the 6 as being bad. I'd like to resurrect the array before wiping it, but if I have to delete the contents, so be it. I can't even seem to do that, though. Looking for someone who understands these machines to get with me and figure things out. This is probably going to get too deep in the weeds for IBM-main, with an obsolete system, so contact me direct, please. Thanks! -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3270 programming
I think IBM still supports 3270 access, if not the 3270s themselves. But if the data stream hasn't changed since the -7 manual was published, there's no need for an update... On Thu, Aug 15, 2024 at 4:54 PM Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Thu, 15 Aug 2024 15:16:15 -0500, Mike Schwab wrote: > > >There have been no updates. > > > Does IBM continue to support the device? If not, there's > little business case to provide user's manuals. > > Regardless, some documentation is necessary as long as > IBM products depend on 3270 data streams. > > -- > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe history - 12 inch floppies?
The 3274 also used them. I have a big pile of ex-3274 floppies that I reformatted and used for my CP/M microcomputer, back in the early 80s... On Thu, Jul 11, 2024 at 11:11 AM Farley, Peter < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > ISTR there were such floppies that loaded CPU microcode, similarly for > DASD and tape controllers I believe. > > You used to have to do “IML” (“Initial Microprogram Load”) of CPU’s and > some peripheral control boxes before you could use them normally, and the > IML source was one of those floppies. Some hardware fixes and upgrades > were just a new floppy and IML. > > Peter > > From: IBM Mainframe Discussion List On Behalf > Of Radoslaw Skorupka > Sent: Thursday, July 11, 2024 12:00 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Mainframe history - 12 inch floppies? > > > I just found information in some book that IBM mainframes used 12 inch > > floppy diskettes. Late 70's. > > > > Anybody heard about such diskettes? > > > > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inquiry about Installing Hercules on LinuxONE
Actually, Hercules does implement TXF, at least in versions 4.6 and later. To answer Jason's question, Hercules on LinuxONE would technically be able to do this. However, I would strongly caution that there are significant licensing issues involved in running any licensed program product on Hercules, on LinuxONE or otherwise. I am not a lawyer, and this is not legal advice. You need to get your corporate counsel involved in this question ASAP. In the meantime, I would recommend looking into facilities to extract the historical data from the form it's in and put it into a form accessible by your other systems. On Tue, Jun 11, 2024 at 1:11 PM Mike Schwab < 05962a42dc49-dmarc-requ...@listserv.ua.edu> wrote: > Transactional execution facility instructions have not been implemented. > > Has your z/OS machine stopped working or the current z/OS can't be > upgraded due to hardware requirements? > > > https://www.ibm.com/docs/bg/zos/2.4.0?topic=guide-transactional-execution > > On Tue, Jun 11, 2024 at 12:58 PM Jason Cai wrote: > > > > Our organization's z mainframe has reached the end of its hardware > service life and is no longer capable of running z/OS. However, we have a > LinuxONE machine that remains operational. > > > > We possess historical data backups from our z/OS environment that we > need to access. To address this, we are considering the installation of the > Hercules emulator on our zLinux environment. Our goal is to utilize > Hercules to emulate the z/OS necessary to access our backup data sometime. > > > > Could you please advise on the feasibility of this approach? > Specifically, we are interested in understanding: > > > > 1. The compatibility of Hercules with zLinux on a LinuxONE machine. > > 2. Any known limitations or considerations we should be aware of when > using Hercules for this purpose. > > 3. The steps required to set up Hercules in a zLinux environment to > access z/OS backup data. > > > > Your expertise and guidance on this matter would be greatly appreciated. > We are eager to find a solution that allows us to utilize our existing > resources effectively while ensuring the integrity and accessibility of our > historical data. > > > > Thank you very much for your time and assistance. > > > > Best regards, > > Jason Cai > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > 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 message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inquiry about Installing Hercules on LinuxONE
Yes, you will need to compile Hercules on LinuxONE. There are no prebuilt binaries for it, mainly because LinuxONE isn't among the systems that our folks have access to. You'll need to use Linux running on the LinuxONE system to do the download and build. The good news is that Bill Lewis's outstanding hercules-helper utility will automate the build for you. It should just work, but if not, he'll be happy to work with you to get it going. You'll find it at https://github.com/wrljet/hercules-helper . On Tue, Jun 11, 2024 at 5:42 AM Jason Cai wrote: > Thank you for your prompt response. > > I have experience using Hercules on Windows and understand that I need it > to work with the relevant z/OS volume files. I have already downloaded > Hercules, but I do not recall needing to compile it. Could you please > clarify if compilation is necessary? If so, should I use Linux to download > and compile Hercules on LinuxONE? > > I would greatly appreciate detailed instructions on how to compile > Hercules on Linux. Additionally, I am interested in understanding the > differences between installing Hercules on Linux versus Windows. > > Thank you very much for your assistance. > > Jason Cai > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EBCDIC/ASCII - FTP
As it happens, I'm dealing with this...have a small task to do some C, and discovered the hard way that the 3279, while having the square brackets in its normal character set, doesn't have them at the same code points as later IBM OSes expect. tn3270 shows them fine, though. On Tue, May 28, 2024 at 7:43 AM Rick Troth < 058ff5c2d0a7-dmarc-requ...@listserv.ua.edu> wrote: > Hi Tom -- > > You're not wrong. > The musical code pages have led to multiplied complexities. > > Living in the US, I've had it easier than some, and in most cases I can > (and do) treat "EBCDIC" as CP1047 (with an exception around not and > circumflex). CP37 came first, and was "close" but got the square > brackets wrong (as most US installations used them). But with "CP37v2" > there is a one-for-one mapping with ISO-8859-1, and that's the A/E table > from which I start. It's not just me, many official implementations > (witness Dignus) use the same A/E mapping as their default. > > EBCDIC representations like "CP 37 version 2" were drummed-up by > customers. In the early 1990s, there was a concerted effort (including a > SHARE project) to solidify a standard. IBM took the requirements to > heart, thus we have CP1047 (which is "CP37v2" except for logical not > versus circumflex). But this all remains an 8-bit solution. > > The ASCII world also had multiple code pages (such as ISO-8859-1) but > then embraced Unicode and such encodings as UTF-8. > But mapping EBCDIC of any code page into UTF-8 is more than I know how > to do (reliably, unless I had source to the FTP client and hacked it > appropriately). > So to the original question, best practice is to have the z/OS side > handle the translation. ISO-8859-1 is most closely covered by CP819, so > the "*10470819*" mapping is what you want. > On the ASCII side, ISO-8859-1 *might* be usable as-is, but if not then > it can be easily converted to UTF-8. But that's a question for the ASCII > consumers of the data. > > -- R; <>< > > > > > On 5/8/24 12:45 PM, Tom Marchant wrote: > > "This" is the link that Gil provided in the email that I replied to, at > the bottom of the post. The assertion was that IBM erred in not making the > System/360 ASCII only. > > > > The availability of multiple EBCDIC code pages seems to me to make > Beemer's assertion that there is a 1 to 1 correspondence between ASCII and > EBCDIC even more dubious. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX vs other languages WAS: Rexx numeric digits and scientific notation question
Agreed Java is simply far too complex a language and ecosystem to hold in the mind. Python is as ubiquitous and much easier to deal with. On Fri, Apr 19, 2024 at 10:25 AM David Crayford < 0595a051454b-dmarc-requ...@listserv.ua.edu> wrote: > I’m not sure I would use Java as a REXX alternative now we have Python. > REXX is very much legacy now. The old timers love it because it’s all they > know but push come to shove Python is much easier to learn then Java with > all the OO cruft. > > > On 19 Apr 2024, at 7:50 AM, Andrew Rowley > wrote: > > > > On 18/04/2024 8:29 pm, Rony G. Flatscher wrote: > >> The mileage of people here vary including the Java people themselves > who have started to reduce the need of explicit declarations like the new > "var" (imitating JavaScript) instead of strict types or foregoing the > static main method such that one can at least code the main method without > the explicit declarations. The motivation about these changes is to make > Java easier, reduce typing needs and the like. > > > > The Java var keyword is more like C# than Javascript. The variable still > has a strict type - you can only use var if the compiler can figure out the > type from other information e.g. > > > > var start = ZonedDateTime.now(); > > > > start is a ZonedDateTime. You can't use it before it is defined, you > can't assign anything other than a ZoneDateTime to it, you can't create a > new variable called start in the same scope, whether or not it is a > ZoneDateTime. You can't e.g compare it to a LocalDateTime without > specifying a timezone for the LocalDateTime - that is one of those things > that helps avoid errors. > > > > var just reduces redundant code, e.g. specifying the type twice in the > same statement. > > > > > >> Of course a static and statically typed languages with a compiler must > define as much rules as possible, such that the compiler can check for them > all. The more rules the more time consuming and the more difficult to learn > a language. > > > > I think the syntax rules for Rexx are actually more complex than Java, > because it is less likely to flag an error if you do something that's not > actually what you want. E.g. string concatenation where variables are > expected to be strings but maybe not, might not be initialized, sometimes > you need vertical bars but not always etc. If you're used to the language > you write it without thinking and avoid the traps, but the rules are there > nonetheless. > > > > Java is relatively straightforward, and shares many rules with other > languages - C++, C# etc. I'm not saying Java is perfect - it has its own > traps (int vs Integer etc) but I find it a much easier language to work > with. > > > > -- > > Andrew Rowley > > Black Hill Software > > > > -- > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tape 6250
I have a package called vtapeutils that will do the job. No binaries, but the source is at https://github.com/jmaynard/vtapeutils . On Fri, Apr 5, 2024 at 7:01 AM W Mainframe < 01304632a58d-dmarc-requ...@listserv.ua.edu> wrote: > Guys,Recently I got some old mainframe converted 6250 tapes.Something like > .tap files, never saw that.The question is... Does anyone know some utility > to extract or convert this files to .aws files? > Thank youDan > > Sent from Yahoo Mail for iPhone > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx numeric digits and scientific notation question
r 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Insecure security - was SDSF PS Command column
This is what password managers were created for. I use Bitwarden, and can't recommend them highly enough. On Wed, Feb 14, 2024 at 9:13 AM Pommier, Rex wrote: > You make a good point about making security so onerous one can't use it. > At my employer, we use a third party cloud application (unnamed to conceal > the perpetrator) that doesn't use multi-factor yet. However their password > to get in has to be a minimum of 16 characters. No problem, right, just > use a passphrase type password. However, they also require upper, lower, > number, and special character. And they keep a history of 10 prior > passwords and require a change every 60 days. Their requirements pretty > much guarantee most people will be writing the passwords down, thus > bypassing a lot of the security they think they have. > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing LMOD doing APPLY
It's not the module that's missing, but the SMP/E definition for the module. You might search for a fix that adds the definition or removes the need for it. On Wed, Feb 7, 2024 at 11:07 AM Gord Neill < 02ff5f18e15f-dmarc-requ...@listserv.ua.edu> wrote: > Hello list, > We're trying to install z/OS 3.1 via CBPDO using the z/OS 2.4 COD system > as the base. We keep getting this message about an LMOD missing: > > GIM24601E ** LMOD ENTRY IEWLDR00 IS NEEDED FOR PROCESSING BUT IS NOT IN > THE SMPCSI LIBRARY > > We can see this module in SYS1.NUCLEUS and in SYS1.LPALIB on the COD > system. Is there a STEPLIB/JOBLIB that we need to include somewhere? > > Any guidance muchly appreciated! > > > > > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Antiquarian Curiosity: Pre-MVS/XA Mount Command for DASD Volumes
M addr,VOL=(SL,volser),USE={PUBLIC|PRIVATE|STORAGE}
There are those of us who use that command frequently when building
not-current versions of MVS...
On Thu, Feb 1, 2024 at 10:44 AM Michael Watkins <
032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:
> Before MVS/XA and RAID DASD, offline DASD volumes (e.g. 3330, 3350 & 3380
> units) had to be mounted instead of simply being varied online. The mount
> command used the volser of the offline DASD volume as a parameter.
>
> Does anyone remember the format of the mount command?
>
> Does anyone have the documentation in .pdf format?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Jay Maynard
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: So Long, and Thanks for All the Fish*
Cheryl, I never had much call to use your knowledge, but I know it has been useful to mainframe shops all around the world. I was more than a little pleased to see you were still around the other day. I hope you have plenty of time to enjoy a very well-earned retirement in the best of health. On Mon, Jan 22, 2024 at 10:34 PM Cheryl Watson wrote: > * For those too young to remember, check out Wiki > > Hi all, > > I’m retiring, but first want to send out a thank you to all the > IBM-Mainers still posting, as well as those who are no longer active. > IBM-Main has provided a life-line to me at times when I had nowhere else to > turn. (I remember one night at 3 am, where I was stuck on a problem, and > found someone who could help me here.) > > I’ve found IBM-Main a wonderful place to learn new tricks, ponder the pros > and cons of different approaches, and learn from some of the brightest in > the industry. (I have to admit that I tend to ignore the posts that delve > into the far annals of time, because I’m more focused on what is happening > now.) > > I haven’t been too active recently because Frank Kyne, our outstanding > Editor and President has been more involved in the technical side of > things. But I want you all to know how valuable this group has been to me > since it started. (Yes, I was one of those at the very beginning.) > > For more info on our retirement, please see our blog post at > https://watsonwalker.com/were-retiring/. > > Thanks from the bottom of my heart! > > All my best, > Cheryl Watson > == > Cheryl Watson Walker, CEO > Watson & Walker, Inc. > Sarasota, FL USA > www.watsonwalker.com > Cell/Text: 941-266-6609 > == > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
John von Neumann, call your office. On Sat, Jan 13, 2024 at 5:41 PM Seymour J Metz wrote: > Programs are data. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf > of Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> > Sent: Saturday, January 13, 2024 12:06 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Technical Reason? - Why you can't encrypt load libraries > (PDSE format)? > > I can imagine technical reason to not encrypt such libraries. > However encryption is a kind of data protection. Data. Not programs. > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > W dniu 13.01.2024 o 17:28, Steve Estle pisze: > > Everyone, > > > > Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and > despite the fact such functionality has been out for years by IBM to do > this, it is quite surprising how many software vendors when you contact > them they have no clue what you're talking about - that is a complete aside > - I'm not going to name vendors here but if you want some examples you can > contact me offline. > > > > My true reason for composing this is that we've discovered the inability > to encrypt load libraries - even in PDSE format. I've yet to get a > straight answer from IBM on why this is?... Is this a "giant" technical > hurdle for IBM? Or is it just cause there hasn't been anyone who raised > the need yet? If the latter does this capability interest others here if I > were to raise as an IBM idea - would you vote for it? > > > > I know this seems innocuous, but we'd like to encrypt as much as > possible in our environment and due to Top Secret deficiencies we have to > encrypt at high level qualifier level (HLQ) (all or nothing under each HLQ > unfortunately). Given we have load module libraries under many differ > HLQ's this is posing difficulties in moving forward with our rollout when > an HLQ does have one or more load module libraries as part of that HLQ. > You can only imagine the pain of renaming a load library given all the JCL, > etc that is referencing that library name. > > > > Also, while encrypting load module libraries might seem a little far > fetched, there are of course many malicious viruses that have been launched > by injecting code into a suspecting piece of code. > > > > So two questions: > > > > 1. Why has IBM not already provided such functionality - can anyone > speak to the technical hurdles to provide? > > 2. If I were to submit an IBM idea, can I count on this community for > some backing here to help in upvoting such an idea submission? > > > > Thanks for your indulgence, > > > > Steve Estle > > sest...@gmail.com > > Peraton systems programmer > > > > -- > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RETRY - was ARR and CSVQUERY
Doggone computers...durn things always do what you tell them to. On Sun, Dec 24, 2023 at 11:35 AM Tom Brennan wrote: > Thanks Peter! Yes, it was the surprise of an 0C4 when I expected 0C1. > Sometimes when totally confusing things like that happen I first assume > the computer itself is at fault, not the code I'm working on. And guess > what, it's always the code :) > > On 12/24/2023 5:58 AM, Peter Relson wrote: > > Tom B wrote > > > > I was referring to my experience with a JES2 exit which setup its own > > recovery routine. In that code you could see it free any getmain'd > > memory, etc. like you mentioned. But also in that code was an error > > that caused an 0C4. So when the x'00' I added for temporary debugging > > ran that user-coded recovery routine, I was surprised to get an 0C4 > > instead and had to fix the recovery routine. > > > > So of course JES2 had its own recovery routine in place that handled > > the 0C4 and we got a dump and JES2 went on its merry way, perhaps after > > disabling that exit (I can't remember). > > > > > > I took a weird view of what I suspect you really meant by "0C4 instead". > I'm now thinking > > you just meant that you were surprised that the recovery routine did not > complete successfully. > > But in case you were thinking of what happened to come to my mind, > here's some info: > > > > When the x'00' "instruction" was executed, it would have gotten an > operation exception > > and the most recently established recovery routine (see "special-case" > below) would have gotten control for the 0C1. > > Its SDWA would have shown that. And TCBCMPC would be x'0C1000'. > > > > If that recovery routine then took some exception that resulted in an > 0C4, a newer recovery routine (established by this recovery routine) or, in > the absence of such, the next-oldest recovery routine would have gotten > control for the 0C4. Its SDWA would have shown that . TCBCMPC would now be > x'0C4000'. > > > > Special-Case: if you have established SPIE/ESPIE for a program > interrupt, that exit will get control even if there is a newer-established > ESTAE-type recovery routine. > > > > Peter Relson > > z/OS Core Technology Design > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
A bit of Googling reveals that TAS is a component of BMC MainView. Under those circumstances, that OSA-ICC session might never talk to a VTAM application like TSO at all; if so, then there's no need for an application LU to pass the emulated terminal to VTAM. In either case, TAS handles all communication with the device, and VTAM never gets involved. On Thu, Nov 16, 2023 at 9:02 AM Jay Maynard wrote: > Yes, TAS is doing something under the covers. Since you're giving it a > device number to talk to the OSA-ICC device, that means that device is not > owned by VTAM at all, at any time; instead, TAS is talking to it directly > using channel programming like it's a channel-attached, non-SNA 3270 > terminal. Under those circumstances, there's no need tor an LBUILD/LU > combination for that device, since VTAM's not talking to it. Instead, > there's an LU definition in VTAM for TAS to pass the device through to > VTAM, and that LU (which need not be the same one for every session) is > what communicates with VTAM applications like TSO. > > On Thu, Nov 16, 2023 at 8:53 AM Michael Babcock > wrote: > >> Perhaps it would be better if I explain what we have. We use the BMC >> suite of products including the Terminal Address Space (an alternate >> access method I think they call it). Within TAS, there is a LOGON >> UCB(B400) parameter. The B400 corresponds to the OSA-ICC definition. >> We have a Visara 500LX box that contains a 3270 session with the same >> LUNAME and CUADDR as the OSA-ICC definition (B400). We do not have a >> LBUILD for B400 CUADDR anywhere in VTAM. I expected to see one however. >> I assume then that the TAS is doing something under the covers and >> as such VTAM doesn't need an LBUILD for B400. We do have LBUILDs for >> other B4xx addresses (but they don't use TAS, they are for TSO). >> >> On 11/16/2023 5:10 AM, Radoslaw Skorupka wrote: >> > W dniu 16.11.2023 o 01:47, Michael Babcock pisze: >> >> We have an OSA-ICC connection set up as a 3270 session type. The LU >> >> Name >> >> in that definition is TERM140. The CUA is B400.We have a 3270 >> >> session >> >> defined with the proper IP and the same LU Name of TERM140. This all >> >> works as expected. My question is that I thought a VTAM APPL with an >> >> LUNAME of TERM140 was required but I do not see a TERM140 defined in >> >> VTAM >> >> at all. I’m not a network guy. Since this is working, I assume >> >> it’s not >> >> required. Can someone enlighten me? >> > >> > In simple words, LUNAME used in OSA-ICC session definition and >> > emulator - it does NOT exist in any VTAM or TCPIP configuration. >> > Instead, VTAM use device number (devnum), which is in turn not used in >> > emulator session. However OSA-ICC session ties devnum with LUNAME. >> > Note: the same devnum can be used by different LPARs and every LPAR >> > has its own console/terminal. It is not shared, just "duplicate" >> > devnum. However OSA-ICC use devum *and* MIF and CSS to uniquely >> > identify the device. >> > >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > -- > Jay Maynard > > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
Yes, TAS is doing something under the covers. Since you're giving it a device number to talk to the OSA-ICC device, that means that device is not owned by VTAM at all, at any time; instead, TAS is talking to it directly using channel programming like it's a channel-attached, non-SNA 3270 terminal. Under those circumstances, there's no need tor an LBUILD/LU combination for that device, since VTAM's not talking to it. Instead, there's an LU definition in VTAM for TAS to pass the device through to VTAM, and that LU (which need not be the same one for every session) is what communicates with VTAM applications like TSO. On Thu, Nov 16, 2023 at 8:53 AM Michael Babcock wrote: > Perhaps it would be better if I explain what we have. We use the BMC > suite of products including the Terminal Address Space (an alternate > access method I think they call it). Within TAS, there is a LOGON > UCB(B400) parameter. The B400 corresponds to the OSA-ICC definition. > We have a Visara 500LX box that contains a 3270 session with the same > LUNAME and CUADDR as the OSA-ICC definition (B400). We do not have a > LBUILD for B400 CUADDR anywhere in VTAM. I expected to see one however. > I assume then that the TAS is doing something under the covers and > as such VTAM doesn't need an LBUILD for B400. We do have LBUILDs for > other B4xx addresses (but they don't use TAS, they are for TSO). > > On 11/16/2023 5:10 AM, Radoslaw Skorupka wrote: > > W dniu 16.11.2023 o 01:47, Michael Babcock pisze: > >> We have an OSA-ICC connection set up as a 3270 session type. The LU > >> Name > >> in that definition is TERM140. The CUA is B400.We have a 3270 > >> session > >> defined with the proper IP and the same LU Name of TERM140. This all > >> works as expected. My question is that I thought a VTAM APPL with an > >> LUNAME of TERM140 was required but I do not see a TERM140 defined in > >> VTAM > >> at all. I’m not a network guy. Since this is working, I assume > >> it’s not > >> required. Can someone enlighten me? > > > > In simple words, LUNAME used in OSA-ICC session definition and > > emulator - it does NOT exist in any VTAM or TCPIP configuration. > > Instead, VTAM use device number (devnum), which is in turn not used in > > emulator session. However OSA-ICC session ties devnum with LUNAME. > > Note: the same devnum can be used by different LPARs and every LPAR > > has its own console/terminal. It is not shared, just "duplicate" > > devnum. However OSA-ICC use devum *and* MIF and CSS to uniquely > > identify the device. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
Can you specify it at IPL time by replying to the IEA101A SPECIFY SYSTEM PARAMETERS message? You would need an IEASYSxx that has the necessary parameter to issue the prompt in it set up beforehand. On Thu, Nov 16, 2023 at 12:54 AM Laurence Chiu wrote: > It was gold for me and will help me settle a dispute with some local > sysprogs who said there would be no problem. My question is, it says if you > don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the > problem occurs, how do you get online to change it? I could not find an > operator command to change it and since the system is able to IPL, > you can't logon to change it. > > On Thu, Nov 16, 2023 at 4:18 PM kekronbekron < > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > > Awesome, how do we even find such gems with TechDocs being what it is... > > Luckily for this one, I seem to have it bookmarked. > > > > > > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi < > > fogar...@gmail.com> wrote: > > > > > > > Answered a decade ago including how to continue the IPL and get running > > > (either single system or sysplex without CF) > > > > > > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf > > > "The paper is being written to provide clear and concise instructions > on > > > how to address the sysplex support team’s most common callout. Where is > > My > > > Coupling Facility?" > > > > > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < > > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a > > > > X'0A3' wait state. > > > > > > > > Mark Jacobs > > > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > > > > GPG Public Key - > > > > > > > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > > > > > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < > > > > lch...@gmail.com> wrote: > > > > > > > > > Thinking about a LPAR defined as being in a parallel sysplex with > > > > > GRS=STAR. > > > > > > > > > > What happens if you IPL that LPAR and the CF is not active? Will it > > > > > start, > > > > > issue a WTOR or just fail? We are wondering what would happen if > our > > LPAR > > > > > was started at the DR site (off a replicated set of volumes) but > the > > DR > > > > > CEC > > > > > did not have a CF defined. 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 > > > > > > > > > -- > > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
Correct. Tony supplied what you need. A VTAM APL is for applications, like CICS and TSO, or for things that emulate terminals in software running under VTAM, like NetView Access or TPX. The OSA-ICC is, as far as VTAM is concerned, nothing more than a hardware 3270; all of the TCP/IP magic is in the firmware, below the level where VTAM sees or cares about it. On Wed, Nov 15, 2023 at 9:04 PM Michael Babcock wrote: > So you are saying I don’t need a VTAM APPL statement with an LU defined? > > On Wed, Nov 15, 2023 at 7:47 PM Jay Maynard wrote: > > > A VTAM APPL is used for a program. The OSA-ICC looks to VTAM like a plain > > old 3270 terminal. The LU definition that mentions the device number is > the > > only LU definition you need, or can have. > > > > On Wed, Nov 15, 2023 at 6:47 PM Michael Babcock > > wrote: > > > > > We have an OSA-ICC connection set up as a 3270 session type. The LU > > Name > > > in that definition is TERM140. The CUA is B400.We have a 3270 > > session > > > defined with the proper IP and the same LU Name of TERM140.This all > > > works as expected. My question is that I thought a VTAM APPL with an > > > LUNAME of TERM140 was required but I do not see a TERM140 defined in > VTAM > > > at all. I’m not a network guy. Since this is working, I assume it’s > > not > > > required. Can someone enlighten me? > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > > -- > > Jay Maynard > > > > -- > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC Connection Question
A VTAM APPL is used for a program. The OSA-ICC looks to VTAM like a plain old 3270 terminal. The LU definition that mentions the device number is the only LU definition you need, or can have. On Wed, Nov 15, 2023 at 6:47 PM Michael Babcock wrote: > We have an OSA-ICC connection set up as a 3270 session type. The LU Name > in that definition is TERM140. The CUA is B400.We have a 3270 session > defined with the proper IP and the same LU Name of TERM140.This all > works as expected. My question is that I thought a VTAM APPL with an > LUNAME of TERM140 was required but I do not see a TERM140 defined in VTAM > at all. I’m not a network guy. Since this is working, I assume it’s not > required. Can someone enlighten me? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT Help with JFY and SQZ
I'm getting the distinct impression that DFSORT is becoming a Swiss Army knife for the systems programmer, much like a SAS DATA step is. On Wed, Nov 8, 2023 at 9:04 AM Sri h Kolusu wrote: > >> Here is my code...can someone help me to get rid of the spaces in the > name, before the ( value? > > > Don, > > You are complicating a simple request. First build Only the fields you > need, and you can add the static characters using LEAD on the SQZ operator. > > Also, you don't have to get a seqnum in zd format and then convert that > into a Alphabet, you can directly use a BINARY format with sequence > starting at 193 and it would be the EBCDIC characters. > > //STEP0100 EXEC PGM=SORT > //SYSOUT DD SYSOUT=* > //SORTIN DD DISP=SHR,DSN=Your.Input.FB.file > //SORTOUT DD SYSOUT=* > //SYSINDD * > OPTION COPY > INCLUDE COND=(1,1,CH,EQ,C'>') > > INREC BUILD=(55,32,SQZ=(SHIFT=LEFT), >88,06, >C',', >49,03, >04,04,UFF,EDIT=(), >SEQNUM,1,BI,START=193,RESTART=(55,32), >80:X) > > OUTREC BUILD=(01,80,SQZ=(SHIFT=LEFT, >LEAD=C'-UTL COPY,TABLE,')) > /* > > The output from this is > > -UTL COPY,TABLE,B400-BRANCH-BLDG(1001),BRN0400A > -UTL COPY,TABLE,B400-TRANHIST(0003),HST0400A > -UTL COPY,TABLE,B400-TRANHIST(0004),HST0400B > -UTL COPY,TABLE,B400-TRANHIST(0005),HST0400C > > > Thanks, > Kolusu > DFSORT Development > IBM Corporation > > > > ---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM APAR Names
r than defects, > e.g., documentation, Small Program Enhancement (SPE). > > Is there an edition of the packaging guide that reflects IBMs current > practice? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > > > > > From: IBM Mainframe Discussion List on behalf > of Anthony Fletcher > Sent: Saturday, November 4, 2023 7:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM APAR Names > > This chain has an interesting range of opinions that I am not going to > comment on specifically, other than to point out that APAR started out > being the acronym for Authorised Problem Analysis Report which would be > outcome of a verified problem, NOT yet a fix. > Likewise PTF stands for Problem Temporary Fix. The final fix goes into the > next release. > > The use of ++APAR is really a mechanism to relate an early bypass before > the formal fix comes out as a ++PTF. > > But the bottom line is that any vendor that is using SMP/E has to follow > the rules of SMP/E but their naming conventions are theirs as long as they > don't conflict with other vendors rules and generate chaos in the SMP/E > database,. Vendors don't have to use SMP/E but in my experience the > knowledgebase covering problems and solutions is better using SMP/E than > any other method. > Anthony > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Mark Zelden > Sent: Sunday, November 5, 2023 9:36 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM APAR Names > > On Sat, 4 Nov 2023 07:19:49 -0500, Bruce Hewson > wrote: > > >HI, > > > >APARs for me are OAx or PHx - these are the entries describing a > problem, and may be associates as Error Holds to existing PTFs. > > > >Before a PTF is issued, the vendor may issue a ++APAR for you to test. A > ++APAR fix is not fully tested. > > > >++APAR names aill be AAx, BAx etc for each new iteration of a fix > for APAR OAx. > > > >So depending on how many attempts have been made to get the corrective > >fix for the problem described in APAR OAx you can see one or more > iterations of the ++APARs. > > > >The eventual PTF will SUPERCEDE all ++APARs that had been built during > testing of the fix for the APAR problem. > > > >When searching, say via Google, use the APAR number only, e.g. OAx > > > >This is how I was introduced to ++APAR naming conventions. > > > > Exactly... I was going through the thread to see if someone explained this > correctly and found your post. The APAR number is different than what is > seen in a ++APAR fix and then eventually > in ++PTF. fix. > > Not many people seem to understand this - at least people I have worked > with. I also > work with people that don't relationship between the APAR number and the > ++PTF that is show for "REL" when looking at IBMLINK or seeing what is in > the public domain from an APAR search in google. > > Regards, > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 > Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: > http://www.mzelden.com/mvsutil.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System Z Enthusiasts discord (yes - Z folks do use discord)
As I understand it, Discord has a corporate version. They also get funding from users' Nitro subscriptions. On Mon, Oct 16, 2023 at 8:00 AM Rick Troth wrote: > On 10/11/23 12:55, Lionel B. Dyck wrote: > > There is an online community for all System Z Enthusiasts on discord > that is > > growing. There are discussions ranging from the z/OS Open Tools to > Hercules > > to CBTape tools to Stack Overflow questions on Z to nearly anything and > > everything related to Z. > > > > Check it out at: https://discord.gg/3PKgUayuSV > > > Second this. > > If you wish, you can think of it as a VMSHARE work-alike. It's an > "online conference". > > Thanks Lionel for inviting us. Thanks Steven for setting it up. > > > > > Lionel B. Dyck <>< > > Website: https://www.lbdsoftware.com > > Github: https://github.com/lbdyck > > > > “Worry more about your character than your reputation. Character is what > you > > are, reputation merely what others think you are.” - - - John Wooden > > > I should also qualify this endorsement. There are two concerns, and > maybe they can be addressed in the near future. > First is supporting the forum. When you look at massively popular > platforms like Twitter and Facebook, you see their demise. How is > Discord funded? We should keep in mind that we likely will have to > step-up to some sort of support down the road. > LISTSERV gets by on the generosity of academic institutions (in this > case the University of Alabama, "Roll Tide!"). But even these sometimes > have to trim their budgets. > > Secondly, and this is personal, I much prefer interaction via email. > Would love to see platforms like Discord support that mode of > communication. Two very important "circles" in my own life use FB > Messenger, which is horribly captive. (But the others don't get it, not > being techie; they don't see the entrapment.) If someone happens to know > of a plug-in or a mod (in this case, to Discord) enabling email please > do share. The problems with email are historical (the original design) > and a tragedy of the commons (the unpoliced shared space will be marred > by the nere do wells). > > > -- R; <>< > > > > > -- > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Somewhat OT: 3279 front bezel needed
That too! Getting an Apple //e to run VT100 emulation at 19200 BPS turned out to be possible with the right program, but getting it on the machine turned out to be nontrivial. From there, though, it's a matter of plugging it into the 11L's AEA and using tn3270... On Tue, Sep 5, 2023 at 9:37 AM Mike Schwab wrote: > And an Apple ][ as console. > > On Tue, Sep 5, 2023 at 9:12 AM Jay Maynard wrote: > > > > One of my P/390s has the bus and tag hardware and a 3174-11L connected. > > (Well, technically they're R/390s and RS/370s, but still...) I also have > a > > 3174-63R talking via Token Ring. > > > > On Tue, Sep 5, 2023 at 9:10 AM Grant Taylor < > > 023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > On 9/5/23 8:56 AM, Jay Maynard wrote: > > > > I do! And two P/390s and two P/370s for it to talk to. > > > > > > Does that mean that you also have the associated B&T cards to connect > > > said P/390s / P370s to the 3174? > > > > > > I'd be very interested reading an article about and pictures of such a > > > setup. Even if it's an ongoing work in progress. > > > > > > > > > > > > -- > > > Grant. . . . > > > unix || die > > > > > > ---------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > > -- > > Jay Maynard > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > 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 message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Somewhat OT: 3279 front bezel needed
One of my P/390s has the bus and tag hardware and a 3174-11L connected. (Well, technically they're R/390s and RS/370s, but still...) I also have a 3174-63R talking via Token Ring. On Tue, Sep 5, 2023 at 9:10 AM Grant Taylor < 023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > On 9/5/23 8:56 AM, Jay Maynard wrote: > > I do! And two P/390s and two P/370s for it to talk to. > > Does that mean that you also have the associated B&T cards to connect > said P/390s / P370s to the 3174? > > I'd be very interested reading an article about and pictures of such a > setup. Even if it's an ongoing work in progress. > > > > -- > Grant. . . . > unix || die > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Somewhat OT: 3279 front bezel needed
I do! And two P/390s and two P/370s for it to talk to. On Tue, Sep 5, 2023 at 8:53 AM Mike Shaw wrote: > Jay, > > Have you got a 3174 also? > > I wrote code in 1981 that invoked GDDM/PGF to write to 3279s. It was fun to > see it display pie charts, bar graphs, etc. Very cool for the times. > > Mike Shaw > MVS/QuickRef Support Group > Chicago-Soft, Ltd. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Somewhat OT: 3279 front bezel needed
I drove 1800 miles over the long weekend, and now own a real live honest-to-goodness 3279 terminal. It's in somewhat rough shape, and in particular is missing the front bezel entirely. Does anyone around here know where I might be able to find one? The 3279 is pretty rare these days, so I won't be surprised if nobody has a line on one, but I'm casting as wide a net as possible. -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "XYZZY"?
I read something not long ago that had a line about "nobody tries to pronounce her name, since it's a Polish name with five silent Zs in it..." On Mon, Aug 28, 2023 at 1:23 PM Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > (My €0.02 contribution to the off-topic thread) > I'm happy Polish has no doubts regarding pronunciation. No flavours, > different versions, etc. > And it is IMHO very clearly and simply defined. Note, it doesn't mean > the Polish is easy to learn to at least easy to speak. > BTW: German pronunciation rules are also quite easy and consistent. > > Something to learn: > Szczebrzeszyn > Łękołody > Łódź > (Google translate will pronounce it quite correctly) > :-) > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > W dniu 27.08.2023 o 20:04, Bob Bridges pisze: > > I didn't think of PLUGH. I just pronounce that "ploo". > > > > Anybody here ever figure out what to do with "Hello, sailor!"? I never > did, > > but a friend of mine told me where it's valid. > > > > (Oh, "5-syllable pronunciation"! I get it now!) > > > > --- > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > > > /* Keep them watching their own minds and trying to produce ~feelings~ > there > > by the action of their own wills. When they meant to ask Him for > charity, > > let them, instead, start trying to manufacture charitable feelings for > > themselves and not notice that this is what they are doing. When they > meant > > to pray for courage, let them really be trying to feel brave. When they > say > > they are praying for forgiveness, let them be trying to feel forgiven. > > Teach them to estimate the value of each prayer by their success in > > producing the desired feeling; and never let them suspect how much > success > > or failure of that kind depends on whether they are well or ill, fresh or > > tired, at the moment. -advice to a tempter from The Screwtape Letters > by C > > S Lewis */ > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of > > David L. Craig > > Sent: Sunday, August 27, 2023 11:42 > > > > The only way I could ever get it to work was to spell it out, so I've > always > > pronounced it ex-why-zee-zee-why. > > Plugh also had to be spelled out, but it's pronunciation was much less > > enigmatic. > > > > --- On 23Aug27:0159-0400, David Cole wrote: > >> For 50 years, I've always used the five syllable pronunciation. > > ---------- > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Am I the only one who remembers JES2 level sets? On Mon, Aug 28, 2023 at 8:30 AM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > "You never see a PTF that is 1MB" > > JAVA SDK's ? > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Jon Perryman > Sent: Friday, August 25, 2023 8:56 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?] > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > > On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson < > ste...@wkyr.net> wrote: > > With Linux distros there are a few maint systems. The one I am most > > familiar with is RPM. > > Linux (nor Unix) does NOT have any maint systems. P in RPM stands for > Package which is the z/OS equivalent of product / component. Complete > packages are replaced regardless of the problems you want to fix. Every > package has a version number which is indentifies all the maintenance > included in that package. > > > To me YAST (the Linux equivalent of SMP/E) handles upgrades > > YAST and SMP/e have nothing in common. YAST tells you it's about > installation and configuration. It's about replacing the entire package and > nothing to do with maintaining that package. The M in SMP/e stands for > Maintenance. You never see a PTF that is 1MB. The only reason SMP/e > installs, is to create a maintenance environment for the product / > component. If installation is your only requirement, then use a different > tool like IEBCOPY, DFDSS or ???. > > > Each product/component has its own main entry and dependencies. > > Unix dependencies are by version number and have nothing to do with the > package (product/component) in question. The package is completely > replaced. SMP/e dependencies can be for entities within the same function, > other functions, PTFs and APARs. A function is the SMP/e equivalent of a > Unix package. > > > I thought it was a fairly good replacement for SMP/E for the Linux > > side of things. > > I can see how it could be used to do z/OS and related. > > YAST, RPM and other Unix package installers are unacceptable replacements > for SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an > entire product/component because they need 1 PTF. Add to that cascading > product installs because of dependencies. Worse than that, testing must > include everything that changed in those installs and every > product/component that interacts with all the installed products/components. > > I think z/OS uptime is 99.%. You get what you pay for. Unix maint > philosophy may be acceptable on $10,000 computers but highly unacceptable > on multi-million $ computers. We don't tolerate unintentional downtime. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received this > email in error please delete it and notify the sender immediately. Before > opening any email and/or attachments, please check them for viruses and > other defects. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ibm-main@listserv.ua.edu
; > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > > > How should the user code > > DD SYSOUT=(,),DSN=&SYSUID > > > > in order that the last qualifier of the system-generated name for the > sysout data set be the user ID under whose authority the job runs? > > > > How many ampersands? How many apostrophes? Is it even possible? > > > > -- > > gil > > > > -- > > 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 > > ::DISCLAIMER:: > > > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received this > email in error please delete it and notify the sender immediately. Before > opening any email and/or attachments, please check them for viruses and > other defects. > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the > message: INFO IBM-MAIN > > > Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA > 02451 ■ Main Office Toll Free Number: +1 855.577.4323 > Contact Customer Support: > https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - > http://www.rocketsoftware.com/manage-your-email-preferences > Privacy Policy - > http://www.rocketsoftware.com/company/legal/privacy-policy > > > This communication and any attachments may contain confidential > information of Rocket Software, Inc. All unauthorized use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > notify Rocket Software immediately and destroy all copies of this > communication. Thank you. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: Cloud may be overpriced compared to on-premises systems
Twitter has no topic. This mailing list does. On Wed, Aug 9, 2023 at 7:55 AM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > First he feeds the troll then tells others to ignore. He can’t even follow > his own suggestion. You obvious trump supporters don’t like when I produce > facts. I’m betting the same folks (over 50 white males mostly) who yell > free speech on Twitter are the ones who don’t like free speech here. And > before you go saying they are 2 different forums, the only difference is my > tax dollars support this one and Twitter is a private company that can > suppress speech. > > > Sent from Yahoo Mail for iPhone > > > On Wednesday, August 9, 2023, 8:17 AM, Allan Staller < > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > > Classification: Confidential > > To all, > Stop feeding the troll and maybe he'll go away > > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received this > email in error please delete it and notify the sender immediately. Before > opening any email and/or attachments, please check them for viruses and > other defects. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > ------ > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
El Reg on z/OS 3.1
According to The Register, z/OS 3.1 is largely about making the OS do more to manage itself because kids don't want mainframe jobs. Or something. Sounds like z/OSMF on steroids. https://www.theregister.com/2023/08/09/ibm_z_os_upgrade/ -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ibm-main@listserv.ua.edu
OK, but retrieving the dataset by what? Under what circumstances is a SYSOUT dataset retrieved by anything but a JES output writer? On Wed, Aug 9, 2023 at 6:32 AM Seymour J Metz wrote: > The constructed DSN is used for retrieving the dataset. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Jay Maynard [jaymayn...@gmail.com] > Sent: Wednesday, August 9, 2023 7:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DD SYSOUT=(,),DSN=&SYSUID? > > OK, dumb question time. Is the DSN on a SYSOUT dataset actually ever used > for anything? > > On Wed, Aug 9, 2023 at 2:25 AM Paul Gilmartin < > 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > > > On Wed, 9 Aug 2023 07:17:31 +0100, Jack Zukt wrote: > > > > >What is it that you are trying to acomplish? > > >Best wishes > > > > > I am trying to improve my understanding of JCL C/I processing. > > > > -- > > gil > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > Jay Maynard > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ibm-main@listserv.ua.edu
OK, dumb question time. Is the DSN on a SYSOUT dataset actually ever used for anything? On Wed, Aug 9, 2023 at 2:25 AM Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Wed, 9 Aug 2023 07:17:31 +0100, Jack Zukt wrote: > > >What is it that you are trying to acomplish? > >Best wishes > > > I am trying to improve my understanding of JCL C/I processing. > > -- > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: Cloud may be overpriced compared to on-premises systems
If you want Europe, you know where to find it. On Tue, Aug 8, 2023 at 9:38 AM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > You’re right, Europe is different. They actually care about people over > profits. Much better infrastructure, better health care, and better quality > of lives. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, August 8, 2023, 10:34 AM, Jay Maynard > wrote: > > In case you haven't noticed, the US is much, much different from Europe, in > many ways big and little that bear on this discussion. > > But, in typical Bill Johnson fashion, he's convinced he's right and will > defend his opinions, well-informed or not, to the death. > > On Tue, Aug 8, 2023 at 9:29 AM Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > Lol, you should have followed your own advice. My dad drove truck his > > whole life. Never once did wind cause an issue. Yeah, it happens, but not > > frequently. And American roads are way more dangerous than European > roads. > > The data (facts) are clear. So profit over lives is a Republican choice. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Tuesday, August 8, 2023, 10:20 AM, Steve Thompson > > wrote: > > > > I've driven in Germany, Austria and Switzerland and some island > > countries. And I held, for over 15 years a CDL-A with Multi and > > Tanker endorsements. > > > > I did not drive LKW (semis) anywhere but within the USofA. And a > > box truck once into Canada. > > > > Stick to what you know, not what what the Huffy post or others say. > > > > Governors are used by different companies. Some limit their > > trucks to 64MPH. Owner operators can get their trucks with no > > governors at all. > > > > I have a son-in-law that is finishing his training to be a Diesel > > mechanic able to work on all the current Tractors in the USofA. > > The electronics are unbelievable, and can cause that truck to be > > down for weeks waiting on some solid state relay board (or > > whatever). The world of trucking has changed significantly since > > I started driving back about 2004. > > > > Because I'm also a pilot, I know a bit about wind and its > > effects. Stick to what you know, what you have experienced. > > > > I've seen fully loaded trucks get blown over (55,000+ gross). > > I've seen trucks lose control in snow and swap ends. Managed to > > not jack knife. > > > > Thankfully I never had any problems, no accidents, no incidents. > > I was lucky and I was a novice and just applied my knowledge of > > physics and energy management that I learned in flying to driving > > a 70,000 gross weight truck. I loaded the trucks so the weight > > was more at the bottom than top (I had specialty loads of barn > > beams). > > > > Stick to what you know. > > > > Take this crap out of here and go argue it elsewhere. > > > > Steve Thompson > > > > > > > > On 8/8/2023 9:07 AM, Bill Johnson wrote: > > > I’ve driven roads in Europe. Every truck is in the right most lane, > > unless they are passing which isn’t common. It’s nothing like the US > > trucking which is designed for large trucks and fast speeds. That’s > exactly > > why the carnage on US highways from trucks is way higher. And wind as an > > excuse is just silly. Or speed differential. > > > In Germany and other European Union counties, trucks with a gross > > vehicle weight rating of 3.5 tonnes (7,700 pounds) or more must have a > > governor that limits their speed to 90 kph (54 miles per hour). > > > > > > > > > Sent from Yahoo Mail for iPhone > > > > > > > > > On Tuesday, August 8, 2023, 3:52 AM, Jeremy Nicoll < > > jn.ls.mfrm...@letterboxes.org> wrote: > > > > > > On Tue, 8 Aug 2023, at 01:56, Bill Johnson wrote: > > >> In Europe all the trucks go the same speed. > > > Rubbish. Age of truck and how heavy its load is are certainly factors. > > > > > > An unloaded truck, is a lot more susceptible to high winds so might > > > be driven slower in those conditions; trucks with no load with curtain- > > > sides often have their curtains open in high winds to significantly > > > reduce wind effects. But that's impossible if there's a partial load > > > or nowhere safe for the driver to open (and tie back) the curtains. > > > > > >> The trucks all have governors. > > > No
Re: [EXT] Re: Cloud may be overpriced compared to on-premises systems
In case you haven't noticed, the US is much, much different from Europe, in many ways big and little that bear on this discussion. But, in typical Bill Johnson fashion, he's convinced he's right and will defend his opinions, well-informed or not, to the death. On Tue, Aug 8, 2023 at 9:29 AM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > Lol, you should have followed your own advice. My dad drove truck his > whole life. Never once did wind cause an issue. Yeah, it happens, but not > frequently. And American roads are way more dangerous than European roads. > The data (facts) are clear. So profit over lives is a Republican choice. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, August 8, 2023, 10:20 AM, Steve Thompson > wrote: > > I've driven in Germany, Austria and Switzerland and some island > countries. And I held, for over 15 years a CDL-A with Multi and > Tanker endorsements. > > I did not drive LKW (semis) anywhere but within the USofA. And a > box truck once into Canada. > > Stick to what you know, not what what the Huffy post or others say. > > Governors are used by different companies. Some limit their > trucks to 64MPH. Owner operators can get their trucks with no > governors at all. > > I have a son-in-law that is finishing his training to be a Diesel > mechanic able to work on all the current Tractors in the USofA. > The electronics are unbelievable, and can cause that truck to be > down for weeks waiting on some solid state relay board (or > whatever). The world of trucking has changed significantly since > I started driving back about 2004. > > Because I'm also a pilot, I know a bit about wind and its > effects. Stick to what you know, what you have experienced. > > I've seen fully loaded trucks get blown over (55,000+ gross). > I've seen trucks lose control in snow and swap ends. Managed to > not jack knife. > > Thankfully I never had any problems, no accidents, no incidents. > I was lucky and I was a novice and just applied my knowledge of > physics and energy management that I learned in flying to driving > a 70,000 gross weight truck. I loaded the trucks so the weight > was more at the bottom than top (I had specialty loads of barn > beams). > > Stick to what you know. > > Take this crap out of here and go argue it elsewhere. > > Steve Thompson > > > > On 8/8/2023 9:07 AM, Bill Johnson wrote: > > I’ve driven roads in Europe. Every truck is in the right most lane, > unless they are passing which isn’t common. It’s nothing like the US > trucking which is designed for large trucks and fast speeds. That’s exactly > why the carnage on US highways from trucks is way higher. And wind as an > excuse is just silly. Or speed differential. > > In Germany and other European Union counties, trucks with a gross > vehicle weight rating of 3.5 tonnes (7,700 pounds) or more must have a > governor that limits their speed to 90 kph (54 miles per hour). > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Tuesday, August 8, 2023, 3:52 AM, Jeremy Nicoll < > jn.ls.mfrm...@letterboxes.org> wrote: > > > > On Tue, 8 Aug 2023, at 01:56, Bill Johnson wrote: > >> In Europe all the trucks go the same speed. > > Rubbish. Age of truck and how heavy its load is are certainly factors. > > > > An unloaded truck, is a lot more susceptible to high winds so might > > be driven slower in those conditions; trucks with no load with curtain- > > sides often have their curtains open in high winds to significantly > > reduce wind effects. But that's impossible if there's a partial load > > or nowhere safe for the driver to open (and tie back) the curtains. > > > >> The trucks all have governors. > > No they don't. Some do. Even so it sets a maximum speed not > > the actual speed. > > > >> They are also all in the right lane. > > By "right" do you mean "correct"? Or do you mean the slowest > > lane? In any case trucks are permitted to be in the next fastest > > lane while overtaking a slower truck. > > > > > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: Cloud may be overpriced compared to on-premises systems
There's one thing you're ignoring: research shows that speed differential is more of a factor in accidents and injuries than absolute speed. A truck going 10 MPH slower than the rest of traffic is more of a hazard than a truck moving at traffic speed, even at 70 MPH. On Mon, Aug 7, 2023 at 7:02 PM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > European roads are way better than US roads. Size & speed are the 2 most > important factors in accidents. A larger/heavier vehicle traveling at a > high rate of speed takes much longer to stop than a lighter slower vehicle. > Basic physics. Wet or icy roads even longer stopping distance. That > explains why this is true. > > Most EU member states have fewer than 80 road deaths per million people > per year. Most U.S. states have more — and ten have at least double that > figure. Even Romania, the worst performer in the EU, is doing better than > almost half of all U.S. states.Jun 1, 2022 > > Profits take preference over lives. > > > > Sent from Yahoo Mail for iPhone > > > On Monday, August 7, 2023, 7:46 PM, Seymour J Metz wrote: > > I'm assuming that Bill Johnson has look at statistics on deaths per > kilogram-kilometer (or deaths per ton-mile if you don't like Metric). And, > yes, there are other factors affecting that, e.g., condition of road > surface. > > Personally, I think that truck speed and truck size are independent > variables, so I would like to see a study that did a four-way comparison: > large-fast, large, slow, small-fast, small-slow. I suspect that speed is > more relevant than size, but data trump suspicions. And what about shipping > by rail or, where feasible, by boat? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Bob Bridges [robhbrid...@gmail.com] > Sent: Monday, August 7, 2023 7:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXT] Re: Cloud may be overpriced compared to on-premises > systems > > This is off-topic, and I'll happily take it up with both Bill and Shmuel > offline if requested. But I may as well point out that "fewer deaths" may > not be as simple as they're assuming. It seems likely to me as well that > if we had smaller trucks going slower, fewer people would die in accidents > caused by bigger trucks going faster. But how many people would die > because of smaller trucks going slower? You gotta compare deaths to > deaths, not simply deaths to nothing. > > Why would people die from smaller trucks going slower? Well, a good deal > less cargo would be transported as a result, and I surmise (but it's only > surmise) that there'd be a lot more pressure on drivers, as a result, to > produce more. Some of that pressure would translate to tired drivers. And > all of it would translate to more expensive transportation, meaning that > poorer people would have increased difficulty affording the goods that are > cheaper now. > > Don't assume I'm saying that it's better as we do things now. I'm not; > I'm just saying that "this cause of death would be reduced" is no help > unless you can estimate how many deaths would also increase. And if anyone > thinks there'd be NO deaths owing to more expensive goods, I'll just shut > up. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* A good scare is worth more than good advice. -Horace (65 BC – 8 BC) */ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Bill Johnson > Sent: Monday, August 7, 2023 18:45 > > For Americans here who’ve never been to Europe, trucks in Europe are much > smaller than US trucks, are required to have governors to limit their > speed, and are restricted to the right lane. The result is far fewer > traffic deaths involving trucks. > > In addition, Europeans almost never drive pickups and their automobiles > are much smaller. > > Their rates of deaths and serious injury are far less than America. > > So for you pro life people, perhaps some road restrictions would keep more > people alive. > > -- > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
A Cray-1 could use a CDC, or an IBM, or a VAX, and possibly others as front end processors. One cow orker in the dim recesses of my past had worked on the IBM Cray Station software before she went to work where I was. On Wed, Aug 2, 2023 at 4:02 PM Grant Taylor < 023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > On 8/2/23 10:35 AM, Allan Staller wrote: > > My vague recollection of the CRAY was that is used (at the time) > > a 370/158 to buffer up all of the data so the CRAY could run full tilt. > > That may very well have been a possibility. > > I read that the CRAY used a CDC mainframe a it's front end for this > purpose. > > But I would not be at all surprised if an IBM mainframe could function > equivalently. > > > > -- > Grant. . . . > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Me too. I learned more in the MVS Internals course I took from Amdahl than any other mainframe class. Really sharp folks. On Mon, Jul 31, 2023, 16:50 Tom Brennan wrote: > I went to some Amdahl MVS internal classes around 1990. The instructors > were probably previous IBMers, and just seemed so relaxed having fun > teaching. I had a great couple of weeks and learned tons. > > On 7/31/2023 1:29 PM, Steve Thompson wrote: > > 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. > > -- > 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: Definition of mainframe? Was: Ars Technica
be computer experts instead of business line experts. > Google management thinks it's cheaper to spend $4,000 for each of their > 5,500,000 servers than $4,000,000 for each IBM z16 computer needed. You get > what you pay for. > > ASK YOURSELF: Are people delusional when they call the mainframe a > dinosaur when it's more advanced than the most advanced workstations and > servers? > > What is the definition of mainframe? > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ignorant z/OS question
Do you really think you're accomplishing anything by getting personally insulting? ...that is, beyond destroying your own credibility and potential future job prospects? If I was looking at your resume, I'd think twice about keeping it instead of sticking it in the nearest shredder. On Sat, Jul 29, 2023 at 11:17 PM Jon Perryman wrote: > > On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz < > sme...@gmu.edu> wrote: > > I'm perfectly willing to be civil with people who are civil, > > If I'm continually "wrong again", how is it that we arrived at the > solution? Does anyone think that Seymour was leading Phil towards a > solution to his problem? I'm civil to those who earn and demonstrate > respect instead of demanding it. Lack of humility and the inability to > understand the value of what others say is not a sign of respect. To > prattle on about complete nonsense is not a sign of respect. What in any > way was Seymour's comments being useful or informative? With the help of > others, I was able to lead Phil to a solution for his problem and a > solution he understands. I have no doubt that Seymour thinks he played a > vital role in solving this problem but as he says, the devils in the > details. I don't expect people to have all the correct answers but I do > expect humility and respect for everyone in this group (not just me). > Disagreements are expected but complete dismissal is not acceptable. I will > show respect as long as respect is returned. As long as everyone is being > respected, I will return that respect. Time will tell if Seymour has > actually learned from what I've said. > > Please accept my apologies for those who are upset with me but there is a > line that I will not allow to be crossed without some form of retribution. > > On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz < > sme...@gmu.edu> wrote: > > I'm perfectly willing to be civil with people who are civil, but when > someone insists on repeated personal attacks. Take a look at the history of > this thread and you will see that I have been restrained by comparison. > > > From: IBM Mainframe Discussion List on behalf > of Jay Maynard > Sent: Saturday, July 29, 2023 6:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Ignorant z/OS question > > Now folks...let's not descend into personal name-calling, how about? > > On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman wrote: > > > > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz < > > sme...@gmu.edu> wrote: > > > Wrong again. When running z/OS under VM for production, multiple 3270 > > consoles is the norm. > > > > See-more Putz. What are you saying is wrong with my second sentence that > > says "z/OS has many consoles." which applies to native and z/VM. Can you > > stop with the non-stop nonsense. > > > >On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz < > > sme...@gmu.edu> wrote: > > > > Wrong again. When running z/OS under VM for production, multiple 3270 > > consoles is the norm. > > > > > > From: IBM Mainframe Discussion List on behalf > > of Jon Perryman > > Sent: Saturday, July 29, 2023 5:04 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Ignorant z/OS question > > > > > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III < > > li...@akphs.com> wrote: > > > After changing the virtual console address from 03E1 to 0009 > > > linemode output went to SECUSER without artifacts > > > > > > Congrats Phil. Here is what you need to know: > > > > 1. z/OS has many consoles. You don't have any consoles activated. The > > hardware console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing > to > > do with DEV(3E1) in CONSOL##. > > > > 2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the > > terminal is defined (DEF CONS, DEF GRAF or ATTACH). If someone decides > they > > need a console located next to the tape drives and another console next > to > > printers, then DEV(SYSCONS) will no longer be automatically activated. > > > > 3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default > for > > screen full with non-autoscroll messages requires a real person clear the > > screen. This VM user typically would not be logged on. It could be days > or > > weeks before someone notices the message backlog. > >On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
Re: Ignorant z/OS question
Now folks...let's not descend into personal name-calling, how about? On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman wrote: > > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz < > sme...@gmu.edu> wrote: > > Wrong again. When running z/OS under VM for production, multiple 3270 > consoles is the norm. > > See-more Putz. What are you saying is wrong with my second sentence that > says "z/OS has many consoles." which applies to native and z/VM. Can you > stop with the non-stop nonsense. > > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz < > sme...@gmu.edu> wrote: > > Wrong again. When running z/OS under VM for production, multiple 3270 > consoles is the norm. > > > From: IBM Mainframe Discussion List on behalf > of Jon Perryman > Sent: Saturday, July 29, 2023 5:04 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Ignorant z/OS question > > > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III < > li...@akphs.com> wrote: > > After changing the virtual console address from 03E1 to 0009 > > linemode output went to SECUSER without artifacts > > > Congrats Phil. Here is what you need to know: > > 1. z/OS has many consoles. You don't have any consoles activated. The > hardware console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing to > do with DEV(3E1) in CONSOL##. > > 2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the > terminal is defined (DEF CONS, DEF GRAF or ATTACH). If someone decides they > need a console located next to the tape drives and another console next to > printers, then DEV(SYSCONS) will no longer be automatically activated. > > 3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default for > screen full with non-autoscroll messages requires a real person clear the > screen. This VM user typically would not be logged on. It could be days or > weeks before someone notices the message backlog. > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III < > li...@akphs.com> wrote: > > After changing the virtual console address from 03E1 (matching the > CONSOLE entry in CONSOLxx) to 0009 (matching no z/OS console definition) > and reIPLing the guest, the linemode output went to SECUSER without > artifacts, as it did on our old hosting environment. > > I'm convinced based on the evidence that: > > *The old environment had the virtual console at 0009 > *The old environment had the z/OS CONSOLE definition at 03E1 > *The folks who ported our system over for us had logon access to the > old environment, but did NOT have access to the VM directory entry for the > guest > *They thus made the logically correct decision to define the virtual > console at 03E1 > > > That was the "right thing to do", except it turned out to change the > behavior in an unintuitive way. Now we know. > > Thanks 10**6 for all the thoughts and advice here! It was a bit of an > odyssey but we got there. > > And this might be due an IBM-MAIN award for the longest thread without > significant topic drift, at least in a while. No idea why, but that's rare > here! > > ...phsiii > > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives
When I got into systems work in 1982, I was at an engineering shop. All of the terminals were 3278-2s aside from a few leftover 3277-2s. There was exactly one 3279-S3G, in the general manager's office so he could do GDDM charts. On Thu, Jul 27, 2023 at 11:02 AM Colin Paice wrote: > In the days when 3270-2 was the best available, and 3279s with colour were > just announced, a team from a bank came round to see these new machines. > One of the executives asked "why do we need colour?" The reply from a > quick thinking developer was "so you can display overdrawn accounts in > red!" - and the executive was sold on the idea. > Colin > > On Thu, 27 Jul 2023 at 15:26, billogden wrote: > > > Long ago and far away I helped an IBM customer set up his new 148 VS1 > > machine to use CICS. At that time it had the macro interface, but as an > > assembly programmer that was good for me. 3270s were very new at the > time > > and controlling the screen appearance was important. The customer was an > > Electric company (in a very different cultural environment) and we rather > > quickly started production use, initially to simply display customer > data. > > > > Some early mistakes: The IBM marketing people were very much unfamiliar > > with > > display terminals and thought that 3270-1 was a good start. I managed to > > change that immediately! (Who remembers the 3270-1?). > > > > We (myself (as an IBM SE) and the customer (both technical and > management)) > > were very happy with how quickly the system became useful. IIRC (which is > > more difficult at my age) we were the first "real" virtual memory > customer > > in that part of the world. We had about a dozen terminals on the system > and > > had no response problems with the terminals or with batch jobs. CICS, at > > least in those days, seemed very efficient. > > > > Being young and stupid, I liked VS1. > > > > Bill Ogden > > > > -- > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives
itasking within each AOR, > > and thus requiring CICS versions of OS commands to prevent wait states > > from freezing the entire AOR? A CICS program can do direct GETMAINs, > > LOADS, abends, rather than use CICS commands? CICS no longer requires > > special versions of tools (e.g. debugger, abend dump management) and > > instead can use the same tools as batch programs? A CICS programmer no > > longer needs to learn a long list of CICS commands and EXEC CICS > > syntax? A CICS region no longer contains the storage from all of the > > transactions currently running and is now only one transaction in the > > region at a time? CICS transactions can no longer stomp on each other's > memory? > > > > Great, I did not know that. > > > > IMS/TM uses the operating system for multitasking. There are no IMS/TM > > specific tools. An IMS/TM programmer only needs to know two commands, > > one to get a message and another to send it. IMS transaction abends > > look > > (almost) exactly like a batch abend. IMS programs have no restrictions > > on OS facilities. An IMS program can even do an STIMER (WAIT) without > > affecting any other transaction processing. Because, it uses the OS to > > do > > *preemptive* multitasking, like a modern operating system. > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Crawford Robert C (Contractor) > > Sent: Tuesday, July 25, 2023 8:14 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and > > why it survives > > > > Sorry, I worked in a shop that had both and I can tell you CICS is way > > more flexible, modern and performed better. > > > > I will give you this: IMS is a great piece of 90's technology. > > > > Robert Crawford > > Abstract Evolutions LLC > > (210) 913-3822 > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Schmitt, Michael > > Sent: Monday, July 24, 2023 11:43 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [EXT] Ars Technica: The IBM mainframe: How it runs and why it > > survives > > > > Ars Technica published a deep-dive explainer of modern IBM mainframes: > > > > > > https://urldefense.com/v3/__https://arstechnica.com/information-techno > > logy/2023/07/the-ibm-mainfra__;!!KjMRP1Ixj6eLE0Fj!rNa-SaGicFiF68vSt9OY > > ExPvljK4ShqzUuxW9fAMxwJNqupUj5wjtWSiwuUmUuPL5Zz9fb1K1RGcyBzezNfMZS69W9 > > lqPfp6mPyI$ > > me-how-it-runs-and-why-it-survives/ > > > > > > I’d quibble with the application server topic that talks about CICS > > with no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows > > 10. 😊 > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby notified > that any disclosure, distribution, copying, or any action taken or action > omitted in reliance on it, is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify us immediately > by replying to this message and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives
tion > > systems. > > Which one is the real dinosaur? (Hint: It's not CICS) > > > > Regards, > > David > > > > On 2023-07-25 10:37, Schmitt, Michael wrote: > >> So CICS is no longer doing cooperative multitasking within each AOR, > and thus requiring CICS versions of OS commands to prevent wait states from > freezing the entire AOR? A CICS program can do direct GETMAINs, LOADS, > abends, rather than use CICS commands? CICS no longer requires special > versions of tools (e.g. debugger, abend dump management) and instead can > use the same tools as batch programs? A CICS programmer no longer needs to > learn a long list of CICS commands and EXEC CICS syntax? A CICS region no > longer contains the storage from all of the transactions currently running > and is now only one transaction in the region at a time? CICS transactions > can no longer stomp on each other's memory? > >> > >> Great, I did not know that. > >> > >> IMS/TM uses the operating system for multitasking. There are no IMS/TM > specific tools. An IMS/TM programmer only needs to know two commands, one > to get a message and another to send it. IMS transaction abends look > (almost) exactly like a batch abend. IMS programs have no restrictions on > OS facilities. An IMS program can even do an STIMER (WAIT) without > affecting any other transaction processing. Because, it uses the OS to do > *preemptive* multitasking, like a modern operating system. > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > >> Behalf Of Crawford Robert C (Contractor) > >> Sent: Tuesday, July 25, 2023 8:14 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and > >> why it survives > >> > >> Sorry, I worked in a shop that had both and I can tell you CICS is way > more flexible, modern and performed better. > >> > >> I will give you this: IMS is a great piece of 90's technology. > >> > >> Robert Crawford > >> Abstract Evolutions LLC > >> (210) 913-3822 > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > >> Behalf Of Schmitt, Michael > >> Sent: Monday, July 24, 2023 11:43 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: [EXT] Ars Technica: The IBM mainframe: How it runs and why > >> it survives > >> > >> Ars Technica published a deep-dive explainer of modern IBM mainframes: > >> > >> https://arstechnica.com/information-technology/2023/07/the-ibm-mainfr > >> ame-how-it-runs-and-why-it-survives/ > >> > >> > >> I’d quibble with the application server topic that talks about CICS > >> with no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to > >> Windows 10. 😊 > >> > >> > >> > >> - > >> - For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > >> > >> - > >> - For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > >> > >> > >> > >> - > >> - For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > > ---------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Will z/OS be obsolete in 5 years?
Yes, it is, because quantum computing enables solving classes of problems that current machines can't. But it is a very poor fit for the overwhelming majority of computing tasks today. Put another way: a z/Series vector facility isn't going to do much good computing payroll. Neither is a quantum system. On Wed, Jul 19, 2023 at 8:21 AM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > Billions is being spent on developing quantum computing. I doubt it’s > because they’ve got money to waste. > > > https://newsroom.ibm.com/2023-05-21-IBM-Launches-100-Million-Partnership-with-Global-Universities-to-Develop-Novel-Technologies-Towards-a-100,000-Qubit-Quantum-Centric-Supercomputer > > > https://thenextweb.com/news/europes-throwing-billions-at-quantum-computers-will-it-pay-off > > > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, July 18, 2023, 11:29 PM, zMan wrote: > > Bill, Bill, Bill. Stick to stuff you know something about. IF quantum > computers ever become realistically powerful, they will have VERY specific > uses. They are not suited for general-purpose computing. Nobody even > quantum-adjacent disputes that, as even the most cursory reading of the > research papers will tell you, > > Note also that quantum machines with the many-thousands of qubits needed > for real use have been "almost here" for quite some time; most people who > aren't scamming money admit that they don't know when or even if they're > actually achievable. Which doesn't make the research a bad thing, of > course. Just keep your hand on your wallet. > > On Tue, Jul 18, 2023 at 9:21 PM Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > Quantum computing is the future. And IBM is the leader. > > > https://www.forbes.com/sites/karlfreund/2023/06/14/ibm-achieves-breakthrough-in-quantum-computing/ > > > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Tuesday, July 18, 2023, 8:47 PM, Jon Perryman > > wrote: > > > > IBM RHEL announced it's move to closed source (IBM RedHat Enterprise > > Linux). With some changes, DB2, RACF and other z/OS products could run in > > Linux on z16 in one sysplexed Linux image. We know it's possible because > > IBM moved Unix and TCP into z/OS. IBM RHEL said closed source would force > > non-paying customers to buy RHEL licenses but this makes no sense. > > Something else must be in play. > > I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain > > insights into IBM's decision to close source RHEL. You can skip the > survey > > if you don't want to take it and view the survey results through this > > website. Feel free to pass this along. > > I think IBM wants to integrate z/OS products to retain their investments > > and expand their customer base.. > > Why is the z/OS community ignoring IBM RHEL closed source? Are software > > vendors preparing their products for Linux? > > > > > > -- > > 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 > > > > > -- > zMan -- "I've got a mainframe and I'm not afraid to use it" > > ------ > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
The one I use was formed by taking the first four non-vowels of the last name and then the first and second initials. And, of course, the usual collection of department code plus sequential number (T40TS01), or installation code plus sequential number (YHX0382), or group code plus initials (S0JM)... On Thu, Jul 13, 2023 at 4:22 PM Phil Smith III wrote: > I've seen various schemes used for creating up-to-eight-character userids, > all truncated as needed, of course. These are IDs I've had, won't tell ya > where each was (and omitting just firstname, just lastname, or intials): > > 1. First initial, last name, plus a number as needed: PSMITH, PSMITH1 > 2. Last name || first name, with number if necessary, but always > including first initial: SMITHIIP, or SMITHIP2 if needed > 3. First three of last name, first two of first name, plus a number: > SMIPH03 (I've always wondered how they'd deal with Kyle Fuchs or Tyrone > Shipman) > 4. First initial, last name, truncated to max of six with a two-digit > number: I was PSMITH87; friend was TSMITH99-we never found out what the > next T. Smith would get: would they reuse a hole, if any, or go to TSMIT100? > > > Anyone got any other variations? This is purely a curiosity item, no > agenda. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOLD Action of a superseded PTF
I would expect that. if new code made the hold action unnecessary, the superseding PTF would note that. On Thu, Jun 1, 2023 at 7:42 AM Seymour J Metz wrote: > While it is probable that the hold should be present on the superseding > PTF, it has happened that new code makes the hold unnecessary. If it is > still necessary and IBM did not propagate it, things will break. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Allan Staller [0387911dea17-dmarc-requ...@listserv.ua.edu] > Sent: Thursday, June 1, 2023 8:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: HOLD Action of a superseded PTF > > Classification: Confidential > > If the PTF has been superseded, that means all of the code in the prior > PTF has been included. In the superseding. Therefore, the action is still > applicable. > IBM has been incredibly consistent in maintain this relationship. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Radoslaw Skorupka > Sent: Thursday, June 1, 2023 7:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: HOLD Action of a superseded PTF > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > As far as I understand the question is: > some PTF has ACTION, but it was superseded by newer PTF which does NOT > have the ACTION. > Is it possible? IMHO yes. > Should you perform the ACTION? IMHO no. No, because it is possible someone > received newer PTF, but not superseded one. In that case he would see only > HOLDSYS assigned to the newer PTF. Which means the ACTION is not needed, > otherwise it would be also assigned to the newer PTF as well. > > My €0.02 > > -- > Radoslaw Skorupka > Lodz, Poland > > > > W dniu 01.06.2023 o 14:13, Allan Staller pisze: > > Classification: Confidential > > > > Short version. Yes. Many times the same action hoid will be repeated > multiple times for each ptf in that particular "chain". > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Munif Sadek > > Sent: Wednesday, May 31, 2023 8:58 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: HOLD Action of a superseded PTF > > > > [CAUTION: This Email is from outside the Organization. Unless you > > trust the sender, Don’t click links or open attachments as it may be a > > Phishing email, which can steal your Information and compromise your > > Computer.] > > > > My SMP APPLY CHECK has multi pages of ++ HOLDSYS ACTION items but APPLY > only a couple. > > > > Do I have to take HOLDSYS Action of the Superseded PTFs as reported in > the APPLY CHECK SMP Report but not listed in the APPLY JOB SMP report? > > > > regards > > Munif. > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received this > email in error please delete it and notify the sender immediately. Before > opening any email and/or attachments, please check them for viruses and > other defects. > > > ---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Two related member generation questions
SMP used to do this, and ISTR SMP/E does as well. On Tue, May 30, 2023 at 9:34 AM Schmitt, Michael wrote: > And IMS. MFS Formats have non-display and lower-case letters in the member > names. > > Such as: > > ."wACOV0 > 07ACCDEF > 2F613650 > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Steve Thompson > Sent: Tuesday, May 30, 2023 8:19 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Two related member generation questions > > I may not have edited these posts correctly for this, but, I > thought I should point out that an IBM product does create > "illegal" (per JCL) member names. And that would be Netview. > > In years gone by I had seen member names that were really "odd" > and found out that it was Netview that was creating them. > > So yes, an assembler programmer could do this and have done this, > because it has been done. > > Steve Thompson > > On 5/30/2023 12:11 AM, Paul Gilmartin wrote: > > > > Can't an Assembler programmer using STOW create PDS members with names > > beginning with '+', '-', '0', 'π', ... just about anything? I don't > believe it's proper > > for higher layers such as JCL to introduce syntactic restrictions > harsher than > > those of core layers. The only member name prohibited is 8X'FF', > indicaring > > the end of a PDS directory. > > > > How do LM services accessible, e.g. through REXX support member > "generations"? > > > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Are Banks Breaking Up With Mainframes? | Forbes
Bob Bridges < > robhbrid...@gmail.com > > > > > > > wrote: > > > > > > > > Bill, you said "bull", which I misunderstood to mean that you > disagree. > > > > But the article you posted in support of that opinion (or whatever it > > is) > > > > doesn't contradict the OP's article. > > > > > > > > I'm just guessing here, but maybe you've been arguing with those > > > > mainframe-is-dying folks so long that you no longer notice the > nuances. > > > Ms > > > > Hovsepian didn't say the mainframe is dying; she said a lot of banks > > > > (repeat banks) are considering (repeat considering) moving to the > > cloud. > > > > > > > > (To be fair, it sounds like she made the same mistake. "Why the > > > readiness > > > > to 'swipe left' on their mainframe and COBOL applications?", she asks > > in > > > a > > > > throwaway inference.) > > > > > > > > --- > > > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > > > > > > > /* Perseverance is not a long race; it is many short races one after > > > > another. */ > > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List On > > Behalf > > > > Of Bill Johnson > > > > Sent: Saturday, May 20, 2023 10:27 > > > > > > > > Bull. > > > > > > > > > > https://www.flynetviewer.com/blog/20220922/global-mainframe-market-projected-grow-318-billion-2029 > > > > > > > > --- On Saturday, May 20, 2023, 4:03 AM, Jack Zukt > > > > > wrote: > > > > Whatever the agenda of the writer, it still is something that is > > > > happening, mostly, I think, because of IBM's SW pricing strategy. > > > > > > > > --- On Fri, May 19, 2023, 20:14 Mark Regan > > wrote: > > > > > > > https://www.forbes.com/sites/forbesfinancecouncil/2023/03/31/are-banks > > > > > -breaking-up-with-mainframes/?sh=acb458b6bccc > > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > -- > > > zMan -- "I've got a mainframe and I'm not afraid to use it" > > > > > > -- > > > 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 > > > > > > > > > -- > > zMan -- "I've got a mainframe and I'm not afraid to use it" > > > > -- > > 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 > > > > > -- > zMan -- "I've got a mainframe and I'm not afraid to use it" > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
Treat the page size as 4K and drive on. The difference in execution speed probably isn't worth the issues. On Fri, Apr 28, 2023 at 7:15 AM Seymour J Metz wrote: > Set the initial length to the remaining bytes on the "page". After that, > use the "page size". That leaves the question of how an unpriveleged > program determines the "page size". > > Scare quotes because a 1 MiB "page" is actually a segment in the > nomenclature of PoOps. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org] > Sent: Friday, April 28, 2023 7:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Inexplicable 0C4! > > On Fri, 28 Apr 2023, at 12:31, Michael Stein wrote: > > > How about setting the length to include just to the end of the current > > page. Then as the first operand doesn't cross a page boundary ... > > Just imagine if the first operand started on the last byte of the page! > > Wouldn't it be better to getmain a page (or a few more), just for the > first operand to reside in, and then follow your "do it in chunks" > approach? > > -- > Jeremy Nicoll - my opinions are my own. > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: reallocating a linklist dataset
Yes, an IPL is incredibly disruptive. There are times, however, where it is needed to prevent even greater disruption from catastrophic system failures. It seems to me that reallocating a dataset on the linklist is one such time. On Sun, Apr 9, 2023 at 7:39 AM Peter Relson wrote: > Bill G wrote > > Would the dataset be de-allocated at IPL so I might redefine my dataset? > Or would there be allocation across the sysplex for other Lpars? > > All the allocations are local to the system. The only safe time to do what > you want is while any system(s) using that data set are not IPL'd. It is > > Doug F wrote > > Take LLA down. > Take the dataset out of the active LNKLIST > Reallocate it. > Put it back. > Start LLA > > > That is incomplete and therefore cannot be considered correct. The missing > step is unpredictably dangerous and you take it wholly at your system's > risk. Only you can decide if that risk is worth taking. > > The 2nd step above would really be stated as making sure that nothing is > running with a LNKLST set (there could be multiple) that has the current > data set in it. In most cases you would do that by defining a single new > LNKLST set that does not have the data set. If, within this window, work > needs that data set you'll need to have a copy of the data set within the > new LNKLST set. Once defined, then you would activate this new LNKLST set. > > Then you get to making sure that no address space is using a LNKLST set > that has the data set in it. > That is the unpredictably dangerous step. SETPROG LNKLST UPDATE will > happily do what you tell it to do. > Don't rely on your system to stay up after that happens. Will it? Very > likely. Will it stay up without encountering problems? Very likely. Can you > tell if something bad is going to happen in advance? No. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Currency format suggestions, please?
It's even weirder than that: it would be written 11 84 89 088. (Or with commas instead of spaces.) Look up the words "lakh" and "crore". On Thu, Mar 30, 2023 at 6:43 PM Bob Bridges wrote: > What, you mean like 1 18 48 90 88? Yeah, you'd think that would be > confusing when trying to think of it as 113MB. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* Black's Rule of Inverse Metaphysical Certainty: The surer you are about > what happens when you die, the less I believe you. -Terry Black */ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Rupert Reynolds > Sent: Thursday, March 30, 2023 17:49 > > Yes. Some sources say blanks as thousands separators are recognised > internationally, especially in Europe. I wouldn't go that far, but I've > seen it in the wild in a few places around Europe. > > The pairs of digits between commas in India were the biggest surprise to > me, so far. > > --- On Thu, 30 Mar 2023, 22:04 Bob Bridges, wrote: > > Spaces, really? I thought I was the only one who'd adopted that. I > > first saw it suggested by Isaac Asimov, but no one else seems to have > > got the memo. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Almost gone
I'm sorry to hear of the demise of another mainframe shop...and that the equipment is being destroyed. I'm sure there's some hobbyist out there who would love to put the equipment to use. (Maybe even me.) The CKD DASD, certainly, would be useful to several hobbyists I know, as well as at least one museum, and the destruction of the data on the disks is easy enough to assure to prevent any HIPAA issues. On Wed, Mar 29, 2023 at 10:17 AM John McKown wrote: > HealthMarkets z9BC is shutting down. User access will be removed 5Apr. CICS > will be unavailable after 31Mar. The last day is at the end of April. Most > of the equipment is so old it is being destroyed, except for the tape > drives which are being sold for parts. SCRT will be run on 2May. I'll be on > the payroll until the beginning of August in lieu of severance. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Stop the ragging on COBOL please [was: RE: ASM call by value]
And this is the reason I think complaints about Python's syntactic indentation miss the point: it's simply the language using what you should be doing anyway. On Wed, Mar 29, 2023 at 8:13 AM Joe Monk wrote: > "Too many languages lack ELSEIF and strong closure. Fie on > the danglig ELSE!" > > Now you know why COBOL programmers always indented their code ... it helps > line up the IF...ELSE structure. That was of course before VS COBOL II > (Cobol '85). > > Joe > > On Wed, Mar 29, 2023 at 8:01 AM Paul Gilmartin < > 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > > > On Wed, 29 Mar 2023 14:16:56 +, Robert Prins wrote: > > > > >> w..., and IBM rejected the original SHARE > > >> requirement for a CASE statement. > > > > > >But the SELECT statement that they added (before my time) later beats > the > > >crap out of CASE in C & Pascal. > > > > > Pascal CASE may have a performance advantage if it can be > > implemented with an indexed branch table. But how much does > > it matter? > > > > Isn't SELECT (I know Rexx, not PL/I) just an ELSEIF chain? > > > > Too many languages lack ELSEIF and strong closure. Fie on > > the danglig ELSE! > > > > -- > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fascinating Interview with Steve Jobs [non-mainframe]
I'm not so sure about Kildall...anyone who snubs a business meeting with IBM to go flying (a worthy endeavor in and of itself) isn't businessman enough to compete with Jobs and Gates. On Wed, Mar 29, 2023 at 3:05 AM Wayne Bickerdike wrote: > Very interesting if one-sided interview. He gives Steve Wozniak very little > credit although Woz really was the inventor and Jobs the salesman in the > partnership. > > I read Sculley's autobiography many years ago (From Pepsi to Apple). It > doesn't describe events quite the same way. > > Nevertheless, good that it has surfaced at a time where nobody gets sued > for defamation. > > After I left IBM in 1979 I wrote some applications on the Apple II. It was > a challenge and from an electrical engineering point of view, it was poor > with a weak power supply that ran the CPU, Floppy drives which caused the > screen to wobble when operating. > > At the same time Apple were turning out the IIE, there was a host of other > nicer systems, such as the Cromemco System 3 and Altos 8000 which ran CP/M > and MP/M and had a more robust construction. > > It was a shame that Gary Kildall died so young, he would have been a great > competitor for Jobs and Gates. > > On Wed, Mar 29, 2023 at 9:28 AM Charles Mills wrote: > > > A friend shared this with me and I thought it was just extraordinary. It > > is not "mainframe" but his comments on what happens when the marketeers > run > > a tech company will resonate with many of us. It’s a fairly long read. > It’s > > a transcript of a long interview done for a TV show – only a few minutes > > were actually used – by Bob Cringely, and thought to be lost. Steve Jobs > > was at the time (1995) running NeXT, which he was to sell to Apple a > month > > later. It is a fascinating read. > > > > https://sameerbajaj.com/jobs/ > > > > Charles > > > > -- > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for our international friends (mostly)
The word you're looking for is "aspirated": you're noticing the difference between aspirated and unaspirated /k/. In English, the two sounds are recognized as different realizations of the same phoneme (allophonic). On Sun, Mar 19, 2023 at 8:34 AM Bob Bridges wrote: > If you'll allow me just a bit of linguistic geekery, it's because the > nature of the following 'k' sound is different. When we say "kin", the 'k' > sound has a very slight expiration of breath after it, not so much that you > would think I was actually pronounced an 'h' but it's there. When we say > "skin", that slight expiration is missing. So when I hear "wih-SKAHN-sin" > and compare it to "wiss-KAHN-sin", I'm pretty sure that the difference is > actually in the 'k' sound, although my brain interprets it as the placement > of the 's'. Same with "rack-EFF" and "ra-KEFF". > > Phoneticists have a word for this (but I'm not a phoneticist, just a > dabbler, so I couldn't tell you off-hand what the word is); it happens with > the other plosives, too, in for example "pat" and "spat", and "tamp" and > "stamp". -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for our international friends (mostly)
This Texan always spelled out CICS, and pronounces the piece of networking equipment, the woodworking tool, and the path taken on a trip with the same vowel value, rOWt. My roommate is from north central Wisconsin, and does so as well...and hates Bobby Troup for "Route 66"'s pronunciation. On Sat, Mar 18, 2023 at 5:29 AM Lennie Dymoke-Bradshaw < 032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote: > In Australia "rooter" means something rather different, so I suggest you > don't look it up. > I was always surprised that most of my USA friends say rowt , but they all > agree they get their kicks (CICS?) on root 66. > Lennie > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of > Jeremy Nicoll > Sent: 18 March 2023 01:49 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Question for our international friends (mostly) > > On Sat, 18 Mar 2023, at 01:38, Bernd Oppolzer wrote: > > Very interesting discussion. > > > > I recently tried to understand what the correct pronounciation of the > > word "router" is, because here in Germany there are different > > opinions. And I learned in the end, that BOTH ways are correct, like > > "rooter" and (don't know how to spell the other, > > maybe) "row-ter". > > In the UK, usual usage is "rooter" for the network device, but "row-ter" > for the woodworking tool. > > -- > Jeremy Nicoll - my opinions are my own. > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for our international friends (mostly)
I once had to call Mercedes-Benz Customer Service to let them know I had purchased a new (to me) used car. I gave them the VIN using the iCAO phonetics. The customer service rep commented on how it was refreshing to get someone who knew how to give letters phonetically... On Fri, Mar 17, 2023 at 7:23 PM Bob Bridges wrote: > Under marginal conditions (which includes cell-phone calls) I use alpha / > bravo / charlie / ... / x-ray / yankee / zulu. But "zed" is probably > unmistakable. > > I'm always surprised how many help-desk folks are perfectly comfortable > with that alphabet. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* I know God won't give me more than I can handle. But there are times I > wish He didn't trust me quite so much. -anonymous, but speaks for most of > us. */ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Jay Maynard > Sent: Friday, March 17, 2023 18:18 > > I've always pronounced my ham callsign kay five zed see ...but I use "zee" > elsewhere. "Zed" works better under marginal conditions. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for our international friends (mostly)
I've always pronounced my ham callsign kay five zed see ...but I use "zee" elsewhere. "Zed" works better under marginal conditions. On Fri, Mar 17, 2023 at 4:00 PM Wayne Bickerdike wrote: > I was giving a talk to some of our guys in Phoenix about REXX. About an > hour into my talk, one of the guys said, "excuse me, what is 'zed'' ". Oops > "zee". > > Always amazed how US English strayed from the home origins. > > In the North of England we always said zebbra not zeebra. Sarf and Norf are > completely different. > > On Sat, Mar 18, 2023, 07:35 Bob Bridges wrote: > > > In English the letter 'z' is a voiced 's'. > > > > I believe the Italians pronounce it 'ts' like the Germans. > > > > --- > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > > > /* If you're going to walk on thin ice, you may as well dance. */ > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Bernd Oppolzer > > Sent: Friday, March 17, 2023 16:10 > > > > not exactly "six" ... more like "tsix", the first letter sounds like a Z > > in Germany, a letter T followed by a letter S. > > > > It comes to my mind that most other languages don't pronounce the letter > Z > > this way, only we Germans do ... the other (like French and English) > simply > > say S. > > For example zebra. How do you pronounce it? The word is the same in all > > three languages, I guess ... > > We say t-s-ebra. > > > > --- Am 17.03.2023 um 20:36 schrieb René Jansen: > > > I’ve heard Germans say ‘six’; in Dutch we say ‘kicks’ like the Brits. > > > > -- > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
Yes, there are indeed Linux package managers. They don't get beyond the "replace the entire package" level. THey have no concept of individual fixes and their interactions. On Tue, Mar 14, 2023 at 7:14 PM Seymour J Metz wrote: > There are a lot of people using package managers in the Linux world, and a > lot of software available as, e.g., deb, rpm, files. To say nothing of, > e.g., cvs, git, SCCS, svn. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Jay Maynard [jaymayn...@gmail.com] > Sent: Tuesday, March 14, 2023 5:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: not using SMPe > > That's because SMP/E and its power are only truly present in the z/OS and > predecessors world. Everyone else thinks of applying maintenance as a > matter of replacing the entire product, instead of individual fixes that > are automatically maintained and managed. > > On Tue, Mar 14, 2023 at 4:22 PM Ed Jaffe > wrote: > > > SMP/E use for products like Java, NodeJS, Zowe, etc. is almost pointless > > since they always do full product replacements. > > > Jay Maynard > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
That's because SMP/E and its power are only truly present in the z/OS and predecessors world. Everyone else thinks of applying maintenance as a matter of replacing the entire product, instead of individual fixes that are automatically maintained and managed. On Tue, Mar 14, 2023 at 4:22 PM Ed Jaffe wrote: > SMP/E use for products like Java, NodeJS, Zowe, etc. is almost pointless > since they always do full product replacements. > Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers
Oh, you can bet I'll tell the world what I think...not like I'm exactly shy, now am i? :-) On Fri, Mar 3, 2023 at 10:14 AM Ed Jaffe wrote: > On 3/3/2023 3:53 AM, Jay Maynard wrote: > > I am assured they are working on a replacement, but I have no details. > > When you do get the details, please post your reactions here on IBM-MAIN. > > For the record, I predict you won't like it... but one never knows... > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system > into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers
heavily on porting tools to z/OS and have a dedicated > >> team headed up by a distinguished engineer. IBM don't do altruism so > >> they obviously take this seriously. I see they have a port of rsync > >> which piqued my interest. > >> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools&data=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D&reserved=0 > >> > >> > >>> > >>> > >>> -- R; <>< > >>> > >>> -- > >>> 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers
I haven't tried to write anything in Rexx, let alone a TCP server. I'd probably be inclined to use Go for that, though. JCL to Python: https://medium.com/theropod/the-journey-from-jcl-to-python-so-easy-even-an-old-mainframer-can-do-it-f088cc49366a On Thu, Mar 2, 2023 at 6:54 AM David Crayford wrote: > On 2/3/23 20:43, Jay Maynard wrote: > > "The mainframe needs to keep pace with the industry." > > > > I certainly hope that whatever the industry is doing that gets adapted to > > the mainframe does so much more cleanly than, say, Python... > > Like what? Have you ever tried to write a TCP server in REXX? > > > > The absolute abortion that is Python's idea of replacing JCL makes COBOL > look like APL. > > I haven't seen that. Can you post a link? > > > > > > On Thu, Mar 2, 2023 at 6:37 AM David Crayford > wrote: > > > >> On 2/3/23 19:48, René Jansen wrote: > >>>> I think 99% of the folks on this forum want a language that can run in > >> a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's > >> orders of magnitudes faster then REXX with the advantage of package > >> management. The next gen guys don't use TSO/ISPF and they're going to > use > >> Python and couldn't give a hoot about NetRexx. > >>> NetRexx can and does, using the IBM jzos classes, which are delivered > >> with its JVM’s. > >> > >> Hmm, I don't think so. NetRexx programs can not reside in PDS data sets. > >> I don't get the point of NetRexx. > >> > >> > >>> They can do a lot more with conventional MVS than LUA, I am sure. > >> Don't agree. Lua4z has a heap of integrations including TSO/ISPF without > >> VDEFINE. And you can write packages and applications using PDS data > >> sets. REXX is impoverished in this respect and you can't share state or > >> data structures between modules. > >> > >> /https://lua4z.github.io/Lua4z > >> > >>> Not that anyone would do that, of course, being so much easier with > ISPF > >> and Rexx and their shared variable pool. I have built dialogs in COBOL > and > >> PL/1 but nothing beats Rexx for that, having not to VDEFINE everything > >> first. > >> > >> That's subjective. I find it much easier to write code in Lua. A > >> programming language that supports OO, meta-programming, functional > >> programming and co-routines with just 20 reserved words is a thing of > >> absolute beauty and a testament to the designers. REXX is a niche > >> language that's only used to any great extend on mainframes and it's > >> popularity is constantly eroding. The mainframe needs to keep pace with > >> the industry. > >> > >> -- > >> 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers
"The mainframe needs to keep pace with the industry." I certainly hope that whatever the industry is doing that gets adapted to the mainframe does so much more cleanly than, say, Python... The absolute abortion that is Python's idea of replacing JCL makes COBOL look like APL. On Thu, Mar 2, 2023 at 6:37 AM David Crayford wrote: > On 2/3/23 19:48, René Jansen wrote: > >> I think 99% of the folks on this forum want a language that can run in > a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's > orders of magnitudes faster then REXX with the advantage of package > management. The next gen guys don't use TSO/ISPF and they're going to use > Python and couldn't give a hoot about NetRexx. > > NetRexx can and does, using the IBM jzos classes, which are delivered > with its JVM’s. > > Hmm, I don't think so. NetRexx programs can not reside in PDS data sets. > I don't get the point of NetRexx. > > > > They can do a lot more with conventional MVS than LUA, I am sure. > > Don't agree. Lua4z has a heap of integrations including TSO/ISPF without > VDEFINE. And you can write packages and applications using PDS data > sets. REXX is impoverished in this respect and you can't share state or > data structures between modules. > > /https://lua4z.github.io/Lua4z > > > Not that anyone would do that, of course, being so much easier with ISPF > and Rexx and their shared variable pool. I have built dialogs in COBOL and > PL/1 but nothing beats Rexx for that, having not to VDEFINE everything > first. > > That's subjective. I find it much easier to write code in Lua. A > programming language that supports OO, meta-programming, functional > programming and co-routines with just 20 reserved words is a thing of > absolute beauty and a testament to the designers. REXX is a niche > language that's only used to any great extend on mainframes and it's > popularity is constantly eroding. The mainframe needs to keep pace with > the industry. > > ---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cant SPKA to PSW Key 4
tructions, > >> send email tolists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> > >> with the message: INFO IBM-MAIN > >> > >> > >> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA > >> 02451 ■ Main Office Toll Free Number: +1 855.577.4323 > >> Contact Customer Support: > >> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport > >> Unsubscribe from Marketing Messages/Manage Your Subscription > Preferences - > >> http://www.rocketsoftware.com/manage-your-email-preferences > >> Privacy Policy - > >> http://www.rocketsoftware.com/company/legal/privacy-policy > >> ============ > >> > >> This communication and any attachments may contain confidential > >> information of Rocket Software, Inc. All unauthorized use, disclosure or > >> distribution is prohibited. If you are not the intended recipient, > please > >> notify Rocket Software immediately and destroy all copies of this > >> communication. Thank you. > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > Robert W. Shimizu > Partner, Concierge > ColeSoft Marketing, Inc. > (800) 932-5150 > (928) 771-2003 > > bshim...@colesoft.com <mailto:bshim...@colesoft.com> > www.colesoft.com <http://www.colesoft.com/> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zOSMF and zOWE for non-mainframers
The discussion about standard libraries like Python's came up in a recent discussion on LinkedIn about REXX, and David Boyes said he was working on something along those lines for REXX. He said he hopes to have it ready for the next VM Workshop. On Tue, Feb 28, 2023 at 6:28 AM Seymour J Metz wrote: > What about Java? How well does JIT work? > > The gold standard for REXX is ooRexx, but IBM has not seen fit to > integrate it into z/OS or z/VM. > > However, for off the shelf package libraries, Perl and Python are > admittedly ahead of REXX. What are the Python and Ruby equivalents of CPAN? > > I've found extending REXX for CMS and TSO to be easy, although admittedly > assembler is mothers' milk to me and I didn't have to deal with LE issues. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of David Crayford [dcrayf...@gmail.com] > Sent: Tuesday, February 28, 2023 12:47 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: zOSMF and zOWE for non-mainframers > > On 25/2/23 01:23, Farley, Peter wrote: > > Python on the mainframe is pretty good, but still can't beat out Rexx in > performance even when the Rex script needs to use BPXWUNIX and friends to > access z/OS Unix file systems, > > > > I have conducted a series of benchtests, and the results suggest that > REXX is not as fast as Python. In my testing, I compare the performance > of C, Lua, Python, and REXX, and the results are clear: C is the > fastest, followed by Lua, which is within an order of magnitude of C. > Python comes next, within an order of magnitude of Lua, and REXX > consistently performs the poorest. In addition to the performance > factor, the vast Python ecosystem compared to the limited options > available for REXX also make it an easy decision. Python is also simpler > to extend with packages, while REXX requires more effort and potentially > complex steps, such as using modern libraries that require Language > Environment (LE). > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5
Am I the only one who remembers the original Sysout Display and Search Facility FDP and marvels at what SDSF has become? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSEn 6.3 hardware requirements
Yup. It started out as a box stock z/OS ADCD and didn't need any alterations. On Sat, Jan 14, 2023, 20:09 Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > I provided official IBM statements. Some of them do not conform > technical ones. > BTW: What does it mean "managed"? Did you simply IPL the system with no > "black magic" changes? > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > W dniu 15.01.2023 o 03:04, Jay Maynard pisze: > > I managed a z/OS 1.6 system running on a P/390... > > > > On Sat, Jan 14, 2023, 19:41 Radoslaw Skorupka < > > 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > > > >> z/OS 1.4 - last system with so called bimodal accomodation - a right to > >> run in 31-bit mode on 64-bit machine. > >> z/OS 1.5 - last system able to run on 31-bit machine. > >> z14 - first machine which disabled ESA/390 mode for IPL. z/OS 1.13 was > >> the first which run on z14. > >> > >> Of course this is a little bit off-topic, since the original question > >> was about VSE 6.3 :-) > >> To complement, z/VSE 6.2 supported up to 10 CPs, but used only up to 4 > >> CPs. That means it will not run on 11+ CPs LPAR, but on i.e. 8-CP LPAR > >> it will run and use max. 4 CPs. Up to 32GB of memory, however you could > >> assign more to the LPAR. The rest will be unusable. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> > >> W dniu 15.01.2023 o 01:36, Mike Schwab pisze: > >>> OS/390 v2.10 had PTFs to add 64 bit mode. > >>> z900 announcement z/OS 1.01 had 64 bit mode included. > >>> Default 64 bit with 1.04. > >>> About 1.10 64 bit required. > >>> z14 Around 2.01 IPLed in 64 bit. > >>> > >>> On Sat, Jan 14, 2023 at 5:07 PM Steve Thompson > wrote: > >>>> I get the understanding that it and the current release of z/VSE > >>>> from IBM are effectively the same (kinda like OS/390 V2.10 and > >>>> z/OS 1.1 -- assuming my memory is correct on the last release of > >>>> OS/390): > > -- > 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: VSEn 6.3 hardware requirements
I managed a z/OS 1.6 system running on a P/390... On Sat, Jan 14, 2023, 19:41 Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > z/OS 1.4 - last system with so called bimodal accomodation - a right to > run in 31-bit mode on 64-bit machine. > z/OS 1.5 - last system able to run on 31-bit machine. > z14 - first machine which disabled ESA/390 mode for IPL. z/OS 1.13 was > the first which run on z14. > > Of course this is a little bit off-topic, since the original question > was about VSE 6.3 :-) > To complement, z/VSE 6.2 supported up to 10 CPs, but used only up to 4 > CPs. That means it will not run on 11+ CPs LPAR, but on i.e. 8-CP LPAR > it will run and use max. 4 CPs. Up to 32GB of memory, however you could > assign more to the LPAR. The rest will be unusable. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > W dniu 15.01.2023 o 01:36, Mike Schwab pisze: > > OS/390 v2.10 had PTFs to add 64 bit mode. > > z900 announcement z/OS 1.01 had 64 bit mode included. > > Default 64 bit with 1.04. > > About 1.10 64 bit required. > > z14 Around 2.01 IPLed in 64 bit. > > > > On Sat, Jan 14, 2023 at 5:07 PM Steve Thompson wrote: > >> I get the understanding that it and the current release of z/VSE > >> from IBM are effectively the same (kinda like OS/390 V2.10 and > >> z/OS 1.1 -- assuming my memory is correct on the last release of > >> OS/390): > >> > > -- > 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: Soc7 abend
Well, your declaration of the INP-VNDR-PACK-COST variable doesn't seem to match the actual data...the decimal point is in the wrong place (two characters to the right), and there's an undeclared minus sign... On Thu, Jan 12, 2023 at 11:45 AM Ron Thomas wrote: > Hi Listers > > I was looking a Cobol code module developed and we ran in to a sco7 issue. > I am not able to figure why this is abending. > > Any help to fix is much appreciated. > > Here is the spool display i have captured. > > 05 INP-VNDR-PACK-COST PIC 9(9)V9(4). > 05 WS-VNDR-PACK-COST PIC S9(9)V9(4) COMP-3. > > INP-VNDR-PACK-COST -035.65 > 4CDD6EDCD6DCCD6CDEE46FFF4FF4 > 095705549071320362300035B650 > --- > WS-VNDR-PACK-COST -0 > 4EE6EDCD6DCCD6CDEE46F444 > 06205549071320362300 > --- > > MOVE INP-VNDR-PACK-COST TO WS-VNDR-PACK-COST > -> Here it is failing > > > CEE3207S The system detected a data exception (System Completion Code=0 > 4CCCE4E88489488A88A8848488A848A889A89944EAAA894C8A8994C9887F > 03553207203850282354045353354010413105735739650D2823540364735396503645E0 > > > Regards > Ron T > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question and CZAM and IPL
Basically, LPSW takes a doubleword, rearranges the bits, and makes a quadword out of it that it then loads into the PSW. On Wed, Jan 11, 2023 at 10:09 AM Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Wed, 11 Jan 2023 15:56:02 +, Seymour J Metz wrote: > > >The quoted text is on page 10-56 (p. 1072 in the PDF) of a227832d.pdf, > the June 2022 edition of z/Architecture Principles of Operation, > SA22-7832-13. What is the issue with "doubleword"? > > > If it replaces a 16-byte PSW it should be a quadword. > > (Or does it mean "the content of the location designated by the doubleword > at the > second-operand address"?) > > > > > > >On Wed, 11 Jan 2023 15:30:25 +, Seymour J Metz wrote:2 > > > >>Standard nomenclature for System/360, inherited through Z, is > >> > >>Halfword (16 bits) > >>Word (32 bits) > >>Doubleword (64 bits) > >> > >>Quadword (128 bits) is newer. > >> > >If you supply a citation, I'll submit an RCF. > > > >___ > >>On Wed, 11 Jan 2023 14:03:24 +, Seymour J Metz wrote: > >> > >>>"The current PSW is replaced by a 16-byte PSW > >>>formed from the contents of the doubleword at the > >>>location designated by the second-operand address. > >>>Figure 4-3 on page 4-8 illustrates the contents of the > >>>second operand." > >>> > >>"doubleword"? > > -- > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS compression needs a new name - defoam? unfoam? degas? I hope someone has a better idea!
At one shop I worked for long ago, there was a proc named DEGAS that did PDS compression. On Wed, Dec 21, 2022 at 8:41 AM Paul Gorlinsky wrote: > Burping ... because we are removing the gas trapped above in a PDS > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx function STORAGE with weird behavior on Netview
Hr... There has to be some significance to it only breaking on Netview on that system. Maybe that Netview proc has something going on weird in a library concatenation or something? On Mon, Dec 19, 2022 at 10:32 AM Eric D Rossman wrote: > That's the expected behavior. STORAGE is documented that the first arg is > a string containing the hexadecimal address. A decimal number will be > converted to a string in this case but treated as hexadecimal. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Paul Gorlinsky > Sent: Monday, December 19, 2022 10:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: Rexx function STORAGE with weird behavior on > Netview > > Yes they all returned the appropriate values ... > > But unexpected since 10+0 should have been passed as a decimal number and > not a string ... maybe this is IBM REXX v ooREXX ... don't know... > > 10+4 is 14 decimal and storage treated it as 14 hex > > just not the behavior I have seen with other REXX implementations... > > more experimenting > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can I get the true jobname in JCL
You can now put a JOB statement in an STC PROC?! On Fri, Dec 16, 2022 at 10:10 AM Steve Smith wrote: > Well, I've only used the new &SYSJOBNM for batch jobs, as the old &JOBNAME > seems to work well for STCs. However! I found (in MVS System Commands) > the following description of the rabbit hole that is names of STCs: > > The job name for a given started task can be assigned based on a variety of > > inputs. These inputs are examined in the following order, so that if item > > #1 is not specified, item #2 is used. If neither #1 nor #2 is specified, > > then #3 is used, and so on. > > > >1. The job name specified in the JOBNAME= parameter of the START > >command > > > >or > > > >The identifier specified on the START command. > >2. The job name specified on the JOB JCL statement within the member. > >3. The device number specified on the START command, or the device > >number associated with the device type specified on the START command > > > >or > > > >The device number associated with the device type specified on the > >START command. > >4. The device number associated with the IEFRDER DD statement within > >the member. > >5. The member name. > > > > IBM® recommends that you use the JOBNAME parameter rather than an > > identifier. If you use the JOBNAME parameter, SMF records, messages, and > > automated programs can reflect or react to job status; identifiers can > only > > be viewed at a console. > > Note: JOBNAME and identifier are mutually exclusive; you cannot specify > > both parameters on the START command. > > > > Nothin's simple. It would be interesting to see how all the options affect > both variables. > > sas > > On Fri, Dec 16, 2022 at 9:37 AM Colin Paice wrote: > > > Wth > > S OMPROUTE.OMP4 &SYSJOBNM gives OMROUTE > > S OMPROUTE,JOBNAME=OMP4 gives OMP4 > > > > I can live with this > > > > Colin > > > > On Fri, 16 Dec 2022 at 14:31, Colin Paice wrote: > > > > > Thank you .. I'll raise some doc comments, as it is not well > documented. > > > It is only mentioned in the > > > *what's changed in 2.3 * > > > Colin > > > > > > On Fri, 16 Dec 2022 at 13:04, Steve Smith wrote: > > > > > >> This was asked and answered before. &SYSJOBNM > > >> > > >> sas > > >> > > >> On Fri, Dec 16, 2022 at 4:07 AM Colin Paice > > >> wrote: > > >> > > >> > If I start OMPROUTE.OMP1, or issue Start OMPROUTE,JOBNAME=OMP1, can > I > > >> get > > >> > the > > >> > OMP1 as a JCL symbol so I can use it to pick up different > > configuration > > >> > members? > > >> > I can crawl around the control blocks and create a symbol - but > want a > > >> > supported solution. > > >> > > > >> > If I use &JOBNAME I get JES2. > > >> > > > >> > Colin > > >> > > > >> > > -- > > >> > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Computers
OK, this is a new one on me. What's DSS? On Tue, Dec 6, 2022 at 6:09 AM Seymour J Metz wrote: > MVS/SE installed on an OS/VS2 base; for R1 it was 3.7 with prerequisite > selectable units and for R2 it was 3.8 with prerequisite selectable units. > In each case a prerequisite SU killed DSS. MVS/SP replaced MVS/SE > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E oddity?
> > SMP/E is a complex tool to manage your z/OS system, but it does the job it > is intended to do. > Indeed so. It's quite complex, but so is the job it's designed to do, and if you understand it, you can maintain your system as it was intended to be maintained. Whenever I hear Linux geeks complain about the complexities of yum or apt or the other package managers, I just smile. -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E oddity?
Well, like I said, this all demands that a sysprog know what the hell he's doing...and clearly I don't. :-) In my defense, it's been 30 years since I wrangled SMP/E... On Wed, Nov 30, 2022 at 9:35 AM Kurt J. Quackenbush wrote: > >> RESTORE does behave the same as APPLY in this respect. > > > RESTORE no longer requires that other maintenance to the involved > elements be ACCEPTed? > > > It can rebuild the load modules using APPLYed-only elements? > > No, no, no, that's not it at all. This discussion was solely about > building load modules from scratch. Both APPLY and RESTORE have this > capability. That is independent of whether RESTORE requires PTFs to be > accepted or must be restored. That processing has not changed. > > Kurt Quackenbush > IBM | z/OS SMP/E and z/OSMF Software Management | ku...@us.ibm.com > > Chuck Norris never uses CHECK when he applies PTFs. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E oddity?
There is no right answer to this one: SMP/E cannot differentiate between this scenario and the one where foo is OK and bar is broken, or where foo has a PE that's relatively benign but bar has an issue that's worse than the problem with foo. The sysprog who's doing this has to know what he's doing. Just like always. On Wed, Nov 30, 2022 at 8:50 AM Seymour J Metz wrote: > Partial restore is a can of worms. What happens if foo has a PE, bar > supersedes the associated APAR, the APPLY only installed foo because bar > had been received and you now restore bar? > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E oddity?
I'd always understood that RESTORE could do this, but it required a lot more work on the part of SMP/E, and the purpose of ACCEPT was to make RESTORE work much faster. Every shop I ever worked at didn't ACCEPT anything (except for those very rare SYSMODs that needed it for sysgen processing) until just before a maintenance cycle and accepted that RESTORE was going to take more work because of it. On Wed, Nov 30, 2022 at 1:12 AM Binyamin Dissen wrote: > On Tue, 29 Nov 2022 20:45:48 + "Kurt J. Quackenbush" > > wrote: > > :>> Yeah, this all makes sense. Basically, the idea of APPLY is to build > the LMOD with everything that's been ACCEPTed or previously APPLYed to it. > :>SMP/E has enough information to reconstruct it from scratch if needed, > but will save itself the work of rebuilding the LMOD from the MODs if it > doesn't have to do it. > > :>> You mention that the MODs are applied from PTFs; I assume that APARs > are also reapplied if not SUPd (which they would be required to be if the > PTF you're working with would clobber them). > > :>Yes, FUNCTIONs, PTFs, APARs, USERMODs, whatever SYSMOD last replaced a > MOD (the MOD's RMID) can be used to obtain a usable copy of that MOD from > the SMPPTS. > > :>> Does the same processing apply to RESTORE? Or does it always build > from scratch? > > :>RESTORE does behave the same as APPLY in this respect. > > RESTORE no longer requires that other maintenance to the involved elements > be > ACCEPTed? > > It can rebuild the load modules using APPLYed-only elements? > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > ---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E oddity?
Yeah, this all makes sense. Basically, the idea of APPLY is to build the LMOD with everything that's been ACCEPTed or previously APPLYed to it. SMP/E has enough information to reconstruct it from scratch if needed, but will save itself the work of rebuilding the LMOD from the MODs if it doesn't have to do it. You mention that the MODs are applied from PTFs; I assume that APARs are also reapplied if not SUPd (which they would be required to be if the PTF you're working with would clobber them). Does the same processing apply to RESTORE? Or does it always build from scratch? On Mon, Nov 28, 2022 at 9:21 AM Kurt J. Quackenbush wrote: > During APPLY processing SMP/E may or may not include the existing load > module when replacing MODs. If the load module does not actually exist in > the target library, or if the LMOD entry has any CALLLIBS subentries, then > the load module is constructed from scratch, including all of the MODs > defined for that LMOD, but not including the existing load module. If the > load module exists in the target library and if the LMOD entry does not > have any CALLLIBS subentries, then the existing load module from the target > library is included, along with the MODs from the PTFs being applied. > > When building a load module from scratch, one or more of the MODs are > replaced/added by PTFs being applied, but SMP/E searches for the other MODs > using the logic documented here: > https://www.ibm.com/docs/en/zos/2.5.0?topic=commands-building-load-modules > Briefly, in this order, SMP/E gets the MODs from the target libraries if > it can find a usable copy, or from the DLIBs if the correct service level > has been accepted, or from PTFs in the SMPPTS. > > Kurt Quackenbush > IBM | z/OS SMP/E and z/OSMF Software Management | ku...@us.ibm.com > > Chuck Norris never uses CHECK when he applies PTFs. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E oddity?
Huh. OK, then I guess it does use the existing LMOD if it's present. But if it's not, it can still deal with the situation. On Sun, Nov 27, 2022 at 7:59 AM Binyamin Dissen wrote: > Nope. > > I always see the existing load module being included after the CSECTs in > the > PTF, but, then again, I have never deleted the load module from the target > library. > > When he reapplied the PTF again, without deleting the load module, it > worked > as expected. > > On Sun, 27 Nov 2022 07:46:19 -0600 Jay Maynard > wrote: > > :>That behavior is what I would have expected: SMP/E builds a target load > :>module during APPLY by including the CSECTs from what's being APPLYed > :>first, then other APPLYed and not accepted PTFs, then the DLIBs. Since > :>there is information on what PTF supersedes what in the SUP statements, > it > :>can proceed this way and produce what you expect. Indeed, I would not > :>expect APPLYing a PTF to use the existing LMOD at all. > > :>On Sun, Nov 27, 2022 at 7:34 AM Binyamin Dissen < > bdis...@dissensoftware.com> > :>wrote: > > :>> I had a workmate delete a load module from a target library before > :>> reapplying > :>> a PTF that only replaced a few CSECTs. > > :>> Strangely enough, instead of the link failing when trying to include > the > :>> original module, it included the CSECTs from the DLIB. > > :>> (1) Is that documented anywhere? > :>> (2) What would have happened if the were unaccepted PTFs? Include from > the > :>> previously APPLYed? > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E oddity?
That behavior is what I would have expected: SMP/E builds a target load module during APPLY by including the CSECTs from what's being APPLYed first, then other APPLYed and not accepted PTFs, then the DLIBs. Since there is information on what PTF supersedes what in the SUP statements, it can proceed this way and produce what you expect. Indeed, I would not expect APPLYing a PTF to use the existing LMOD at all. On Sun, Nov 27, 2022 at 7:34 AM Binyamin Dissen wrote: > I had a workmate delete a load module from a target library before > reapplying > a PTF that only replaced a few CSECTs. > > Strangely enough, instead of the link failing when trying to include the > original module, it included the CSECTs from the DLIB. > > (1) Is that documented anywhere? > (2) What would have happened if the were unaccepted PTFs? Include from the > previously APPLYed? > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage protection keys
On Wed, Nov 23, 2022 at 9:29 AM Paul Gorlinsky wrote: > Engineers always think they can improve upon the works of others. > Sometimes they even succeed. :-) -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage protection keys
Well, you have to store the key *somewhere* when the page is paged out. But you're right, the page table entry isn't it. I don't know what I was thinking. I'm sure that VSM maintains its own table of correspondence between virtual storage addresses and storage key, so the key can be applied to the page upon page-in, but I don't know the details. On Wed, Nov 23, 2022 at 4:12 AM Ian Worthington < 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote: > Many thanks for that Jay. This would certainly seem the logical place to > store it. > > I'm still a bit confused though. The pop section on Page-Table Entries > (page 3-51 in the 13th edition...) does not mention this (though it does > have a unused byte at the end). If the intention is to make the storage > key unaddressable (p 3-9) and alterable only via SSKE (which, given the > need to propagate it to the caches of all processers would seem make sense) > would it not be contraindicated to use this byte to keep it in? > > I'd love to see a paper or article which discusses how this is done, > though, like cpu design, I appreciate it may well change from model to > model. > > > Best wishes > > Ian ... > > On Tuesday, November 22, 2022 at 05:28:37 PM GMT+1, Jay Maynard < > jaymayn...@gmail.com> wrote: > > They are held in the page tables and set in the hardware - in extra memory > that is not software accessible except through a few supervisor-level > instructions such as SSK (set storage key) - when the page is assigned to a > real storage frame. > > On Tue, Nov 22, 2022 at 10:24 AM Ian Worthington < > 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote: > > > I don't think the storage keys (and their friends) are held in the page > > tables though. > > > > > > Best wishes / Mejores deseos / Meilleurs vœux > > > > Ian ... > > > >On Tuesday, November 22, 2022 at 05:04:08 PM GMT+1, Jay Maynard < > > jaymayn...@gmail.com> wrote: > > > > Each page table entry has a byte associated with it that stores the key, > > as > > well as the referenced and changed bits. > > > > And yes, 4K page tables do soak up lots of memory, which is why later > OSes > > use 1M or 2M pages. > > > > On Tue, Nov 22, 2022 at 9:22 AM Ian Worthington < > > 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Does anyone know where the storage protection keys are kept? It seems > > > that the processors maintain recent keys in the TLB to be accessed by > the > > > DAT, but where do they live when they're not in the TLB? Surely we > need > > > one byte per 4k page per address space, which could be quite a bit of > > > storage, so I'm assuming this has to be above the bar now? I can't see > > any > > > information in the pop about this. > > > > > > > > > Best wishes / Mejores deseos / Meilleurs vœux > > > > > > Ian ... > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > > -- > > Jay Maynard > > > > -- > > 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 > > > > > -- > Jay Maynard > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage protection keys
They are held in the page tables and set in the hardware - in extra memory that is not software accessible except through a few supervisor-level instructions such as SSK (set storage key) - when the page is assigned to a real storage frame. On Tue, Nov 22, 2022 at 10:24 AM Ian Worthington < 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote: > I don't think the storage keys (and their friends) are held in the page > tables though. > > > Best wishes / Mejores deseos / Meilleurs vœux > > Ian ... > > On Tuesday, November 22, 2022 at 05:04:08 PM GMT+1, Jay Maynard < > jaymayn...@gmail.com> wrote: > > Each page table entry has a byte associated with it that stores the key, > as > well as the referenced and changed bits. > > And yes, 4K page tables do soak up lots of memory, which is why later OSes > use 1M or 2M pages. > > On Tue, Nov 22, 2022 at 9:22 AM Ian Worthington < > 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote: > > > Does anyone know where the storage protection keys are kept? It seems > > that the processors maintain recent keys in the TLB to be accessed by the > > DAT, but where do they live when they're not in the TLB? Surely we need > > one byte per 4k page per address space, which could be quite a bit of > > storage, so I'm assuming this has to be above the bar now? I can't see > any > > information in the pop about this. > > > > > > Best wishes / Mejores deseos / Meilleurs vœux > > > > Ian ... > > > > ---------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > Jay Maynard > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage protection keys
Each page table entry has a byte associated with it that stores the key, as well as the referenced and changed bits. And yes, 4K page tables do soak up lots of memory, which is why later OSes use 1M or 2M pages. On Tue, Nov 22, 2022 at 9:22 AM Ian Worthington < 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote: > Does anyone know where the storage protection keys are kept? It seems > that the processors maintain recent keys in the TLB to be accessed by the > DAT, but where do they live when they're not in the TLB? Surely we need > one byte per 4k page per address space, which could be quite a bit of > storage, so I'm assuming this has to be above the bar now? I can't see any > information in the pop about this. > > > Best wishes / Mejores deseos / Meilleurs vœux > > Ian ... > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SPF/SE is available for free
Hm. According to the README on the Github site, the source code was stored encrypted...are the encrypted files still in existence? Perhaps they can be obtained and decrypted. It's a long shot, to be sure, but definitely worth a try. On Tue, Nov 1, 2022 at 9:22 AM Michael Knigge wrote: > FYI: > > I guess some of you guys use SPF/SE (SPF SourceEdit) from Command > Technology. The editor was developed by Tim Tetivia, who unfortunately died > in 2022 as a result of a corona infection. With some research and help from > other SPF users (namely Peter aka Verizon), it was possible to contact > Tim's wife Bonnie. She gave us permission to distribute the editor for free > (sadly the source code is “lost” forever). > > On my GitHub (https://github.com/michaelknigge/spf-editor) I made some > releases available, together with product keys. I also provide a > “professional” installer created with InnoSetup that installs SPF/SE > together with some useful macros, file profiles and color schemes (a color > scheme that makes SPF/SE look like ISPF). > > The original releases can be found here: > https://github.com/michaelknigge/spf-editor/tree/main/binaries > > My installers can be found here: > https://github.com/michaelknigge/spf-editor/releases > > > Bye, > Michael > > > > Mit freundlichen Grüßen > > Michael Knigge > Software Engineer > > SET GmbH > Rühmkorffstraße 5 > 30163 Hannover > > Telefon: +49 511 330 998 23 > Fax: +49 511 330 998 65 > michael.kni...@set.de<mailto:michael.kni...@set.de> > https://set.de > Hinweise zum Datenschutz: https://set.de/datenschutz > > Handelsregister: Amtsgericht Hannover HRB 52778 > Geschäftsführer: Dr.-Ing. Tobias Baum, Dr.-Ing. Arthur Brack > > > ------ > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SPF/SE is available for free
Thank you for preserving this and making it available. One question: You say it's picky about fonts...how well does it work with Ricardo Banffy's outstanding 3270 font, available at https://github.com/rbanffy/3270font ? On Tue, Nov 1, 2022 at 9:22 AM Michael Knigge wrote: > FYI: > > I guess some of you guys use SPF/SE (SPF SourceEdit) from Command > Technology. The editor was developed by Tim Tetivia, who unfortunately died > in 2022 as a result of a corona infection. With some research and help from > other SPF users (namely Peter aka Verizon), it was possible to contact > Tim's wife Bonnie. She gave us permission to distribute the editor for free > (sadly the source code is “lost” forever). > > On my GitHub (https://github.com/michaelknigge/spf-editor) I made some > releases available, together with product keys. I also provide a > “professional” installer created with InnoSetup that installs SPF/SE > together with some useful macros, file profiles and color schemes (a color > scheme that makes SPF/SE look like ISPF). > > The original releases can be found here: > https://github.com/michaelknigge/spf-editor/tree/main/binaries > > My installers can be found here: > https://github.com/michaelknigge/spf-editor/releases > > > Bye, > Michael > > > > Mit freundlichen Grüßen > > Michael Knigge > Software Engineer > > SET GmbH > Rühmkorffstraße 5 > 30163 Hannover > > Telefon: +49 511 330 998 23 > Fax: +49 511 330 998 65 > michael.kni...@set.de<mailto:michael.kni...@set.de> > https://set.de > Hinweise zum Datenschutz: https://set.de/datenschutz > > Handelsregister: Amtsgericht Hannover HRB 52778 > Geschäftsführer: Dr.-Ing. Tobias Baum, Dr.-Ing. Arthur Brack > > > ---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A Million Years
Wasn't an official utility, but IPOUPDTE was provided with the CBIPO software delivery to do that job. On Mon, Oct 17, 2022 at 1:25 PM Steve Beaver wrote: > A million years ago the was an IBM Batch Utility to change strings > > In a PDS. > > > > Does anyone remember the name of that utility? > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM python documentation?
n a USS > environment so if you need to “ADDRESS TSO” you need to call a REXX from > Python in USS and do the other work. Its probably not going to happen but > a “System” Python might fill that gap. > >> > >> Matt Hogstrom > >> m...@hogstrom.org > >> > >> “It may be cognitive, but, it ain’t intuitive." > >> — Hogstrom > >> > >>> On Sep 25, 2022, at 11:15 PM, David Crayford > wrote: > >>> > >>> On 26/9/22 10:43, Charles Mills wrote: > >>>>> It's trivial to write an MVS I/O package if you have a C compiler. > >>>> One might ask then why IBM has not done so. > >>> I would suggest that they have not had a requirement. IBM use Python > in their analytics products and for new stuff like Ansible. Same with > golang, they need it for Kubernetes and OpenShift for z/CX containers. I > doubt very much if many customers have tried golang. It's a great language > now it supports generics. As fast as C++ with many advantages. > >>> > >>> > >>>> Charles > >>>> > >>>> -Original Message- > >>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >>>> On Behalf Of David Crayford > >>>> Sent: Sunday, September 25, 2022 6:57 PM > >>>> To: IBM-MAIN@LISTSERV.UA.EDU > >>>> Subject: Re: IBM python documentation? > >>>> > >>>> On 26/9/22 07:34, Farley, Peter x23353 wrote: > >>>>> I know Rocket's port of python has some documented enhancements to > support MVS dataset access among other things, but I have failed to find > any documentation on the IBM websites for an IBM-produced "python > Programmers Guide" (or similar) that would describe and provide examples > for any "IBM-specific" functional enhancements to the base language > facilities. > >>>>> > >>>>> Is there any such documentation? Or are the python.org > >>>>> documentation websites the only reference material available for the > >>>>> IBM port of python? (i.e., no functional enhancements at all are > >>>>> provided in the IBM port) > >>>> Correct! It's trivial to write an MVS I/O package if you have a C > compiler. > >> -- > >> > >> This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > >> > >> > >> -- > >> 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Latin
Romanes eunt domus! On Sun, Sep 18, 2022 at 7:59 PM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > Vade vilis. > > > Sent from Yahoo Mail for iPhone > > > On Sunday, September 18, 2022, 8:43 PM, Tony Harminc > wrote: > > On Sun, 18 Sept 2022 at 19:00, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > I had a class on medical terminology when I worked at a hospital. No need > > to learn Latin. While Latin might make some feel superior, learning > Spanish > > or Chinese would probably be far more useful. Most Americans are > pathetic, > > unilingual speakers, while most of the world is multilingual. Having > > travelled throughout the world, I’m happy most speak English, or I can > > speak English & German. (3 years worth) Also got exposed to some Latin > via > > my foray into the legal profession, albeit a short one. > > > > De minimis non curat lex. > > Tony H. > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Redbook SG24-8205-06 - zPDT Guide
My understanding is that a Wazi user gets no access to the OS system level at all. A Wazi user cannot do any systems modifications, period: no access to system parameters, no ability to alter any specifications, no console access beyond what an application programmer might need. This is all what I have been told, so if I'm incorrect, I'll be happy to be corrected. On Wed, Sep 7, 2022 at 10:49 AM Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > I am curious - why do you say that Wazi is not good for systems programmer > learning? What is restricted there for systems programmers? Are the > images they start with not kept private to your own instance so that any > systems-level changes you make to your private instance persist across > virtual IPL's of that instance? > > I did a minimal amount of research on Wazi and I *sort of* like that the > instances are hosted on "real iron" z hardware, so I presume you get a z/VM > login from which to IPL your z/OS instance. There are good and bad points > there. Assuming it is hosted for "Learners" versions at Dallas RDP, there > are other issues that can come up, like the recent Dallas network outage. > > OTOH, the "aaS" aspect may indicate that they control update of the > system-level images to the point where you cannot update (or automatically > lose updates to) certain system-level features in order to provide "good > service". > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Jay Maynard > Sent: Wednesday, September 7, 2022 11:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM Redbook SG24-8205-06 - zPDT Guide > > That's what I'd heard. > Wazi is great if all you want to do is play with application programming, > but as a systems programmer learning tool, it sucks rocks. > > On Wed, Sep 7, 2022 at 9:58 AM Tom Brennan > wrote: > > > On 9/7/2022 7:18 AM, Farley, Peter x23353 wrote: > > > I was told my application would be "moved into the approval queue" > > > in > > February 2022, but significant numbers of unanswered emails later I > > still do not have a copy. They just stopped responding at all. > > > > > > The FAQ at url > > > https://urldefense.com/v3/__https://www.ibm.com/products/z-development-test-environment/pricing__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!JCU20a5vNTFZsapeX6Gz6vfgNpz4NDcJnXtWQqS0tdzvZcfpJUO2SNYFMP-nqNGsQjIcRCP7-ej-blM2b1bvIOp7$ > now > > says: > > > > > > "Learner's Edition is currently being updated and will return soon." > > > > A couple of months ago I was on a phone meeting with IBMer's for some > > other reason, and the manager of zPDT happened to be on the call. So > > I couldn't help asking about the status. He said it was "on pause" > > (which mirrors that web page text), but he also said the plan at that > > time was to move it to Wazi. > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Redbook SG24-8205-06 - zPDT Guide
That's what I'd heard. Wazi is great if all you want to do is play with application programming, but as a systems programmer learning tool, it sucks rocks. On Wed, Sep 7, 2022 at 9:58 AM Tom Brennan wrote: > On 9/7/2022 7:18 AM, Farley, Peter x23353 wrote: > > I was told my application would be "moved into the approval queue" in > February 2022, but significant numbers of unanswered emails later I still > do not have a copy. They just stopped responding at all. > > > > The FAQ at url > https://www.ibm.com/products/z-development-test-environment/pricing now > says: > > > > "Learner's Edition is currently being updated and will return soon." > > A couple of months ago I was on a phone meeting with IBMer's for some > other reason, and the manager of zPDT happened to be on the call. So I > couldn't help asking about the status. He said it was "on pause" (which > mirrors that web page text), but he also said the plan at that time was > to move it to Wazi. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Redbook SG24-8205-06 - zPDT Guide
I got mine in May. I've been told that IBM has quietly discontinued the program, though. On Tue, Sep 6, 2022, 23:37 Brian Westerman wrote: > Has anyone successfully received the zD&T learners edition setup yet? I > realize this is about zpdt, but it reminded me that I was told that I was > approved last November, but nothing seems to have happened after that time. > > Brian > > > > On Tue, 6 Sep 2022 10:54:26 -0500, Parwez Hamid > wrote: > > >Wanted to make the List aware of the following which some might find > useful - especially those new to zPDT > > > > > >IBM Redbook SG24-8205-06 > > > >IBM ISV zPDT Guide and Reference > > > >https://www.redbooks.ibm.com/redpieces/abstracts/sg248205.html > > > >-- > >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: C compile: INFORMATIONAL CCN4118 **name** C F1:2008 Character constant 'xF0' has more than 1 character.
C provides lots of different ways to shoot yourself in the foot. That's just one. On Thu, Aug 18, 2022 at 11:25 AM Kirk Wolf wrote: > IMO, not a good way. > According to the standard, the integer value of 'ABC' is implementation > dependent. The IBM XLC/C++ Language Reference doesn't document how it > will be treated (padding, alignment, etc) as far as I can see. > > Kirk Wolf > Dovetailed Technologies, LLC > http://coztoolkit.com > Dovetailed Technologies: +1 636.300.0901 > > Note: Our website and domain name have changed from dovetail.com to > coztoolkit.com > > > On Thu, Aug 18, 2022, at 11:13 AM, Charles Mills wrote: > > 'A' is just another way of saying 193. > > > > 'ABC' is just another way of saying 12698307. > > > > Charles > > > > -- > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for old (fake) humorous IBM password memo
Eh...Dilbert is a documentary. That's what makes it so funny. On Wed, Aug 3, 2022 at 10:45 AM Charles Mills wrote: > @Gil, thanks, that's the joke, albeit non in IBM-specific form. Works for > now. > > And yes, of course, I know the xkcd panel. xkcd is amazing: funny, but > also with truly useful tech advice. His "date and time format" cartoon is a > classic. Dilbert can be funny, but seldom contains any actually useful > information. > > Charles > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
